Краткие теоретические и учебно-методические материалы

По теме лабораторной работы

Описываемые ниже способы ориентированы на отдельный класс и операции, которые инкапсулированы классом.

Даже с этими ограничениями существует множество допустимых перестановок операций.

Минимальная работа экземпляра Счета включает следующую последовательность операций: Открыть ► Установить ► Положить ► Снять ► Закрыть.

 обозначает операцию следования. Иначе говоря, здесь записано, что экземпляр Счета сначала выполняет операцию открытия, затем установки и т. д. Эта последовательность является минимальным тестовым вариантом для Счета. Впрочем, в эту последовательность можно встроить группировку, обеспечивающую создание других вариантов поведения Открыть ► Установить ► Положить ► [Остаток●Снять●Итог●ОграничитьКредит●Положить] ► Снять ► Закрыть.

Здесь приняты дополнительные обозначения: точка означает операцию И/ИЛИ, пара квадратных скобок — группировку, а показатель степени — количество повторений группировки.

Набор различных последовательностей может генерироваться случайным образом:
Тестовый вариант N:
Открыть ► Установить ► Положить ► Остаток ► Снять ►Итог ► Снять ► Закрыть.
Тестовый вариант М:
Открыть ► Установить ► Положить ► Итог ► ОграничитьКредит ► Снять ► Остаток ► Снять ► Закрыть.
Эти и другие тесты случайных последовательностей проводятся для проверки различных вариантов жизни объектов

Тестирование разбиений на уровне классов

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

Обычно используют одну из трех категории разбиения [43]. Категории образуются операциями класса.

Первый способ — разбиение на категории по состояниям. Основывается на способности операций изменять состояние класса. Обратимся к классу Счет. Операции Снять, Положить изменяют его состояние и образуют первую категорию. Операции Остаток, Итог, ОграничитьКредит не меняют состояние Счета и образуют вторую категорию. Проектируемые тесты отдельно проверяют операции, которые изменяют состояние, а также те операции, которые не изменяют состояние. Таким образом, для нашего примера:

Тестовый вариант 1:Открыть ►Установить ►Положить ►Положить ►Снять ►Снять ►Закрыть.Тестовый вариант2:Открыть ►Установить ►Положить ►Остаток ►Итог ►ОграничитьКредит ►Снять►Закрыть.

ТВ1 изменяет состояние объекта, в то время как ТВ2 проверяет операции, которые не меняют состояние. Правда, в ТВ2 пришлось включить операции минимальной тестовой последовательности, поэтому для нейтрализации влияния операций Снять и Положить их аргументы должны иметь одинаковые значения.

Второй способ —разбиение на категории по свойствам. Основывается на свойствах, которые используются операциями. В классе Счет для определения разбиений можно использовать свойства остаток и ограничение кредита. Например, на основе свойства ограничение кредита операции подразделяются на три категории:

1) операции, которые используют ограничение кредита;

2) операции, которые изменяют ограничение кредита;

3) операции, которые не используют и не изменяют ограничение кредита.

Для каждой категории создается тестовая последовательность. Третий способ — разбиение на категории по функциональности. Основывается на общности функций, которые выполняют операции. Например, операции в классе Счет могут быть разбиты на категории:операции инициализации (Открыть, Установить); вычислительные операции (Положить, Снять); запросы (Остаток, Итог, ОграничитьКредит);
операции завершения (Закрыть).

Способы тестирования взаимодействия классовДля тестирования сотрудничества классов могут использоваться различные способы: стохастическое тестирование; тестирование разбиений; тестирование на основе сценариев; тестирование на основе состояний. В качестве примера рассмотрим программную модель банковской системы, в состав которой входят классы Банк, Банкомат, ИнтерфейсБанкомата, Счет, Работа с наличными, ПодтверждениеПравильности, имеющие следующие операции:

Диаграмма сотрудничества объектов банковской системы представлена на рис. 16.1. На этой диаграмме отображены связи между объектами, стрелки передачи сообщений подписаны именами вызываемых операций.

 

Рис..1. Диаграмма сотрудничества банковской системы

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

Для каждой операции в классе-сервере, которая вызывается сообщением из класса-клиента, определяются сообщения, которые она, в свою очередь, посылает.

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

В качестве примера приведем последовательность операций для класса Банк, вызываемых классом

Банкомат:
ПроверитьСчет ►ПроверитьРIN ►[[ПроверитьПолис ►ЗапросСнятия]●ЗапросДепозита●ИнфоСчета]n.

ПРИМЕЧАНИЕ

Здесь приняты следующие обозначения: стрелка означает операцию следования, точка — операцию И/ИЛИ, пара квадратных скобок — группировку операций классов, показатель степени — количество повторений группировки из операций классов.

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

Тестовый вариант N: ПроверитьСчет ►ПроверитьРШ ►ЗапросДепозита.

Для выявления сотрудников, включенных в этот тест, рассматриваются сообщения, связанные с каждой операцией, записанной в ТВ N. Для выполнения заданий ПроверитьСчет и ПроверитьРТМ Банк должен сотрудничать с классом ПодтверждениеПравильности. Для выполнения задания ЗапросДепозита Банк должен сотрудничать с классом Счет. Отсюда новый ТВ, который проверяет отмеченные сотрудничества:

Тестовый вариант М: ПроверитьСчетБанк ►(ПодтвСчетПодтвПрав) ►ПроверитьРINБанк ►(ПодтвРШПодтвПрав) ►ЗапросДепозитаБанк ►(ПоложитьСчет).

В этой последовательности операции классов-сотрудников Банка помещены в круглые скобки, индексы отображают принадлежность операций к конкретным классам.

Тестирование разбиений

В основу этого метода положен тот же подход, который применялся к отдельному классу. Отличие в том, что тестовая последовательность расширяется для включения тех операций, которые вызываются с помощью сообщений для сотрудничающих классов.Другой подход к тестированию разбиений основан на взаимодействиях с конкретным классом. Как показано на рис. 16.1, Банк получает сообщения от Банкомата и класса Работа с наличными. Поэтому операции внутри Банка тестируются разбиением их на те, которые обслуживают класс Банкомат, и на те, которые обслуживают класс Работа с наличными. Для дальнейшего уточнения может быть использовано разбиение на категории по состояниям.

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

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

Рис.2. Диаграмма схем состояний класса Счет

 

Проектируемые тесты должны обеспечить покрытие всех состояний. Это значит, что тестовые варианты должны инициировать переходы через все состояния объекта:

Пример: N: ПроверитьСчет ► ПроверитьРШ ► ЗапросДепозита. Для выявления сотрудников, включенных в этот тест, рассматриваются сообщения, связанные с каждой операцией, записанной в ТВ N. Для выполнения заданий Проверить Счет и Проверить РТМ Банк должен сотрудничать с классом Подтверждение Правильности. Для выполнения задания Запрос Депозита Банк должен сотрудничать с классом Счет. Отсюда новый ТВ, который проверяет отмеченные сотрудничества:

Задания для лабораторной работы:

Провести тестирование получившихся в результате генерации UML классов кода

 

Контрольные вопросы

1.Преимущества тестирования разбиениями классов

2.Минусы тестирования разбиениями классов

3.Опишите способ тестирование классов разбиением на категории

4. Опишите способ тестирование классов по функциональности