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

В обеспечения разработке программного покрытие кода , также называемое тестовым покрытием собой процентную меру степени исходного кода программы , представляет выполнения определенного набора тестов при запуске . В программе с высоким покрытием кода во время тестирования выполняется большая часть исходного кода, что предполагает меньшую вероятность наличия необнаруженных программных ошибок по сравнению с программой с низким покрытием кода. ^{[ 1 ]}^{[ 2 ]} Для расчета тестового покрытия можно использовать множество различных показателей. Некоторые из самых основных — это процент программных подпрограмм и процент программных операторов, вызываемых во время выполнения набора тестов.

Покрытие кода было одним из первых методов систематического тестирования программного обеспечения . Первая опубликованная ссылка была сделана Миллером и Мэлони в журнале Communications of ACM в 1963 году. ^{[ 3 ]}

Критерии покрытия

Чтобы измерить, какой процент кода был выполнен набором тестов один или несколько критериев покрытия , используется . Обычно они определяются как правила или требования, которым должен удовлетворять набор тестов. ^{[ 4 ]}

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

Критериев покрытия несколько, но основными являются: ^{[ 5 ]}

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

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

int foo (int x, int y)
{
    int z = 0;
    if ((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), и foo(1,1). Это необходимо, поскольку в первом случае (x>0) оценивается как true, а во втором он оценивается как false. В то же время первый случай делает (y>0) false, второй случай не оценивает (y>0) (из-за ленивого вычисления логического оператора), третий случай делает это true.

В языках программирования, которые не выполняют короткую оценку , покрытие условий не обязательно подразумевает покрытие ветвей. Например, рассмотрим следующий Pascal фрагмент кода :

if a and b then

Покрытие условий может быть выполнено с помощью двух тестов:

a=true, b=false
a=false, b=true

Однако этот набор тестов не удовлетворяет охвату ветвей, поскольку ни один из случаев не соответствует требованиям. if состояние.

Внедрение ошибок может потребоваться для обеспечения обработки исключений адекватного покрытия всех условий и ветвей кода во время тестирования.

Измененное покрытие условий/решений

Комбинацию покрытия функций и покрытия ветвей иногда также называют покрытием решений . Этот критерий требует, чтобы каждая точка входа и выхода в программе вызывалась хотя бы один раз, и каждое решение в программе принималось по всем возможным результатам хотя бы один раз. В этом контексте решение представляет собой логическое выражение, содержащее условия и ноль или более логических операторов. Это определение не то же самое, что покрытие филиалов. ^{[ 6 ]} однако термин «покрытие решений» иногда используется как его синоним. ^{[ 7 ]}

Покрытие условий/решений требует, чтобы были удовлетворены как покрытие решений, так и условия. Однако для критически важных для безопасности приложений (таких как программное обеспечение авионики ) часто требуется, чтобы покрытие модифицированных условий/решений (MC/DC) удовлетворялось . Этот критерий расширяет критерии условия/решения требованиями, согласно которым каждое условие должно влиять на результат решения независимо.

Например, рассмотрим следующий код:

if (a or b) and c then

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

а	б	с
истинный	истинный	истинный
ЛОЖЬ	ЛОЖЬ	ЛОЖЬ

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

а	б	с
ЛОЖЬ	истинный	ЛОЖЬ
ЛОЖЬ	истинный	истинный
ЛОЖЬ	ЛОЖЬ	истинный
истинный	ЛОЖЬ	истинный

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

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

а	б	с
ЛОЖЬ	ЛОЖЬ	ЛОЖЬ
ЛОЖЬ	ЛОЖЬ	истинный
ЛОЖЬ	истинный	ЛОЖЬ
ЛОЖЬ	истинный	истинный
истинный	ЛОЖЬ	ЛОЖЬ
истинный	ЛОЖЬ	истинный
истинный	истинный	ЛОЖЬ
истинный	истинный	истинный

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

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

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

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

Покрытие линейной кодовой последовательности и перехода (LCSAJ), также известное как покрытие JJ-Path – каждый ли LCSAJ/JJ-путь был выполнен? ^{[ 9 ]}
Покрытие пути . Были ли выполнены все возможные маршруты через данную часть кода?
Покрытие входа/выхода . Были ли выполнены все возможные вызовы и возвраты функции?
Покрытие цикла . Каждый ли возможный цикл выполнялся ноль раз, один раз и более одного раза?
Покрытие состояний . Было ли достигнуто и исследовано каждое состояние в конечном автомате ?
Охват потока данных . Было ли получено и изучено определение каждой переменной и ее использование? ^{[ 10 ]}

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

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

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

Вместо этого методы практического тестирования покрытия путей пытаются идентифицировать классы путей кода, которые различаются только количеством выполнения циклов, и для достижения покрытия «базового пути» тестер должен охватить все классы путей. ^{[ нужна ссылка ]}^{[ нужны разъяснения ]}

На практике

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

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

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

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

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

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

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

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

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

Покрытие испытаний также является требованием части 6 стандарта автомобильной безопасности ISO 26262 «Дорожные транспортные средства — функциональная безопасность» . ^{[ 19 ]}

См. также

Ссылки

^ Брейдер, Ларри; Хилликер, Хоуи; Уиллс, Алан (2 марта 2013 г.). «Глава 2 Модульное тестирование: тестирование изнутри». Тестирование непрерывной доставки с помощью Visual Studio 2012 . Майкрософт. п. 30. ISBN 978-1621140184 . Проверено 16 июня 2016 г.
^ Уильямс, Лори ; Смит, Бен; Хекман, Сара. «Тестовое покрытие с помощью EclEmma» . Открытый семинар «Программная инженерия» . Государственный университет Северной Каролины. Архивировано из оригинала 14 марта 2016 года . Проверено 16 июня 2016 г.
^ Джоан С. Миллер, Клиффорд Дж. Мэлони (февраль 1963 г.). «Систематический анализ ошибок цифровых компьютерных программ» . Коммуникации АКМ . 6 (2). Нью-Йорк, штат Нью-Йорк, США: ACM : 58–63. дои : 10.1145/366246.366248 . ISSN 0001-0782 .
^ Пол Амманн, Джефф Оффатт (2013). Введение в тестирование программного обеспечения . Издательство Кембриджского университета.
^ Гленфорд Дж. Майерс (2004). Искусство тестирования программного обеспечения, 2-е издание . Уайли. ISBN 0-471-46912-2 .
^ Документ с изложением позиции CAST-10 (июнь 2002 г.). Что такое «решение» при применении измененного покрытия условий/решений (MC/DC) и покрытия решений (DC)?
^ Математика. Типы модельного покрытия.
^ «Модульное тестирование с покрытием значений параметров (PVC)» .
^ М. Р. Вудворд, М. А. Хеннелл, «О взаимосвязи между двумя критериями покрытия потока управления: всеми JJ-путями и MCDC», Information and Software Technology 48 (2006), стр. 433-440.
^ Тин Су, Кэ Ву, Вэйкай Мяо, Гегуан Пу, Цзифэн Хэ, Ютин Чен и Чжэндун Су. «Опрос по тестированию потоков данных». АКМ Компьютер. Выж. 50, 1, статья 5 (март 2017 г.), 35 с.
^ ECSS-E-ST-40C: Космическая техника — Программное обеспечение. Секретариат ECSS, ESA-ESTEC. Март, 2009 г.
^ К. Прауз, Дж. Вернер, К. Хорниг, С. Босекер, М. Курманн (2017): Является ли 100% тестовое покрытие разумным требованием? Уроки, извлеченные из проекта космического программного обеспечения . В: ПРОФЕС 2017. Спрингер. Последний доступ: 17.11.2017.
^ Блог Мартина Фаулера: TestCoverage. Последний доступ: 17.11.2017.
^ Дорф, Ричард К.: Компьютеры, разработка программного обеспечения и цифровые устройства , Глава 12, стр. 15. ЦРК Пресс, 2006. ISBN 0-8493-7340-9 , ISBN 978-0-8493-7340-4 ; через Поиск книг Google
^ Ю.Н. Шрикант; Прити Шанкар (2002). Справочник по проектированию компиляторов: оптимизации и генерация машинного кода . ЦРК Пресс. п. 249. ИСБН 978-1-4200-4057-9 .
^ Jump up to: ^а ^б RTCA/ DO-178B , Вопросы программного обеспечения при сертификации бортовых систем и оборудования, Радиотехническая комиссия по аэронавтике, 1 декабря 1992 г.
^ Борис Бейзер (2009). Методы тестирования программного обеспечения, 2-е издание . Дримтек пресс. ISBN 978-81-7722-260-9 .
^ RTCA/ DO-178C , Вопросы программного обеспечения при сертификации бортовых систем и оборудования, Радиотехническая комиссия по аэронавтике, январь 2012 г.
^ ISO 26262-6:2011(ru) Транспорт дорожный. Функциональная безопасность. Часть 6. Разработка продукции на уровне программного обеспечения . Международная организация по стандартизации.

[Brader,_2013-1] Брейдер, Ларри; Хилликер, Хоуи; Уиллс, Алан (2 марта 2013 г.). «Глава 2 Модульное тестирование: тестирование изнутри». Тестирование непрерывной доставки с помощью Visual Studio 2012 . Майкрософт. п. 30. ISBN 978-1621140184 . Проверено 16 июня 2016 г.

[Williams_2003-2] Уильямс, Лори ; Смит, Бен; Хекман, Сара. «Тестовое покрытие с помощью EclEmma» . Открытый семинар «Программная инженерия» . Государственный университет Северной Каролины. Архивировано из оригинала 14 марта 2016 года . Проверено 16 июня 2016 г.

[3] Джоан С. Миллер, Клиффорд Дж. Мэлони (февраль 1963 г.). «Систематический анализ ошибок цифровых компьютерных программ» . Коммуникации АКМ . 6 (2). Нью-Йорк, штат Нью-Йорк, США: ACM : 58–63. дои : 10.1145/366246.366248 . ISSN 0001-0782 .

[4] Пол Амманн, Джефф Оффатт (2013). Введение в тестирование программного обеспечения . Издательство Кембриджского университета.

[5] Гленфорд Дж. Майерс (2004). Искусство тестирования программного обеспечения, 2-е издание . Уайли. ISBN 0-471-46912-2 .

[Position_Paper_CAST10-6] Документ с изложением позиции CAST-10 (июнь 2002 г.). Что такое «решение» при применении измененного покрытия условий/решений (MC/DC) и покрытия решений (DC)?

[mathworks-7] Математика. Типы модельного покрытия.

[8] «Модульное тестирование с покрытием значений параметров (PVC)» .

[On_the_relationship_between_two_control-flow_coverage_criteria:_all_JJ-paths_and_MCDC-9] М. Р. Вудворд, М. А. Хеннелл, «О взаимосвязи между двумя критериями покрытия потока управления: всеми JJ-путями и MCDC», Information and Software Technology 48 (2006), стр. 433-440.

[A_Survey_on_Data-Flow_Testing-10] Тин Су, Кэ Ву, Вэйкай Мяо, Гегуан Пу, Цзифэн Хэ, Ютин Чен и Чжэндун Су. «Опрос по тестированию потоков данных». АКМ Компьютер. Выж. 50, 1, статья 5 (март 2017 г.), 35 с.

[ECSS-E-ST-40C-11] ECSS-E-ST-40C: Космическая техника — Программное обеспечение. Секретариат ECSS, ESA-ESTEC. Март, 2009 г.

[is_100_percent_reasonable-12] К. Прауз, Дж. Вернер, К. Хорниг, С. Босекер, М. Курманн (2017): Является ли 100% тестовое покрытие разумным требованием? Уроки, извлеченные из проекта космического программного обеспечения . В: ПРОФЕС 2017. Спрингер. Последний доступ: 17.11.2017.

[fowler_blog-13] Блог Мартина Фаулера: TestCoverage. Последний доступ: 17.11.2017.

[14] Дорф, Ричард К.: Компьютеры, разработка программного обеспечения и цифровые устройства , Глава 12, стр. 15. ЦРК Пресс, 2006. ISBN 0-8493-7340-9 , ISBN 978-0-8493-7340-4 ; через Поиск книг Google

[SrikantShankar2002-15] Ю.Н. Шрикант; Прити Шанкар (2002). Справочник по проектированию компиляторов: оптимизации и генерация машинного кода . ЦРК Пресс. п. 249. ИСБН 978-1-4200-4057-9 .

[DO-178B-16] Jump up to: ^а ^б RTCA/ DO-178B , Вопросы программного обеспечения при сертификации бортовых систем и оборудования, Радиотехническая комиссия по аэронавтике, 1 декабря 1992 г.

[17] Борис Бейзер (2009). Методы тестирования программного обеспечения, 2-е издание . Дримтек пресс. ISBN 978-81-7722-260-9 .

[DO-178C-18] RTCA/ DO-178C , Вопросы программного обеспечения при сертификации бортовых систем и оборудования, Радиотехническая комиссия по аэронавтике, январь 2012 г.

[ISO26262part6-19] ISO 26262-6:2011(ru) Транспорт дорожный. Функциональная безопасность. Часть 6. Разработка продукции на уровне программного обеспечения . Международная организация по стандартизации.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]

[ 17 ]

[ 18 ]

[ 19 ]