Документация, сопровождающая процесс верификации и тестирования (отчеты)

Рассмотрим более подробно каждую из характеристик.

True-false decisions - количество логических выражений, в данном случае их 1405. Из этого числа на оба возможных значения ( True и False ) покрыто лишь 674, еще 494 покрыто на какое-то одно из значений, а 237 не покрыто вообще.

Conditions in the decisions - количество логических условий внутри логических выражений. Как можно догадаться, их количество не может быть меньше количества логических выражений. Непокрытие логических условий явным образом влечет за собой непокрытие логических выражений. Факт, что если все условия будут покрыты, то все выражения также будут покрыты.

Case branches - количество веток ветвления операторов выбора ( select ). Ветка считается покрытой, если выражение, стоящее в условии оператора select, принимает значение, соответствующее данному варианту выбора ( case ), в результате чего ветка выполняется.

Coverage events - в данном случае, это количество точек входа / выхода в функциях. Точка входа в функцию считается покрытой, если эта функция была вызвана хотя бы один раз. Точками выхода являются точка окончания функции ( } ), когда управление передается в место вызова этой функции, а также операторы возврата ( return ), после выполнения которых управление также передается в место вызова функции.

Затем выводится информация для первого модуля, а именно: имя модуля, путь к файлу на диске, дата последнего изменения, контрольная сумма. После этого выводится суммарная информация о покрытии только для этого модуля (для всех его функций, количество которых также указывается). Структура этой информации аналогична структуре, описанной выше:

1. File <Module_1_name.cpp> in <Path_to_module_1>
    Last Modified: Fri Oct 15 18:34:14 2004
    Checksum: CEDBAB67

    File Summary (Extended MCDC): 6 Functions
       24 true-false decisions
           10  41.7%  covered
           11  45.8%  partially covered
            3  12.5%  not covered
       39 conditions in the decisions
           20  51.3%  covered
           15  38.5%  partially covered
            4  10.3%  not covered
        0 case branches
       12 coverage events
           12 100.0%  covered
            0   0.0%  not covered

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

COVERED - участок полностью покрыт в понятиях типа, к которому он приписан;

PARTIALLY covered - участок частично покрыт. Применимо только к логическим выражениям и условиям и указывает на то, что выражение (условие) покрыто на какое-то одно из двух возможных значений;

NOT covered - участок не покрыт. Это означает, что данный участок не выполнялся в процессе работы скомпилированного программного кода.

Ниже представлен типичный результат покрытия для функции.

1.1 Function <Function_1>
        void Function_1(void)

        Function Summary (MCDC):
            3 true-false decisions
                0   0.0%  covered
                2  66.7%  partially covered
                1  33.3%  not covered
            5 conditions in the decisions
                1  20.0%  covered
                3  60.0%  partially covered
                1  20.0%  not covered
            0 case branches
            2 coverage events
                2 100.0%  covered
                0   0.0%  not covered

        coverage line 266: function entry
            COVERED

        decision line 267: if statement
            if ((A == B)  (...

             T     F
         1: *ttt  *fxx  ((A == ...)    COVERED
         2: *ttt   tfx  ((C...)        PARTIALLY covered
         3: *ttt   ttf  ((D == 0)        PARTIALLY covered

        decision line 271: if statement
            if (E <= 0)

             T   F
         1:  t  *f  (E <= 0)   PARTIALLY covered

        decision line 276: if statement
            if (D == 0)

             T   F
         1:  t   f  (D...)   NOT covered

        coverage line 291: function end
            }
            COVERED

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

if ((A==B)  (C > 0)  (D == 0))

и пусть результат покрытия для него такой, как приведен выше ( decision line 267: if statement ). Для этого выражения строится таблица, где в каждой строке помещается информация для каждого из логических условий, входящих в это логическое выражение. Нумерация логических условий начинается с 1, в нашем случае их 3.

В первом столбце указывается комбинация значений логических условий (с участием рассматриваемого условия), которую необходимо выставить, чтобы логическое выражение приняло значение True. В данном случае, так как все условия соединены логическим оператором "И" ( ), такой комбинацией может быть только TTT. Если указанная комбинация была сформирована в процессе тестирования программы, то она помечается символом ( * ).

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

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

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

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

Отчеты о покрытиях, создаваемые Microsoft Visual Studio Team Edition, будут рассмотрены на семинарских занятиях.

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

В некоторых случаях инструментальные средства сбора покрытия анализируют покрытие программного кода тестами не на уровне исходных текстов системы, а на уровне машинных инструкций. В этом случае степень покрытия зависит и от того, какой исполняемый код генерируется компилятором. Отчеты о покрытии в этом случае выглядят следующим образом (отчет о покрытии сгененирован при помощи отладчика Microtec XRAY для Motorola 680x0):

******* INSTRUCTION EXECUTION COVERAGE - Analyze Unit: Menu_Display
Function: DATA_PROCESSING\Menu_Display.  Instruction(s) not executed:
  5668             switch (Key) 
0004A0F6 0352              BCHG    D1,(A2)                            
0004A102 0466 0466         SUBI.W  #$466,-(A6)
0004A106 0466 0466         SUBI.W  #$466,-(A6)
0004A10A 0466 0466         SUBI.W  #$466,-(A6)
0004A10E 0466 0466         SUBI.W  #$466,-(A6)
0004A112 0466 0466         SUBI.W  #$466,-(A6)
0004A116 0466 0474         SUBI.W  #$474,-(A6)
  5751                       i = 1; 
0004A4A6 7401              MOVEQ   #$1,D2
   Executed     Total   Percent  Analyze-unit
        467       475     98.32  DATA_PROCESSING\Menu_Display
                0 unit(s) excluded.

******* BRANCH EXECUTION COVERAGE - Analyze Unit: Menu_Display
Function: DATA_PROCESSING\Menu_Display.  Branch(es) not executed:
  5612      if ( First_Call == TRUE ) {  /* Only execute this block during th
00049E3A 6600 0722         BNE.W   $4A55E               Branch not taken.
  5613              if ( MP_Rd_Config_Straps ( RAW_STRAPS, Strap_Config ) ==
00049E52 664A              BNE.B   $49E9E               Branch not taken.
  5750                    if (i == 17) 
0004A4A4 6602              BNE.B   $4A4A8               Fall thru not taken.
   Executed     Total   Percent  Analyze-unit
         74        77     96.10  DATA_PROCESSING\Menu_Display
                0 unit(s) excluded.

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

Например, в случае покрытия следующей конструкции на языке C:

typedef enum
{
CC1 = 250,
CC2 = 251,
CC3 = 252
} E_CC;
   … 
E_CC key;
   …
switch (key) {
   case CC1: printf("CC1"); break; 
   case CC2: printf("CC2"); break; 
   case CC3: printf("CC3"); break; 
}

компилятор Microtec C для Motorola 680x0 создаст таблицу возможных значений переменной key, в которой будут присутствовать все элементы от 0 до 255. Реально в программной системе возможно передать только значения констант CC1 - CC3, и в результате покрытыми окажутся только три ветки из 255 возможных в исполняемом коде. Никакими стандартными средствами увеличить степень такого покрытия нельзя. В этом случае отчет о покрытии сопровождается дополнительной информацией о причинах невозможности обеспечить полное покрытие.

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

13.2. Отчеты о проблемах

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

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

Главное, что должно быть включено в отчет об ошибке, - это:

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

13.2.2. Структура отчетов о проблемах, их трассировка на программный код и документацию

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

Обычный вид отчета о проблеме, соответствующего данной структуре, следующий:

Отчет о проблеме

Порядковый номер отчета:

Автор отчета:  ___________________    Дата создания отчета: __ __ __

Документы/разделы, связанные с проблемой:
  ……………………………………..
Идентификация объекта/процесса, где проявляется проблема:
………………………………………………………………………………………….

Определение проблемы:
………………………………………………………………………………………….

Автор решения: ___________________  Дата формирования решения __ __ __

Принятое решение: (возможно, ссылки на изменяемые компоненты/запросы на изменения)
………………………………………………………………………………………….

Результаты анализа, определяющие, на содержание каких компонент влияет решение:
………………………………………………………………………………………….

План проверок, восстанавливающих текущее состояние документов разработки
………………………………………………………………………………………….

Оценка принятого автором отчета решения о проблеме: _
………………………………………………………………………………………….
 ( 0 = полностью согласен
  1 = не все аспекты проблемы учтены/разрешены
  2 = основная часть проблемы осталась неразрешенной
  3 = решение не адекватно проблеме - не устраняет ее)

13.3. Трассировочные таблицы

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

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

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

[ANCHOR: код]

Здесь код записывается в виде AAA_RR_NNNNNN, где AAA - тип документа (SYS, ORD и т.п.), RR - номер раздела верхнего уровня, в котором содержится якорь, и NNNNNN - номер ссылки с ведущими нулями.

Требование в таком виде будет выглядеть следующим образом:

Для каждого вычислимого атрибута должна быть определена роль, 
от которой производится вычисления. [ANCHOR: SYS_02_000084].

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

[REF: код]

где код имеет тот же формат, что и для якоря, ссылка на требования будет иметь следующий вид:

Для доступа к названию роли в формуле расчета 
значения вычислимого атрибута 
должна использоваться мнемоника 
[RoleName]. [ANCHOR: SRD_02_000058] [REF: SYS_02_000084].

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

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

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

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

13.3.2. Возможные формы трассировочных таблиц

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

В первом столбце перечислены якоря требований к программному обеспечению, в первой строке - якоря системных требований. На пересечении указаны типы ссылок: cross-ref - обычная информационная перекрестная ссылка; based on - требование к ПО, основанное на данном системном требовании; variant - может использоваться либо одно, либо другое требование к ПО в зависимости от варианта системы.

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

Здесь РД СВТ - документ Гостехкомиссии РФ, включающий в себя требования по защищенности средств вычислительной техники [5], Protection Profile - один из аналогичных документов, используемых в США. Таблица представляет собой трассировку требований РД СВТ на требования различных глав Protection Profile. В первой строке указаны главы, а в ячейчах - конкретные разделы.