Особенности тестирования объектно - ориентированных приложений

Особенности тестирования объектно-ориентированных приложений

В начале тестируются модули, а потом их интеграция. Это касается понятия – модуль – минимально допустимая единица.

Объектно – ориентированный модуль – класс объекта.

Нельзя тестировать операции изолированно. Каждую операцию рассматривают как часть класса.

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

Тестирование классов ориентированно на тестирование операций, инкапсулированных в классе и состояния в пространстве поведения класса.

Интеграционное тестирование в объектно – ориентированных приложениях

Объектно – ориентированное программное обеспечение не имеет иерархического управления структурой. Применить метод восходящей и нисходящей интеграции нельзя.

Существуют два метода интеграции объектно – ориентированных приложений:

1. Тестирование, основанное на потоках

2. Тестирование, основанное на использовании

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

При необходимости используют регрессионное тестирование.

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

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

Основное направление тестирования – это соответствие поведения объекта его спецификации.

Перспектива тестирования:

«+» - объект инкапсулирует в себе данные легко инкапсулировать.

«-» - объект скрывает информацию сложно их обнаружить и проанализировать.

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

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

Объекты взаимодействуют между собой через сообщения.

Сообщения – это запрос на выполнение определенной операции конкретным объектом. Могут быть указаны параметры для выполнения операций передачи результата.

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

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

Получатель может быть не в состоянии выполнить действие, если получит неожиданное сообщение.

Сообщение может содержать фактический параметр, который может быть использован или скорректирован получателем во время обработки сообщения. Объекты, передаваемые в качестве параметров, должны быть в адекватном состоянии до и после обработки, и должны обеспечивать выполнение интерфейсов, на которые рассчитывает получатель.

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

Интерфейс инкапсулирует спецификации операций из них строятся спецификации для более крупных конструкций, таких как классы.

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

Каждый интерфейс вступает в отношение с другими элементами и классами. Может быть описан как тип параметра для поведения с целью обеспечить возможность его передачи как параметра.

Класс– является базисным элементом для определения. Процесс построения объекта – это процесс создания экземпляра.

При этом учитывают следующее:

1. Спецификация класса – объявления того, что может делать любой объект класса.

2. Реализация класса – определяет как каждый объект делает возможные действия.

3. При разработке спецификаций операций взаимодействия отправителя и получателя можно воспользоваться одним из 2-х базовых подходов.

   1. Контрактное программирование

   2. Защитное программирование

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

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

Контрактное: ответственность соблюдается обеими сторонами

Защищенное: недоверие к получателю/отправителю.

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

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

Реализация класса – это описание как объекты представляют свои атрибуты и выполняют операции. Спецификация класса содержит операции построения новых экземпляров. Эти операции могут допускать ошибки при инициализации атрибутов новых экземпляров.

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

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

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

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