Составление тестовых вариантов ТВ1(путь1=1,2,3,7,8) И.Д n=1 arr=1.5 ОЖ.РЕЗ: arr=1.5 -------------------- ТВ2(путь2=1,2,3,5,4) И.Д n=3 arr=1.5,3,4,7 ОЖ.РЕЗ: arr=1.5,3,4.7 --------------------- ТВ3(путь3=1,2,3,5,6,4) И.Д n=3 arr=4.7,3,1.5 ОЖ.РЕЗ: arr=1.5,3,4.7 (1) | v +>(2) | | | v |>(3)--+ || | | ||(5)-+| || | || || v || ||(6) || || | || || v || |+(4)<+| | | +-(7)<-+ | v (8) Драйвер void main(...) { double m1[]={1.5}; double m2[]={1.5,3,4.7}; double m3[]={4.7,3,1.5}; ArrDbl ar1(m1,1); ar1.sort(); ar1.print(); ArrDbl ar2(m2,3); ar2.sort(); ar2.print(); ArrDbl ar3(m3,3); ar3.sort(); ar3.print(); } Тестирование методами чёрного ящика Тестирование методом "чёрного ящика" (функциональное тестирование) предполагает получение комбинации входных данных, обеспечивающих полную проверку всех функциональных требований к программе. Принцип "чёрного ящика" не альтернативен принципу "белого ящика", поскольку он обнаруживает другие типы ошибок. Тестирование "чёрного ящика" обеспечивает поиск следующих категорий ошибок: 1) некорректных или отсутствующих функций; 2) ошибок интерфейса; 3) ошибок во внешних структурах данных или в доступе к внешней базе данных; 4) ошибок характеристик (например, необходимая память); 5) ошибок инициализации и завершения. Техника "чёрного ящика" ориентирована на решение следующих задач: 1) сокращение необходимого количества тестовых вариантов; 2) выявление классов ошибок, а не отдельных ошибок. Способы разбиения по эквивалентности и анализа граничных значений Для этого способа входная область тестируемой программы делится на классы эквивалентности. Для каждого класса эквивалентности разрабатывается один тестовый вариант. Класс эквивалентности -- это набор данных с общими свойствами. Обрабатывая различные элементы класса, программа должна себя вести одинаково. ---------- ----------- | ---------- | ---------- || ---------- || ------------ |||Допустимые| |||Недопустимые| |||исх. | |||исх. | ||данные | ||данные | ---------- ------------+ +------------ | | ----------------+ Классы эквивалентности можно определить из спецификаций на программу, например, если спецификация задаёт в качестве допустимых входных данных трёхразрядные целые числа в диапазоне 250-500, то класс эквивалентости допустимых данных включает все эти числа, и есть два класса недопустимых данных: x>500, y<250. Способы анализа граничных значений Большая часть ошибок обычно происходит на границах области ввода, а не в центре. Анализ граничных значений заключается в получении тестовых вариантов именно для граничных значений. Данный способ тестирования обычно дополняет способ разбиения по эквивалентности. Рассмотрим некоторые правила анализа граничных значений. Пусть условие ввода задаёт диапазон значений n..m. Тогда тестовые варианты должны быть построены для значений n и m, для значений чуть левее n и чуть правее m на числовой оси. Пример: программа должна решать следующую задачу: задан массив целых положительных чисел. Сформировать на его основе три массива чисел таким образом, чтобы суммы их элементов по возможности меньше отличались друг от друга. Предусловие: числа целые, положительные, количество чисел -- не менее трёх и не больше десяти. [Предусловие выполняется] [Предусловие не выполняется] / \ / | | \ [k кратно 3] [k не кратно 3] [k=2] [Есть отриц.] [Есть не ] [k=11] | \ / \ 9 [числа ] [целые числа] 12 [можно ][нельзя ][можно ][нельзя ] 10 11 |получить||получить||получить||получить| |3 равные||3 равные||3 равные||3 равные| [(SIGMA) ][(SIGMA) ][(SIGMA) ][(SIGMA) ] [k=3][k=9][k=3][k=9][k=4][k=10][k=4][k=10] 1 2 3 4 5 6 7 8 ТВ1 И.Д k=3 m=5,5,5 ОЖ.РЕЗ: m1=5 m2=5 m3=5 ТВ2 И.Д k=9 m=3,8,2,5,1,1,1,3,1 ОЖ.РЕЗ: m1=3,5 m2=8 m3=2,1,1,1,3,1 ТВ9 И.Д k=2 m=3,7 ОЖ.РЕЗ: недостаточно эл-тов м исх. массиве ТВ11 И.Д k=4 m=2,7,3,5.1 ОЖ.РЕЗ: В исх. массиве есть вещ. числа Тестирование интеграции Тестирование интеграции поддерживает сборку цельной программной системы. Тесты проводятся для обнаружения ошибок интерфейса. Основные категории ошибок интерфейса: 1) потеря данных при прохождении через интерфейс; 2) отсутствие в модуле необходимой ссылки; 3) неблагоприятное влияение одного модуля на другой; 4) подфункции при объединении не образуют требуемую главную функцию; 5) отдельные (допустимые) неточности при интеграции превышают допустимый уровень; 6) проблемы при работе с глобальными структурами данных. Классические методы предусматривают: 1) нисходящее тестирование интеграции; 2) восходящее тестирование интеграции. При нисходящем тестировании интеграции выделяется т. н. главный (управляющий) модуль. Все остальные модули заменяются заглушками. Тестируется главный модуль. Следующий шаг: одна из заглушек заменяется модулем, и т. д., пока не будет собрана вся система. [гл. модуль] [гл. модуль] / | \ / | \ [з] [з] [з] [м1] [з] [з] При восходящем тестировании модули объединяются в кластеры. Для этих модулей создаётся драйвер. Когда классы оттестированы, к ним подключается модуль более высокого уровня и снова создаётся драйвер. Преимущества и недостатки: нисходящее: недостаток -- использование заглушек, восходящее -- о результатах тестирования мы можем заявить только после окончания интеграции. Тестирование объектно-ориентированных систем Особенности тестирования объектно-ориентированных систем Системы, разработанные в соответствии с функционально-процедурной моделью и объектно-ориентированные имеют следующие существенные различия: 1) разработка объектно-ориентированного ПО начинается с построения моделей, отражающих статические и динамические характеристики будущей системы; на этот этап уходит значительная часть времени всей разработки; цена устранения ошибок этого этапа на поздних этапах разработки велика; 2) объекты, как отдельные программные компоненты -- более сложные компоненты, чем отдельные подпрограммы; 3) при анализе объектно-ориентированого ПО меняется понятие модуля; 4) объектно-ориентированное ПО не имеет иерархической управляющей структуры. Указанные различия определяют уровни тестирования, применяемые к объектно-ориентированным системам: 1) тестирование моделей; 2) тестирование отдельных методов; 3) тестирование отдельных объектов класса (здесь применимо тестирование "чёрного ящика", однако понятие классов эквивалентности требует уточнения; 4) тестирование кластеров объектов; 5) верификация и аттестация объектно-ориентированной системы. Тестирование моделей Разработка объектно-ориентированного ПО начинается с создания моделей. О синтаксической правильности модели судят по корректности использования языка моделирования (например, UML). О семантической правильности судят по соответствию модели реальным проблемам. Для этого модель оценивается экспертами в данной области. Эксперты анализируют содержание классов, наследование, выявляя пропуски и неоднозначности. О согласованности судят путём рассмотрения противоречий между элементами модели. Для этого исследуется каждый класс в его взаимодействии с другими классами. Модель CRC: класс-обязанность-сотрудничество Для оценки модели (диаграммы) на основе CRC-карт рекомендуются следующие шаги: 1) выполнить перекрёстный просмотр CRC-карты и диаграммы взаимодействия объекта; цель -- проверить наличие сотрудников и согласованность информации в обеих моделях; 2) исследуются обязанности CRC-карты; цель -- определить, предусмотрена ли в карте сотрудника обязанность, которая делегируется ему из данной карты; 3) организуется проход по каждому соединению CRC-карты, проверяется корректность запросов, выполняемых через соединение; такая проверка гарантирует, что каждый сотрудник, предоставляющий услугу, получает обоснованный запрос; 4) определяется, требуются ли другие классы и правильно ли распределены обязанности по классам; для этого используются проходы по соединениям; 5) определяется, нужно ли объединять часто запрашиваемые обязанности; 6) шаги 1-5 применяются итеративно к каждому классу и на каждом шаге эволюции ОО-модели. +----------------------------------------+ | Имя класса: Заказ Order | +--------------------------+-------------+ |Обязанность | Сотрудники| +--------------------------+-------------+ |Получить названия станций |Register | |Проверить названия станций|StationSpec | |Получить и сохранить путь |Itinerary,Way| |Определить поезд |Way | |Определить стоимость |Way,Payment | |Расчёт с клиентом |Payment | +--------------------------+-------------+ Особенности тестирования объектно-ориентированных модулей Тестовое окружение объектно-ориентированного ПО выполняет такие же функции, как и для процедурных программ, однако имеет особенности, связанные с наследованием и инкапсуляцией. Если при тестировании структурные программ минимальным объектом является функция, то в объектно-ориентированных это класс. Принцип инкапсуляции предусматривает, что все внутренние данные класса и некоторая часть его методов недоступна извне. В этом случае тестирующий не имеет возможности обращаться в своих тестах непосредственно к данным классам и произвольным образом вызывать методы. То, что ему доступно -- это вызывать методы внешнего интерфейса класса. Существует несколько подходов к тестированию классов. Каждый из них накладывает свои ограничения на структуру драйвера и заглушек: 1) драйвер создаёт один или несколько объектов класса, который тестируется; все обращения к объектам выполняются только с использованием их внешнего интерфейса; тест драйвера в этом случае представляет собой т. н. тестирующий класс, который имеет по одному методу для каждого тестового варианта; процесс тестирования заключается в последовательном вызове этих методов; вместо заглушек в тестовое окружение входит программный код реальной системы; такой подход сейчас довольно широко используется и называется Unit-testing; 2) аналогичный первому, но для всех классов, которые используют тестирующий класс, при необходимости используются заглушки; 3) программный код класса, который тестируется, модифицируется таким образом, чтобы открыть доступ для всех его свойств и методов; построение тестового окружения аналогично как при тестировании структурных программ; 4) используются специальные способы доступа для закрытых данных и методов класса (скрипты отладчика, ассессоры в Visual Studio). Основное преимущество первых методов: класс работает таким же образом, как и в реальной системе. Недостаток: нет уверенности, что проверен весь код класса. Недостаток третьего метода: после изменения текста модуля нельзя дать гарантии, что он будет работать так же, как он работал раньше.