Критерии выбора тестов

Функциональные критерии (класс II)

Функциональный критерий - важнейший для программной индустрии критерий тестирования. Он обеспечивает, прежде всего, контроль степени выполнения требований заказчика в программном продукте. Поскольку требования формулируются к продукту в целом, они отражают взаимодействие тестируемого приложения с окружением. При функциональном тестировании преимущественно используется модель "черного ящика". Проблема функционального тестирования - это, прежде всего, трудоемкость; дело в том, что документы, фиксирующие требования к программному изделию (Software requirement specification, Functional specification и т.п.), как правило, достаточно объемны, тем не менее, соответствующая проверка должна быть всеобъемлющей.

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

• Тестирование пунктов спецификации - набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.

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

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

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

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

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

• Тестирование классов выходных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out).

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

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

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

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

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

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

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

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

1. Произвести опрос статуса склада (вызвать функцию GetStoreStat ). Добавить в журнал сообщений запись "СИСТЕМА : Запрошен статус СКЛАДА". В зависимости от полученного значения произвести следующие действия:
   • Полученный статус склада = 32. В приемную ячейку склада поступил подшипник. Система должна:
     1. Добавить в журнал сообщений запись "СКЛАД : Статус СКЛАДА = 32".
     2. Получить параметры поступившего подшипника с терминала подшипника (должна быть вызвана функция GetRollerPar ).
     3. Добавить в журнал сообщений запись "СИСТЕМА: Запрошены параметры подшипника".
     4. В зависимости от возвращенного функцией GetRollerPar значения должны быть выполнены следующие действия ( таблица 3.2):

   Таблица 3.2. Действия по результатам функции GetRollerPar

   Значение, возвращенное функцией GetRollerPar	Действия системы
   ...	...
   0	Добавить на первое место команду GetR - "ПОЛУЧИТЬ ИЗ ПРИЕМНИКА В ЯЧЕЙКУ" Добавить в журнал сообщений запись "ТЕРМИНАЛ ПОДШИПНИКА: 0 - параметры возвращены <Номер_группы>"
   1	Добавить в журнал сообщений запись "ТЕРМИНАЛ ПОДШИПНИКА: 1 - нет данных"
   ...	...
2. Произвести опрос терминала оси (вызвать функцию получения сообщения от терминала - GetAxlePar ). В журнал сообщений должно быть добавлено сообщение "СИСТЕМА : Запрошены параметры оси". В зависимости от возвращенного функцией GetAxlePar значения должны быть выполнены следующие действия ( таблица 3.3):

   Таблица 3.3. Действия по результатам функции GetAxlePar

   Значение, возвращенное функцией GetAxlePar	Действия системы
   ...	...
   1	Добавить в журнал сообщений запись "ТЕРМИНАЛ ОСИ: 1 - нет данных"
   ...	...

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

1. Статус склада = 0 (правильный).
2. Статус склада = 4 (правильный).
3. Статус склада = 16 (правильный).
4. Статус склада = 32 (правильный).
5. Статус склада = любое другое значение (ошибочный).

Теперь рассмотрим тестовые случаи:

1. Тестовый случай 1 (покрывает класс 4):

   Состояние окружения (входные данные - X ):

   Статус склада - 32.

   ...

   Ожидаемая последовательность событий (выходные данные - Y ):

   Система запрашивает статус склада (вызов функции GetStoreStat ) и получает 32

   ...

2. Тестовый случай 2 (покрывает класс 5):

   Состояние окружения (входные данные - X ):

   Статус склада - 12dfga.

   ...

   Ожидаемая последовательность событий (выходные данные - Y ):

   Система запрашивает статус склада (вызов функции GetStoreStat ) и согласно пункту спецификации при ошибочном значении статуса склада в журнал добавляется сообщение "СКЛАД : ОШИБКА : Неопределенный статус".

   ...