теория_6 (Методичка и инструкции на ЛР №8), страница 2

Для обеспечения полного покрытия по этому методу необходимо выполнение следующих условий:

• каждое логическое условие должно принимать все возможные значения;

• каждая компонента логического условия должна хотя бы один раз принимать все возможные значения;

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

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

Пример 1. Рассмотрим фрагмент кода, который мы использовали как пример для покрытия по строкам и по веткам. Для покрытия данного участка кода по методу MC/DC введем условные обозначения. Обозначим проверку prev == "оператор" как A, проверку prev == "унарный оператор" - как B, а переменную ShowMessage — как C. Первые два обозначения сделаны для того, чтобы элементарными переменными для метода MC/DC были булевы переменные, а третье обозначение — для единообразия.

С учетом сделанных обозначений фрагмент кода может быть записан так:

if (A || B)

{

if (C)

{

…

}

else

{

…

}

}

Для тестирования первого условия по MC/DC надо показать независимость результата (т.е. функции A || B) от каждого аргумента. Соответственно, для этого используются три тестовых примера:

1. A = 0, B = 0, A || B = 0 (начальное значение)

2. A = 1, B = 0, A || B = 1 (показано влияние аргумента A)

3. A = 0, B = 1, A || B = 1 (показано влияние аргумента B)

Для тестирования ветвей (входящего в MC/DC) в зависимости от условия C необходимо, чтобы в тестовых примерах C принимало значение как true, так и false.

Итоговая таблица тестовых примеров для покрытия по MC/DC будет выглядеть следующим образом:

	1	2	3	4
prev	операнд(A=0, B=0)	оператор(A=1,B=0)	унарный оператор (A=0, B=1)	оператор
ShowMessage	false	false	false	true

Количество тестовых примеров можно сократить до 3, если совместить примеры 3 и 4. Такое совмещение не повлияет на покрытие.

	1	2	3
prev	операнд(A=0, B=0)	оператор(A=1,B=0)	унарный оператор(A=0, B=1)
ShowMessage	false	false	true

Пример 2. Для покрытия по MC/DC более сложных выражений рассмотрим следующий участок кода:

if ((operators.Count != 0 && operators.Peek().ToString() ==

== "m") || operators.Peek().ToString() == "p")

{

strarr.Add(operators.Pop());

}

Исходное условное выражение в операторе if можно записать как (A & B) || C. Данное выражение зависит от 3 переменных, т.е. может быть рассмотрено как булева функция с тремя аргументами. Согласно методу MC/DC для тестирования функции с тремя входами достаточно 4 тестовых примеров – один базовый и три показывающих независимое влияние каждого входа на выход.

Начнем построение набора тестов с самой внешней операции, т.е. с ||. Одним из аргументов этой операции является выражение (A & B). Будем пока рассматривать это выражение как единое целое. Для тестирования операции || по MC/DC требуется три тестовых примера:

1. A&B = 0, C = 0 (базовый пример)

2. A&B = 0, C = 1 (независимое влияние C на выход)

3. A&B = 1, C = 0 (независимое влияние A&B на выход)

В третьем тестовом примере значения A и B могут быть получены сразу, т.е. имеем

1) A = 1, B = 1, C = 0

Значения A = 1 и B = 1 являются базовыми для тестирования по MC/DC операции &&. Соответственно, необходимо рассмотреть еще два случая, при которых A = 0, B = 1 и A = 1, B = 0 для демонстрации независимого влияния аргументов A и B на значение функции. При этом необходимо, чтобы аргумент С был равен 0, дабы исключить его влияние на выход. Исходя из этих соображений, первый тестовый пример может быть записан как

1) A = 1, B = 0, C = 0

т.е. при этом проверяется влияние переменной B на значение функции. Во втором тестовом примере значение C = 1, поэтому он не может быть использован для проверки независимости аргументов A и B. Значения A и B в этом примере могут быть любыми, при условии, что A&B=0. Запишем второй тестовый пример как

2) A = 1, B = 0, C = 1

Для тестирования независимого влияния аргумента A необходимо добавить еще один тестовый пример, в котором A = 0, B =1:

4) A = 0, B = 1, C = 0

Таким образом, мы построили 4 тестовых примера для проверки данного участка кода.

	1	2	3	3
A	1 (true)	1 (true)	1 (true)	0 (false)
B	0 (false)	0 (false)	1 (true)	1 (true)
C	0 (false)	1 (true)	0 (false)	0 (false)

При переходе от обозначений A, B, C к исходным получим следующие тестовые примеры:

	1	2	3	3
operators.Count	10 (не 0)	10 (не 0)	10 (не 0)	0 (равен 0)
operators.Peek().ToString()	"k" (не m и не p)	"p" (не m, но "p")	"m" (m, но не p)	"m" (m, но не p)

19.2.3. Анализ покрытия

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

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

2. Анализ полноты покрытия тестами структуры кода может быть выполнен с использованием исходного текста, если программное обеспечение не относится к уровню A. Для уровня А необходимо проверить объектный код, сгенерированный компилятором, чтобы установить, трассируется ли он в Исходный текст или нет. Если Объектный код не трассируется в Исходный текст, должны быть проведены поверки объектного кода на предмет правильности генерации последовательности команд. Примером объектного кода, который напрямую не трассируется в Исходный текст, но генерируется компилятором, может быть проверка выхода за заданные границы массива.

3. Анализ должен подтвердить правильность передачи данных и управления между компонентами кода.

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

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

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

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

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

5. избыточности условия. Логика работы такого условия должна быть пересмотрена. Например, в условии if(A && B || !B) принципиально невозможно проверить, что часть условия A && B будет равна False в случае, когда A=True и B=False, так как вторая часть условия (!B) будет равна True и общий результат логического выражения будет True;

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

19.2.4. Отчеты о покрытии программного кода

19.2.4.1. Отчеты о покрытии и их связь с другими типами проектной документации

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

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

Рис. 19.1.  Генерация отчета о покрытии и изменения по результатам его анализа

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

19.2.4.2. Возможные формы отчетов о покрытии

Типичный отчет о покрытии представляет собой список структурных элементов покрываемого программного кода (функций или методов), содержащий для каждого структурного элемента следующую информацию:

1. название функции или метода;

2. тип покрытия (по строкам, по ветвям, MC/DC или иной);

3. количество покрываемых элементов в функции или методе (строк, ветвей, логических условий);

4. степень покрытия функции или метода (в процентах или в абсолютном выражении);

5. список непокрытых элементов (в виде участков непокрытого программного кода с номерами строк).

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

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

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

19.2.4.3. Покрытие на уровне исходных текстов и на уровне машинных кодов

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