25.12.2010      81      Комментарии к записи Структурное Тестирование отключены
 

Структурное Тестирование


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

Наиболее слабым из критериев полноты структурного тестирования является требование хотя бы однократного выполнения (покрытия) каждого оператора программы.

Более сильным критерием является так называемый критерий С1 : каждая ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз. Для большинства языков программирования покрытие переходов обеспечивает и покрытие операторов, но , например, для программ на языке ПЛ/1 дополнительно к покрытию всех ветвей требуется всех дополнительных точек входа в процедуру (задаваемых операторами ENTRY) и всех ON – единиц.

Использование критерия покрытия условий может вызвать подбор тестов, обеспечивающих переход в программе, который пропускается при использовании критерия С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 или SWITCH ) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом случае все ветви алгоритма , не выполнявшиеся на данном тесте будут “видимы” из таблицы частоты выполнения операторов преобразованной программы.

Рекомендуем почитать ►
«Захар Беркут». Патріотичні мотиви, його зв’язок з розгортанням сюжету. Характеристика образі Максима, Мирослави

Актуальной остается задача создания инструментальных средств, позволяющих :

1) накапливать информации о покрытых и непокрытых ветвях для всех использованных тестов ;

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

3) поддерживать более мощные критерии полноты структурного тестирования.

Известны два подхода к совместному тестированию модулей : пошаговое и монолитное тестирование.

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

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

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

Допустим , что на следующем шаге тестирования заглушка модуля H заменяется его реальным текстом. Тогда

1) может оказаться трудным или даже невозможным построить такой тест на входе модуля J, который соотвеьствовал бы любой заданной наперед последовательности значений данных на входе модуля Н ;

2) не всегда окажется возможным легко оценить соответствие значений данных на входе модуля J требуемым тестам для проверки модуля Н;

3) т. к. результаты выполнения прграммы на построенном для проверки модуля Н тесте выводятся не им, а модулем I , может оказаться трудным восстановлении дейсвительных результатов работы модуля Н.

Другие проблемы, которые могут возникать при нисходящем тестировании :

появляется соблазн совмещения нисходящего проектирования с тестированием, что, как правило, неразумно, т.к. проектирование – процесс итеративный и в нем неизбежен возврат на верхние уровни и исправление принятых ранее решений, что обесценивает результаты уже проведенного тестирования ;

Рекомендуем почитать ►
Кто главный герой трагедии «Борис Годунов»?

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

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

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

Другие достоинства восходящего тестирования :

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

нет возможности совмещения проектирования с тестированием ;

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

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

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

На третьем этапе тестирования программных комплексов (тестировании функций) ипользуются прежде всего методы функционального тестирования.

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

Рекомендуем почитать ►
МЦЫРИ КАК РОМАНТИЧЕСКИЙ ГЕРОЙ

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

На втором этапе в спецификации выделяются причины и следствия, а на третьем – анализируется семантическое содержание спецификации и она преобразуется в булевский граф, связывающий причины и следствия и называющийся функциональной диаграммой. На рис.3 приведены базовые символы для записи функциональных диаграмм (каждый узел функциональной диаграммы может находиться в состоянии 1 – “существует” – или 0 – “не существует”).


Об авторе: dimasey