Автоматическое тестирование – проблема с программистами


Инструменты генератора тестов белого ящика могут помочь вам автоматически находить ошибки, генерируя комбинации входных данных, которые могут дать неправильный ответ. Однако возникает проблема – как узнать, что у вас неправильный ответ?

Недавнее исследование Дэвида Хона и Золтана Миккеи из Будапештского технологического и экономического университета ставит автоматическое тестирование в центр внимания.

Инструменты генератора тестов белого ящика полагаются только на тестируемый код для выбора тестовых входов и фиксируют выходные данные реализации в качестве утверждений. Если в реализации есть ошибка, она может быть закодирована в сгенерированных тестах. При оценке инструментов обычно измеряется способность к обнаружению неисправностей с использованием количества таких тестов кодирования неисправностей. Однако эти ошибки обнаруживаются только в том случае, если разработчик может распознать, что закодированное поведение является ошибочным.

Они провели исследование с участием 54 аспирантов и двух проектов с открытым исходным кодом, а также инструмента IntelliTest Tool, который все еще более известен как Pex. Инструмент сгенерировал тестовые примеры, и испытуемых попросили определить, когда выходные данные указывают на неисправность. Результаты были несколько удивительными.

ŒРезультаты показали, что участники неправильно классифицировали большое количество тестов как на кодирование ошибок, так и на правильные (со средним уровнем ошибочной классификации 33% и 25% соответственно). Таким образом, реальная способность генераторов тестов к обнаружению неисправностей может быть намного ниже, чем обычно сообщается, и мы предлагаем принять во внимание этот человеческий фактор при оценке созданных тестов белого ящика.

Вы можете увидеть матрицу путаницы для тестов проекта NBitcoin:

FP = ложноположительный, FN = ложноотрицательный, TP = истинно положительный, TN = истинно отрицательный

Это означает, что на практике тестирование методом белого ящика само по себе подвержено ошибкам программистов. Изучая видео испытуемых, пытающихся интерпретировать тесты, исследователи отмечают, что они, как правило, использовали методы отладки для дальнейшего изучения кода и прояснения смысла теста. Опрос «на выходе» также показывает виды трудностей, которые, по мнению испытуемых, у них были при выполнении задания:

«Решение о правильности теста или неправильности при проверке неопределенного случая, например сравнение с нулем или равенство нулю ».

«Было сложно различить переменные, например, assetMoney, assetMoney1, assetMoney2».

«Тесты должны меньше сравниваться с нулевым значением, а объекты – с самими собой».

«Я думаю, что некоторые утверждения бесполезны и не утверждают« настоящие проблемы », а лишь некоторые технические детали».

«Сгенерированные тестовые примеры не разделяются на Arrange, Act, Assert и должны создавать более частные методы для этих задач».

«Создавайте комментарии к тестам, описывающие, что происходит».

Ключевой вывод:

ŒСмысл результатов состоит в том, что фактические возможности инструментов генератора тестов по устранению неисправностей могут быть намного ниже, чем сообщалось в экспериментах, ориентированных на технологии.

Конечно, было бы лучше, если бы программиста можно было вывести из цикла, но это потребовало бы, чтобы тестировщик белого ящика определил, каким должен быть результат теста, а это потребовало бы большого количества ИИ.


Добавить комментарий