Неудачные автоматические тесты: как отличить известные и вновь появившиеся ошибки?

Question

Вариант использования: Fitnesse используется для автоматизированного тестирования веб-сайта.

SUT (тестируемое программное обеспечение) содержит известную ошибку.Скажем, мы ожидаем, что веб-страница содержит строку «Изменения успешно сохранены», но эта строка отсутствует из-за ошибки.Таким образом, в Fitnesse этот контрольный пример помечается как красный.

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

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

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

Или я не могу выполнить тестовый пример с известной ошибкой.

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

Но все это очень неудобно.Я хочу различать два вида ошибок (хорошо известная ошибка и новая ошибка) так, чтобы:

1. Глядя на результаты теста, я мог легко сказать: это новая ошибкаа те старые.Например: Нет ошибок - зеленый, Уже известные ошибки - желтый, Новые ошибки - красный.

2. Легко изменить тестовый случай, когда ошибка исправлена.

Каковы наилучшие стратегии приемочных испытаний в целом и фитнеса в частности?

Answer 1

Здесь есть тонкое различие: вы говорите о отслеживании состояния теста, а не только о том, является ли это известной ошибкой.Хорошие CI-системы могут помочь вам отслеживать состояние теста с помощью истории и сообщать, когда он меняет состояние.(Прошло вчера, сегодня выходит из строя.) Хорошие системы CI также могут устранять ложные сбои, чтобы они не запачкали вашу историю.(Я имею в виду именно Team City, в которой я это сделал.)

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

Answer 2

Когда мы регистрируем подтвержденную ошибку, мы добавляем #warning к ошибочному выражению в исходном коде теста, чтобы указать номер ошибки и (очень) краткое описание ошибочного поведения. Если мы не ожидаем, что ошибка будет исправлена ​​в ближайшее время (, например, , в течение нескольких дней), мы поместим тест в группу тестов, которые, как ожидается, не пройдут. Мы периодически проверяем историю этих тестов, чтобы убедиться в том, что они не разработали новые режимы сбоев, и выводим их из карантина после исправления ошибки.

Как говорит Джим Холмс, хорошая система CI (мы также используем JetCrains TeamCity) будет поддерживать историю таким образом, чтобы облегчить этот вид анализа после смерти .

Answer 3

Это на самом деле несколько вопросов.Я собираюсь сосредоточиться на том, что я считаю хорошей практикой для выполнения тестов FitNesse.

Я предлагаю вам запускать свои тесты в системе CI, такой как Hudson.Системы CI хорошо отслеживают, что происходит от запуска к запуску.

Для этого вам понадобятся результаты в формате, который может отслеживать Хадсон.Вы можете использовать XSL для преобразования результатов прогонов FitNesse Suite в отчеты в стиле Junit, а затем использовать способность Хадсона отслеживать результаты Junit.Это дает вам тренды и графики.Это также позволяет увидеть возраст любого отказа.Вот мой способ сделать это: http://whotestedthis.squarespace.com/journal/2012/1/26/transforming-fitnesse-results-to-junit.html

Answer 4

Насколько я знаю, не существует простого способа отличить «новую» ошибку от ожидаемой, кроме как иметь список известных проблем под рукой. Если вы используете соглашение об именах, в котором вы можете быстро перечислить тесты, о которых известно, что они не пройдут, тогда вы можете быстро выполнить сканирование, в котором ошибок нет в этом списке - I.E. это новые ошибки, на которые нужно посмотреть.