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

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. Структура отчетов о проблемах, их трассировка на программный код и документацию

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

• Объект, в котором найдена проблема. Здесь помещается максимально полная информация - для документации это название документа, раздел, автор, версия. Для исходных текстов это имя модуля, имя функции/метода или номера строк, версия.
• Выпуск и версия системы. Определяет место, откуда был взят объект с обнаруженной проблемой. Обычно требуется отдельная идентификация версии системы (а не только версии исходных текстов), поскольку может возникнуть путаница с повторно выявленными проблемами. В этом случае, если проблема уже была когда-то выявлена разработчиком и потом вновь появилась из-за того, что в систему попала не самая последняя версия программного модуля, разработчик может решить, что ему пришел старый отчет и проблемы на самом деле не существует.
• Тип отчета
  • Ошибка кодирования - код не соответствует требованиям.
  • Ошибка проектирования - тестировщик не согласен с проектной документацией.
  • Предложение - у тестировщика возникла идея, как можно усовершенствовать код.
  • Расхождение с документацией - поведение ПО не соответствует руководству пользователя или проектной документации либо вообще нигде не описано. При этом у тестировщика нет оснований объявлять, где именно находится ошибка.
  • Взаимодействие с аппаратурой - неверная диагностика плохого состояния устройства, ошибка в интерфейсе с устройством.
  • Вопрос - тестировщик не уверен, что это проблема, и ему требуется дополнительная информация.
• Степень важности. Строгого критерия определения степени важности не существует, и обычно это поле кодируют от 1 (незначительно) до 10 (фатально). Однако способов обоснованной оценки нет - очень сложно определить, насколько фатальной может оказаться, например, опечатка в один символ в руководстве пользователя.
• Суть проблемы. Краткое (не более 2 строчек) определение проблемы. Даже если две проблемы очень похожи, их описания должны различаться.
• Можно ли воспроизвести проблемную ситуацию? Ответ - Да, Нет, Не всегда. Последнее - если проблема носит нерегулярный характер. Нужно описывать, когда она проявляется, а когда - нет (например, если не вовремя нажать не ту клавишу).
• Подробное описание проблемы и способ ее воспроизведения. При этом нужны подробности - и в описании условий воспроизведения, и в описании причины объявления получившейся реакции ошибкой.

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

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

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

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

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

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

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

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

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

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

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