Покрытие кода

редактировать
Показатель тестирования исходного кода

В информатика, охват тестированием - это мера, используемая для описания степени, в которой исходный код программы выполняется, когда конкретный набор тестов запускается. У программы с высоким уровнем тестового покрытия, измеряемым в процентах, во время тестирования была выполнена большая часть исходного кода, что позволяет предположить, что у нее меньше шансов содержать необнаруженные программные ошибки по сравнению с программой с низким тестовым покрытием. Для расчета тестового покрытия можно использовать множество различных показателей; некоторые из самых основных - это процентное соотношение программ подпрограмм и процентное соотношение программ операторов, вызываемых во время выполнения набора тестов.

Тестовое покрытие было одним из первых методов, изобретенных для систематического тестирования программного обеспечения. Первое опубликованное упоминание было сделано Миллером и Мэлоуни в Сообщениях ACM в 1963 году.

Содержание
  • 1 Критерии покрытия
    • 1.1 Основные критерии покрытия
    • 1.2 Модифицированное покрытие условий / решений
    • 1.3 Покрытие множественных условий
    • 1.4 Покрытие значений параметров
    • 1.5 Другие критерии покрытия
  • 2 На практике
  • 3 Использование в промышленности
  • 4 См. Также
  • 5 Ссылки
Критерии покрытия

Чтобы измерить, какой процент кода был использован набором тестов, используется один или несколько критериев покрытия. Критерии покрытия обычно определяются как правила или требования, которым должен удовлетворять набор тестов.

Основные критерии покрытия

Существует ряд критериев покрытия, основными из которых являются:

  • Функция покрытие - каждая функция (или подпрограмма ) в программе вызывалась?
  • Покрытие оператора - выполнялся ли каждый оператор в программе?
  • Покрытие края - было ли выполнено каждое ребро в Графе потока управления ?
  • Покрытие ветви - есть каждая ветвь (также называемая DD- путь ) каждой управляющей структуры (например, в операторах if и case )? Например, для данного оператора if были выполнены как истинная, так и ложная ветви? Это подмножество покрытия краев.
  • Покрытие условий (или покрытие предиката) - каждое логическое подвыражение оценивается как истинное, так и ложное?

Например, рассмотрим следующую функцию C:

int foo (int x, int y) {int z = 0; если ((x>0) (y>0)) {z = x; } return z; }

Предположим, эта функция является частью какой-то более крупной программы, и эта программа запускалась с некоторым набором тестов.

  • Если во время этого выполнения функция 'foo' была вызвана хотя бы один раз, то покрытие функции для этой функции удовлетворено.
  • Покрытие инструкции для этой функции будет удовлетворено, если она была вызвана, например, как 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

Критерии условия / решения будут удовлетворены следующим набором тестов:

  • a = true, b = true, c = true
  • a = false, b = false, c = false

Однако вышеуказанный набор тестов не будет удовлетворять измененному покрытию условий / решений, поскольку в первом тесте значение 'b' и во втором тесте значение 'c' не повлияет на результат. Итак, для соответствия MC / DC необходим следующий набор тестов:

  • a = false, b = true, c = false
  • a = false, b = true, c = истина
  • a=ложь, b = ложь, c = истина
  • a=истина, b = ложь, c = истина

Покрытие нескольких условий

Этот критерий требует, чтобы проверялись все комбинации условий внутри каждого решения. Например, для фрагмента кода из предыдущего раздела потребуется восемь тестов:

  • a = false, b = false, c = false
  • a = false, b = false, c = true
  • a = false, b = true, c = false
  • a = false, b = true, c = true
  • a = true, b = false, c = false
  • a = true, b = false, c = true
  • a = true, b = true, c = false
  • a = true, b = true, c = true

Охват значения параметра

Охват значения параметра (PVC) требует, чтобы в методе, принимающем параметры, учитывались все общие значения для таких параметров. Идея состоит в том, что проверяются все общие возможные значения параметра. Например, общие значения для строки: 1) null, 2) пусто, 3) пробел (пробел, табуляция, новая строка), 4) допустимая строка, 5) недопустимая строка, 6) однобайтовая строка, 7) двухбайтовая строка. байтовая строка. Также может оказаться целесообразным использовать очень длинные строки. Отсутствие проверки каждого возможного значения параметра может привести к ошибке. Тестирование только одного из них может привести к 100% покрытию кода, поскольку покрывается каждая строка, но поскольку тестируется только один из семи вариантов, ПВХ составляет только 14,2%.

Другие критерии покрытия

Существуют и другие критерии покрытия, которые используются реже:

  • Покрытие линейной кодовой последовательности и скачка (LCSAJ), также известное как Покрытие JJ-пути - были ли выполнены все пути LCSAJ / JJ?
  • Покрытие пути - Были ли выполнены все возможные маршруты через данную часть кода?
  • Вход / выход Покрытие - Были ли выполнены все возможные вызов и возврат функции?
  • Покрытие цикла - Все возможные циклы выполнялись ноль раз, один раз и более одного раза?
  • Покрытие состояния - Было ли достигнуто и исследовано каждое состояние в конечном автомате ?
  • Покрытие потока данных - Были ли определены и изучены каждое определение переменной и ее использование?

Критично для безопасности или надежные приложения часто требуются для демонстрации 100% некоторой формы тестового покрытия. Например, стандарт ECSS -E-ST-40C требует 100% покрытия заявлений и решений для двух из четырех различных уровней критичности; для других значения целевого охвата являются предметом переговоров между поставщиком и заказчиком. Однако установка конкретных целевых значений - и, в частности, 100% - подвергалась критике со стороны практикующих специалистов по разным причинам (см.) Мартин Фаулер пишет: «Я бы с подозрением отнесся к чему-то вроде 100% - это было бы запах того, что кто-то пишет тесты, чтобы удовлетворить показатели покрытия, но не думает о том, что они делают ».

Некоторые из вышеперечисленных критериев покрытия связаны. Например, покрытие пути подразумевает покрытие решения, утверждения и входа / выхода. Покрытие решений подразумевает покрытие операторов, потому что каждое утверждение является частью ветви.

Полное покрытие пути описанного выше типа обычно непрактично или невозможно. Любой модуль с последовательностью решений n {\ displaystyle n}nв нем может иметь до 2 n {\ displaystyle 2 ^ {n}}2 ^ {n} путей внутри Это; конструкции цикла могут приводить к бесконечному количеству путей. Многие пути также могут быть недопустимыми, поскольку в тестируемую программу нет ввода, который может вызвать выполнение этого конкретного пути. Однако оказалось, что универсальный алгоритм для определения недопустимых путей невозможен (такой алгоритм можно использовать для решения проблемы остановки ). Тестирование базового пути, например, метод достижения полного покрытия ветвей без достижения полного покрытия пути.

Методы для практического тестирования покрытия пути вместо этого пытаются идентифицировать классы путей кода, которые различаются только количеством выполнений цикла, и достичь покрытия "базового пути" тестер должен охватывать все классы путей.

На практике

Целевое программное обеспечение создается со специальными параметрами или библиотеками и запускается в контролируемой среде, чтобы сопоставить каждую выполняемую функцию с функциональными точками в исходный код. Это позволяет тестировать части целевого программного обеспечения, которые редко или никогда не используются в нормальных условиях, и помогает удостовериться, что самые важные условия (функциональные точки) были протестированы. Полученный результат затем анализируется, чтобы увидеть, какие области кода не были проверены, и тесты обновляются, чтобы включить эти области по мере необходимости. В сочетании с другими методами покрытия тестами цель состоит в разработке строгого, но управляемого набора регрессионных тестов.

При реализации политик покрытия тестами в среде разработки программного обеспечения необходимо учитывать следующее:

  • Каковы требования к охвату для сертификации конечного продукта, и если да, то какой уровень покрытия тестированием требуется? Типичный уровень развития строгости следующий: утверждение, ветвь / решение, измененное условие / покрытие решения (MC / DC), LCSAJ (линейная последовательность кода и скачок )
  • Будет ли измеряться покрытие в сравнении с тестами, которые проверяют требования, предъявляемые к тестируемой системе (DO-178B )?
  • Отслеживается ли сгенерированный объектный код напрямую до заявлений исходного кода? Некоторые сертификаты (например, DO-178B уровня A) требуют покрытия на уровне сборки если это не так: «Затем необходимо выполнить дополнительную проверку объектного кода, чтобы установить правильность таких сгенерированных кодовых последовательностей» (DO-178B ) пункт-6.4.4.2.

Программное обеспечение Авторы могут просматривать результаты покрытия тестами, чтобы разработать дополнительные тесты и наборы входных данных или конфигурации для увеличения покрытия жизненно важных функций. Двумя распространенными формами покрытия тестами являются покрытие операторов (или строк) и покрытие ветвей (или границ). след выполнения тестирования с точки зрения того, какие строки кода были выполняется для завершения теста. Граничное покрытие сообщает, какие ветви или точки принятия решения по коду были выполнены для завершения теста. Оба они сообщают метрику покрытия, измеряемую в процентах. Смысл этого зависит от того, какая форма (формы) покрытия использовалась, так как 67% покрытие филиалов является более полным, чем покрытие 67% отчетов.

Как правило, инструменты тестового покрытия требуют вычислений и протоколирования в дополнение к фактической программе, тем самым замедляя работу приложения, поэтому обычно этот анализ не выполняется в производственной среде. Как и следовало ожидать, существуют классы программного обеспечения, которые не могут быть реально подвергнуты этим тестам покрытия, хотя степень отображения покрытия может быть приблизительно определена путем анализа, а не прямого тестирования.

Такие инструменты также могут иметь некоторые дефекты. В частности, некоторые состояния гонки или аналогичные чувствительные операции в реальном времени могут быть замаскированы при запуске в тестовых средах; хотя, наоборот, некоторые из этих дефектов может быть легче найти в результате дополнительных накладных расходов на код тестирования.

Большинство профессиональных разработчиков программного обеспечения используют покрытие C1 и C2. C1 означает покрытие операторов, а C2 - покрытие ветвей или условий. С помощью комбинации C1 и C2 можно охватить большинство операторов базой кода. Покрытие операторов также будет охватывать покрытие функций с входом и выходом, циклом, путем, потоком состояний, потоком управления и покрытием потока данных. С помощью этих методов можно достичь почти 100% покрытия кода в большинстве программных проектов.

Использование в промышленности

Покрытие испытаний - одно из соображений при сертификации безопасности авиационного оборудования. Требования, согласно которым авионика сертифицирована Федеральным авиационным управлением (FAA), задокументированы в DO-178B и DO-178C.

. в части 6 стандарта автомобильной безопасности ISO 26262 Транспортные средства - Функциональная безопасность.

См. также
Ссылки
Последняя правка сделана 2021-05-15 13:39:30
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте