Уровни тестирования | QArtel
methodology
Уровни тестирования
Введение Уровни тестирования — это группы тестовых мероприятий, организованных и управляемых на определённом этапе жизненного цикла разработки. Каждый уровень фокусируется на конкретном аспекте системы и имеет свои цели, участников и критерии.
В модели ISTQB CTFL v4.0 выделяют четыре основных уровня:
Компонентное тестирование (Component / Unit Testing)Интеграционное тестирование (Integration Testing)Системное тестирование (System Testing)Приёмочное тестирование (Acceptance Testing / UAT)
1. Компонентное тестирование (Unit Testing)
Определение Тестирование отдельных программных компонент (модулей, функций, классов) в изоляции от остальной системы.
Цели
Проверить корректность работы отдельного компонента
Обнаружить дефекты на ранней стадии, когда их устранение дешевле всего
Убедиться, что компонент соответствует своей спецификации (unit-level design)
Кто выполняет
Разработчики — основные исполнителиВ командах с TDD — тесты пишутся до кода
Автотесты запускаются в CI/CD пайплайне
Примеры
Тест функции calculateDiscount(price, percent) с граничными значениями
Тест метода класса UserValidator.isValidEmail() с валидными и невалидными email
Проверка обработки null и пустых коллекций
Критерии входа (Entry Criteria)
Код компонента написан и скомпилирован
Тестовая среда / фреймворк настроен (JUnit, pytest, Jest и т.д.)
Требования к компоненту определены
Критерии выхода (Exit Criteria)
Все запланированные unit-тесты выполнены
Покрытие кода соответствует установленному порогу (например, ≥ 80%)
Все критические дефекты исправлены
Нет открытых блокирующих или критических дефектов
Техники
Эквивалентное разделение, граничные значения
Таблицы решений
Покрытие кода (statement, branch, path coverage)
Тестирование через заглушки (stubs) и моки (mocks)
2. Интеграционное тестирование
Определение Тестирование взаимодействия между двумя или более компонентами или системами.
Цели
Обнаружить дефекты в интерфейсах и взаимодействии между компонентами
Проверить корректность передачи данных между модулями
Проверить обработку ошибок на границах компонентов
Кто выполняет
Разработчики — при интеграции на уровне кодаТестировщики / QA-инженеры — при интеграции подсистем и внешних сервисовАрхитекторы участвуют в планировании стратегии интеграции
Стратегии Стратегия Описание Big Bang Все компоненты интегрируются одновременно Сверху вниз (Top-Down) От верхних уровней к нижним, нижние замещаются заглушками Снизу вверх (Bottom-Up) От нижних уровней к верхним, верхние замещаются драйверами Песочница (Sandwich) Комбинация обоих подходов
Примеры
Тест API между фронтендом и бэкендом
Проверка интеграции с внешним платёжным шлюзом
Тест передачи данных между микросервисами
Проверка обмена сообщениями через очередь (Kafka, RabbitMQ)
Критерии входа
Компоненты прошли компонентное тестирование
Интерфейсы между компонентами определены
Тестовые среды и заглушки/моки настроены
Критерии выхода
Все интеграционные тесты пройдены
Дефекты в интерфейсах исправлены
Корректность передачи данных подтверждена
3. Системное тестирование
Определение Тестирование полной интегрированной системы для проверки соответствия заданным требованиям.
Цели
Проверить функциональные и нефункциональные требования к системе в целом
Обнаружить дефекты, которые невозможно найти на предыдущих уровнях
Снизить риски перед выпуском продукта
Кто выполняет
QA-инженеры / тестировщики — основные исполнителиБизнес-аналитики могут участвовать в валидации
Проводится в среде, максимально приближённой к продакшн
Примеры
Сквозной (end-to-end) сценарий: регистрация → авторизация → создание заказа → оплата
Тестирование нагрузки (как система выдерживает 10 000 одновременных пользователей)
Тестирование безопасности (SQL-инъекции, XSS)
Тестирование совместимости (браузеры, ОС, устройства)
Проверка логирования и мониторинга
Критерии входа
Интеграционное тестирование завершено
Система развёрнута в тестовой среде
Тест-кейсы на системный уровень подготовлены и утверждены
Критерии выхода
Все тест-кейсы выполнены
Оставшиеся дефекты документированы и проанализированы
Нефункциональные требования подтверждены
Тестовый отчёт утверждён
4. Приёмочное тестирование (UAT)
Определение Тестирование, проводимое для определения того, удовлетворяет ли система потребностям и ожиданиям конечных пользователей / заказчика.
Цели
Убедиться, что система готова к эксплуатации
Подтвердить соответствие бизнес-требованиям и пользовательским сценариям
Дать заказчику / бизнесу основание принять систему
Кто выполняет
Конечные пользователи / заказчики Бизнес-аналитики (помогают сценариям)
QA-команда может обеспечить инфраструктуру и поддержку
Виды приёмочного тестирования Вид Описание Alpha-тестирование Проводится в среде разработчиков силами потенциальных пользователей Beta-тестирование Проводится в среде конечных пользователей (ограниченная группа) Приёмочное тестирование по контракту Проверка выполнения критериев приёмки из контракта Приёмочное тестирование по регуляторным требованиям Соответствие законодательству и стандартам Операционное приёмочное тестирование Проверка готовности системы к эксплуатации (Operational Acceptance)
Примеры
Пользователь проверяет полный сценарий заказа товара в бета-версии
Заказчик проводит демонстрацию (showcase) и подтверждает готовность
Проверка соответствия требованиям регулятора (GDPR, PCI DSS)
Критерии входа
Системное тестирование завершено
Критические и блокирующие дефекты устранены
Данные для тестирования подготовлены
Пользователи прошли обучение (при необходимости)
Критерии выхода
Все сценарии приёмочного тестирования пройдены
Заказчик / бизнес подписал акт приёмки
Оставшиеся дефекты не влияют на ключевую функциональность
5. Функциональное и нефункциональное тестирование
Функциональное тестирование Определение: Тестирование функций и операций компонента или системы («что система делает»).
Фокус: Поведение системы — входы, выходы, бизнес-логика, обработка данных.
Проверка, что форма регистрации создаёт пользователя в базе данных
Проверка, что поиск по товарам возвращает корректные результаты
Проверка расчёта налога в корзине
Не зависит от уровня — проводится на каждом из четырёх уровней.
Нефункциональное тестирование Определение: Тестирование атрибутов системы, не связанных с конкретными функциями («как хорошо система работает»).
Фокус: Производительность, удобство использования, надёжность, безопасность, совместимость и т.д.
Нагрузочное тестирование (response time < 2 сек при 1000 пользователей)
Юзабилити-тестирование (пользователь находит товар за ≤ 3 клика)
Тестирование безопасности (авторизация не обходится без пароля)
Совместимость (приложение работает в Chrome, Firefox, Safari)
Не зависит от уровня — может проводиться на уровне системы, интеграции и т.д.
6. Конфирмационное и регрессионное тестирование
Конфирмационное тестирование (Confirmation Testing) Определение: Тестирование, проводимое для подтверждения того, что дефект исправлен.
Также называют: Re-testing, повторное тестирование.
Цель: Убедиться, что исправление работает и дефект больше не воспроизводится.
Пример: После исправления бага «форма не отправляется при пустом телефоне» — тестировщик повторяет именно этот сценарий.
Регрессионное тестирование (Regression Testing) Определение: Тестирование для обнаружения дефектов в ранее протестированных частях системы после внесения изменений.
Цель: Убедиться, что изменения не сломали существующую функциональность.
После исправления дефектов
После добавления нового функционала
После рефакторинга
После обновления окружения (новая версия ОС, библиотеки)
Пример: После добавления функции «список желаний» — прогнать тесты корзины, оформления заказа, регистрации.
Автоматизация: Регрессионное тестирование — главный кандидат на автоматизацию, так как набор тестов повторяется многократно.
Сравнительная таблица уровней Критерий Компонентное Интеграционное Системное Приёмочное Объект Отдельный модуль/класс Взаимодействие компонентов Вся система Соответствие бизнес-ожиданиям Кто тестирует Разработчики Разработчики + QA QA Пользователи / заказчик Когда Во время кодирования После компонентного После интеграционного После системного Что ищем Логические ошибки в коде Ошибки интерфейсов Системные дефекты Несоответствие потребностям Окружение IDE / CI Тестовое / стейджинг Стейджинг ≈ продакшн Стейджинг / продакшн-like Заглушки Моки и стабы Минимум заглушек Без заглушек Без заглушек
Сноски
ISTQB Foundation Level Syllabus v4.0, Chapter 2.2 — Test Levels
Все уровни могут использовать как функциональное, так и нефункциональное тестирование
Порядок уровней не обязательно строго последовательный — в Agile они часто совмещаются