Курсовая работа: Программа сложной структуры с использованием меню
Использование критерия покрытия условий может вызвать подбор тестов, обеспечивающих переход в программе, который пропускается при использовании критерия С1 (например, в программе на языке Паскаль, использующей конструкцию цикла WHILE х AND y DO... , применение критерия покрытия условий требует проверки обоих вариантов выхода из цикла : NOT x и NOT y ).
С другой стороны покрытие условий может не обеспечивать покрытия всех переходов. Например, конструкция IF A AND B THEN... требует по критерию покрытия условий двух тестов (например, A=true, B=false и A=false, B=true ), при которых может не выполняться оператор, расположенный в then - ветви оператора if.
Практически единственным средством, предоставляемым современными системами программирования, является возможность определения частоты выполнения различных операторов программы (ее профилизации). Но с помощью этого инструмента поддержки тестирования можно проверить выполнение только слабейшего из критериев полноты - покрытие всех операторов.
Правда, с помощью этого же инструмента можно проверить и выполнение критерия С1. Но для этого предварительно текст программы должен быть преобразован таким образом, чтобы все конструкции условного выбора (IF и CASE
10
или SWITCH ) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом случае все ветви алгоритма , не выполнявшиеся на данном тесте будут “видимы” из таблицы частоты выполнения операторов преобразованной программы.
Актуальной остается задача создания инструментальных средств, позволяющих :
1) накапливать информации о покрытых и непокрытых ветвях для всех использованных тестов ;
2) выделять разработчику еще не покрытые при тестировании участки программы, облегчая выбор следующих тестов ;
3) поддерживать более мощные критерии полноты структурного тестирования.
Совместное тестирование модулей.
Известны два подхода к совместному тестированию модулей : пошаговое и монолитное тестирование.
При монолитном тестировании сначала по отдельности тестируются все модули программного комплекса, а затем все они объединяются в рабочую программу для комплексного тестирования.
При пошаговом тестировании каждый модуль для своего тестирования подключается к набору уже проверенных модулей.
В первом случае для автономного тестирования каждого модуля требуется модуль - драйвер ( то есть вспомогательный модуль, имитирующий вызов тестируемого модуля) и один или несколько модулей - заглушек ( то есть вспомогательных модулей, имитирующих работу модулей, вызываемых из тестируемого). При пошаговом тестировании модули проверяются не изолированно друг от друга, поэтому требуются либо только драйверы, либо только заглушки.
А
 |
|||||||
 |
 |
 |
|||||
B C D
 |
 |
E F
рис. 1
12
При сравнении пошагового и монолитного тестирования можно отметить следующие преимущества первого подхода :
1) меньшая трудоемкость (для примера на рис.1 при монолитном тестировании требуются 5 драйверов и 5 заглушек ; при пошаговом тестировании требуются или только 5 драйверов - если модули подключаются “снизу вверх ”, - или только 5 заглушек - если модули подключаются “сверху вниз”) ;
2) более раннее обнаружение ошибок в интерфейсах между модулями (их сборка начинается раньше, чем при монолитном тестировании ) ;
3) легче отладка, то есть локализация ошибок (они в основном связаны с последним из подключенных модулей ) ;
4) более совершенны результаты тестирования (более тщательная проверка совместного использования модулей).
Есть приемущества и у монолитного тестирования :
1) меньше расход машинного времени (хотя из-за большей сложности отладки может потребоваться дополнительная проверка программы и это приемущество будет сведено на нет) ;
2) предоставляется больше возможностей для организации параллельной работы на начальном этапе тестирования.
В целом более целесообразным является выбор пошагового тестирования. При его использовании возможны две стратегии подключения модулей : нисходящая и восходящая.
Нисходящее тестирование начинается с главного (или верхнего) модуля программы, а выбор следующего подключаемого модуля происходит из числа модулей, вызываемых из уже протестированных. Одна из основных проблем , возникающих при нисходящем тестировании, - создание заглушек. Это тривиальная задача, т. к. как правило недостаточно, чтобы в заглушке выполнялся вывод соответствующего информационного сообщенияи и возврат всегда одних и тех же значений выходных данных.
Другая прблема , которую необходимо решать при нисходящем тестировании, - форма представления тестов в программе, так как, как правило, главный модуль получает входные данные не непосредственно, а через специальные модули ввода, которые при тестировании в начале заменяются заглушками. Для передачи в главный модуль разных тестов нужно или иметь несколько разных заглушек, или записать эти тесты в файл во внешней памяти и с помощью заглушки считывать их.
Поскольку после тестирования главного модуля процесс проверки может продолжаться по-разному, следует придерживаться следующих правил :
а) модули, содержащие операции ввода-вывода, должны подключаться к тестированию как можно раньше ;
б) критические (т.е. наиболее важные ) для программы в целом модули также должны тестироваться в первую очередь.
12
Основные достоинства нисходящего тестирования :
уже на ранней стадии тестирования есть возможность получить работающий вариант разрабатываемой программы ;
быстро могут быть выявлены ошибки, связанные с организацией взаимодействие с пользователем.
Недостатки нисходящей стратегии продемонстрируются с помощью рис.2.
Допустим , что на следующем шаге тестирования заглушка модуля H заменяется его реальным текстом. Тогда
1) может оказаться трудным или даже невозможным построить такой тест на входе модуля J, который соотвеьствовал бы любой заданной наперед последовательности значений данных на входе модуля Н ;
2) не всегда окажется возможным легко оценить соответствие значений данных на входе модуля J требуемым тестам для проверки модуля Н;
3) т. к. результаты выполнения прграммы на построенном для проверки модуля Н тесте выводятся не им, а модулем I , может оказаться трудным восстановлении дейсвительных результатов работы модуля Н.
Другие проблемы, которые могут возникать при нисходящем тестировании :
появляется соблазн совмещения нисходящего проектирования с тестированием, что, как правило, неразумно, т.к. проектирование - процесс итеративный и в нем неизбежен возврат на верхние уровни и исправление принятых ранее решений, что обесценивает результаты уже проведенного тестирования ;
может возникнуть желание перейти к тестированию модуля следующего уровня до завершения тестирования предыдущего по объективным причинам (необходимости создания нескольких версий заглушек, использования модулями верхнего уровня ресурсов модулей нижних уровней).
При восходящем тестировании прверка программы начмнается с терминальных модулей (т.е. тех, которые не вызывают не каких других модулей программы). Эта стратегия во многом противоположна нисходящему тестированию (в частности, преимущества становятся недостатками и наоборот).
