В статье автор представляет технику тестирования ПО, помогающую пользователям автоматизированных инструментов тестирования в процессе принятия решений, без использования ручного кодирования.
Представление процесса принятия решений в табличном формате восходит к античности.1 Таблицы принятия решений предоставляют простые визуальные средства, за счет чего они могут применяться в основанных на знаниях системах для выполнения эффективной верификации процессов. В процессе разработки ПО таблицы принятия решений помогут коллективам разработчиков в управлении сложной логикой программных приложений.2
В данной статье приводится общее описание техники тестирования с таблицами принятия решений, а также обсуждается использование этой техники при работе с IBM Rational Functional Tester и IBM Rational Software Modeler. Эта техника использует нерегрессионные пакеты тестирования, выполняющие в свою очередь набор повторно используемых сценариев тестирования. Каждый описываемый сценарий тестирования сгенерирован в Functional Tester с использованием техники записи/воспроизведения графического интерфейса.
Целью этой статьи является доказательство работоспособности идеи, для чего я за пятидневный период разработал библиотеку Java-классов, реализующую эту технику таблиц принятия решений с инструментарием IBM Rational. Хотя описанная техника пока не была использована при работе над реальным проектом, я продемонстрирую потенциал такого подхода с использованием инструментария IBM Rational, основанного на среде Eclipse. Предлагаемая мной реализация полностью основана на стандартных, документированных интерфейсах, доступных любому заказчику.
Проблема
Нерегрессионные тесты, основанные на управляемых данными техниках тестирования, в которых одиночный сценарий тестирования используется повторно с различными входными данными, достаточно популярны среди пользователей автоматизированных инструментов тестирования.3 Эта техника может быть реализована с Functional Tester, с использованием пулов данных, ассоциированных со сценариями тестирования во время или после их создания. К сожалению, когда при тестировании приложений используется сложная логика, непросто проводить управляемое данными тестирование без утомительного кодирования. В общем смысле, на поведение приложения влияют вариации входных данных в различных тестовых сценариях, из которых состоит пакет тестирования. Эквивалентное разбиение входных данных требуется для идентификации таких наборов данных, которые обеспечивают эквивалентное поведение AUT (тестируемого приложения - application under test). Для каждого пакета тестирования должны быть жестко закодированы условия - это должно помочь в выборе правильного пути тестирования и в учете проблемы вариации данных. Этот подход, который может быть "смешным" для разработчиков, в действительности не слишком ценится тестировщиками, особенно при использовании автоматизированных средств тестирования, так как жесткое кодирование условий сценариев тестирования значительно затрудняет их сопровождение и расширение. Кроме того, не имея четкого представления о стратегии, трудно оптимизировать декомпозицию сценариев тестирования.
Предлагаемый подход
Когда тестировщик вручную реализует процедуру тестирования, он отбирает входные данные в соответствии с целью своего тестирования, при этом он принимает решения, основываясь на поведении тестируемого приложения (AUT). Возникает вопрос - как мы можем помочь тестировщику в этом процессе принятия решений, в случае использования автоматизированных инструментов тестирования, но без использования упомянутого выше жесткого кодирования?
Поиск ответа на этот простой вопрос ведет нас к рассмотрению техники таблиц принятия решений с последующей разработкой библиотеки Java-классов для подтверждения правильности концепции. Таблицы принятия решений реализованы в пулах данных Functional Tester. Сценарии принятия решений, интерпретирующие логику тестирования, предоставленную таблицами принятия решений, включаются в архитектуру пакета тестирования, как показано на рис. 1. Другие повторно используемые сценарии тестирования, входящие в пакет тестирования, генерируются с помощью Functional Tester с использованием техники записи/воспроизведения графического интерфейса. Сегмент тестирования определяется как последовательность сценариев тестирования между:
- двумя сценариями принятия решений;
- между стартовым сценарием и сценарием принятия решения;
- между сценарием принятия решения и завершающим сценарием.
Управляемая данными таблица связана с пакетом тестирования для его повторного выполнения с несколькими комбинациями входных данных, введенных в различные сценарии тестирования.
Рис. 1: Пакет тестирования состоит из сценариев тестирования и сценариев принятия решений.
Эта техника предоставляет следующие преимущества:
- Формализованный подход к выполнению пакетов и сценариев тестирования
- Инкапсуляцию логики пакета тестирования в сценариях принятия решений
- Архитектура пакета тестирования центрируется вокруг точек принятия решений
- Более просто отслеживаемая и изменяемая с помощью таблиц принятия решений логика тестирования, которая может быть прочитана и дополнена даже далекими от программирования сотрудниками
- Более гибкая реализация управляемого данными подхода.
Техника тестирования, основанная на таблицах принятия решений
Когда в процессе тестирования достигается точка принятия решения, тестировщик изучает состояние AUT и определяет дальнейшие действие тестирования. Каждая точка принятия решения может быть определена с помощью таблицы принятия решений. Таблица принятия решения состоит из двух частей: части условий и части действий. В таблице принятия решений определяется, при каких условиях должно выполняться действие тестирования. Каждое условие выражается в виде отношения между переменными, которое должно быть разрешено как истинное или ложное. Все возможные комбинации условий определяют набор альтернатив. Для каждой альтернативы должно быть рассмотрено действие тестирования. Число альтернатив увеличивается экспоненциально вместе с числом условий, что может быть выражено как 2ЧислоУсловий. Когда таблица принятия решений становится слишком сложной, может быть создана иерархия новых таблиц принятия решений.
Так как некоторые указанные альтернативы могут выглядеть нереалистично, стратегия тестирования должна: 1) убедиться в том, что все альтернативы реально могут быть достижимы 2) описать, как тестируемое приложение будет вести себя во всех альтернативных условиях. С помощью таблицы принятия решений достаточно просто добавлять или удалять условия в зависимости от стратегии тестирования. Область охвата теста легко увеличить с помощью добавления новых действий тестирования от итерации к итерации, в соответствии со стратегией тестирования.
Как проиллюстрировано на рис. 2, таблицы принятия решений удобны при спецификации, анализе и тестировании сложной логики. Они эффективны в описании ситуаций, когда изменяющиеся условия приводят к различным действиям тестирования. Кроме того, они очень хорошо подходят при поиске ошибок как в реализации, так и в спецификации.
Рис. 2: Пример таблицы принятия решений
Работа с таблицами принятия решений и с таблицами, управляемыми данными
В каждой точке принятия решения, в таблице должно быть указано, что необходимо для верификации AUT (в зависимости от условий), а также приведены дальнейшие действия тестирования. Так как логика определена в таблице принятия решений, тестировщику не требуется выполнять жесткое кодирование какой-либо логики тестирования. Сценарий принятия решений выполняет верификацию во время выполнения, сравнивает результат с альтернативами, представленными в таблице принятия решений, и возвращает для выполнения следующий сценарий тестирования в случае обнаружения решения.
Сценарий пакета тестирования содержит несколько сценариев тестирования и принятия решений. Все элементы пакета тестирования определяются в таблице драйверов, в которой указывается неупорядоченный набор сегментов тестирования. Каждый сегмент тестирования содержит набор сценариев тестирования, которые последовательно выполняются между двумя сценариями принятия решений. Для каждого сегмента тестирования, в таблице драйверов указывается переход между исходными и целевыми сценариями тестирования.
Так как решение вычисляется динамически во время исполнения сценарием принятия решения, должен быть реализован механизм оповещения, чтобы сценарий пакета тестирования извещался сценарием принятия решения о следующем исполняемом сценарии тестирования. Когда сценарий принятия решения извещает сценарий пакета тестирования о следующем выполняемом сценарии, то сценарий пакета тестирования запрашивает таблицу драйверов для поиска следующего предназначенного для выполнения сегмента тестирования. Схема этого процес c а изображена на рис. 3.
Рис. 3: Элементы пакета тестирования
Потенциально любой сценарий в пределах пакета тестирования привязан к пулу данных, что необходимо для обеспечения ввода данных. Когда управляемая данными таблица привязана к пакету тестирования, имеется возможность указания нескольких комбинаций записей данных для ввода в сценарии тестирования и динамического изменения поведения AUT. Когда поведение AUT меняется, меняется и результат, предоставляемый каждым сценарием принятия решения, и соответственно меняется путь тестирования в рамках изменений AUT. С одиночным сценарием пакета тестирования возможно проведение валидации нескольких путей тестирования. Становится просто рассматривать новые комбинации входных данных и расширять область покрытия пакета тестирования, добавляя новые условия в таблицы принятия решений.
Этот подход четко отделяет логику тестирования, инкапсулированную в сценариях тестирования, от действий тестирования и верификаций, выполняемых сценариями тестирования. Идентификация точек принятия решений в AUT помогает формализовать и использовать декомпозицию пакета тестирования на сценарии тестирования.
Использование этой техники с Functional Tester
Для доказательства работоспособности этой концепции автор разработал Java-библиотеку для реализации техники, основанной на таблицах принятия решений, с Functional Tester. Для создания сценария пакета тестирования тестировщик должен выполнить следующие действия:
- Повторно использовать кодовые шаблоны пакета тестирования и заполнить таблицу драйверов пакета тестирования
- Создать сценарии принятия решений с кодовыми шаблонами и заполнить таблицы принятия решений
- Заполнить управляемую данными таблицу
Библиотека тестирования с использованием таблиц принятия решений
Библиотека тестирования с использованием таблиц принятия решений состоит из Java-классов, предоставляющих следующие сервисы:
- Сервисы для инициализации и выполнения итераций по структуре пакета тестирования, определенной в таблице драйверов
- Сервисы для изучения таблиц принятия решений и для сравнения альтернатив с результатами верификации AUT
Механизм листенера событий между сценарием принятия решений и сценарием пакета тестирования прозрачен для тестировщика. Это реализовано в библиотеке с помощью классов DecisionBuilder и TestSuiteDriver, как показано на рис. 4. Для использования сервисов, предоставленных библиотекой, каждый сценарий пакета тестирования и каждый сценарий принятия решений, созданные тестировщиком, должны быть произведены на базе класса TestSuiteHelper4, который предоставляет интерфейс к библиотеке. Для этой цели тестировщик выбирает данный класс "super helper" каждый раз, когда создает новый пакет тестирования или сценарий принятия решений.
Рис. 4: Основные классы в библиотеке тестирования с использованием таблиц принятия решений
Создание нового пакета тестирования
Пакеты тестирования могут быть использованы для реализации стратегии автоматизированного тестирования на бизнес-уровне или на уровне системных прецедентов. На уровне системных прецедентов, пакет тестирования реализует сценарии прецедентов. На бизнес-уровне, пакет тестирования отслеживает поток бизнес-задач в рамках нескольких прецедентов. Для данного уровня тестирования, пакеты тестирования также могут быть организованы в соответствии с целями, определенными в плане итерационного тестирования. Например, пакет тестирования может фокусироваться на верификации бизнес-правил, или на предоставлении сервисов, или на проверке целостности данных (создание, модификация, удаление). Хотя теоретически и возможно работать с только одним пакетом тестирования, но на практике это чрезвычайно неудобно. Поэтому тестировщику следует создавать пакеты в соответствии с архитектурой тестирования, а также имеет смысл иметь пакет тестирования, выполняющий остальные пакеты.
Для создания нового пакета тестирования тестировщик должен выполнить следующие действия:
- Создать пустой сценарий тестирования с помощью Functional Tester
- Вставить кодовый шаблон в сценарий пакета тестирования (такой кодовый шаблон для сценария пакета тестирования показан на рис. 5.)
- Указать название таблицы драйверов и таблицы, управляемой данными
Рис. 5: Кодовый шаблон для сценария пакета тестирования
Как показано на рис. 6, структура каждого пакета тестирования описывается в таблице драйверов, пуле данных, определяющих переходы между сценариями тестирования (т.е. переходы от исходного сценария к целевому сценарию ). Порядок следования не имеет значения, так как класс TestSuiteDriver анализирует пул данных драйвера и загружает в память структуру пакета тестирования. В любом случае, вам следует определить стартовые и завершающие сценарии. Тестировщик может заполнить эту таблицу с целью указания пакета тестирования или генерации этого пула данных из UML-определения пакета тестирования (см. упомянутую ниже статью "Modeling test suites with IBM Rational Software Modeler").
Рис. 6: Пример таблицы драйверов пакета тестирования
Создание управляемого данными пакета тестирования
Управляемые данными таблицы могут быть привязаны к сценарию пакета тестирования для следующих целей: 1) контроль ввода данных в различные сценарии тестирования 2) создание различных путей в рамках проводимого тестирования AUT. Заголовок управляемой данными таблицы содержит названия пулов данных, используемых сценариями в пакете тестирования. Каждая строка этой таблицы определяет различные комбинации записей входных данных, используемых для каждого пула данных пакета тестирования. Как показано на рис. 7, в первом столбце управляемой данными таблицы имеется флаг "true/false", используемый пакетом тестирования для выбора или отклонения строки, в зависимости от целей тестирования.
Рис. 7: Пример управляемой данными таблицы пакета тестирования
Каждый пул данных сценария тестирования также содержит флаг, указывающий, должен или нет сценарий тестирования выбирать запись, при итерационном проходе через записи пула данных. Когда сценарий тестирования начинает новую итерацию, класс TestSuiteDriver читает таблицу драйверов пакета тестирования и устанавливает флаги выбора пула данных пакета тестирования, затем эта процедура повторяется для всех сценариев тестирования. Таким образом, при итеративном проходе через записи пула данных пакета тестирования рассматривается только запись, указанная в таблице драйверов. Этот механизм управляется библиотекой и полностью прозрачен для тестировщика. Единственным ограничением является присутствие флага SelectRecord для всех пулов данных.
Создание сценария принятия решения
Тестировщик идентифицирует точки приятия решений в потоке задач пакета тестирования и создает сценарий принятия решений для каждой точки. Когда поток задач пакета тестирования разрабатывается с помощью диаграммы активности UML, сценарий принятия решения создается для каждого условия (см. упомянутую ниже статью "Modeling test suites with IBM Rational Software Modeler").
Для реализации точки принятия решения тестировщик должен выполнить следующие действия:
- Создать и заполнить пул данных принятия решения
- Создать пустой сценарий принятия решения и вставить кодовый шаблон
- Зарегистрировать точки верификации для каждого условия в решении
Прежде всего, тестировщик создает таблицу принятия решений с помощью пула данных Functional Tester. Таблица принятия решений, пример которой показан на рис. 8, также может быть сгенерирована из UML-определения пакета тестирования (см. упомянутую ниже статью "Modeling test suites with IBM Rational Software Modeler"). Сценарий принятия решений сравнивает результаты верификаций, выполняемых при тестировании AUT, с условиями, что делается для идентификации выполняемых действий тестирования (т.е. предназначенного для выполнения следующего сценария тестирования). Когда комбинация недоступна или еще не реализована, строка в пуле данных исключается и действие тестирования становится неопределенным.
Рис. 8: Пример таблицы принятия решений
Затем тестировщик создает пустой сценарий тестирования, вставляет кодовый шаблон в сценарий тестирования (как проиллюстрировано на рис. 9), и указывает название пула данных принятия решения. Тестировщик использует Functional Tester для вставки точек верификации, которые собирают информацию, необходимую таблице принятия решения.
Рис. 9: Кодовый шаблон для сценария принятия решений
Моделирование пакетов тестирования с помощью IBM Rational Software Modeler
Пакет тестирования разработан с помощью UML-диаграммы действий, в которой каждое действие соответствует действию тестирования (сценарию тестирования) и каждое решение соответствует сценарию принятия решения, как показано на рис. 10. Условия, указанные в точке принятия решения, используются для генерации соответствующей таблицы принятия решения. Диаграммы действий просты в использовании и понимании сотрудниками, не занимающимися разработкой.
Рис. 10: Реализация пакета тестирования сгенерирована на основе спецификации UML.
Объектный узел со стереотипом "datastore" может быть привязан к действию тестирования для указания того, какой именно пул данных требуется для этого действия тестирования. Также имеется возможность указать структуру пула данных с помощью класса. Каждая колонка пула данных соответствует атрибуту класса. UML-анализатор генерирует все пулы данных, требуемые для выполнения пакета тестирования с помощью Functional Tester, включая таблицу драйверов, таблицы принятия решений, и структуру управляемых данными таблиц и пулов данных сценариев тестирования. Как диаграмма действий, так и диаграмма классов может быть организована с учетом элемента совместной работы, как проиллюстрировано на рис. 11. Между определением пакета тестирования и моделью прецедента могут быть созданы связи трассируемости, как проиллюстрировано на рис. 12. С помощью возможностей трансформации, предоставленных IBM Rational Software Modeler, может быть разработан еще более сложный подход.
Рис. 11: Определение пакета тестирования инкапсулировано с учетом совместной работы.
Рис. 12: Связи трассируемости между пакетом тестирования и другими элементами модели
Я разработал UML-анализатор, который генерирует таблицу драйверов пакета тестирования, таблицы принятия решений и пулы данных (например, структуру для таблицы, управляемой данными, и таблицы входных данных сценария тестирования) в XML-формате. Подключаемый модуль Eclipse с контекстным меню используется для генерации таблиц пакета тестирования при выборе возможности совместной работы, как показано на рис. 13.
Рис. 13: Библиотека классов для генерации таблиц пакета тестирования из UML-определения
Все возможные альтернативы автоматически генерируются пулом данных таблицы принятия решений, как показано на рис. 14. Генерируются только действия тестирования, указанные в диаграмме действий. Новые действия тестирования, которые не указаны в диаграмме действий, могут быть добавлены в таблицу принятия решений перед выполнением импорта в проект тестирования Functional Tester.
Рис. 14: Все возможные комбинации генерируются в таблице принятия решений.
Заключение
Я уверен, что эта техника тестирования, основанная на использовании таблиц принятия решений, значительно расширит возможности тестировщика по управлению решениями, которые должны быть приняты во время проведения автоматизированного тестирования. С использованием IBM Rational Functional Tester и IBM Rational Software Modeler, эта техника может облегчить работу с нерегрессионными пакетами тестирования, которые выполняют набор повторно используемых сценариев тестирования.
Как я отметил во введении, эта техника пока не была использована в реальных проектах, но уже имеющаяся реализация с использованием библиотеки Java-классов говорит о том, что эта техника вполне жизнеспособна и осуществима.
В дальнейших работах будет показано расширение описанной здесь модели тестирования. Сервисы трансформации моделей, предоставляемые IBM Rational Software Architect, будут использованы для разработки с последующим автоматизированным тестированием.
Я буду рад услышать ваши отзывы об этом подходе; мне можно написать по адресу vauthier@fr.ibm.com.
Примечания
1 Вавилоняне, например, использовали глиняные таблички для вычислений. См. работу Дж. Дж. О'Коннора и Е.Ф. Робертсона "Обзор Вавилонской математики", имеющуюся по адресу http://www-history.mcs.st-andrews.ac.uk/HistTopics/Babylonian_mathematics.html
2 См. презентацию в PowerPoint Марьен Де Вильда, озаглавленную "Таблицы принятия решений: удобная техника тестирования и не только" компании Software Quality NZ Inc., http://www.sqnz.org.nz/documents/Decision Table training session.ppt
3 Эти три статьи особенно интересны: Михаил Келли, "Использование IBM Rational Functional Tester 6.1 для выполнения вашего первого функционального регрессионного тестирования," http://www-128.ibm.com/developerworks/rational/library/05/412_kelly/, IBM developerWorks, ноябрь 2005 г.; Михаил Келли, "Среда автоматизации с IBM Rational Functional Tester: управление со стороны данных," http://www-128.ibm.com/developerworks/rational/library/05/1108_kelly/, IBM developerWorks, ноябрь 2005 г.; и техническая публикация Кейт Замбелич, "Полностью управляемое данными автоматизированное тестирование": http://www.geocities.com/model_based_testing/online_papers.htm
4 См. статью Дэнниса Шульца, "Создание класса "super helper" в IBM Rational Functional Tester", http://www-128.ibm.com/developerworks/rational/library/1093.html, IBM developerWorks, декабрь 2003 г.
5 См. презентацию Джеймса Баха, "Стратегия тестирования: что это такое? На что это похоже?" 1998 г. www.satisfice.com; и статью Сема Кейнера, "Улучшение сопровождения пакетов автоматизированного тестирования", опубликованную в Quality Week в 1997 г.
6 См. работу Жена Ру Дая, "Управлемое моделями тестирование с помощью UML 2.0": http://www.cs.kent.ac.uk/projects/kmf/mdaworkshop/submissions/Dai.pdf
Об авторе
Жан-Клод Ватье (Jean-Claude Vauthier) является IT-специалистом IBM Software Services Rational во Франции. С 2001 г. занимается оптимизацией использования решений Rational. Перед тем, как начать работать в IBM Rational, он работал в сфере программной инженерии CAD/CAM, разрабатывал военные и телекоммуникационные системы. Имеет докторскую степень в аналитической химии, степень бакалавра в жидкостной механике, и опыт работы в военно-космической отрасли.