Объектно-ориентированное тестирование

Стратегии выполнения пошагового тестирования

Существуют две принципиально различных стратегии выполнения пошагового тестирования:

- нисходящее тестирование;

- восходящее тестирование.

Нисходящее тестирование начинается с головного модуля, в нашем случае с модуля А. Возникают проблемы: как передать тестовые данные в А, ведь ввод и вывод осуществляется в других модулях? Как передать в А несколько тестов?

Решение можно представить в следующем виде:

а) написать несколько вариантов заглушек B (для каждого теста);

б) написать заглушку B так, чтобы она читала тестовые данные из внешнего файла.

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

а) подключаются наиболее важные с точки зрения тестирования модули;

б) подключаются модули, осуществляющие операции ввода/вывода (для того, чтобы обеспечивать тестовыми данными «внутренние» модули.

Нисходящее тестирование имеет ряд недостатков: предположим, что модули I и J уже подключены, и на следующем шаге тестирования заглушка H меняется на реальный модуль H. Как передать тестовые данные в Н? Это нетривиальная задача, потому что между J и Н имеются промежуточные модули и может оказаться невозможным передать тестовые данные, соответствующие разработанным тестам. К тому же достаточно сложно интерпретировать результаты тестирования Н, так как между Н и I также существуют промежуточные модули.

Восходящее тестирование практически полностью противоположно нисходящему тестированию. Начинается с терминальных (не вызывающих другие модули) модулей.

Стратегия подключения новых модулей также должна основываться на степени критичности данного модуля в программе. Восходящее тестирование лишено недостатков нисходящего тестирования, однако имеет свой, главный недостаток: рабочая программа не существует до тех пор, пока не добавлен последний (в нашем случае А) модуль.

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

Объектно-ориентированное тестирование

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

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

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

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

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

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

К недостаткам обзоров (ревизий) относятся:

- возможные ошибки, обусловленные человеческим фактором;

- значительно большие затраты и усилия, нежели регрессионное тестирование.

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

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

- роль класса в системе, в частности, степень связанного с ним риска;

- сложность класса, измеряемая количеством состояний, операций и связей с другими классами;

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

Если какой-либо класс должен стать частью некоторой библиотеки

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

При тестировании классов можно выделить 5 оцениваемых факторов:

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

2. Что тестировать.Тестировать нужно программный код на точное соответствие его требованиям, т.е. в классе должно быть реализовано все запланированное и ничего лишнего. Если для конкретного класса характерны статические элементы, то их также необходимо тестиро-вать. Такие элементы принадлежат самому классу, но не каждому экземпляру.

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

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

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