Ответ
Достаточность покрытия оценивается по нескольким взаимодополняющим критериям, а не по одному метрику. Вот мой подход:
-
Матрица трассируемости (Traceability Matrix): Я создаю таблицу, где каждое функциональное требование (или User Story) связано с одним или несколькими тест-кейсами. Это дает визуальное подтверждение, что для каждого требования есть проверка.
-
Анализ типов тестовых сценариев: Я убеждаюсь, что набор включает:
- Позитивные (Happy Path): Проверка основного потока при корректных данных.
- Негативные: Проверка обработки неверных данных, ошибок валидации, исключительных ситуаций.
- Граничные значения (Boundary Value Analysis): Тестирование на минимумах, максимумах и значениях вокруг границ.
- Сценарии, связанные с состоянием системы: Проверка поведения после повторных действий, в разных состояниях данных.
-
Пример для функции «Добавление товара в корзину»:
# Позитивный сценарий Сценарий: Успешное добавление товара в пустую корзину Дано пользователь находится на странице товара Когда он нажимает кнопку "Добавить в корзину" Тогда счетчик товаров в корзине увеличивается на 1 И товар отображается в мини-корзине # Негативный сценарий Сценарий: Попытка добавить недоступный товар (статус "Нет в наличии") Дано пользователь находится на странице товара со статусом "Нет в наличии" Тогда кнопка "Добавить в корзину" неактивна # Граничный сценарий Сценарий: Добавление максимально допустимого количества одного товара Дано пользователь добавляет товар в корзину 99 раз Когда он пытается добавить его в 100-й раз Тогда отображается сообщение "Достигнут лимит на этот товар" -
Практические метрики и ревью:
- Code Coverage (для unit- и integration-тестов) показывает, какие строки кода были выполнены. Цель — высокий процент, но 100% не гарантирует отсутствие багов.
- Ревью тест-кейсов коллегами (peer review) помогает выявить пропущенные сценарии.
- Анализ дефектов: Если баги часто находят в непокрытых областях, это сигнал к расширению тестового набора.