Методы тестирования объектно-ориентированных систем

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

Класс представляет собой набор атрибутов и методов ( обычно часть из них скрыта ) и, следовательно, граф управления не применим. Отметим основные черты нового модуля тестирования:

· нет глобальных данных ( или они сведены к минимуму в виде констант ),

· класс не является тестируемым элементом, тестироваться могут только объекты, т.е. экземпляры класса,

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

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

Тестирование наследования.Наследуемые методы должны быть протестированы заново при переопределении или дополнении базового метода. Это связано с тем, что новый контекст атрибутов, новые аспекты поведения могут добавить новые ошибки. Таким образом если класс А является базовым для класса В. То сначала тестируются все методы класса А, затем все методы класса В причем так, что все методы класса А, вызываемые из В тестируются заново.

Инкапсуляция, сама по себе, не является источником ошибок, однако представляет препятствие для проведения тестирования, так как при тестировании требуется получение полной информации о состоянии класса, в том числе и всех его атрибутов, многие из которых могут быть объявлены как "невидимые" извне. Решение этой проблемы может быть найдено в определении специальных отладочных методов, возвращающих информацию о состоянии класса или в использовании низкоуровневых отладчиков программного кода.

Тестирование полиморфизма. Каждый возможный вариант полиморфного вызова метода должен быть протестирован. Примером такого случая является класс А, содержащий метод МА, вызывающий в свою очередь полиморфный метод МАV. Тогда для любого производного класса В, переопределяющего метод MAV, должен быть выполнен тест по вызову метода МА.

Тестирование с учетом внутренней структуры. Такой метод обычно именуют "white-box testing" (метод "прозрачного ящика"). Тестирование выполняется путем рассмотрения структуры и определения возможных тестовых последовательностей. Существует два варианта подобного тестирования: тестирование, основанное на интерфейсе класса и тестирование, основанное на методах класса. В первом случае набор тестов составляется так, чтобы проверить функционирование интерфейсных свойств объекта, таких как сообщения и исключения.

Основными методами составления тестов является анализ графа передачи управления в рамках методов объекта, и анализ потока данных.

Тестирование без учета внутренней структуры. Так называемое тестирование методом "черного ящика" ("Black-box testing"). Набор тестов составляется опираясь на спецификацию и требования к классу. Структура класса при этом не анализируется.

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

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

Основой для составления автоматной модели класса могут служить диаграммы использования, также допустимо определение допустимых состояний методом "white box" (т.е. на основе анализа программного кода).

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

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

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

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

Интеграция классов для создания прикладной системы тесно переплетается с общим подходом к разработке. Существуют две стратегии интеграции: базирующаяся на задаче и базирующаяся на использовании. Первая определяет всю цепочку классов, начиная с главного (управляющего) класса и заканчивая классами "исполнителями". Если каждый класс проверен, то вся задача считается протестированной. Интеграция, основанная на использовании, применяется когда существует несколько или вообще не существует управляющих классов. Отдельные классы используют другие группы классов для выполнения своих задач. Тестирование такого вида интеграции осуществляется путем выделения отдельных групп классов, и тестирование каждого класса, использующего данную группу.

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

Приложение 1. Пример разработки объектно-ориентированной программной системы

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

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

Проведем анализ требований и определим внешнее функционирование проектируемой системы и ее взаимодействия с внешним миром, путем построения диаграммы использования (рис П.1)

Рис П.1. Диаграмма использования ИС "Абитуриент"

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

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

Аналогичным образом формируются остальные диаграммы.

Рис. П.2. Диаграмма последовательностей для блока "Учет поданных заявлений"

Дальнейшие стадии разработки связанны с проектированием структуры объектов, определенных на этапе анализа.

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

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

· вставка новой записи,

· удаление записи,

· поиск записи по ключу.

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

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

Возвращаясь к проектированию таблицы заявлений в ИС "Абитуриент", определим необходимые классы, которые образуют данную таблицу.

Базовым элементом таблицы должен являться объект “Элемент хэш-таблицы”. Этот класс имеет свойство “ключ” и метод поведения “вычислить хэш-функцию”, и "отобразить информацию" (печать значения атрибута "ключ"):

объект:

элемент хэш-таблицы

атрибуты:

ключ : строка

методы:

вычислить хеш-функцию
отобразить информацию

Далее необходимо определить абстрактную хэш-таблицу, задающую метод хранения элементов, и методы поиска, вставки и удаления элементов.

объект:

хэш-таблица

атрибуты:

массив элементов типа элемент хэш-таблицы

количество элементов : число

методы:

вставить элемент( элемент : элемент хэш-таблицы )

удалить элемент ( элемент : элемент хэш-таблицы )

найти элемент ( ключ : строка ) : элемент хеш-таблицы

Ключевым моментом в определении методов таблицы является то, что параметрами являются объекты “Элемент хэш-таблицы”. За счет этого можно легко модифицировать тип элементов таблицы и даже включать в одну и ту же таблицу разнотипные элементы.

Конкретизируем информацию, содержащуюся в таблице. Для хранения сведений об абитуриенте, подавшем заявление, будем использовать новый объект "Абитуриент", наследующий свойства объекта "Элемент хеш-таблицы" .

объект:

Абитуриент ( Элемент хеш-таблицы )

атрибуты:

Номер диплома : строка

средний балл : число

методы:

отобразить информацию

Отметим, что ключом является фамилия абитуриента, для хранения которой используется атрибут "ключ", наследованное от объекта-предка. Метод "отобразить информацию" для данного объекта производит печать значений всех атрибутов. При этом, в отличии от одноименного метода родительского объекта, он будет в состоянии распечатать конкретную информацию (номер диплома, средний балл ) по данному абитуриенту.

Кроме того, проектируема таблица должна обеспечивать хранение информации и о внеконкурсных абитуриентах, зачисляемых в ВУЗ на основании заключаемого контракта. Для хранения подобной информации введем объект "контрактный абитуриент", который также будем наследовать от объекта "Элемент хеш-таблицы".

объект:

Контрактный абитуриент ( Элемент хеш-таблицы )

атрибуты:

номер контракта : строка

методы:

отобразить информацию

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

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

Отобразим полученную структуру объектов системы в виде диаграммы классов (рис. П.3).

Рис.П.3. Диаграмма классов для пакета "Таблица заявок"

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

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

Приложение 2. Словарь терминов

Блок использования - элемент диаграммы использования, который представляют собой некоторый набор функций системы, объединяемых в единое целое с точки зрения пользователя.

Диаграмма действий - показывают выполнение операций, используются в UML

Диаграмма использования - диаграмма, отражающая внешнее функционирование системы и ее связи. Используется в рамках UML

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

Диаграмма объектов - диаграмма, используемая в объектно-ориентированном проектировании, для представления объектной структуры системы в процессе ее функционирования.

Диаграмма компонентов - отражает зависимости составных частей программного обеспечения, в которые включаются файлы исходных текстов, двоичные файлы библиотек объектных модулей и исполняемые файлы, используется в рамках UML

Диаграмма переходов - диаграмма, используемая в объектно-ориентированном проектировании для описания состояний объектов и переходов между состояниями.

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

Диаграмма развертывания - показывают конфигурацию исполняемой программной системы, состоящей из программных компонентов, процессов, объектов. Используется в UML

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

Диаграмма сотрудничества - предназначена для описания методов взаимодействия между объектами., используется в UML

Инкапсуляция - принцип объектно-ориентированного подхода, определяющий такое свойство, при котором объекты содержат описание атрибутов и действий одновременно

Категория классов - являются набором классов и категорий классов в рамках объектно-ориентированного проектирования. Аналогично понятию пакета в UML.

Наследование - принцип объектно-ориентированного подхода , определяющий такой способ задания объектов, при котором производные объекты (потомки) наследуют свойства (атрибуты и действия) от своих родителей

Пакеты - элемент языка UML, представляющие собой универсальное средство для группировки элементов модели, например классов

Полиморфизм - принцип объектно-ориентированного подхода , определяющий такое свойство объектов, при котором действие с одинаковыми именами вызывают различное поведение для различных объектов

Схема атрибутов - диаграмма объектно-ориентированного анализа, на которой определяются атрибуты объектов.

Схема методов - диаграмма объектно-ориентированного анализа, на которой определяются методы объектов

Схема объектов - диаграмма объектно-ориентированного анализа, представляющая собой перечисление объектов предметной области.

Схема предметной области - диаграмма объектно-ориентированного анализа, содержит описание отдельных частей предметной области и взаимодействий между ними.

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

Шаблон диаграммы классов - текстовый документ, определяющий сведения об атрибутах и методах классов. Используется в объектно-ориентированном проектировании.

Activity diagram - см. диаграмма действий

Component diagram - см. диаграмма компонент

Collaboration diagram - см.. диаграмма сотрудничества

Class diagram - см. диаграмма классов.

Deployment diagrams - см. диаграмма развертывания

Sequence diagram - см. диаграмма последовательностей

State chat diagram - см. диаграмма состояний

UML - универсальный язык моделирования

Use case - см. блок использования.

Use case diagram - см. диаграмма использования