В информатика, охват тестированием - это мера, используемая для описания степени, в которой исходный код программы выполняется, когда конкретный набор тестов запускается. У программы с высоким уровнем тестового покрытия, измеряемым в процентах, во время тестирования была выполнена большая часть исходного кода, что позволяет предположить, что у нее меньше шансов содержать необнаруженные программные ошибки по сравнению с программой с низким тестовым покрытием. Для расчета тестового покрытия можно использовать множество различных показателей; некоторые из самых основных - это процентное соотношение программ подпрограмм и процентное соотношение программ операторов, вызываемых во время выполнения набора тестов.
Тестовое покрытие было одним из первых методов, изобретенных для систематического тестирования программного обеспечения. Первое опубликованное упоминание было сделано Миллером и Мэлоуни в Сообщениях ACM в 1963 году.
Чтобы измерить, какой процент кода был использован набором тестов, используется один или несколько критериев покрытия. Критерии покрытия обычно определяются как правила или требования, которым должен удовлетворять набор тестов.
Существует ряд критериев покрытия, основными из которых являются:
Например, рассмотрим следующую функцию C:
int foo (int x, int y) {int z = 0; если ((x>0) (y>0)) {z = x; } return z; }
Предположим, эта функция является частью какой-то более крупной программы, и эта программа запускалась с некоторым набором тестов.
foo (1,1)
, как в этом случае, каждая строка в функции выполняется, включая z = x;
.foo (1,1)
и foo (0,1)
удовлетворят охвату ветвления, потому что в первом случае выполняются оба условия if
и z = x;
, в то время как во втором случае первое условие (x>0)
не выполняется, что препятствует выполнению z = x;
.foo (1,0)
и foo (0,1)
. Это необходимо, потому что в первых случаях (x>0)
оценивается как true
, а во втором - как false
. В то же время первый случай делает (y>0)
false
, а второй делает его истинным
.Покрытие условий не обязательно подразумевает покрытие ветвей. Например, рассмотрим следующий фрагмент кода:
если a и b, то
Покрытие условий может быть выполнено двумя тестами:
a = true
, b = false
a = false
, b = true
Однако этот набор тестов не удовлетворяет охвату ветвления, поскольку ни один из вариантов не удовлетворяет условию if
.
Внедрение ошибки может потребоваться для обеспечения адекватного покрытия всех условий и ветвей кода обработки исключений во время тестирования.
Комбинация покрытия функций и покрытия ветвей иногда также называется покрытием решений . Этот критерий требует, чтобы каждая точка входа и выхода в программе вызывалась хотя бы один раз, и каждое решение в программе принималось по всем возможным результатам хотя бы один раз. В этом контексте решение - это логическое выражение, состоящее из условий и нуля или более логических операторов. Это определение не то же самое, что и покрытие ветвей, однако некоторые используют термин покрытие решений как синоним покрытия ветвей.
Покрытие условий / решений требует, чтобы выполнялись и решения, и условия покрытия. Однако для критически важных с точки зрения безопасности приложений (например, для программного обеспечения авионики) часто требуется, чтобы выполнялось модифицированное покрытие условий / решений (MC / DC) . Этот критерий расширяет критерии условия / решения с требованиями, чтобы каждое условие независимо влияло на результат решения. Например, рассмотрим следующий код:
if (a или b) и c then
Критерии условия / решения будут удовлетворены следующим набором тестов:
Однако вышеуказанный набор тестов не будет удовлетворять измененному покрытию условий / решений, поскольку в первом тесте значение 'b' и во втором тесте значение 'c' не повлияет на результат. Итак, для соответствия MC / DC необходим следующий набор тестов:
Этот критерий требует, чтобы проверялись все комбинации условий внутри каждого решения. Например, для фрагмента кода из предыдущего раздела потребуется восемь тестов:
Охват значения параметра (PVC) требует, чтобы в методе, принимающем параметры, учитывались все общие значения для таких параметров. Идея состоит в том, что проверяются все общие возможные значения параметра. Например, общие значения для строки: 1) null, 2) пусто, 3) пробел (пробел, табуляция, новая строка), 4) допустимая строка, 5) недопустимая строка, 6) однобайтовая строка, 7) двухбайтовая строка. байтовая строка. Также может оказаться целесообразным использовать очень длинные строки. Отсутствие проверки каждого возможного значения параметра может привести к ошибке. Тестирование только одного из них может привести к 100% покрытию кода, поскольку покрывается каждая строка, но поскольку тестируется только один из семи вариантов, ПВХ составляет только 14,2%.
Существуют и другие критерии покрытия, которые используются реже:
Критично для безопасности или надежные приложения часто требуются для демонстрации 100% некоторой формы тестового покрытия. Например, стандарт ECSS -E-ST-40C требует 100% покрытия заявлений и решений для двух из четырех различных уровней критичности; для других значения целевого охвата являются предметом переговоров между поставщиком и заказчиком. Однако установка конкретных целевых значений - и, в частности, 100% - подвергалась критике со стороны практикующих специалистов по разным причинам (см.) Мартин Фаулер пишет: «Я бы с подозрением отнесся к чему-то вроде 100% - это было бы запах того, что кто-то пишет тесты, чтобы удовлетворить показатели покрытия, но не думает о том, что они делают ».
Некоторые из вышеперечисленных критериев покрытия связаны. Например, покрытие пути подразумевает покрытие решения, утверждения и входа / выхода. Покрытие решений подразумевает покрытие операторов, потому что каждое утверждение является частью ветви.
Полное покрытие пути описанного выше типа обычно непрактично или невозможно. Любой модуль с последовательностью решений в нем может иметь до путей внутри Это; конструкции цикла могут приводить к бесконечному количеству путей. Многие пути также могут быть недопустимыми, поскольку в тестируемую программу нет ввода, который может вызвать выполнение этого конкретного пути. Однако оказалось, что универсальный алгоритм для определения недопустимых путей невозможен (такой алгоритм можно использовать для решения проблемы остановки ). Тестирование базового пути, например, метод достижения полного покрытия ветвей без достижения полного покрытия пути.
Методы для практического тестирования покрытия пути вместо этого пытаются идентифицировать классы путей кода, которые различаются только количеством выполнений цикла, и достичь покрытия "базового пути" тестер должен охватывать все классы путей.
Целевое программное обеспечение создается со специальными параметрами или библиотеками и запускается в контролируемой среде, чтобы сопоставить каждую выполняемую функцию с функциональными точками в исходный код. Это позволяет тестировать части целевого программного обеспечения, которые редко или никогда не используются в нормальных условиях, и помогает удостовериться, что самые важные условия (функциональные точки) были протестированы. Полученный результат затем анализируется, чтобы увидеть, какие области кода не были проверены, и тесты обновляются, чтобы включить эти области по мере необходимости. В сочетании с другими методами покрытия тестами цель состоит в разработке строгого, но управляемого набора регрессионных тестов.
При реализации политик покрытия тестами в среде разработки программного обеспечения необходимо учитывать следующее:
Программное обеспечение Авторы могут просматривать результаты покрытия тестами, чтобы разработать дополнительные тесты и наборы входных данных или конфигурации для увеличения покрытия жизненно важных функций. Двумя распространенными формами покрытия тестами являются покрытие операторов (или строк) и покрытие ветвей (или границ). след выполнения тестирования с точки зрения того, какие строки кода были выполняется для завершения теста. Граничное покрытие сообщает, какие ветви или точки принятия решения по коду были выполнены для завершения теста. Оба они сообщают метрику покрытия, измеряемую в процентах. Смысл этого зависит от того, какая форма (формы) покрытия использовалась, так как 67% покрытие филиалов является более полным, чем покрытие 67% отчетов.
Как правило, инструменты тестового покрытия требуют вычислений и протоколирования в дополнение к фактической программе, тем самым замедляя работу приложения, поэтому обычно этот анализ не выполняется в производственной среде. Как и следовало ожидать, существуют классы программного обеспечения, которые не могут быть реально подвергнуты этим тестам покрытия, хотя степень отображения покрытия может быть приблизительно определена путем анализа, а не прямого тестирования.
Такие инструменты также могут иметь некоторые дефекты. В частности, некоторые состояния гонки или аналогичные чувствительные операции в реальном времени могут быть замаскированы при запуске в тестовых средах; хотя, наоборот, некоторые из этих дефектов может быть легче найти в результате дополнительных накладных расходов на код тестирования.
Большинство профессиональных разработчиков программного обеспечения используют покрытие C1 и C2. C1 означает покрытие операторов, а C2 - покрытие ветвей или условий. С помощью комбинации C1 и C2 можно охватить большинство операторов базой кода. Покрытие операторов также будет охватывать покрытие функций с входом и выходом, циклом, путем, потоком состояний, потоком управления и покрытием потока данных. С помощью этих методов можно достичь почти 100% покрытия кода в большинстве программных проектов.
Покрытие испытаний - одно из соображений при сертификации безопасности авиационного оборудования. Требования, согласно которым авионика сертифицирована Федеральным авиационным управлением (FAA), задокументированы в DO-178B и DO-178C.
. в части 6 стандарта автомобильной безопасности ISO 26262 Транспортные средства - Функциональная безопасность.