Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы тестирования и отладки программного обеспечения. Учебник
.pdf
В качестве базиса для тестирования глубинной структуры используются модели анализа и проектирования. Например, разработчик исследует диаграмму взаимодействия (невидимую
извне) и спрашивает: «Проверяет ли тест сотрудничество, отмеченное на диаграмме?».
Диаграммы классов обеспечивают понимание структуры наследования, которая используется в тестах, основанных
на ошибках. Рассмотрим операцию Обработать (Ссылка_на_РодительскийКласс). Что произойдет, если в вызове этой операции
указать ссылку на дочерний класс? Есть ли различия в поведении, которые должны отражаться в операции Обработать? Эти
вопросы инициируют создание конкретных тестов.
5.6. Тестирование содержимого класса
5.6.1. Стохастическое тестирование класса
При стохастическом тестировании ИД для тестовых вариантов генерируются случайным образом. Обсудим методику, предложенную С. Кирани и В. Тсай.
Рассмотрим класс Счет, который имеет следующие операции:
Открыть, Установить, Положить, Снять, Остаток, Итог, ОграничитьКредит, Закрыть.
Каждая из этих операций применяется при определенных
ограничениях:
– счет должен быть открыт перед применением других опе-
раций;
– счет должен быть закрыт после завершения всех операций.
Даже с этими ограничениями существует множество допустимых перестановок операций. Минимальная работа экземпляра
Счет включает следующую последовательность операций:
Открыть►Установить►Положить►Снять►Закрыть.
Стрелка обозначает операцию следования. Иначе говоря,
здесь записано, что экземпляр класса Счет сначала выполняет
операцию открытия, затем установки и т.д. Эта последовательность является минимальным тестовым вариантом для экземпляра класса Счет.
Впрочем, в эту последовательность можно
81
встроить группировку, обеспечивающую создание других вариантов поведения:
Открыть►Установить►Положить►[Остаток●Снять●Итог●
n
ОграничитьКредит●Положить]
►Снять►Закрыть.
Здесь приняты дополнительные обозначения: точка означает
операцию И/ИЛИ, пара квадратных скобок – группировку, а показатель степени – число повторений группировки.
Набор различных последовательностей может генерироваться
случайным образом:
Тестовый вариант N:
Открыть►Установить► Положить►Остаток►Снять► Итог►
Снять►Закрыть.
Тестовый вариант М:
Открыть►Установить►Положить►Итог►ОграничитьКредит►
Снять►Остаток►Снять►Закрыть.
Эти и другие тесты случайных последовательностей прово-
дятся для проверки различных вариантов жизни объектов.
5.6.2. Тестирование разбиений на уровне классов
Тестирование разбиений уменьшает число тестовых вариантов, требуемых для проверки классов (тем же способом, что и
разбиение по эквивалентности для стандартного ПО). Области
ввода и вывода разбивают на категории, а тестовые варианты
разрабатываются для проверки каждой категории.
Обычно используют одну из трех категорий разбиения. Категории образуются операциями класса.
Первый способ – разбиение на категории по состояни-
ям – основывается на способности операций изменять состояние класса. Обратимся к классу Счет. Операции Снять, Поло-
жить изменяют его состояние и образуют первую категорию.
Операции Остаток, Итог, ОграничитьКредит не меняют состояние класса Счет и образуют вторую категорию. Проектируемые
тесты отдельно проверяют операции, которые изменяют состояние, а также те операции, которые не изменяют его. Таким образом, для примера:
82
Тестовый вариант 1:
Открыть►Установить►Положить►Положить►Снять► Снять►
Закрыть.
Тестовый вариант 2:
Открыть►Установить►Положить►Остаток►Итог►Ограничить
Кредит►Снять►Закрыть.
Тестовый вариант 1 изменяет состояние объекта, в то время
как тестовый вариант 2 проверяет операции, которые не меняют состояние. Правда, в тестовый вариант 2 пришлось включить
операции минимальной тестовой последовательности, поэтому
для нейтрализации влияния операций Снять и Положить их аргументы должны иметь одинаковые значения.
Второй способ – разбиение на категории по свойствам – основывается на свойствах, которые используются операциями. В классе Счет для определения разбиений можно использовать свойства
Остаток и Ограничение кредита. Например, на основе свойства
ограничение кредита операции подразделяются на три категории:
1) операции, которые используют ограничение кредита;
2) операции, которые изменяют ограничение кредита;
3) операции, которые не используют и не изменяют ограниче-
ние кредита.
Для каждой категории создается тестовая последовательность.
Третий способ – разбиение на категории по функционально-
сти – основывается на общности функций, которые выполняют
операции. Например, операции в классе Счет могут быть разбиты на категории:
– операции инициализации (Открыть, Установить);
– вычислительные операции (Положить, Снять);
– запросы (Остаток, Итог, ОграничитьКредит);
– операции завершения (Закрыть).
5.7. Методы тестирования взаимодействия
классов
Для тестирования сотрудничества классов могут использо-
ваться следующие способы:
83
– стохастическое тестирование;
– тестирование разбиений;
– тестирование на основе сценариев;
– тестирование на основе состояний.
В качестве примера рассмотрим программную модель бан-
ковской системы, в состав которой входят классы Банк, Бан-
комат, ИнтерфейсБанкомата, Счет, Работа с наличными, ПодтверждениеПравильности, имеющие операции, перечисленные
в табл. 5.2.
Таблица 5.2
Взаимодействие классов модели банковской системы
ла анкоат à ла анк
ПроверитьСчет( );
ПроверитьРIN( );
ПроверитьПолис( );
ЗапросСнятия( );
ЗапросДепозита ( );
ИнфоСчета( );
ла аота налиныи à ла анк
ОткрытьСчет( );
НачальнДепозит( );
РазрешитьКарту( );
СнятьРазрешен( );
ЗакрытьСчет( );
ла анкоат à ла нтерей анкоата
КартаВставлена( );
Пароль( );
Положить( );
Снять( );
СостояниеСчета( );
Завершить( );
ла нтерей анкоат à ла анкоат
ПроверитьСостояние( );
СостояниеПоложить( );
ВыдатьНаличные( );
ПечатьСостСчета( );
ЧитатьИнфоКарты( );
ПолучитьКолвоНалич( );
84
ла ет à ла анк
: Подтверждение правильнос ти
ОграничКредит( );
ТипОчета( );
Остаток( );
Снять( );
Положить( );
Закрыть( );
ла одтвердение правилноти à ла анк
ПодтвРIN( );
ПодтвСчет( );
1 : КартаВс тавлена()
2 : Пароль()
3 : Положить()
4 : Снять()
5 : СостояниеСчета()
Интерфейс банк омата : Банкомат
6 : Завершить()
7 : ПроверитьСос тояние()
8 : СостояниеПоложить()
9 : Выдат ьНаличные()
10 : ПечатьСос тоянияСч ета()
11 : ЧитатьИнфоКарты ()
12 : ПолучитьКолвоНалич()
13 : ПроверитьСч ет()
14 : ПроверитьPIN()
15 : ПроверитьПолис()
16 : ЗапросСнятия()
17 : ЗапросДепоз ита()
18 : ИнфоСчета()
Окончание табл.5.2
: Работа с наличными
19 : ОткрытьСч ет()
20 : НачалнДепозит()
21 : РазрешитьКарт у()
: Счёт
22 : СнятьР азрешен()
23 : Закрыт ьСчет( )
24 : ОграничКред ит()
25 : ТипСчета()
26 : Ост аток()
27 : Снять()
28 : Положить()
29 : Закрыт ь()
30 : ПодтвPIN()
31 : ПодтвСч ет()
: Банк
Рис. 5.1. Диаграмма сотрудничества банковской системы
85
Диаграмма сотрудничества объектов банковской системы
представлена на рис. 5.1. На этой диаграмме отображены связи
между объектами, стрелки передачи сообщений подписаны именами вызываемых операций.
5.7.1. Стохастическое тестирование
Стохастические тестовые варианты генерируются следующей
последовательностью шагов.
Для создания тестов используют списки операций каждого
класса-клиента. Операции будут посылать сообщения в классысерверы.
Для каждого созданного сообщения определяется класссотрудник и соответствующая операция в классе-сервере.
Для каждой операции в классе-сервере, которая вызывается
сообщением из класса-клиента, определяются сообщения, которые она, в свою очередь, посылает.
Для каждого из сообщений определяется следующий уровень
вызываемых операций; они вставляются в тестовую последовательность.
В качестве примера рассмотрим последовательность операций
для класса Банк, вызываемых классом Банкомат:
ПроверитьСчет►ПроверитьРIN►[[ПроверитьПолис►
n
ЗапросСнятия]●ЗапросДепозита●ИнфоСчета]
.
Здесь приняты следующие обозначения: стрелка означает
операцию следования, точка – операцию И/ИЛИ, пара квадратных скобок – группировку операций классов, показатель степени – число повторений группировки из операций классов.
Случайный тестовый вариант для класса Банк может иметь
вид:
Тестовый вариант N:
ПроверитьСчет►ПроверитьРIN►ЗапросДепозита.
Для выявления сотрудников, включенных в этот тест, рассматриваются сообщения, связанные с каждой операцией, записанной в тестовом варианте N. Для выполнения заданий Про-
веритьСчет и ПроверитьРIN класс Банк должен сотрудничать
с классом ПодтверждениеПравильности. Для выполнения зада-
86
ния ЗапросДепозита класс Банк должен сотрудничать с классом
Счет. Отсюда создается новый тестовый вариант, который проверяет отмеченные сотрудничества:
Тестовый вариант М:
ПроверитьСчет
(ПодтвРШ
ПодтвПрав
►(ПодтвСчет
Банк
ПодтвПрав
)►ЗапросДепозита
Банк
)►ПроверитьРIN
►(Положить
Счет
►
Банк
).
В этой последовательности операции классов-сотрудников
класса Банк помещены в круглые скобки, индексы отображают
принадлежность операций к конкретным классам.
5.7.2. Тестирование разбиений
В основу этого метода положен тот же подход, который применялся к отдельному классу. Отличие в том, что тестовая последовательность расширяется для включения тех операций, которые вызываются с помощью сообщений для сотрудничающих
классов.
Другой подход к тестированию разбиений основан на взаимодействиях с конкретным классом. Как показано на рис. 5.1,
класс Банк получает сообщения от классов Банкомат и Работа
с наличными. Поэтому операции внутри класса Банк тестируются разбиением их на те, которые обслуживают класс Банкомат,
и на те, которые обслуживают класс Работа с наличными. Для
дальнейшего уточнения может быть использовано разбиение
на категории по состояниям.
5.7.3. Тестирование на основе состояний
В качестве источника исходной информации используют диаграммы схем состояний, фиксирующие динамику поведения
класса. Данный способ позволяет получить набор тестов, проверяющих поведение класса и тех классов, которые сотрудничают
с ним. В качестве примера на рис. 5.2 показана диаграмма схем
состояний класса Счет.
На рис. 5.2 показано, что объект Счет начинает свою жизнь
в состоянии Пустой счет
лить счет
. Наибольшее количество событий (и действий) связано
, а заканчивает жизнь в состоянии Уда-
с состоянием Работа счета.
87
Открыть
Неработающий
Счет
Пустой счет
Удалить счет
УстановитьСчет
Остаток
Кредит
Закрыть
Установка счета
Положить (начальное)
Работа счета
Снять
Снять (конечное)
Рис. 5.2. Диаграмма схем состояний класса Счет
ИнфоСчета
Проектируемые тесты должны обеспечить покрытие всех состояний. Это значит, что тестовые варианты инициируют переходы через все состояния объекта:
Тестовый вариант 1:
Открыть►УстановитьСчет►Положить (начальное)►Снять (конечное) ►Закрыть.
Отметим, что эта последовательность аналогична минимальной тестовой последовательности. Добавим к минимальной последовательности дополнительные тестовые варианты:
88
Тестовый вариант 2:
Открыть►УстановитьСчет►Положить(начальное)►Положить
►Остаток►Кредит►Снять (конечное)►Закрыть.
Тестовый вариант 3:
Открыть►Установить►Положить (начальное)►Положить►Сн
ять►ИнфоСчета►Снять (конечное)►Закрыть.
Для гарантии проверки всех вариантов поведения число тестовых вариантов может быть увеличено. Когда поведение класса определяется в сотрудничестве с несколькими классами, для
отслеживания «потока поведения» используют набор диаграмм
схем состояний, характеризующих смену состояний других
классов.
Возможна другая методика исследования состояний – «пре-
имущественно в ширину». По этой методике:
– каждый тестовый вариант проверяет один новый переход;
– новый переход можно проверять, если полностью провере-
ны все предшествующие переходы, т.е. переходы между предыдущими состояниями.
Рассмотрим объект Карта клиента (рис. 5.3). Начальное со-
стояние карты Не определена, т.е. не установлен номер карты.
После чтения карты (в ходе диалога с банкоматом) объект переходит в состояние Определена. Это означает, что определены
банковские идентификаторы Номер Карты и Дата Истечения
Срока. Карта клиента переходит в состояние Предъявляется
на рассмотрение, когда проводится ее авторизация, и в состоя-
ние Разрешена, когда авторизация подтверждается. Переход
карты клиента из одного состояния в другое проверяется отдельным тестовым вариантом.
Подход «преимущественно в ширину» требует: нельзя про-
верять Разрешена перед проверкой Не определена, Определе-
на – «Предъявляется на рассмотрение». В противном случае нарушается условие этого подхода: перед тестированием текущего
перехода должны быть протестированы все переходы, ведущие
к нему.
89
Не определена
Проверено
Определена
Проверено
Предъявляется на
рассмотрение
Текущий переход
Разрешена
Рис. 5.3. Тестирование «преимущественно в ширину»
Можно проверять
Контрольные вопросы
1. Что такое CRC-карта? Как ее применить для тестирования
визуальных моделей?
2. Поясните особенности тестирования объектно-ориентиро-
ванных модулей.
3. В чем состоит суть методики тестирования интеграции объ-
ектно-ориентированных систем, основанной на потоках?
4. Поясните содержание методики тестирования интеграции объектно-ориентированных систем, основанной на использовании.
5. В чем заключаются особенности объектно-ориентированного тестирования правильности?
6. Как учитывается инкапсуляция, полиморфизм и наследование при проектировании тестовых вариантов?
7. Поясните содержание тестирования, основанного
на ошибках.
8. Поясните содержание тестирования, основанного на сценариях.
9. Чем отличается тестирование поверхностной структуры
от тестирования глубинной структуры системы?
90
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]