A

B

C

D

E

F

G

H

I

J

Рис. 2. Схема многомодульной программы

У

Обозначения на рис. 2 следующие: прямоугольники – это модули,

тонкие линии представляют иерархию

управления

(связи по управлению

Т

между модулями), жирные стрелки – ввод и вывод данных в программу.

Монолитное

тестирование [1, 5]

заключается в том, что каждый

Н

модуль тестируется отдельно. Для каждого модуля пишется один модуль-

драйвер, который передает тестируемому модулю управление, и один или

Б

несколько модулей-заглушек. Например, для модуля B нужны 2 заглушки,

имитирующие работу модулей Е F. Когда все модули протестированы, они

собираются вместе, и тестируется вся программа в целом.

й

Пошаговое тестирование п едполагает, что модули тестируются не

изолированно, а подключаются поочеиедно к набору уже оттестированных

модулей.

р

Можно выдели ь следующие недостатки монолитного тестирования

(перед пошаговым) [5, 6]:

1.

о

Требуется много дополнительных действий (написание драйверов и

заглушек).

т

2.

дно

обнаруживаются

ошибки

в

межмодульных

и

взаим действиях.

3.

Следствиезиз 2 – труднее отлаживать программу.

К реимуществам монолитного тестирования можно отнести:

1. Экономию машинного времени (в настоящее время существенной

По

экономии не наблюдается)

п

2. Возможность параллельной организации работ на начальной фазе

тестирования.

е

Р

1.4.5. Стратегии выполнения пошагового тестирования

•

восходящее тестирование.

Нисходящее тестирование начинается с головного модуля, в нашем

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

ведь ввод и вывод осуществляется в других модулях? Как передать в А

несколько тестов?

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

У

а) написать несколько вариантов заглушек B (для каждого теста);

б)

написать заглушку B так, чтобы она читала тестовые данные из

внешнего файла.

Т

В качестве стратегии подключения модулей можно использовать одну

из следующих:

а)

подключаются наиболее важные с точки зрения тестирования

модули;

Б

б)

подключаются

модули, осуществляющие операции ввода/вывода

(для того чтобы обеспечивать тестовыми данными «внутренниеН» модули).

Нисходящее тестирование имеет ряд недостатков: предположим, что

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

H меняется на реальный модуль H. Как передать тестовые данные в Н? Это

р

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

модули и может оказаться невозможным передать тестовые данные,

ирование

соответствующие разраб танным тестами. К тому же достаточно сложно

другие модули) модулейрезультаты.

интерпретировать

тести ования Н, так как между Н и I также

существуют промежу

чные м дули.

Восходящее ес

практически полностью противоположно

нисходящему тест рован ю. Начинается с терминальных (не вызывающих

з

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

степени критичностииданного

модуля в программе. Восходящее

п

тестир вание лишено недостатков нисходящего тестирования, однако имеет

свой, главный недостаток: рабочая программа не существует до тех пор, пока

какие

не добавленопоследний (в нашем случае А) модуль.

Р

Выбор одной их двух представленных стратегий определяется тем, на

модули (верхнеуровневые

или нижнеуровневые) следует обратить

инкапсулирован со своими методами. Это означает, что поэлементное

тестирование по существу заменяется классовым тестированием. Однако не

следует отклоняться слишком далеко от наших корневых принципов

относительно того, что каждый метод класса объектов можно рассматривать

как "небольшой элемент", тестирование которого можно выполнять

обособленно, применяя для этого методы "белого и черного ящика". Классы

У

объектов необходимо протестировать во всех возможных состояниях. Это

означает, что

необходимо

сымитировать все события,

вызывающие

изменения состояния объекта.

Т

В традиционном отношении [7] элементы компилируются в

подсистемы и подвергаются интеграционным тестам. При объектно-

ориентированном подходе не применяется тестирование структурной схемы

сверху вниз, поскольку точно не известно, какой класс будет вызван

пользователем за предыдущим. Интеграционные тесты заменяются

тестированием

функциональных возможностей,

при Нкотором

тестируется

й

набор классов, которые должны реагировать на один входной сигнал или

системное событие, или же эксплуатационным тестированиемБ

, при котором

и

описывается один способ применен я с стемы, основанный на сценариях

случаев эксплуатации.

Тестирование взаимодейств я объектов следует по путям сообщения с

о

целью отследить последовательность взаимодействий объектов, которая

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

стема

посылается сообщение и не вызываютсярслужбы любого другого объекта.

Системное, альфа-, бе а-тестирование и приемочное испытание

пользователем

зменяю ся

незначительно,

поскольку

объектно-

з

проходит эксплуатационные тесты точно также,

ориентированная с

как и ра работанные трад ционным способом системы. Это означает, что

по

процесс V&V

исуществу не изменяется.

Тестир вание классов охватывает виды деятельности, направленные на

роверку с тветствия реализации этого класса спецификации. Если

е

реализация корректна, то каждый экземпляр этого класса ведет себя

одобающим образом.

Р

пТ стирование

классов

в первом приближении

аналогично

т стированию модулей и может проводиться с помощью обзоров (ревизий) и

выполнения тестовых случаев.

К недостаткам обзоров (ревизий) относятся:

заключается

в

коды

том, что неп авильное понимание спецификации

ровать

разработчиками распрос раняе ся на тестовые наборы и тестовые драйверы.

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

тестировщиков

друг х разработчиков для ревизий программных кодов.

з

. Тестировать нужно программный код на точное

2. Что тест

Когда

соответствие его требованиям, т.е. в классе должно быть реализовано все

запланир ванн

лие и ничего лишнего. Если для конкретного класса характерны

проводить регрессионное тестирование класса каждый раз, когда меняется

статические элементы, то их также необходимо тестировать. Такие элементы

ринадлежат сам му классу, но не каждому экземпляру.

е

тестировать. Тестирование класса должно проводиться до

3.

программный код. Главное, чтобы этот подход не привел к проблемам во

время интеграции этого класса в более крупную часть системы.

4. Каким образом тестировать. Тестирование классов обычно

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

создает экземпляры классов и окружает их соответствующей средой, чтобы

стал возможен прогон соответствующего тестового случая.

Драйвер

У

посылает одно или большее количество сообщений экземпляру класса (в

соответствии с тестовым случаем),

затем сверяет результат его работы с

Т

ожидаемым и составляет протокол о прохождении или не прохождении

теста. В обязанности тестового драйвера обычно входит и удаление

созданного им экземпляра.

5. В каких объемах тестировать. Адекватность может быть измерена

полнотой охвата тестами спецификации и реализации класса. Т.е необходимо

тестировать операции и переходы состояний в различных сочетаниях.

Поскольку объекты находятся в

одном из возможныхНсостояний, эти

й

состояния определяют значимость операций. Поэтому требуется определить,

целесообразно ли проводить исчерпывающее тестированиеБ

. Если

нет, то

и

рекомендуется выполнить наиболее важные тестовые случаи, а менее важные

выполнять выборочно.

р

о

т

и

з

о

п

е

Р