Набор тестов достигает 100% покрытия строк, но в продукте обнаруживается дефект. Как объяснить, почему такой показатель не доказывает корректность поведения?
100% покрытия строк означает только, что каждая строка была выполнена хотя бы одним тестом. Это не доказывает проверку всех ветвей, комбинаций входных данных и правильности ожидаемых результатов. Поэтому покрытие — вспомогательная метрика полноты тестов, а не доказательство отсутствия дефектов.
Метрики покрытия появились как способ оценить, какая часть программного кода реально выполняется во время тестов. Они помогали находить участки, до которых тесты вообще не доходят, особенно в больших проектах.
Однако сама по себе метрика не отвечает на вопрос, были ли результаты выполнения проверены корректно. Она показывает область выполнения программы, но не качество тестовых утверждений и не соответствие поведения требованиям.
Тест может вызвать функцию и пройти через строку, не проверив результат или проверив его слишком слабо. В таком случае строка считается покрытой, хотя ошибка в вычислении или выборе ветви остаётся незамеченной.
Высокое покрытие создаёт риск ложной уверенности. Команда может прекратить разработку тестов, хотя не проверены граничные значения, альтернативные ветви, взаимодействия условий, ошибки зависимостей и бизнес-сценарии.
Нужно различать несколько уровней покрытия. Покрытие строк показывает выполнение строк, покрытие ветвей — прохождение результатов условных переходов, а покрытие условий — влияние отдельных логических условий на результат. Даже полное покрытие ветвей не гарантирует проверку всех возможных комбинаций условий и корректности требований.
Например, тесты могут пройти по каждой строке и подтвердить только типичные результаты. Если ожидаемое значение в утверждении ошибочно, тест будет формально выполнен, но не обнаружит дефект. Поэтому покрытие следует сопоставлять с качеством проверок, анализом рисков и тестовыми техниками.
В этом примере обе ветви и все строки выполняются, но отдельная проверка веса ровно 5 отсутствует. Если реализация ошибочно использует строгое сравнение и возвращает для веса 5 значение 200, показанное покрытие может остаться полным, а дефект — незамеченным.
Практический подход: использовать покрытие для поиска непротестированных участков, затем добавлять проверки на основе требований, классов эквивалентности, границ, рисков и ожидаемых последствий ошибок. Повышение процента покрытия без усиления утверждений может увеличить объём тестов, но не их способность обнаруживать дефекты.
В расчёте стоимости доставки команда получила 100% покрытия строк. После релиза выяснилось, что для заказа с нулевым весом система выставляет плату как за минимально допустимый вес, хотя требование предписывает отклонять такой заказ.
Рассматривались два варианта. Первый — добавить ещё тесты, пока процент покрытия не изменится; это не помогло бы, поскольку строки уже выполнялись. Второй — проверить требования, выделить классы допустимых и недопустимых значений и явно зафиксировать ожидаемый результат для нулевого веса.
Выбрали второй вариант: добавили тест на недопустимое значение и проверки границ допустимого диапазона. Покрытие осталось 100%, но тестовый набор стал проверять бизнес-правило, а не только факт выполнения кода. Это показывает, что содержательные утверждения важнее самого процента.
Нет. Полное покрытие ветвей лучше показывает прохождение альтернативных результатов условий, но всё равно не проверяет все комбинации условий, корректность вычислений и соответствие требованиям. Кроме того, разные входы могут пройти одну и ту же ветвь, скрывая ошибку на границе диапазона.
Да. Набор с меньшим покрытием может проверять критические бизнес-сценарии, ошибки и границы, тогда как набор с высоким покрытием может содержать слабые или бессодержательные утверждения. Качество оценивают не только по охвату кода, но и по способности обнаруживать значимые дефекты.
Следует применять её как сигнал для анализа, а не как критерий безусловной готовности. Непокрытые участки нужно оценивать по риску, а покрытые — проверять на наличие корректных ожидаемых результатов и соответствие требованиям. Порог покрытия может быть полезным командным ориентиром, но не заменяет анализ тест-дизайна и результатов тестирования.