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

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

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

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

Внешний вид

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

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

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

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

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

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

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

4 лайка

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

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

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

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

http://allure.qatools.ru/



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

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

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

5 лайков

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

  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 лайков

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

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

2 лайка

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

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

1 лайк

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

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

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

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

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

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

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

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

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

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

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

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

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

@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 лайк

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

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

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

3 лайка