Comments 9
Немного непонятно о чем статья. А JUnit чем не угодил? Тестируйте класс за классом
JUnit и другие фреймворки модульного тестирования – это тесты написанные вручную. Статья о современных попытках переложить часть этой важной, но рутинной процедуры на автоматические средства. Ко всему, давайте не будем забывать о разнице в покрытии строк кода и всех путей в программе. Вручную практически нереально написать такое астрономическое количество тестов которые бы покрывали всевозможные пути в программе. А только такой набор тестов может гарантировать отсутствие ошибок.
Но, да согласен, что без практических примеров не сразу понятно о чем идет речь. Примеры использования программ я решил перенести в следующую часть, иначе статья оказалась бы слишком большой.
Но, да согласен, что без практических примеров не сразу понятно о чем идет речь. Примеры использования программ я решил перенести в следующую часть, иначе статья оказалась бы слишком большой.
Дмитрий, Вы занимаетесь разработкой динамического анализатора?
>> Безусловно, динамический анализ найдет свою нишу среди
Поясните, что значит «найдет» нишу, если уже есть и активно используются динамические анализаторы?
>> Безусловно, динамический анализ найдет свою нишу среди
Поясните, что значит «найдет» нишу, если уже есть и активно используются динамические анализаторы?
Нет, я не занимаю разработкой динамических анализаторов.
Я всего лишь пытаюсь применить данные инструменты для решения задачи эффективного повышения качества кода и снижения трудозатрат тестирования.
Говоря о динамическом анализе, я имел ввиду относительно новый подход к анализу программ, представленный в этой статье.
Я всего лишь пытаюсь применить данные инструменты для решения задачи эффективного повышения качества кода и снижения трудозатрат тестирования.
Говоря о динамическом анализе, я имел ввиду относительно новый подход к анализу программ, представленный в этой статье.
>> Я всего лишь пытаюсь применить данные инструменты для решения задачи эффективного повышения качества кода и снижения трудозатрат тестирования.
А со статическими анализаторами у Вас опыт работы есть?
Платформа только Unix интересует?
А со статическими анализаторами у Вас опыт работы есть?
Платформа только Unix интересует?
>А со статическими анализаторами у Вас опыт работы есть?
Из статических анализаторов у меня есть опыт работы с flexelint и проприетарными статическим анализатором.
>Платформа только Unix интересует?
Да, меня интересует только Unix интересует, если быть точнее то Android платформа.
Я бы хотел уточнить, что данное направление меня интересует скорее с R&D точки зрения.
Из статических анализаторов у меня есть опыт работы с flexelint и проприетарными статическим анализатором.
>Платформа только Unix интересует?
Да, меня интересует только Unix интересует, если быть точнее то Android платформа.
Я бы хотел уточнить, что данное направление меня интересует скорее с R&D точки зрения.
По опыту применения РД НДВ для сертификационных исследований знаю, что добиться значительного покрытия кода трассами динамического анализа очень трудно.
Хороший результат для «ручных прогонов» со средним уровнем усилий — 30-50 %.
Кроме того, РД НДВ не содержит никаких (!) требований к тому, ЧТО нужно искать в динамике.
Создаётся глупая ситуация — покрытие ради самого покрытия.
Сертификация (по сложившейся традиции) — самый последний перед сдачей софта Заказчику этап.
На доработки по найденным дефектам уже нет времени (да и денег, кстати). Ошибки искать уже поздно.
Поэтому самый правильный вариант — начинать испытания (и динамический анализ в том числе) — как можно раньше. Тогда и дефекты можно исправить оперативно.
Единственное препятствие — продукта как такового может ещё не быть на ранних этапах разработки.
Хорошим выходом была бы интеграция автоматизированного динамического анализа в nightly-сборки и вообще в жизненный цикл автоматизированного тестирования.
Но большая доля ручного труда даже с использованием инструментов, описанных в статье, оставляет мало надежды на скорое изменение ситуации с эффективностью динамического анализа.
Для малых проектов внедрить автоматический динамический анализ будет не очень трудно.
Но хотелось бы услышать (если такой опыт есть) о внедрении описанных инструментов в большие проекты.
Как распределяются трудозатраты на внедрение во времени?
Стоит ли овечка выделки?
Можно ли повторно использовать полученные на одном проекте «артефакты внедрения» в других проектах?
Хороший результат для «ручных прогонов» со средним уровнем усилий — 30-50 %.
Кроме того, РД НДВ не содержит никаких (!) требований к тому, ЧТО нужно искать в динамике.
Создаётся глупая ситуация — покрытие ради самого покрытия.
Сертификация (по сложившейся традиции) — самый последний перед сдачей софта Заказчику этап.
На доработки по найденным дефектам уже нет времени (да и денег, кстати). Ошибки искать уже поздно.
Поэтому самый правильный вариант — начинать испытания (и динамический анализ в том числе) — как можно раньше. Тогда и дефекты можно исправить оперативно.
Единственное препятствие — продукта как такового может ещё не быть на ранних этапах разработки.
Хорошим выходом была бы интеграция автоматизированного динамического анализа в nightly-сборки и вообще в жизненный цикл автоматизированного тестирования.
Но большая доля ручного труда даже с использованием инструментов, описанных в статье, оставляет мало надежды на скорое изменение ситуации с эффективностью динамического анализа.
Для малых проектов внедрить автоматический динамический анализ будет не очень трудно.
Но хотелось бы услышать (если такой опыт есть) о внедрении описанных инструментов в большие проекты.
Как распределяются трудозатраты на внедрение во времени?
Стоит ли овечка выделки?
Можно ли повторно использовать полученные на одном проекте «артефакты внедрения» в других проектах?
Sign up to leave a comment.
Автоматическое тестирование программ