0

Я работаю над существующим веб-приложением (написанным на .NET), которое, к удивлению, содержит несколько ошибок. Мы отслеживаем выдающиеся результаты в трекере ошибок (JIRA, в данном случае), и уже есть несколько тестовых библиотек (написанных в NUnit).Как связать тесты с регрессионным модулем с отслеживателем проблем?

То, что я хотел бы иметь, заключается в закрытии проблемы, чтобы связать эту проблему с тестом unit/интеграция, который гарантирует, что регрессия не произойдет, и я хотел бы быть способный максимально информировать эту информацию.

Есть несколько вещей, которые я могу вспомнить с рук, которые могут быть использованы в различных комбинациях, в зависимости от того, как далеко я хочу пойти:

  • скопировать URL выпуска и вставить его как комментарий в тестовом коде;
  • добавить атрибут категории к тесту и назвать его регрессиями, чтобы я мог явно выбирать регрессионные тесты и запускать их как группу (но как автоматически сообщать, какие проблемы не прошли регрессионное тестирование?);
  • сделать номер проблемы частью названия тестового примера;
  • создать настраиваемый атрибут регрессии, который принимает URI проблемы как обязательный параметр;
  • создать новое настраиваемое поле в трекер-проблеме для хранения имени (или пути) теста (ов) регрессии;

Идеальный сценарий для меня заключается в том, что я могу посмотреть на трекер проблемы и посмотреть, какие проблемы были закрыты с помощью регрессионных тестов (золотая звезда для этого разработчика!) И посмотреть отчеты об испытаниях и посмотрите, какие проблемы не проходят регрессионные тесты.

Неужели кто-нибудь встретил или придумал хорошее решение?

ответ

0

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

Если мы хотим увидеть, какие тесты были добавлены по конкретным вопросам, мы отправляемся в систему отслеживания проблем. есть все коммиты, в идеале только один (спасибо раздавить), трекер треков связан с git, поэтому мы можем легко просматривать измененные файлы

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

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

Смежные вопросы