какие сущности необходимо использовать в таблицах принятия решений

Decision Table — что это и как применять

Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинаторику условий из ТЗ.

Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям.

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

Decision Table относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:

Decision Table (таблицы решений) — текущая статья

Сегодня говорим про Decision Table (таблица решений):

Помимо статьи есть видео о таблице решений с моего канала. Кому что удобнее! 🙂

Как составлять таблицу

По горизонтали — выписываем условия, которые влияют на результат. А чуть ниже — сам результат, в оригинале Action — действие, которое нужно выполнить.

По вертикали — правила: конкретная комбинация входных условий.

То есть мы указываем значения условий и результата

Правило 1

Правило 2

Правило N

Условия

Действия

Давайте посмотрим на простом примере — когда у нас один результат (action).

Пример 1. Страховка на автомобиль (один результат)

Я прихожу в страховую компанию и заполняю анкету, где есть 2 вопроса:

Есть ли 5 лет стажа вождения?

Ответить можно либо да, либо нет.

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

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

Если нет стажа, но нет аварий — плачу поменьше, но не сильно. Знаете как бывает — первое время катаются очень осторожно, а потом начинают думать «да я царь и бог, не попаду в аварию». И понеслось.

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

Если опытный, да еще и без аварий — меньше всего. Очень аккуратный водитель, платить скорее всего не придется!

А теперь то же самое, только в виде таблички:

Источник

Тестирование таблицы решений

Что такое тестирование таблицы решений?

Таблица решений — это табличное представление входных данных в сравнении с правилами / случаями / условиями испытаний. Давайте учиться на примере.

Пример 1. Как составить таблицу базовых решений для экрана входа в систему

Давайте создадим таблицу решений для экрана входа в систему.

Условие простое, если пользователь вводит правильное имя пользователя и пароль, он будет перенаправлен на домашнюю страницу. Если какой-либо из вводимых данных неправильный, появится сообщение об ошибке.

Преобразуя это в тестовый пример, мы можем создать 2 сценария,

И один из сценария ниже

По сути, они проверяют одно и то же правило.

Пример 2: Как создать таблицу решений для экрана загрузки

Теперь рассмотрим диалоговое окно, которое попросит пользователя загрузить фотографию с определенными условиями, такими как —

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

Давайте создадим таблицу решений для этого случая.

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

Почему важно тестирование таблицы решений?

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

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

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

Значение этого метода сразу становится понятным по мере увеличения количества входов. Количество возможных комбинаций задается как 2 ^ n, где n — количество входов. Для n = 10, который очень распространен в веб-тестировании, имеющем большие формы ввода, количество комбинаций будет 1024. Очевидно, что вы не можете протестировать все, но вы выберете богатое подмножество возможных комбинаций, используя решение на основе методика тестирования.

Преимущества тестирования таблицы решений

Недостатки тестирования таблицы решений

Основным недостатком является то, что с увеличением количества входных данных таблица станет более сложной.

Источник

QA evolution

Таблица принятия решений

(таблица решений) — способ компактного представления модели со сложной логикой; инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте. Это взаимосвязь между множеством условий и действий.

В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определённому действию.

Таблица принятия решений

Таблица принятия решений, как правило, разделяется на 4 квадранта:

Условия — список возможных условий.

Варианты выполнения действий — комбинация из выполнения и/или невыполнения условий этого списка.

Действия — список возможных действий.

Необходимость действий — указание надо или не надо выполнять соответствующее действие для каждой из комбинаций условий.

Рассмотрим таблицу принятия решений на примере страницы регистрации нового пользователя сервиса KUKU.io

Используем понятия “корректные” и “некорректные” данные.

Чтобы регистрация прошла успешно, необходимо заполнить корректными оба поля. Если поля заполняются некорректными данными, то система должна выдать ошибку: “Введены невалидные данные”.

Значения 2, 3, 4 приводят к одному и тому же результату с разными входными значениями.

Источник

Какие сущности необходимо использовать в таблицах принятия решений

Что пишут в блогах

I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:

Онлайн-тренинги

Что пишут в блогах (EN)

Introduction

Разделы портала

Про инструменты

Автор: Жан-Клод Ватье, Software Services, IBM

Источник публикации: Журнал Rational Edge

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

Таблицы принятия решений

В данной статье приводится общее описание техники тестирования с таблицами принятия решений, а также обсуждается использование этой техники при работе с 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: Пакет тестирования состоит из сценариев тестирования и сценариев принятия решений.

Эта техника предоставляет следующие преимущества:

Техника тестирования, основанная на таблицах принятия решений

Так как некоторые указанные альтернативы могут выглядеть нереалистично, стратегия тестирования должна: 1) убедиться в том, что все альтернативы реально могут быть достижимы 2) описать, как тестируемое приложение будет вести себя во всех альтернативных условиях. С помощью таблицы принятия решений достаточно просто добавлять или удалять условия в зависимости от стратегии тестирования. Область охвата теста легко увеличить с помощью добавления новых действий тестирования от итерации к итерации, в соответствии со стратегией тестирования.

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

Рис. 2: Пример таблицы принятия решений

Работа с таблицами принятия решений и с таблицами, управляемыми данными

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

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

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

Рис. 3: Элементы пакета тестирования

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

Этот подход четко отделяет логику тестирования, инкапсулированную в сценариях тестирования, от действий тестирования и верификаций, выполняемых сценариями тестирования. Идентификация точек принятия решений в AUT помогает формализовать и использовать декомпозицию пакета тестирования на сценарии тестирования.

Использование этой техники с Functional Tester

Для доказательства работоспособности этой концепции автор разработал Java-библиотеку для реализации техники, основанной на таблицах принятия решений, с Functional Tester. Для создания сценария пакета тестирования тестировщик должен выполнить следующие действия:

Библиотека тестирования с использованием таблиц принятия решений

Библиотека тестирования с использованием таблиц принятия решений состоит из Java-классов, предоставляющих следующие сервисы:

Рис. 4: Основные классы в библиотеке тестирования с использованием таблиц принятия решений

Создание нового пакета тестирования

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

Для создания нового пакета тестирования тестировщик должен выполнить следующие действия:

Рис. 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 Вавилоняне, например, использовали глиняные таблички для вычислений. См. работу Дж. Дж. О’Коннора и Е.Ф. Робертсона «Обзор Вавилонской математики»

2 См. презентацию в PowerPoint Марьен Де Вильда, озаглавленную «Таблицы принятия решений: удобная техника тестирования и не только» компании Software Quality NZ Inc.

4 См. статью Дэнниса Шульца, «Создание класса «super helper» в IBM Rational Functional Tester», IBM developerWorks, декабрь 2003 г.

5 См. презентацию Джеймса Баха, «Стратегия тестирования: что это такое? На что это похоже?» 1998 г. и статью Сема Кейнера, «Улучшение сопровождения пакетов автоматизированного тестирования», опубликованную в Quality Week в 1997 г.

Об авторе

Жан-Клод Ватье (Jean-Claude Vauthier) является IT-специалистом IBM Software Services Rational во Франции. С 2001 г. занимается оптимизацией использования решений Rational. Перед тем, как начать работать в IBM Rational, он работал в сфере программной инженерии CAD/CAM, разрабатывал военные и телекоммуникационные системы. Имеет докторскую степень в аналитической химии, степень бакалавра в жидкостной механике, и опыт работы в военно-космической отрасли.

Источник