К теме...
Помимо продуктов заявленных разработчиком как "анализаторы кода" для целей отчета по коду (списки классов и методов, дерево вызовов и пр.) можно пытаться использовать продукты позиционируемые как "генераторы хелпов и руководств".
Таких немало, хороший список нашел вот здесь:
http://www.stack.nl/...ygen/links.html
и вот здесь:
http://www.helpmaster.de/

Для себя выделил Doc-O-Matic. Так как поддерживает большинство языков и обширно настраивается выходной формат. Недостатком для себя выделил ненастраиваемый парсинг кода.

В Вашем списке (http://tester.com.ua...yzing_tools.htm) только специализированные (под конкретный язык) анализаторы, есть ли в природе универсальный, или настраиваемый пользователем?

2 Олешка
Так оно так и получится - смотришь по списку изменений и заглядываешь в связанные компоненты и чешешь репу - "проверить надо бы". С одной стороны есть список изменений в компонентах, а с другой стороны в связанных компонентах тоже не все тесты проводить надо, а только некоторые. Вот и пытаешся по характеру изменения и по характеру связи с измененной компоненте прикинуть какие тесты желательно провести...
....А по сути просьбы есть что-нибудь?

Добрый день.

2 Олешка
Конечно, список измененных компонент и список компонент, связанных с измененными, это лишь первый шаг. Следующий шаг - провести анализ "подозрительной" части кода (пальчиками по экрану:-), но не всего, а только в связанных компонентах . Затем на основании личных сомнений тестировщика надо сформировать список тестов. В него войдут приемочные тесты измененных компонент (скорее всего их источник менеджер или заказчик) и регриссионные тесты связанных компонент (это именно их составил тестировщик, анализируя код)

2 SALar
Приемочный тест - это неминуемое явление, о нем и рассуждать нечего. Другое дело "минорные" баги (это общий термин или Ваша собственность?) - не видимые в основном функционале (и в приемочном тесте тоже), но заявляющие о себе в самый неприятный момент. Глупо ждать наступления инцидента у заказчика (на примере того же резервного копирования), желательно провести упреждающую атаку на баг. Понимаю, что идеальный вариант это объемный набор тестов, но все вынужденны сокращать его. Я пытаюсь сузить их список опираясь на автоматизированный анализ кода.

2 Все.
И все-таки, есть ли у кого опыт работы с анализаторами кода? Не могли бы Вы что-либо посоветовать?

Приветствую участников,
надеюсь пополнить список постоянных посетителей форума...
После исправления багов и довеска новых фич неизменно возникает вопрос - где и что "потрогать" на предмет "не отвалилось ли". Речь идет о проверки работоспособности старого функционала. (кажется все присутствующие здесь называют это "регрессионным тестом"). Наверное, есть какая-то теория для этого случая, но я пока подхожу по-сермяжному - для исправленного компонента надо посмотреть на все вызовы, все линки и пр. relations. В моем мозгу появляется идея - найти анализатор кода который быстренько сканирует сорсы и говорит, что и откуда вызывается и создает какой-нибудь удобоваримый отчет. Что-нибудь посоветуете?