На сайте 100500 рефератов в 150 категориях	Искать реферат
Рефераты на 5 с плюсом С нашим сайтом написать реферат проще простого

Программа сложной структуры с использованием меню

Категория: Компьютерные науки

версия для печати

Страница: [1] [2] [3] [4] [5] [6] [7] [8]

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

СТРУКТУРНОЕ ТЕСТИРОВАНИЕ

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

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

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

Использование критерия покрытия условий может вызвать подбор тестов, обеспечивающих переход в программе, который пропускается при использовании критерия С1 (например, в программе на языке Паскаль, использующей конструкцию цикла WHILE х AND y DO ..., применение критерия покрытия условий требует проверки обоих вариантов выхода из цикла: NOT x и NOT у).

С другой стороны покрытие условий может не обеспечивать покрытие всех переходов. Например, конструкция IF А AND В THEN ... требует по критерию покрытия условий двух тестов (например, А = true, В = false и А = false, В = true), при которых может не выполняться оператор, расположенный в then - ветви оператора if.

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

Правда, с помощью этого же инструмента можно проверить и выполнение критерия С1. Но для этого предварительно текст программы должен быть преобразован таким образом, чтобы все конструкции условного выбора (IF и CASE

10

или SWITCH) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом случае все ветви алгоритма, не выполнялись на данном тесте будут "видимы" из таблицы частоты выполнения операторов преобразованной программы.

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

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

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

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

† † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † † x0D20

СОВМЕСТНОЕ ТЕСТИРОВАНИЕ МОДУЛЕЙ.

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

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

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

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

А

BCD

EF

рис. 1

При сравнении пошагового и монолитного тестирования можно отметить следующие преимущества первого подхода:

1) меньшая трудоемкость (для примера на рис.1 при монолитном тестировании требуются 5 драйверов и 5 заглушек; при пошаговом тестировании требуются или только 5 драйверов - если модули подключаются "снизу вверх", - или только 5 заглушек - если модули подключаются "сверху вниз ");

2) более раннее обнаружение ошибок в интерфейсах между модулями (их сборка начинается раньше, чем при монолитном тестировании);

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

Страница: [1] [2] [3] [4] [5] [6] [7] [8]

версия для печати