Уровни тестирования: модульное, интеграционное, системное, приемочное
Мы уже разобрались с тем, какие виды тестирования существуют и как они помогают проверять функциональность или производительность системы. Однако для эффективной работы Middle-инженера недостаточно просто знать, «что» тестировать. Нужно понимать, «когда» и «на каком уровне» это делать.
Представьте разработку веб-сервиса как сборку автомобиля. Бессмысленно заводить двигатель, если мы не уверены, что каждый поршень отлит без брака. Но и идеальных поршней мало — нужно проверить, как они работают в связке с валом, а затем — поедет ли машина в целом. В IT этот путь описывают уровни тестирования.
Модульное тестирование (Unit Testing)
Это фундамент. Мы проверяем минимальные части кода в изоляции: функции, методы или классы.
- Кто делает: Обычно разработчики.
- Цель: Убедиться, что конкретный «кирпичик» логики работает верно сам по себе.
- Роль Middle QA: Вы не обязаны писать Unit-тесты, но должны анализировать их покрытие (Code Coverage). Если критический метод
validatePassword()не покрыт тестами, риск поймать баг на релизе возрастает в разы.
Для изоляции модуля от внешних систем (баз данных или API) используют заглушки (Stubs или Mocks). Это имитация, которая возвращает заранее заданный ответ, не запуская реальные процессы.
Интеграционное тестирование
Когда модули работают по отдельности, пора проверить их стыковку. Интеграционное тестирование фокусируется на передаче данных между компонентами.
В микросервисной архитектуре это критический этап. Мы проверяем, понимает ли сервис заказов формат данных, который прислал сервис оплаты. Как показано на Схеме 1, интеграция — это мост между «чистым» кодом и готовым продуктом.
Системное тестирование
Здесь мы проверяем приложение в сборе. Системное тестирование проводится в окружении, максимально близком к реальному (Staging или Pre-production).
Мы больше не смотрим внутрь кода. Наша задача — проверить продукт как единое целое на соответствие требованиям.
| Характеристика | Модульное | Системное |
|---|---|---|
| Объект | Метод или функция | Весь продукт целиком |
| Метод | White Box (видим код) | Black Box (код не важен) |
| Кто проводит | Разработчик | QA-инженер |
| Локализация багов | Мгновенная | Требует расследования |
Приемочное тестирование (UAT)
Финальный этап — приемочное тестирование (User Acceptance Testing). Его цель — не найти ошибки (к этому моменту их быть не должно), а подтвердить, что бизнес-задача решена.
В UAT часто участвует заказчик или фокус-группа. Если системное тестирование проверяет, правильно ли работает код, то приемочное — то ли мы вообще сделали для пользователя.
Пирамида тестирования
Для Middle-специалиста пирамида — это инструмент планирования. Она диктует два правила:
- Unit-тестов должно быть больше всего. Они быстрые и дешевые в запуске.
- Системных тестов (через интерфейс) должно быть меньше. Они медленные, часто «падают» из-за изменений в дизайне и дороги в поддержке.
💡 Закон стоимости: Баг, найденный на модульном уровне, исправляется за 5 минут. Тот же баг на этапе UAT может заставить команду переписывать архитектуру, что стоит компании недель работы.
Практика: Форма регистрации
Разберем уровни на примере одного поля Email:
- Модульное тестирование: Проверяем функцию
trim(), которая удаляет пробелы в начале и конце строки. Браузер не нужен, только код. - Интеграционное тестирование: Проверяем, что после нажатия кнопки данные из поля долетают до базы данных и создают там запись.
- Системное тестирование: QA открывает Chrome, вводит данные, ждет письмо с подтверждением и видит экран «Добро пожаловать».
- Приемочное тестирование: Заказчик решает, не слишком ли длинная форма и не уйдет ли пользователь к конкурентам из-за сложной капчи. 🕸️
Теперь, когда мы разобрались с иерархией, пора научиться экономить время. В следующей теме мы изучим техники тест-дизайна — они помогут проверить миллионы комбинаций данных всего парой точных тестов.