Тестирование оо программ
В начале тестируются модули, а потом их интеграция. Это касается понятия – модуь – минимально допустимая единица.
ОО: модуль – класс объекта.
Нельзя тестировать операции изолированно. Каждую операцию приходится рассматривать как часть класса.
Тестирование классических модулей ориентированное на поток управления внутри модуля и поток данных через интерфейс модуля.
Тестирование классов ориентированное на тестирование операций, инкапсулированных в классе и состояния в пространстве поведения класса.
Тестирование оо интеграции
ОО ПО не имеет уерархического управления структурой невозможно применить метод восходящей и нисходящей интеграции.
Байндер предложил 2 метода интеграции ОО систем:
Тестирование, основанное на потоках
Тестирование, основанное на использовании
Объект интеграции – набор классов, обслуживающий единичный ввод данных системы Срадства описывающий каждый поток тестируются и интегрируются отдельно.
Применяют регрессионное тестирование.
Вначале интегрируются и тестируются независимые друг от друга классы. Далее работаем последовательно с первым слоем зависимых классов. Стараются избегать драйверов и заглушек.
Оо тестирование правильности
Подробности относительно классов нас не интересуют. Может использоваться тестирование черного ящика. Полную информацию содержат диаграммы: взаимодействия, деятельности, схемы состояния.
Объект- операционная категория. Подлежит тестированию. Основное направление: соответствие поведения объекта его спецификации.
Перспектива тестирования:
«+» - объект инкапсулирует в себе данные легко инкапсулировать.
«-» - объект скрывает информацию сложно их обнаружить и проанализировать.
Объект может перейти в состояние в котором будет удерживаться на протяжении жизненного цикла. Но оно может стать неадекватным и повлиять на корректность поведения.
Объект обладает жизненным циклом. Может подвергнут анализу в любой момент существования. Можно проверить состояние объекта и его соответствие моменту.
Сообщения– запрос на выполнение определенной операции конкретным объектом. Могут быть указаны параметры для выполнения операций передачи результата.
У каждого сообщения есть отправитель, который определяет момент передачи сообщения, и тут может ошибиться
У каждого сообщения есть получатель, который может быть не готов к приему сообщения.
Получатель может быть не в состоянии выполнить действие, если получит неожиданное сообщение.
Сообщение может содержать фактический параметр, который может быть использован или скорректирован получателем во время обработки сообщения. Объекты, передаваемые в качестве параметров должны быть в адекватном состоянии до/после обработки и должны обеспечивать выполнение интерфейсов, на которые рассчитывает получатель.
Интерфейс– совокупность объявлений, регламентирующих их поведение.
ПТ: Интерфейс инкапсулирует спецификации операций из них строятся спецификации для более крупных конструкций, таких как классы.
Если интерфейс создает поведение, не связанное с интерфейсами других поведений, то его реализация приводит к ущербным проектам.
Каждый интерфейс вступает в отношение с другими элементами и классами. Может быть описан как тип параметра для поведения с целью обеспечить возможность его передачи как параметра.
Класс– является базисным элементом для определения.
Процесс построения объекта – это процесс создания экземпляра.
Концептуальная база, выраженная в 2-х составляющих:
Спецификация класса – объявления того, что может делать любой объект класса.
Реализация класса – определяет как каждый объект делает возможные действия.
При разработке спецификаций операций взаимодействия отправителя и получателя можно воспользоваться одним из 2-х базовых подходов.
Контрактное программирование
Защитное программирование
В условиях контрактного подхода: интерфейс определяется в виде обязательств отправителя и получателя во взаимодействии. Обычно оформляется как набор предикативных условий – обязательства отправителя, постусловий – получателя, совокупности инвариантов условий.
Защищенное: оперирует возвращающимися сигналами – результат запроса. Обычно поступают в виде кодов возвратов.
Контрактное: ответственность соблюдение обеими сторонами
Защищенное: недоверие к получателю/отправителю.
ПТ: контрактный подход упрощает тестирование классов, но усложняет тестирование взаимодействия. То есть, должна быть уверенность, что все отправители выполняют предусловия.
Подход защищенного программирования усложняет задачу тестирования класса, т.к. КП должен быть рассчитан на любой возможный результат и тестирование взаимодействия: т.к. мы должны убедиться в том, что можно получить все возможные результаты взаимодействия и что получатель их адекватно воспримет.
Реализация класса – описание как объекты представляют свои атрибуты и выполняют операции.
ПТ:
1. Спецификация класса содержит операции построения новых экземпляров.
2. Эти операции могут допускать ошибки при инициализации атрибутов новых экземпляров.
3. Класс определяет свое поведение значениями атрибутов во взаимодействии с другими классами.
Эти и другие классы могут быть построены некорректно и могут стать причиной отказа класса использовать их в определении.
Реализация класса удовлетворяет спецификации данного класса. Но это не означает что сама спецификация безошибочна. Реализация может нарушать требования более высокого уровня.
Реализация может не поддерживать все необходимые операции, либо неправильно их выполнять.
Класс определяет предусловия выполнения всех операций. В самом классе могут отсутствовать средства для проверки предусловий перед отправкой сообщений.
Полиморфизм: возможность рассматривать объект как принадлежащий более чем 1 классу.
1. Включения: вхождения различных форм в один и тот же класс
ПТ: позволяют проводить инкрементное расширение систем, путем добавления новых классов вместо модификации существующих. В таких расширениях могут возникать непредвиденные взаимодействия.
Позволяют иметь 1 или более параметров полиморфных ссылок. Это приводит к увеличению количества возможных типов фактических параметров.
Позволяют любой операции задавать описание ответа предстоящей полиморфной ссылки. Фактический класс объекта-ссылки может оказаться некорректным, либо неожиданным для отправителя.
2. Параметрический– способность определить тип в терминах одного или большего числа параметров.
ПТ: ПП поддерживает различие типов отношений идущих от наследования. Если шаблон работает в рамках одного сеанса порождения экземпляра, то нет гарантии того, что он будет работать и в рамках другого такого же сеанса. Поскольку программный код шаблона под правильной реализацией может подразумевать такие операции, как создание копий и деструкторов.