Верификация программного обеспечения

Покрытие программного кода

Разбить на страницы
Показывать лекцию целиком

19.1. Проверка домашнего задания

Студенты приносят заполненные отчеты об ошибках для тех модулей, которые они тестировали на 5-ом семинаре. Преподаватель оценивает их тест-планы, тестовые модули и смотрит, удалось ли студентам найти все допущенные в методах ошибки.

19.2. Понятие покрытия

19.2.1. Покрытие программного кода

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

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

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

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

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

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

19.2.2. Уровни покрытия

19.2.2.1. По строкам программного кода (Statement Coverage)

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

Пример. В следующем фрагменте кода входными переменными являются prev и ShowMessage.

if (prev == "оператор" || prev == "унарный оператор")
{
    if (ShowMessage)
    {
        MessageBox.Show("Два подряд оператора на 
           " + i.ToString() + " символе."); 
    } 
    else 
    {
    	Log.Write("Два подряд оператора на " +
                   + i.ToString() + " символе.")
    }
    Program.res = 4;
    return "Error 04 at " +
       + i.ToString();
}

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

12
prev оператор оператор
ShowMessage true false

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

Также проблемы этого метода покрытия можно увидеть и на примерах других управляющих структур. Например, проблемы возникают при проверке циклов do ... while – при данном уровне покрытия достаточно выполнение цикла только один раз, при этом метод совершенно нечувствителен к логическим операторам || и .

Другой особенностью данного метода является зависимость уровня покрытия от структуры программного кода. На практике часто не требуется 100% покрытия программного кода, вместо этого устанавливается допустимый уровень покрытия, например 75%. Проблемы могут возникнуть при покрытии следующего фрагмента программного кода:

if (condition)
   MethodA();
else
   MethodB();

Если MethodA() содержит 99 операторов, а MethodB() — один оператор, то единственного тестового примера, устанавливающего condition в true, будет достаточно для достижения необходимого уровня покрытия. При этом аналогичный тестовый пример, устанавливающий значение condition в false, даст слишком низкий уровень покрытия.

19.2.2.2. По веткам условных операторов (Decision Coverage)

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

Также данный метод называют: branch coverage, all-edges coverage, basis path coverage, DC, C2, decision-decision-path.

В отличие от предыдущего уровня покрытия данный метод учитывает покрытие условных операторов с пустыми ветками.

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

123
prev оператор оператор операнд
ShowMessage true false true

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

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

if (condition1  (condition2 || Method()))
    statement1;
else
    statement2;

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

12
condition1 true false
condition2 true true/false

В обоих случаях не происходит вызова метода Method(), хотя покрытие данного участка кода будет полным. Для проверки вызова метода Method() необходимо добавить еще один тестовый пример (который, однако, не улучшает степени покрытия по веткам):

123
condition1 true false true
condition2 true true/false false

19.2.2.3. По компонентам логических условий

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

19.2.2.4. Покрытие по условиям (Condition Coverage)

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

if (condition1 || condition2)
  MethodA();
else
  MethodB();

для покрытия по условиям потребуется два тестовых примера:

12
condition1 true False
condition2 false True

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

19.2.2.5. Покрытие по веткам/условиям (Condition/Decision Coverage)

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

Для покрытия рассмотренного выше фрагмента с условием

(condition1 || condition2)

потребуется 2 тестовых примера:

12
condition1 true false
condition2 true false

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

19.2.2.6. Покрытие по всем условиям (Multiple Condition Coverage)

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

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

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

a  b  (c || (d  e))
((a || b)  (c || d))  e

потребуется разное количество тестовых примеров. Для первого случая для полного покрытия нужно 6 тестов, для второго – 11.

19.2.2.7. Метод MC/DC для уменьшения количества тестовых примеров при 3-м уровне покрытия кода

Для уменьшения количества тестовых примеров при тестировании логических условий фирмой Boeing был разработан модифицированный метод покрытия по веткам/условиям (Modified Condition/Decision Coverage или MC/DC). Данный метод широко используется при верификации бортового авиационного программного обеспечения согласно процессам стандарта DO-178B.

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

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

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

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

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

    if (A || B) 
{
 if (C) 
  {
   ...
  } 
 else 
  {
   ...
  }
}

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

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

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

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

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

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

    123
    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 требуется три тестовых примера:

  • AB = 0, C = 0 (базовый пример)
  • AB = 0, C = 1 (независимое влияние C на выход)
  • AB = 1, C = 0 (независимое влияние AB на выход)
    •

    В третьем тестовом примере значения 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 в этом примере могут быть любыми, при условии, что AB=0. Запишем второй тестовый пример как

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

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

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

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

    1233
    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 к исходным получим следующие тестовые примеры:

    1233
    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. Анализ покрытия

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

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

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

  • недостатков в формировании тестовых примеров или тестовых процедур, основанных на требованиях. В этом случае должны быть дополнен набор тестовых примеров или изменены тестовые процедуры для обеспечения покрытия упущенной части кода. При этом может потребоваться пересмотр метода (методов), используемого для проведения анализа полноты тестов на основе требований;
  • неадекватности в требованиях на программное обеспечение. В этом случае должны быть модифицированы требования на программное обеспечение, разработаны и выполнены дополнительные тестовые примеры и тестовые процедуры;
  • "мертвого" кода. Этот код должен быть удален, и проведен анализ для оценки эффекта удаления и необходимости перепроверки;
  • дезактивируемого кода. Для дезактивируемого кода, который не предполагается к выполнению в каждой конфигурации, сочетание анализа и тестов должно продемонстрировать возможности средств, которыми непреднамеренное исполнение такого кода предотвращается, изолируется или устраняется. Для дезактивируемого кода, который выполняется только при определенных конфигурациях, должна быть установлена нормальная эксплуатационная конфигурация для исполнения этого кода, и для нее должны быть разработаны дополнительные тестовые примеры и тестовые процедуры, удовлетворяющие целям полноты покрытия тестами структуры кода;
  • избыточности условия. Логика работы такого условия должна быть пересмотрена. Например, в условии if(A B || !B) принципиально невозможно проверить, что часть условия A B будет равна False в случае, когда A=True и B=False, так как вторая часть условия (!B) будет равна True и общий результат логического выражения будет True ;
  • защитного кода. Эта часть кода используется для предотвращения исключительных ситуаций, которые могут возникнуть в процессе работы программы. Как пример, это может быть ветка default в операторе выбора switch, причем входное условие оператора switch может принимать определенные значения, которые он описывает, и как следствие, ветка default никогда не будет выполнена.
    •

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    19.3. Возможности MVSTE по построению покрытия кода

    Замечание. Подробнее о покрытии кода можно прочитать по адресу: http://msdn2.microsoft.com/en-us/library/ms182496(VS.80).aspx

    Чтобы увидеть, какая часть кода вашего проекта фактически тестируется, используйте такой инструмент для тестировщиков в Visual Studio Team System, как Покрытие кода. Этот инструмент показывает процент кода, который был выполнен, и "раскрашивает" его, показывая, какие линии кода были выполнены, а какие нет.

    На прошлых семинарах мы познакомились с возможностями MVSTE по автоматизации модульного тестирования на примерах тестирования метода Add класса CalcClass и метода RunEstimate класса AnalaizerClass. Покажем на этих же примерах, какую часть кода покрыли созданные нами модульные тесты.

    Для начала откроем BaseCalculator, с которым мы работали на семинаре 5.

    Далее в меню Test выбираем Edit Test Run Configuration. В подменю выбираем Local Test Run ( localtestrun.testrunconfig ), чтобы запустить файл конфигурации. (аналогично запустить файл конфигурации можно, щелкнув в Solution Explorer под Solution Items на localtestrun.testrunconfig ). Появится диалоговое окно localtestrun.testrunconfig (рис. 19.2).

    (рис 19.2) Диалоговое окно "localtestrun.testrunconfig"

    Выбираем Code Coverage.

    В поле Select artifacts to instrument отмечаем пункты BaseCalculator.exe и BaseCalculator.Test.dll

    Замечание. Если вы выбрали BaseCalculator.Test.dll, то MVSTE генерирует информацию о покрытии кода для методов в вашем тестовом проекте.

    Нажмите Apply, затем закройте диалоговое окно. Мы настроили файл конфигурации.

    Далее в меню Test выберите Select Active Test Run Configuration. Подменю показывает все конфигурации запуска теста вашего решения. Поместим метку на конфигурацию запуска, которую мы только что редактировали, localtestrun.testrunconfig ; что сделает её активной конфигурацией запуска теста.

    В окне Test View выделяем все тесты и нажимаем кнопку Run Selection. Запустятся созданные нами на 5-ом семинаре тесты.

    После выполнения всех тестов в окне Test Results в меню Test выберем Windows и в раскрывшемся подменю нажмем на Code Coverage Results. Откроется окно Code Coverage Results. (рис. 19.3)

    (рис 19.3) Окно "Code Coverage Results"

    Замечание. Колонка Hierarchy изначально показывает единственный узел (в данном случае Belf@BLEFF 2006-11-08 01:34:12), который содержит данные обо всем покрытии кода, достигнутом в последнем запущенном и выполненном тесте. Он назван, используя следующий формат: <user name>@<computer name> <date> <time>.

    Если вы раскроете этот узел, то увидите выбранные нами в файле конфигурации проекты BaseCalculator.exe и BaseCalculator.Test.dll

    Раскроем узел для сборки BaseCalculator.exe, для пространства имен BaseCalculator и для класса CalcClass, как показано на рис.19.4.

    (рис 19.4) Окно "Code Coverage Results"

    Строки в классе CalcClass представляют его методы. Колонки в окне Code Coverage Results показывают статистику покрытия для отдельных методов, для классов, и для всего пространства имен.

    Замечание. В этой таблице можно выбирать, в каком порядке и какие колонки будут отображаться. Для этого нужно нажать правой кнопкой мыши в окне Code Coverage Results и выбрать в контекстном меню пункт Add/Remove Columns.

    Замечание. Статистика покрытия кода показывает покрытие блоков и линий кода.

    Чтобы посмотреть, какая именно часть кода была покрыта, щелкнем два раза на строку с методом Add.

    Откроется файл исходного текста CalcClass.cs на методе Add. В этом файле мы видем "окрашенный" код. Линии, окрашенные в голубой цвет, были выполнены в процессе выполнения тестов, а линии, окрашенные в красный, не были выполнены. (рис.19.5)

    Замечание. Цвета окрашивания линий покрытия кода можно изменить. Для этого нужно зайти в Tools->Options. В открывшемся диалоговом окне нужно выбрать Environment->Fonts and Colors. Далее в раскрывающемся списке Show settings for выбираем Text Editor. Далее в Display items нужно выбрать область покрытия кода, цвет которой вы хотите изменить: это Coverage Not Touched Area, или Coverage Partially Touched Area, или Coverage Touched Area. Для этих областей покрытия кода можно изменить шрифт, его размер, жирность, цвет текста и его "окрашивание". По завершении, чтобы сохранить изменения и выйти из диалогового окна, нажмите OK.

    (рис 19.5) "Окрашивание" покрытия кода

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

    Замечание. Точно так же можно просмотреть покрытие кода наших модульных тестов, то есть, можно увидеть, какие из тестовых методов были осуществлены (раскрыв в окне Code Coverage Results сборку BaseCalculator.Test.dll ). Применяется та же самая схема окрашивания: голубой показывает выполненный в процессе выполнения теста код; красный — невыполненный.

    , указать имя и местоположение файла.

    19.4. Раздаточный материал

    19.4.1. Программа

    Модульные тесты, которые написали студенты, выполнив домашнее задание 5-го семинара.

    19.5. Домашнее задание

    Доработать модульные тесты, добившись максимального покрытия кода по MC\DC.

    Страницы:

    19.1. Проверка домашнего задания

    Студенты приносят заполненные отчеты об ошибках для тех модулей, которые они тестировали на 5-ом семинаре. Преподаватель оценивает их тест-планы, тестовые модули и смотрит, удалось ли студентам найти все допущенные в методах ошибки.

    19.2. Понятие покрытия

    19.2.1. Покрытие программного кода

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

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

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

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

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

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

    19.2.2. Уровни покрытия

    19.2.2.1. По строкам программного кода (Statement Coverage)

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

    Пример. В следующем фрагменте кода входными переменными являются prev и ShowMessage.

    if (prev == "оператор" || prev == "унарный оператор")
{
    if (ShowMessage)
    {
        MessageBox.Show("Два подряд оператора на 
           " + i.ToString() + " символе."); 
    } 
    else 
    {
    	Log.Write("Два подряд оператора на " +
                   + i.ToString() + " символе.")
    }
    Program.res = 4;
    return "Error 04 at " +
       + i.ToString();
}

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

    12
    prev оператор оператор
    ShowMessage true false

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

    Также проблемы этого метода покрытия можно увидеть и на примерах других управляющих структур. Например, проблемы возникают при проверке циклов do ... while – при данном уровне покрытия достаточно выполнение цикла только один раз, при этом метод совершенно нечувствителен к логическим операторам || и .

    Другой особенностью данного метода является зависимость уровня покрытия от структуры программного кода. На практике часто не требуется 100% покрытия программного кода, вместо этого устанавливается допустимый уровень покрытия, например 75%. Проблемы могут возникнуть при покрытии следующего фрагмента программного кода:

    if (condition)
   MethodA();
else
   MethodB();

    Если MethodA() содержит 99 операторов, а MethodB() — один оператор, то единственного тестового примера, устанавливающего condition в true, будет достаточно для достижения необходимого уровня покрытия. При этом аналогичный тестовый пример, устанавливающий значение condition в false, даст слишком низкий уровень покрытия.

    19.2.2.2. По веткам условных операторов (Decision Coverage)

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

    Также данный метод называют: branch coverage, all-edges coverage, basis path coverage, DC, C2, decision-decision-path.

    В отличие от предыдущего уровня покрытия данный метод учитывает покрытие условных операторов с пустыми ветками.

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

    123
    prev оператор оператор операнд
    ShowMessage true false true

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

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

    if (condition1  (condition2 || Method()))
    statement1;
else
    statement2;

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

    12
    condition1 true false
    condition2 true true/false

    В обоих случаях не происходит вызова метода Method(), хотя покрытие данного участка кода будет полным. Для проверки вызова метода Method() необходимо добавить еще один тестовый пример (который, однако, не улучшает степени покрытия по веткам):

    123
    condition1 true false true
    condition2 true true/false false

    19.2.2.3. По компонентам логических условий

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

    19.2.2.4. Покрытие по условиям (Condition Coverage)

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

    if (condition1 || condition2)
  MethodA();
else
  MethodB();

    для покрытия по условиям потребуется два тестовых примера:

    12
    condition1 true False
    condition2 false True

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

    19.2.2.5. Покрытие по веткам/условиям (Condition/Decision Coverage)

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

    Для покрытия рассмотренного выше фрагмента с условием

    (condition1 || condition2)

    потребуется 2 тестовых примера:

    12
    condition1 true false
    condition2 true false

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

    19.2.2.6. Покрытие по всем условиям (Multiple Condition Coverage)

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

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

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

    a  b  (c || (d  e))
((a || b)  (c || d))  e

    потребуется разное количество тестовых примеров. Для первого случая для полного покрытия нужно 6 тестов, для второго – 11.

    19.2.2.7. Метод MC/DC для уменьшения количества тестовых примеров при 3-м уровне покрытия кода

    Для уменьшения количества тестовых примеров при тестировании логических условий фирмой Boeing был разработан модифицированный метод покрытия по веткам/условиям (Modified Condition/Decision Coverage или MC/DC). Данный метод широко используется при верификации бортового авиационного программного обеспечения согласно процессам стандарта DO-178B.

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

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

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

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

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

    if (A || B) 
{
 if (C) 
  {
   ...
  } 
 else 
  {
   ...
  }
}

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

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

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

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

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

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

    123
    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 требуется три тестовых примера:

  • AB = 0, C = 0 (базовый пример)
  • AB = 0, C = 1 (независимое влияние C на выход)
  • AB = 1, C = 0 (независимое влияние AB на выход)
    •

    В третьем тестовом примере значения 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 в этом примере могут быть любыми, при условии, что AB=0. Запишем второй тестовый пример как

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

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

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

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

    1233
    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 к исходным получим следующие тестовые примеры:

    1233
    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. Анализ покрытия

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

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

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

  • недостатков в формировании тестовых примеров или тестовых процедур, основанных на требованиях. В этом случае должны быть дополнен набор тестовых примеров или изменены тестовые процедуры для обеспечения покрытия упущенной части кода. При этом может потребоваться пересмотр метода (методов), используемого для проведения анализа полноты тестов на основе требований;
  • неадекватности в требованиях на программное обеспечение. В этом случае должны быть модифицированы требования на программное обеспечение, разработаны и выполнены дополнительные тестовые примеры и тестовые процедуры;
  • "мертвого" кода. Этот код должен быть удален, и проведен анализ для оценки эффекта удаления и необходимости перепроверки;
  • дезактивируемого кода. Для дезактивируемого кода, который не предполагается к выполнению в каждой конфигурации, сочетание анализа и тестов должно продемонстрировать возможности средств, которыми непреднамеренное исполнение такого кода предотвращается, изолируется или устраняется. Для дезактивируемого кода, который выполняется только при определенных конфигурациях, должна быть установлена нормальная эксплуатационная конфигурация для исполнения этого кода, и для нее должны быть разработаны дополнительные тестовые примеры и тестовые процедуры, удовлетворяющие целям полноты покрытия тестами структуры кода;
  • избыточности условия. Логика работы такого условия должна быть пересмотрена. Например, в условии if(A B || !B) принципиально невозможно проверить, что часть условия A B будет равна False в случае, когда A=True и B=False, так как вторая часть условия (!B) будет равна True и общий результат логического выражения будет True ;
  • защитного кода. Эта часть кода используется для предотвращения исключительных ситуаций, которые могут возникнуть в процессе работы программы. Как пример, это может быть ветка default в операторе выбора switch, причем входное условие оператора switch может принимать определенные значения, которые он описывает, и как следствие, ветка default никогда не будет выполнена.
    •

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    19.3. Возможности MVSTE по построению покрытия кода

    Замечание. Подробнее о покрытии кода можно прочитать по адресу: http://msdn2.microsoft.com/en-us/library/ms182496(VS.80).aspx

    Чтобы увидеть, какая часть кода вашего проекта фактически тестируется, используйте такой инструмент для тестировщиков в Visual Studio Team System, как Покрытие кода. Этот инструмент показывает процент кода, который был выполнен, и "раскрашивает" его, показывая, какие линии кода были выполнены, а какие нет.

    На прошлых семинарах мы познакомились с возможностями MVSTE по автоматизации модульного тестирования на примерах тестирования метода Add класса CalcClass и метода RunEstimate класса AnalaizerClass. Покажем на этих же примерах, какую часть кода покрыли созданные нами модульные тесты.

    Для начала откроем BaseCalculator, с которым мы работали на семинаре 5.

    Далее в меню Test выбираем Edit Test Run Configuration. В подменю выбираем Local Test Run ( localtestrun.testrunconfig ), чтобы запустить файл конфигурации. (аналогично запустить файл конфигурации можно, щелкнув в Solution Explorer под Solution Items на localtestrun.testrunconfig ). Появится диалоговое окно localtestrun.testrunconfig (рис. 19.2).

    (рис 19.2) Диалоговое окно "localtestrun.testrunconfig"

    Выбираем Code Coverage.

    В поле Select artifacts to instrument отмечаем пункты BaseCalculator.exe и BaseCalculator.Test.dll

    Замечание. Если вы выбрали BaseCalculator.Test.dll, то MVSTE генерирует информацию о покрытии кода для методов в вашем тестовом проекте.

    Нажмите Apply, затем закройте диалоговое окно. Мы настроили файл конфигурации.

    Далее в меню Test выберите Select Active Test Run Configuration. Подменю показывает все конфигурации запуска теста вашего решения. Поместим метку на конфигурацию запуска, которую мы только что редактировали, localtestrun.testrunconfig ; что сделает её активной конфигурацией запуска теста.

    В окне Test View выделяем все тесты и нажимаем кнопку Run Selection. Запустятся созданные нами на 5-ом семинаре тесты.

    После выполнения всех тестов в окне Test Results в меню Test выберем Windows и в раскрывшемся подменю нажмем на Code Coverage Results. Откроется окно Code Coverage Results. (рис. 19.3)

    (рис 19.3) Окно "Code Coverage Results"

    Замечание. Колонка Hierarchy изначально показывает единственный узел (в данном случае Belf@BLEFF 2006-11-08 01:34:12), который содержит данные обо всем покрытии кода, достигнутом в последнем запущенном и выполненном тесте. Он назван, используя следующий формат: <user name>@<computer name> <date> <time>.

    Если вы раскроете этот узел, то увидите выбранные нами в файле конфигурации проекты BaseCalculator.exe и BaseCalculator.Test.dll

    Раскроем узел для сборки BaseCalculator.exe, для пространства имен BaseCalculator и для класса CalcClass, как показано на рис.19.4.

    (рис 19.4) Окно "Code Coverage Results"

    Строки в классе CalcClass представляют его методы. Колонки в окне Code Coverage Results показывают статистику покрытия для отдельных методов, для классов, и для всего пространства имен.

    Замечание. В этой таблице можно выбирать, в каком порядке и какие колонки будут отображаться. Для этого нужно нажать правой кнопкой мыши в окне Code Coverage Results и выбрать в контекстном меню пункт Add/Remove Columns.

    Замечание. Статистика покрытия кода показывает покрытие блоков и линий кода.

    Чтобы посмотреть, какая именно часть кода была покрыта, щелкнем два раза на строку с методом Add.

    Откроется файл исходного текста CalcClass.cs на методе Add. В этом файле мы видем "окрашенный" код. Линии, окрашенные в голубой цвет, были выполнены в процессе выполнения тестов, а линии, окрашенные в красный, не были выполнены. (рис.19.5)

    Замечание. Цвета окрашивания линий покрытия кода можно изменить. Для этого нужно зайти в Tools->Options. В открывшемся диалоговом окне нужно выбрать Environment->Fonts and Colors. Далее в раскрывающемся списке Show settings for выбираем Text Editor. Далее в Display items нужно выбрать область покрытия кода, цвет которой вы хотите изменить: это Coverage Not Touched Area, или Coverage Partially Touched Area, или Coverage Touched Area. Для этих областей покрытия кода можно изменить шрифт, его размер, жирность, цвет текста и его "окрашивание". По завершении, чтобы сохранить изменения и выйти из диалогового окна, нажмите OK.

    (рис 19.5) "Окрашивание" покрытия кода

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

    Замечание. Точно так же можно просмотреть покрытие кода наших модульных тестов, то есть, можно увидеть, какие из тестовых методов были осуществлены (раскрыв в окне Code Coverage Results сборку BaseCalculator.Test.dll ). Применяется та же самая схема окрашивания: голубой показывает выполненный в процессе выполнения теста код; красный — невыполненный.

    , указать имя и местоположение файла.

    19.4. Раздаточный материал

    19.4.1. Программа

    Модульные тесты, которые написали студенты, выполнив домашнее задание 5-го семинара.

    19.5. Домашнее задание

    Доработать модульные тесты, добившись максимального покрытия кода по MC\DC.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^