Тестовый прогон

Тестовый прогон (test run) - однократное выполнение выбранного набора тест-кейсов на определённой версии продукта в определённом окружении. Прогон фиксирует, что тестировалось, где, когда и кем, и содержит по одному результату на каждый включённый в него тест-кейс. В прогонах система управления тестированием записывает выполнение тестов - и ручных, и автоматизированных.

Термин пришёл из практики, а не из стандарта. Глоссарий ISTQB использует его в определении набора тестов: совокупность тестовых сценариев или тестовых процедур, которые выполняются в определённом тестовом прогоне. Стандарт ISO/IEC/IEEE 29119-3 (документация тестирования, текущая редакция 2021 года) не определяет документа «тестовый прогон». Он описывает записи, которые прогон создаёт: фактические результаты и результаты тестов, журнал выполнения тестов, отчёты об инцидентах, а поверх них - отчёт о состоянии тестирования и отчёт о завершении тестирования.

Зачем нужен тестовый прогон

Тест-кейс описывает проверку. Он не говорит, выполнялась ли проверка на текущей сборке и чем она закончилась. Один и тот же тест-кейс выполняют много раз: на каждом кандидате в релиз, в нескольких браузерах, после каждого исправления. Каждое выполнение происходит в контексте: версия продукта, окружение, дата, исполнитель.

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

• какие тест-кейсы выполнены на сборке 2.4.1, а какие нет;
• сколько из них прошло, не прошло или не могло быть выполнено;
• новые ли это сбои или они были и на предыдущей сборке;
• выполнены ли критерии выхода уровня тестирования.

Базовые понятия системы управления тестированием (тест-кейс, набор, прогон, результат) введены в статье Что такое система управления тестированием.

Состав тестового прогона

Выбор тест-кейсов

В прогон входят тест-кейсы, нужные для его цели. Обычные способы их выбрать:

• целый набор тестов или несколько наборов, например все тесты оформления заказа;
• фильтр по атрибутам: все актуальные тест-кейсы с приоритетом «Высокий» для компонента «Оплата»;
• регрессионное подмножество - фиксированный список тест-кейсов, который выполняется в каждом релизе;
• тест-кейсы, которые затрагивает изменение, выбранные по связям с изменёнными требованиями;
• тест-кейсы, не прошедшие в предыдущем прогоне, - для повторного тестирования.

При создании прогона его список тест-кейсов фиксируется. Тест-кейсы, добавленные в набор позже, в существующем прогоне не появляются. Так прогон остаётся сопоставимым со своим планом: число запланированных выполнений не меняется во время работы.

Тестируемая версия

Прогон ссылается на определённую версию продукта: номер сборки, релиз, коммит. Без неё результаты нельзя интерпретировать. Непройденный результат на сборке 2.4.0 и пройденный на сборке 2.4.1 описывают исправление. Те же результаты без версий не описывают ничего.

Тестовое окружение

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

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

Run "Release 2.4.1, regression"
 |
 +-- TC-12 "Pay with a saved card"
 |     +-- Windows 11, Chrome 141   -> passed
 |     +-- macOS 15, Safari 26      -> failed
 |     +-- Android 16, app          -> passed
 |
 +-- TC-13 "Pay with an expired card"
       +-- Windows 11, Chrome 141   -> passed
       +-- macOS 15, Safari 26      -> passed
       +-- Android 16, app          -> blocked

В обоих случаях результат относится ровно к одному окружению. Результат «пройден» без окружения не говорит, где поведение проверено.

Исполнители и сроки

Прогон ручных тестов распределяют между тестировщиками: у каждого тест-кейса или группы тест-кейсов есть исполнитель. У прогона есть плановое начало и окончание, часто привязанные к вехе или дате релиза. Автоматизированные прогоны запускает система CI, и исполнителей у них нет - есть источник: конвейер и задача, которые получили результаты.

Статусы результатов

Статус результата говорит, что произошло с одним тест-кейсом в одном прогоне. В ISO/IEC/IEEE 29119 результат теста сводится к двум значениям: тест-кейс пройден или не пройден. Системы управления тестированием используют более широкий набор, потому что не каждый запланированный тест-кейс доходит до вердикта. Стандарты этот набор не фиксируют. Типичный вариант:

«Не пройден» и «заблокирован» - разные статусы не случайно. Непройденный тест-кейс проверил поведение и нашёл отклонение. Заблокированный не проверил ничего. Глоссарий ISTQB описывает заблокированный тест-кейс как тест-кейс, который нельзя выполнить, потому что не выполнены предусловия для его выполнения. Если заблокированные результаты считать непройденными, отчёт показывает дефекты там, где не хватает информации.

У результатов автотестов свои статусы. В формате JUnit XML тест-кейс без элемента результата считается пройденным, failure означает непройденную проверку, error - непредвиденную проблему при выполнении, skipped - тест, который не выполнялся. При импорте результатов эти статусы сопоставляются со статусами системы:

Выполнение прогона

При выполнении тестировщик проходит шаги каждого тест-кейса и записывает результат. В результате есть не только статус:

• фактический результат (actual result): что наблюдалось, особенно если это отличается от ожидаемого;
• вложения: снимки экрана, записи экрана, журналы, файлы, которые показывают наблюдаемое поведение;
• затраченное время и исполнитель;
• для непройденного результата - ссылка на дефект.

Аномалию - расхождение фактического и ожидаемого результата - анализируют до того, как завести отчёт о дефекте. Силлабус ISTQB Foundation Level (версия 4.0.1) отмечает, что зарегистрированная аномалия может оказаться настоящим дефектом, ложным срабатыванием или запросом на изменение. Ложное срабатывание часто вызвано ошибкой в самом тест-кейсе или проблемой окружения. Структура отчёта о дефекте описана в статье Отчёт о дефекте.

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

Повторное и регрессионное тестирование

После исправления дефектов следуют два вида тестирования. Силлабус ISTQB их разделяет.

Подтверждающее тестирование (confirmation testing), его также называют повторным тестированием (retesting), подтверждает, что исходный дефект исправлен. Оно снова выполняет тест-кейсы, которые не прошли из-за дефекта, на сборке с исправлением. В зависимости от риска для проверки исправления могут добавить новые тест-кейсы.

Регрессионное тестирование (regression testing) подтверждает, что изменение, в том числе исправление, не вызвало нежелательных последствий в других частях продукта. Оно выполняет тест-кейсы, которые проходили раньше и которые изменение может затронуть. Его объём определяют с помощью анализа влияния (impact analysis) - определения рабочих продуктов, которые затрагивает изменение. Связи требований, тест-кейсов и кода, на которые опирается анализ влияния, описаны в статье Трассируемость и покрытие требований.

В системе управления тестированием оба вида тестирования - новые прогоны на новой сборке:

Run A: "Release 2.4.0"            TC-12 failed  -> BUG-310
                                   TC-40 passed
                                   TC-41 passed
Fix of BUG-310 in build 2.4.1
Run B: "Retest BUG-310, 2.4.1"    TC-12 passed  (confirmation testing)
Run C: "Regression, 2.4.1"        TC-40 passed  (regression testing)
                                   TC-41 failed  -> BUG-325

Регрессионные наборы выполняются много раз и меняются медленно. Они - первые кандидаты на автоматизацию. Автоматизированные регрессионные прогоны в CI описаны в статье Автотесты в CI.

Итоги прогона

Итоги прогона вычисляются из его результатов. Они показывают число результатов в каждом статусе, долю выполненных тест-кейсов и долю пройденных. Для прогона из 200 запланированных тест-кейсов:

Из этих чисел: до вердикта дошли 176 тест-кейсов, 162 пройдены и 14 не пройдены. Заблокированные, пропущенные и невыполненные тест-кейсы не выполнялись. 176 из 200 - это 88 процентов прогона. Из 176 тест-кейсов с вердиктом прошли 162, это 92 процента. Тот же прогон можно описать как «пройдено 81 процент» (162 из 200) или «пройдено 92 процента» (162 из 176) - в зависимости от знаменателя. Отчёт указывает, какой знаменатель он использует. Как считаются такие метрики и где они вводят в заблуждение, описано в статье Метрики тестирования.

Силлабус ISTQB различает два вида отчётов на основе результатов. Отчёт о ходе тестирования (test progress report) выпускают регулярно во время тестирования: ход работ относительно графика, препятствия, метрики, новые риски и тестирование, запланированное на следующий период. Отчёт о завершении тестирования (test completion report) выпускают на вехе: сводка выполненного тестирования, оценка по критериям выхода тест-плана, отклонения от плана, неисправленные дефекты и остаточные риски, извлечённые уроки. В системе управления тестированием оба собираются из результатов одного или нескольких прогонов.

Итоги прогона сравнивают с критериями выхода тест-плана. Критерий вроде «все тест-кейсы с высоким приоритетом выполнены, открытых дефектов критической серьёзности нет» проверяется прямо по результатам и связанным дефектам. Критерии выхода описаны в статье Тест-план и тестовая стратегия.

Тестовый прогон, набор тестов и тест-план

Три сущности связаны, и их часто путают.

Набор отвечает на вопрос «что можно проверить», прогон - «что проверено на этой сборке и с каким итогом», план - «что нужно проверить, как и к какому сроку». План обычно объединяет несколько прогонов: в разных окружениях, для разных уровней тестирования или последовательные прогоны одного релиза.

Термины

Источники

• ISTQB Certified Tester Foundation Level Syllabus v4.0.1, ISTQB, 2024(откроется в новой вкладке) (на английском)
• Глоссарий ISTQB(откроется в новой вкладке) (на английском)
• ISO/IEC/IEEE 29119-3:2021, Software testing, Part 3: Test documentation(откроется в новой вкладке) (на английском)
• Common JUnit XML format and examples, Testmo(откроется в новой вкладке) (на английском)