Метод комбинаторного покрытия условий
Критерий метода: все возможные комбинации результатов условий в каждом предикате выполняется хотя бы 1 раз
Этот метод устраняет все недостатки, рассмотренные ранее, метод создает столько тестов, сколько необходимо для выполнения по крайней мере одного раза всех возможных комбинаций результатов условий в предикатах всех переходов в программе. Для построения тестов необходимо использовать все системы уравнений (1)÷(8), т.е. системы (9)÷(12) и (2),(3),(6),(7):
(15)
(16)
(17)
(18)
Из 8 систем можно получить в общем случае 8 тестов, но т.к. Р2 вычисляется после Р1, то достаточно 4.
T1=(A0=2,B0=0,X0=4) <-{9,10}
T2=(A0=2,B0=1,X0=1)<-{15,16}
T3=(A0=1,B0=0,X0=2)<-{17,18}
T4=(A0=1,B0=1,X0=1)<-{11,12}
Общая стратегия проектирования тестов
Каждый рассмотренный метод обеспечивает создание определенного набора тестов, но ни один из них сам по себе не может дать полный набор тестов.
Рекомендации:
1.Если спецификации содержат комбинацию входных условий, то начать надо с применения метода функциональных диаграмм.
2.Всегда надо использовать анализ граничных условий.
3.Метод эквивалентного разбиения.
4.Для получения дополнительных тестов можно использовать метод предположения об ошибке.
5.Применяя методы структурного тестирования отобрать тесты не входящие в ранее построенные.
Реализация этой стратегии весьма трудоемка. Она не гарантирует что все ошибки будут найдены.
Тестирование модульных программ
Процесс тестирования больших программных систем (с модульной структурой) состоит из двух этапов:
- тестирование отдельных модулей системы;
-тестирование всей системы.
Различают 2 подхода к комбинированию модулей:
-монолитное тестирование;
-пошаговое тестирование.
Монолитное тестирование методом «большого удара»
Это традиционный подход. В начале рассмотренными методами тестируется каждый модуль в отдельности (независимо друг от друга).
Для тестирования отдельного модуля надо:
- модуль «драйвер»
- модуль «заглушка»
Схема полигона для тестирования ниже:
В заключении оттестированные модули собираются в единую программу, которая тестируется как отдельный модуль. Монолитное тестирование – трудоемко, но ускоряет проверку за счет распределения работ.
Пошаговое тестирование
Модули тестируются не изолированно друг от друга, а подключаются поочередно к ранее оттестированному набору. Возможно направление тестирования
-сверху,
-снизу.
При нисходящем тестировании проверка начинается с головного (верхнего) модуля:
А (первый уровень), B,C,D (второй уровень) E,F (третий уровень)
Рекомендации по порядку подключения очередного тестируемого модуля.
модули, включающие операции ввода-вывода, подключаются как можно раньше
если в программе есть критические в каком-либо смысле части (сложный модуль, новый алгоритм и т.д.) то целесообразно включить эти части как можно раньше.
Например, если модуль F содержит операторы ввода, то пошаговая последовательность может быть следующей:
A,D,F,B,C,E
Для подключаемого тестируемого модуля создаются модули заглушки, которые имитируют функции вызова модулей.
Создание заглушек – задача не тривиальная, их задача – вернуть вызывающему модулю правильные данные. Могут создаваться разные заглушки индивидуально для каждого теста. При этом все тесты и сопутствующую информацию записывают во внешней памяти и заглушка их только читает и передает тестируемому модулю.
Недостатки нисходящего тестирования:
- может оказаться невозможным передать модулю необходимый набор данных, например из f в Е.
- получить входной набор, соответствующих тесту для Е – трудная интеллектуальная задача.
При восходящем тестировании проверка начинается с терминальных модулей (в начале E,C,F, потом B,D и в конце А).
Для каждого модуля – свой драйвер (для нашего примера 5 драйверов). Иногда драйверы разработать легче чем заглушки. На последовательность также влияет критичность модуля.
Выводы: при пошаговым тестировании обнаруживаются ошибки в интерфейсах. Отладка программы при пошаговом тестировании легче (ошибки локализируются в текущем контексте).