Стадии тестирования программного обеспечения¶
Стадии тестирования — последовательные этапы проверки программного обеспечения, направленные на выявление дефектов, оценку качества продукта и подтверждение соответствия требованиям. В зависимости от методологии (водопадная модель, Agile, DevOps) набор стадий варьируется, но общий принцип остаётся неизменным: тестирование проходит от низкоуровневой проверки отдельных модулей к сквозной проверке готового продукта в реальных условиях эксплуатации.
¶Основные стадии
Типовой жизненный цикл тестирования включает следующие стадии:
| Стадия | Цель | Основной артефакт |
|---|---|---|
| Планирование | Определение стратегии, объёма, ресурсов | План тестирования |
| Подготовка | Проектирование тест-кейсов, создание среды | Тестовая документация |
| Модульное (юнит) тестирование | Проверка отдельных компонентов | Отчёт о юнит-тестах |
| Интеграционное тестирование | Проверка взаимодействия модулей | Протокол интеграции |
| Системное тестирование | Проверка системы в целом | Отчёт о системном тестировании |
| Приёмочное тестирование | Подтверждение соответствия требованиям заказчика | Акт приёмки |
| Регрессионное тестирование | Проверка отсутствия регрессий после изменений | Протокол регрессии |
| Эксплуатационное тестирование | Проверка в боевых условиях | Отчёт о мониторинге |
¶Планирование
Стадия планирования определяет стратегию тестирования: какие виды тестов будут применяться, каков приоритет рисков, какие ресурсы и инструменты задействованы. Формируется план тестирования — документ, описывающий объём, критерии входа и выхода, расписание и ответственных. В гибких методологиях планирование носит итеративный характер и пересматривается на каждом спринте.
¶Подготовка
На стадии подготовки разрабатывается тестовая документация: тест-кейсы, сценарии, чек-листы. Одновременно создаётся тестовая среда — копия промышленного окружения с тестовыми данными. Качество подготовки напрямую влияет на эффективность последующих стадий: плохо спроектированные тест-кейсы приводят к пропуску дефектов и повторному прохождению цикла.
¶Модульное тестирование
Модульное (юнит) тестирование проверяет отдельные функции, классы или компоненты в изоляции. Выполняется, как правило, разработчиками с использованием фреймворков (JUnit, NUnit, pytest, Google Test). Автоматизируется в большинстве проектов и встраивается в процесс непрерывной интеграции. Цель — обнаружить дефекты на максимально раннем этапе, когда стоимость исправления минимальна.
¶Интеграционное тестирование
Интеграционное тестирование проверяет взаимодействие между модулями: обмен данными, вызовы API, работу с базами данных и внешними сервисами. Применяются подходы «снизу вверх», «сверху вниз» и комбинированные. На этом этапе выявляются ошибки интерфейсов, несовместимость форматов данных, проблемы с транзакциями и конкурентным доступом.
¶Системное тестирование
Системное тестирование рассматривает продукт как единое целое и проверяет его соответствие функциональным и нефункциональным требованиям. К функциональным тестам относятся проверки бизнес-логики, сценариев использования, граничных значений. К нефункциональным — нагрузочное, стрессовое, безопасность, удобство использования, совместимость, локализация. Системное тестирование выполняется на интегрированной системе в тестовой среде, максимально приближённой к промышленной.
¶Приёмочное тестирование
Приёмочное (акцептное) тестирование проводится для подтверждения, что система удовлетворяет потребностям заказчика и условиям контракта. Формы: приёмочные тесты (UAT), альфа- и бета-тестирование, демонстрация результата. Успешное прохождение этой стадии является основанием для подписания акта приёмки и выхода продукта в эксплуатацию.
¶Регрессионное тестирование
Регрессионное тестирование выполняется после каждого изменения кода, исправления дефекта или обновления конфигурации. Его цель — убедиться, что новые правки не привели к появлению ранее отсутствующих ошибок в уже проверенных функциях. Полный регрессионный набор может быть весьма объёмным, поэтому широко применяется автоматизация и приоритизация тест-кейсов на основе анализа изменений (impact analysis).
¶Эксплуатационное тестирование
Эксплуатационное (пострелизное) тестирование выполняется уже после выхода продукта в эксплуатацию. Включает мониторинг производительности, анализ логов, сбор обратной связи от пользователей, проверку обновлений на ограниченной группе (canary-выкладка). Завершает цикл и формирует обратную связь для планирования следующих итераций.
¶Связь со стадиями жизненного цикла ПО
Стадии тестирования тесно связаны со стадиями разработки. В водопадной модели тестирование концентрируется после этапа реализации, что повышает риск позднего обнаружения дефектов. В гибких методологиях (Scrum, Kanban) тестирование интегрировано в каждый спринт. В DevOps-практике тестирование автоматизировано и выполняется непрерывно в пайплайне CI/CD, что сокращает время от коммита до развёртывания.
¶Смежные понятия
- Виды тестирования — функциональное, нефункциональное, чёрный ящик, белый ящик, серый ящик.
- Уровни тестирования — юнит, интеграция, система, приёмка (часто отождествляются со стадиями).
- Типы тестирования — исследовательское, ручное, автоматизированное, дымовое, смоук-тестирование.
¶Источники
- Романько Е. Юнит-тестирование на Java. — СПб.: БХВ-Петербург, 2015.
- Канер Ф., Фолк Дж., Нг П.-К. Тестирование программного обеспечения. — М.: Вильямс, 2006.
- Майерс Г. Искусство тестирования программного обеспечения. — М.: Вильямс, 2004.
- ГОСТ Р ИСО/МЭК 12207-2010. Информационные технологии. Системная и программная инженерия. Процессы жизненного цикла программных систем.
- Шаталов В. Д. Тестирование: как это работает и что делать. — М.: Вильямс, 2016.