или SWITCH ) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом случае
всеветви алгоритма , не выполнявшиеся на данном тесте будут “видимы” из таблицы
частоты выполнения операторов преобразованной программы.
Актуальной остается задача создания инструментальных средств, позволяющих :
1) накапливать информации о покрытых и непокрытых ветвях для
всех использованных тестов ;
2) выделять разработчику еще не покрытые при тестировании
участки программы, облегчая выбор следующих тестов;
3) поддерживать более мощные критерии полноты структурного
тестирования.
Совместное тестирование модулей.
Известны два подхода к совместному тестированию модулей : пошаговое и монолитное
тестирование.
При монолитном тестировании сначала по отдельности тестируются все модули
программногокомплекса, а затем все они объединяются в рабочую программу для
комплексного тестирования.
При пошаговом тестировании каждый модуль для своего тестирования подключается к
набору ужепроверенных модулей.
В первом случае для автономного тестирования каждого модуля требуется модуль -
драйвер ( то естьвспомогательный модуль, имитирующий вызов тестируемого модуля)
и один или несколько модулей - заглушек ( то есть вспомогательных модулей,
имитирующихработу модулей, вызываемых из тестируемого). При пошаговом
тестировании модули проверяются не изолированно друг от друга, поэтому требуются
либо толькодрайверы, либо только заглушки.
А
BC 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 , может оказаться
трудным восстановлении дейсвительных результатов работы модуля Н.
Другие проблемы, которые могут возникать при нисходящем тестировании :
появляется соблазн совмещения нисходящего
проектирования с тестированием, что, как правило,неразумно, т.к. проектирование
- процесс итеративный и в нем неизбежен возврат на верхние уровни и исправление
принятых ранее решений, что обесцениваетрезультаты уже проведенного тестирования
;
может возникнуть желание перейти к тестированию модуля
следующего уровня до завершениятестирования предыдущего по объективным причинам
(необходимости создания нескольких версий заглушек, использования модулями
верхнего уровня ресурсовмодулей нижних уровней).
При восходящем тестировании прверка программы начмнается с терминальных модулей
(т.е. тех,которые не вызывают не каких других модулей программы). Эта стратегия
во многом противоположна нисходящему тестированию (в частности, преимущества
становятсянедостатками и наоборот).
Нет проблемы выбора следующего подключаемого модуля - учитывается лишь то ,
чтобы он вызывал толькоуже протестированые модули. В отличие от заглушек
драйверы не должны иметь несколько версий, поэтому их разработка в большенстве
случаев проще (крометого, использование средств автоматизации и отладки
облегчает создание как раз драйверов, а не заглушек).
Другие достоинства восходящего тестирования :
поскольку нет промежуточных модулей (тестируемый модуль
является для рабочего вариантапрограммы модулем самого верхнего уровня), нет
проблем, связанных с возможностью или тружностью задания тестов ;
нет возможности совмещения проектирования с
тестированием ;
нет трудностей, вызывающих желание перейти к
тестированию следующего модуля , не завершивпроверки предыдущего.
Основными недостатком восходящего тестирования является то , что проверка всей
структурыразрабатываемого программного комплекса возможна только на завершающей
стадии тестирования.
Хотя однозначного вывода о преимущества той или иной стратегии пошаговаого
тестирования сделать нельзя(нужно учитывать конкретные характеристики
тестируемой программы), в большинстве случаев более предпочтительным является
восходящеетестирование.
На третьем этапе тестирования программных комплексов (тестировании функций)
ипользуются преждевсего методы функционального тестирования.
Функциональное тестирование.
Обзор методов проектирования тестов при функциональеом тестировании начнем с
методазквивалентного разбиения.
Т.к. нашей целью является построения множества тестов, характеризующегося
наивысшейвероятностью обнаружения большинстыва ошибок в тестируемой программе,
то тест из этого множества должен :
1) уменьшать (более чем на единицу) число других тестов, которые должны быть
разработанны для достижения заранее поставленной цели
“удовлетворительного”тестирования ;
2) покрывать собой значительную часть других возможных
тестов .
Другими словами :
1) каждый тест должен заключать в себе проверку
наибольшего числа задаваемых внешней спецификациейвходных условии (ограничений
на входные данные) для того, чтобы минимизировать общее число необходимых тестов
;
2) необходимо разбить область значений входных данных
на конечное число подобластей (которыебудут называться классами
эквивалентности), чтобы можно было полагать каждый тест, являющийся
представителем некоторого класса, эквивалентным любомудругрому тесту этого
класса (т.е. обнаруживающим одни и те же ошибки).
В общем случае использование термина “класс эквивалентности” является здесь
невполне точным, т.к. выделенные подобласти могут пересекаться.
Проектирование тестов по методу эквивалентного разбиения проводится в два этапа
:
выделение по внещней спецификации классов эквивалентности;
построение множества тестов.
Напервом этапе происходит выбор из спецификации каждого входного условия и
разбиение его на две или более группы, соответствующие так называемым
“правильным”(ПКЭ) и “неправильным” классом эквивалентности (НКЭ), т.е. облатям
допустых для программы и недопустимых значений входных данных. Этот процесс
зависит от видавходного условия. Если входное условие описывает область
(например, х <=0.5) или количеством (например, размер массива А равен 50)
допустимых значенийвходных данных, то определяются один ПКЭ (х <=0.5 или размер
А равен 50) и два НКЭ (х< -0.5 ; х>0.5 или размер А меньше 50 ; размер А больше
50).
Если входное условие описывает дискретное множество допустимых значений