Ответ
Результаты тестирования хранят в специализированных системах, которые обеспечивают анализ, историчность и интеграцию с процессом разработки.
Для автоматических тестов:
-
Allure Report / ReportPortal
- Зачем: Генерация интерактивных отчетов с графиками, историями запусков, логированием и скриншотами.
- Пример интеграции с Maven (Allure):
<plugin> <groupId>io.qameta.allure</groupId> <artifactId>allure-maven</artifactId> <version>2.10.0</version> </plugin> - Хранение: Отчеты генерируются как артефакты в CI/CD (Jenkins, GitLab CI) и могут быть развернуты на отдельном сервере.
-
JUnit/TestNG XML + CI/CD Dashboard
- Результаты в стандартном формате собираются CI-сервером (Jenkins, TeamCity), который строит графики трендов.
Для ручного тестирования и управления тест-кейсами:
- TestRail, Zephyr, Qase
- Зачем: Централизованное хранилище тест-кейсов, планов прогонов и результатов. Позволяет отслеживать покрытие и прогресс.
- Интеграция: Часто интегрируется с Jira для создания баг-репортов прямо из упавшего тест-кейса.
Для ad-hoc тестирования и быстрых проверок:
- Таблицы (Google Sheets, Excel): Подходят для разовых экспериментов, но не для постоянного использования из-за сложности анализа истории.
Важно: Все артефакты (логи, скриншоты, видео) должны быть привязаны к конкретному запуску теста и храниться с определенным TTL (Time to Live).
Ответ 18+ 🔞
А, ну это же классика, блядь! Сидишь такой, тесты написал, они там зелененькие все, и думаешь — ну вот, работа сделана, можно и откинуться. А потом приходит какой-нибудь менеджер с глазами, как у совы на соляре, и такой: «А где, сука, отчёты? Где графики? Где доказательства, что мы не просто так хуй писали?».
Так вот, чтобы не было такого пиздеца, результаты надо не в стол скидывать, а в нормальные системы. И они, блядь, бывают разные, как девки в баре — одни для автоматики, другие для ручных мучений.
Для этих самых автотестов, чтобы не гадать на кофейной гуще:
-
Allure Report или ReportPortal
- Зачем, блядь? Ну чтобы не просто «упал/прошёл», а целую историю с графиками, скриншотами и логами, которые можно тыкать пальцем. Красиво, наглядно, начальство пускает слюни. ReportPortal — это вообще ёперный театр, целая панель управления, как в NASA.
- Как прикрутить, например, через Maven (Allure):
<plugin> <groupId>io.qameta.allure</groupId> <artifactId>allure-maven</artifactId> <version>2.10.0</version> </plugin> - Где это всё живёт? Генерируешь отчёт как артефакт в своей CI-пайплайне (Jenkins, GitLab CI — неважно) и можешь его на отдельный сервак залить, чтобы все любовались.
-
Старые добрые XML от JUnit/TestNG + дашборд CI/CD
- Твоя CI-система (Jenkins, TeamCity) жрёт эти XML-файлы, как кот сметану, и сама строит графики: сколько прошло, сколько сломалось, как со временем меняется. Просто, дешево, сердито.
А для ручного тестирования, где надо мозги включать, а не скрипты:
- TestRail, Zephyr, Qase
- Зачем? Это, блядь, чтобы не хранить тест-кейсы в голове или в тысяче txt-файлов на рабочем столе. Всё централизованно: кейсы, планы прогонов, результаты. Видно, что протестировали, а что нет. Часто цепляются к Jira, чтобы баг-репорт одним кликом из упавшего кейса создать — удобно, ёпта!
Ну и для разовых «а давайте попробуем вот эту хуйню»:
- Гугл-таблицы или Excel. Быстро, всем знакомо. Но это, блядь, как одноразовая зажигалка — для сиюминутной задачи сойдёт, а для постоянной работы — пиздец и бардак, историю не отследить, анализировать овердохуища времени надо.
И главное, запомни раз и нахуй: все эти логи, скриншоты и видео падений должны быть жёстко привязаны к конкретному запуску и не валяться вечно. Надо задавать им срок годности (TTL), а то сервер превратится в цифровое помойное ведро, ядрёна вошь!