Отчет по тестовому прогону автоматических тестов. Внешний вид HTML отчета. Как выглядит ваш отчет?!

общие вопросы
, ,
#1

Кастомный html отчет

Тут я недавно реализовывал небольшой кастомный html отчет по пройденным автоматическим тестам с небольшим набором функциональности:

  1. Скрывающиеся сьюты, тесты и степы для тестов по клику
  2. Статистика по выполнению тестов с временем прогона
  3. Скрытие ненужной информации по фильтрам (меню в шапке)
  4. Отображение только фейлов, или только пройденных тестов или игнорируемых тестов через фильтры
  5. Сокращение\увеличение детализированности об стектрейсе при фейле, чтобы информацию более удобно помещалась на страницу и быстро и наглядно просматривать
  6. Применение комбинированных фильтров из пункта 3, 4 и 5 совместно (т.е. например показывать только фейлы с сокращенной информацией об ошибке и стек трейсе )
  7. При нажатии на стектрейс вываливается дополнительная информация без перезагрузки страницы
  8. Навигация по фейлам через клавиатуру для быстрого анализа результатов, space и enter прокручивание к следующему фейлу, backspace прокручивание к предыдущему фейлу
  9. Прямые ссылки на логи и сорцы теста, чтобы можно было просмотреть все без отвлечения от отчета
  10. При загрузке все зафейлинные тесты разворачиваются, а все остальное скрывается, чтобы сфокусироваться только на фейлах с первого же просмотра отчета.

Внешний вид

В общем HTML отчет выглядит так:

Сейчас еще в реализации

  1. Автоматическое распознавание и категоризация фейлов по критерием, тегам и системам с статистикой в шапке и соответствующей фильтрацией

Что меня интересует

Меня просто интересует мнение и общее впечатление по отчету, а также чего не хватает такому отчету?

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

Если у вас какие-то стандартные отчеты, то хотя бы напишите их названия или откуда вы их взяли и какие-то ссылки на сорцы или github.

4 лайка
Как настроить ReportNG для вашего проекта с помощью Java, TestNG, Velocity и IntelliJ IDEA
Mustache template engine или как создавать кастомные репорты. Part 2
#2

Интересно, кстати, что этот вопрос с логами тесто-прогона для UI тестов так стандартно и не решен.
Для юнит-тестов – да. Все конвертируют в JUnit формат и отображают на TeamCity / Jenkins. И той информации вполне хватает для анализа результатов прогона для юнит-тестов.

Для UI… тут все сложнее. Ведь нет привязки к коду приложения и необходимы скриншоты или видео или логи приложения отдельно.

На прошлом проекте, я написал парсер для логов MSTest, в котором в середине так же обрабатывался markdown. Следовательно, можно было использовать базовое форматирование текста и вставлять картинки в середину лога. Выглядело приблизительно так.

Я знаю, что ребята из Яндекса сейчас делают некоторое универсальное решение

http://allure.qatools.ru/



Но, мне не понравилось в нем…

  • то, что я его так и не смог скомпилировать из исходников под Windows
  • Если JUnit / TestNG поддерживается из коробки, то для .NET-товских инструментов, пока непонятно как, нужно будет писать свой парсер преобразовывающий результаты в формат JUnit xml

Хотя, видел позитивный отзыв по этому инструменту

5 лайков
#3

В ответ на вопрос, чего не хватает, могу лишь сказать, что все зависит от того, на кого ориентирован отчет:

  1. тим автоматизаторов;
  2. весь тим, работающий с проектом, включая продакт оунеров;
  3. менеджмент и высшее руководство.

В первом случае вообще достаточно одного стек-трейса, ведь свой код автоматизаторы наизусть знают.

В последних двух случаях, как правило, всем до задницы наш стек-трейс, никто в код заглядывать и не подумает. Чем выше уровень publicity, тем больший упор идет на всякие красивости, логику, здравый смысл и т.п. Да, метрики очень важны, но о чем девелоперам / мануальщикам / менеджменту скажет строка - test01 failed? Да ровным счетом ни о чем. И никто не будет лазить по коду в поисках шагов воспроизведения.

Я покажу пример своего репорта. Конечно в нем еще много чего не хватает, но возможно кто-то для себя что-то полезное извлечет.

Морда выглядит следующим образом (некоторые вещи замазал ввиду конфиденциальности):

Ну и внутренности:

В случае фейла:

Из фишек:

  1. В случае запуска из Jenkins, подхватывается тайтл джобы.
  2. На морде слева (см. первый скрин) список testng сьютов, обозванных по имени / версии браузера (берется из testng xml).
  3. Каждый сьют кликабелен и перемещает нас к детальному отчету (см. второй скрин).
  4. Помимо всего прочего, морда содержит даты запуска / завершения, длительность, результаты и pass rate.
  5. Сверху можно еще найти информацию об экзекьюторе (юзер / доменное имя тачки, с которой были запущены тесты) + конфиг ее системы.
  6. Из центральной части морды также можно перебраться на детализированный отчет по сьюту.
  7. Внутренности содержат в шапке инфу о ноде (ip:port / domain name), на котором был заэкзекьючен сьют + конфигурация (ОС / браузер / версия).
  8. Центральная часть содержит список всех тестов, разбитых на passed / failed + группировка по классам. Ну и базовая инфа: имя / длительность / степы с тестовыми данными пришедшими в качестве аргументов.
  9. Опциональный линк на HarStorage с инфой по реквестам / респонсам теста.
  10. Опциональный линк на видеозапись теста.
  11. Список верификейшенов (выдранных из софт ассертов). При этом, каждый верификейшен содержит линк на релевантную стори в Jira.
  12. Скрин последнего дыхания теста.
  13. В случае фейла под скрином еще будет раскрывающийся линк со стек стрейсом + ID зафейлившихся верификейшенов.

По опыту последних двух проектов скажу, что “забугорный” менеджмент очень требователен к репортам. Им нужен visibility, чтобы они понимали, за что платят. Чтобы верили, что их не дурят запуском пустых тестов. Хотя репорт тоже можно зафотошопить. Но если все происходит в динамике, via Jenkins, то обмануть вряд ли кого-то получится. А ввиду того, что с течением времени им становится скучно смотреть на тесты во время демо, приходится подкармливать их всякими новыми фишками в репортах. И на удивление, они прям писяются от счастья.

П.С. Репорт создавался на базе всем известного reportng. Присоединюсь к вопросу о предложениях / пожеланиях. Все равно скоро нужна будет новая порция фишек для демо. :smile:

UPDATE: добавил скрин фейла с информацией о не прошедшем верификацию ID + эксепшен, вылетевший после. Т.е. вначале будет печататься список id, затем анэкспектед эксепшен (все, что вылетает, и не является AssertionError).

7 лайков
#4

Соглашусь с тем мнением, что менеджерам нужны свои отчёты, тестировщикам - свои, заказчикам - свои.
В итоге я для себя решил: каждому по отчёту. Главное - меньше ручных действий для тестировщика, больше интеграций.

  1. Для тестировщиков у нас вполне пригодным является стандартный отчёт “робота” (Robot Framework) + интеграция с jenkins\bamboo
  2. Если хочется большего: для робота написан расширенный логгер
  3. Для менеджеров, начальства и заказчиков: сделан листенер записи результатов в TestMenegement систему: у меня больше не болит голова за выборки, крисивые диаграммы, динамику тестов и пр. менеджерские штуки
  4. Отчёты по performance тестам: отдельный комплекс библиотек со своими графопостроителями ибо это совсем другой уровень отчётов
  5. Для исторических трендов - интеграция и запись результатов в БД

2 лайка
#5

Возможно, я не увидел, но мне кажется, что нехватает такой фичи: все failed тесты должны группироваться\быть в списке первыми и сразу перед глазами, листать длинный отчёт сотен тестов в поисках той самой ошибки утомительно.

#6

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

1 лайк
#7

Я также реализовывал следующее, что оказалось весьма полезным:

  • интеграция с Bug-трекинг системами (JIRA, Mingle)

  • “Падающие” тесты заранее помечаются тегами с номером дефекта, а при генерации отчета эти теги превращаются в ссылки с соотвествующими номером, названием и текущим статусом. Таким образом можно удобно отслеживать состояние дефектов при регулярных прогонах — например, если тест отмечен незакрытым дефектом, но при этом проходит.

  • группировка тестов, упавших с одинаковыми сообщениями об ошибке

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

Использовался JUnit + JBehave + bash-скрипт на Jenkins.

P.S. За тему спасибо! Очень полезно и интересно посмотреть и почитать. =)

#8

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

#9

У нас вся статистика выполнения уходит в TeamCity и TestRail. Весь репортинг получается из коробки от этих тулов, которые и так используются. Свои HTML-ки рисовать не нужно по итогу.

#10

@anym0us @Igor коллеги а можете вставить с свои посты по пару основных скриншотов (даже если они стандартные, чтобы уже было более одинаково с остальными ответами в этой теме), где вы смотрите отчеты, чтобы другие, когда будут просматривать тему просто визуально увидели как ваши отчеты выглядят. Заранее спасибо

#11

Для всех падений генерировался дополнительный репорт. Группировалось по всему тексту сообщения с ошибкой. Плюс можно было сортировать по этому полю. Этого было достаточно.

#12

Вот это интересно) не подскажете, как? тоже его используем

#13

@Igor кстати, в помощь @uslashka и другим, может быть ты напишешь небольшой code recipe по этому поводу?

#14

@uslashka, @polusok
C TestRail’ом особо нечего добавить кроме этой ссылки: http://docs.gurock.com/testrail-api2/start
Там всё есть, чтобы добавлять через эту апишечку результаты автотестов.

Во внутренней разработке есть плагин для nose’a, который аплоадит результаты nose-тестов через эту апишечку сам. Попробую поговорить с парнями, чтобы этот плагинчик выложить в open-source.

По поводу же скриншотов, тут я ничего сильно не выложу. Обычные скриншоты TestRail’a и TeamCity… TestRail – Orchestrate Testing. Elevate Quality., TeamCity: the Hassle-Free CI/CD Tool by JetBrains - тут картинок хватает, как оно всё выглядит.

1 лайк
#15

Ого, спасибо, буду внедрять)

#16

Глядя на те проекты, которые я делал, пришёл к выводу, что наилучший отчёт для автотестов - это тот, к которому привыкли.
Меньше объяснять, меньше проблем с внедрением автотестов потом, проще людям на результаты смотреть.

Смотрим на то, в каком виде репортают ручные тесты и делаем то же самое в автоматических. Привыкли к Quality Center - складируйте результаты автотестов туда, TestRail - аналогично. Если привыкли к excel-ке с 5-ю красно-зелёными колонками, то лучше потратить полдня и нарисовать такую же, чем потом неделю объяснять всем, как смотреть результаты в какой-нибудь модном ajax-интерфейсе в браузере, который может быть и красивый-модный, но воспринимается как непривычный и чужеродный.

3 лайка