Тестирование рассматривается как метод конструирования, контроля качества, верификации и валидации программ, в методологии TDD и как средство получения требований к ПО. Теория тестирования выступает против необоснованного уровня доверия к серии успешно пройденных тестов. К сожалению, большинство установленных результатов теории тестирования – негативны, означая, по словам Дейкстры, то, что “тестирование программы может использоваться для демонстрации наличия дефектов, но никогда не покажет их отсутствие”. Основная причина этого в том, что полное (всеобъемлющее) тестирование недостижимо для реального программного обеспечения.
1. Понятие тестирования
Тестирование (testing) – это набор операций, проводимых для обеспечения выявления и/или оценки свойств одного или более программных элементов.
Оно служит механизмом получения доказательств качества на всех уровнях создания системы
Артефакт: План тестирования, тестовый сценарий, контрольный пример, отчет об ошибках, матрица прослеживаемости тестирования, тестовое покрытие.
2. Модульное тестирование
Объект тестирования: Минимально возможный, изолированный компонент исходного кода (отдельная функция, метод класса или сам класс).
- Кто выполняет: Непосредственно разработчик (Software Engineer) в процессе конструирования.
- Главная цель: Проверить корректность внутренней логики модуля, алгоритмов и граничных условий в полной изоляции от внешней среды (баз данных, сети, файловой системы).
- Особенности реализации:
- Пишется в виде кода с использованием специализированных фреймворков (JUnit, NUnit, PyTest).
- Изоляция зависимостей: Для исключения влияния внешнего мира используются тестовые дублеры (Test Doubles):
- Stubs (Заглушки): Возвращают жестко заданные данные при вызове.
- Mocks (Макеты): Проверяют сам факт вызова метода и правильность переданных в него аргументов.
- Метрика эффективности: Покрытие кода тестами (Code Coverage) — процент строк или ветвлений логики, выполненных в ходе тестов.
3. Интеграционное тестирование
Объект тестирования: Взаимодействие и интерфейсы между несколькими модулями, компонентами или сторонними подсистемами.
- Кто выполняет: Разработчики (при сборке модулей) или QA-инженеры (при проверке межсервисного взаимодействия).
- Главная цель: Выявить дефекты на стыке компонентов. Модули могут идеально работать по отдельности, но ломаться при попытке передать данные друг другу.
- Типичные выявляемые ошибки: Несовместимость типов данных в API, неверный порядок вызовов, ошибки протокола обмена, проблемы с правами доступа к БД.
- Подходы к интеграции (из главы Конструирование):
- Нисходящая (Top-Down) — тестирование сверху вниз с использованием заглушек (Stubs).
- Восходящая (Bottom-Up) — тестирование снизу вверх с использованием драйверов вызова (Drivers).
- Непрерывная (CI-driven) — автоматическая проверка интеграции при каждом слиянии веток кода.
4. Системное тестирование
Объект тестирования: Вся программная система в целом, развернутая на окружении, максимально близком к реальному (Staging / Pre-production).
- Кто выполняет: Отдельная команда инженеров по тестированию (QA/Testing Team).
- Главная цель: Проверить соответствие всей системы как функциональным, так и нефункциональным (системным) требованиям спецификации.
- Виды проверок на системном уровне:
- Функциональное тестирование: Проверка реализации сквозных бизнес-сценариев (End-to-End, E2E).
- Нагрузочное тестирование (Performance/Stress): Проверка работы системы под пиковыми нагрузками.
- Тестирование безопасности (Security): Проверка устойчивости к атакам и уязвимостям.
- Тестирование отказоустойчивости (Failover): Эмуляция сбоев железа и сети для проверки тактик восстановления.
5. Приемочное тестирование
Объект тестирования: Готовая система, оцениваемая с точки зрения соответствия бизнес-целям, контракту и ожиданиям пользователей.
- Кто выполняет: Заказчик, конечные пользователи или уполномоченные бизнес-аналитики.
- Главная цель: Принятие решения о готовности продукта к промышленной эксплуатации (релиз в Production) и подписании актов выполненных работ. Ответ на вопрос: «Мы построили именно ту систему, которую хотел заказчик?» (Валидация).
- Основные формы приемочного тестирования:
- UAT (User Acceptance Testing): Проверка реальными пользователями на основе их ежедневных рабочих сценариев.
- Альфа-тестирование ($\alpha$-testing): Внутреннее приемочное тестирование силами сотрудников внутри компании-разработчика.
- Бета-тестирование ($\beta$-testing): Передача предрелизной версии ограниченному кругу реальных внешних пользователей для сбора обратной связи в реальных условиях.
6. Методы проектирования тестов
| Метод проектирования тестов | Идея метода | Что проверяет | Когда применять | Пример |
|---|---|---|---|---|
| Эквивалентное разбиение | Разделение входных данных на классы, внутри которых система должна вести себя одинаково | Корректную обработку групп однотипных данных | Когда количество возможных входов слишком велико | Поле «Возраст»:<0— ошибка,0–120— корректно,>120— ошибка |
| Анализ граничных значений | Проверка значений на границах допустимых диапазонов | Ошибки, возникающие на границах условий | Для диапазонов, ограничений, размеров, количеств | Для диапазона 1–100 проверить:0, 1, 2, 99, 100, 101 |
| Таблицы решений | Представление сложной логики в виде комбинаций условий и действий | Корректность бизнес-правил | Когда результат зависит от нескольких условий | Скидка зависит от возраста, статуса клиента и суммы покупки |
| Диаграммы переходов состояний | Построение тестов на основе модели состояний объекта | Корректность изменения состояния системы | Для объектов с жизненным циклом | Заказ: создан → оплачен → отправлен → доставлен |
| Попарное тестирование | Проверка всех пар значений параметров вместо полного перебора комбинаций | Ошибки взаимодействия параметров | При большом числе настроек и комбинаций | Браузер × ОС × язык × тип пользователя |
| Тестирование на основе сценариев | Проверка типичных пользовательских действий | Сквозное поведение системы | Для пользовательских процессов | Регистрация → покупка → оплата → получение заказа |
| Исследовательское тестирование | Одновременное изучение системы и создание тестов | Неочевидные ошибки | Когда требования неполные или система сложная | Поиск неожиданных сценариев работы интерфейса |
| Предугадывание ошибок | Использование опыта тестировщика для поиска вероятных ошибок | Типовые дефекты | На основе опыта и истории ошибок | null, пустые строки, отрицательные числа, переполнение |
| Мутационное тестирование | Искусственное внесение ошибок в код и проверка, находят ли их тесты | Качество набора тестов | Для оценки эффективности автоматических тестов | Изменить>на<и проверить, падает ли тест |
Автоматизация тестирования
это инженерный механизм получения быстрой обратной связи о качестве программной системы. Ее цель не написать больше тестов, а встроить проверку качества в процесс разработки