Таблица принятия решений: Таблица принятия решений — QA evolution

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

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

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

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

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

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

Условия	Варианты выполнения действий
Действия	Необходимость действий

 

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

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

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

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

 

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

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

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

 

Условие	Значения 1	Значения 2	Значения 3	Значения 4
Ввод корректных данных в поле E-mail	+	—	+	—
Ввод корректных данных в поле Password	+	—	—	+
Ввод некорректных данных в поле E-mail	—	+	—	+
Ввод некорректных данных в поле Password	—	+	+	—
Действия
Регистрация прошла успешно	+	—	—	—
Выдается ошибка: “Введены невалидные данные”	—	+	+	+

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

О других техниках читайте здесь:

1) Техника анализа граничных значений

2) Техника анализа классов эквивалентности

техника проведения тестирования с использованием Functional Tester от IBM Rational

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

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

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

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

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

В данной статье приводится общее описание техники тестирования с таблицами принятия решений, а также обсуждается использование этой техники при работе с IBM Rational Functional Tester и IBM Rational Software Modeler. Эта техника использует нерегрессионные пакеты тестирования, выполняющие в свою очередь набор повторно используемых сценариев тестирования. Каждый описываемый сценарий тестирования сгенерирован в Functional Tester с использованием техники записи/воспроизведения графического интерфейса.

Целью этой статьи является доказательство работоспособности идеи, для чего я за пятидневный период разработал библиотеку Java-классов, реализующую эту технику таблиц принятия решений с инструментарием IBM Rational. Хотя описанная техника пока не была использована при работе над реальным проектом, я продемонстрирую потенциал такого подхода с использованием инструментария IBM Rational, основанного на среде Eclipse. Предлагаемая мной реализация полностью основана на стандартных, документированных интерфейсах, доступных любому заказчику.

Проблема

Нерегрессионные тесты, основанные на управляемых данными техниках тестирования, в которых одиночный сценарий тестирования используется повторно с различными входными данными, достаточно популярны среди пользователей автоматизированных инструментов тестирования.³ Эта техника может быть реализована с 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. Для использования сервисов, предоставленных библиотекой, каждый сценарий пакета тестирования и каждый сценарий принятия решений, созданные тестировщиком, должны быть произведены на базе класса TestSuiteHelper⁴, который предоставляет интерфейс к библиотеке. Для этой цели тестировщик выбирает данный класс «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, будут использованы для разработки с последующим автоматизированным тестированием.

Я буду рад услышать ваши отзывы об этом подходе; мне можно написать по адресу

Примечания

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

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

³ Михаил Келли, «Использование IBM Rational Functional Tester 6.1 для выполнения вашего первого функционального регрессионного тестирования», IBM developerWorks, ноябрь 2005 г.; Михаил Келли, «Среда автоматизации с IBM Rational Functional Tester: управление со стороны данных», IBM developerWorks, ноябрь 2005 г.; и техническая публикация Кейт Замбелич, «Полностью управляемое данными автоматизированное тестирование».

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

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

⁶ См. работу Жена Ру Дая, «Управлемое моделями тестирование с помощью UML 2.0»

Об авторе

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

Таблица принятия решений — это… Что такое Таблица принятия решений?

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

Таблицы принятия решений, как правило, разделяются на четыре квадранта, как показано ниже.

Условия	Варианты выполнения условий
Действия	Необходимость действий

В простейшем случае здесь Условия — список возможных условий, Варианты выполнения условий — комбинация из выполнения и/или невыполнения условий из этого списка. Действия — список возможных действий, Необходимость действий — указание надо или не надо выполнять соответствующее действие для каждой из комбинаций условий. Например для ситуации «свет погас»

Свет в соседней комнате горит	Да	Нет	Нет
Свет у соседей горит	—	Да	Нет
Поменять лампочку	Х
Проверить пробки		Х
Позвонить электрику		Х	Х
Позвонить диспетчеру			Х

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

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

Cсылки

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

По «счастливому» стечению обстоятельств в основном я занимаюсь тестированием молодых проектов. Назвать этот процесс «выполнением работы» не поворачивается язык, скорее это похоже на постоянную борьбу за выживание в условиях нехватки ресурсов (как времени, так и сотрудников), отсутствия документации, отсутствия процессов, постоянного неожиданного расширения контента поставки срочными задачами и т.д.

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

В этой статье я расскажу о своем опыте применения методологии «Таблицы принятия решений» (Decision Table, далее я буду использовать сокращение DT). Вся необходимая теория изложена в замечательной книге «A Practitioner’s Guide to Software Test Design» by Lee Copeland.

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

В общем случае метод DT заключается в построении таблицы, содержащей следующие сущности:

Conditions (условия) — четко сформулированное описание входных условий (данных) для функционала. Формулировка условия должна быть выполнена в виде вопроса, на который можно дать однозначный ответ «да» или «нет» (или указать «не важно», но об этом чуть позже). Например, обязательное поле заполнено?
Rules (правила) — различные комбинации входных данных.
Actions (действия) — четко сформулированное описание ожидаемого результата, действия системы. Формулировка действия должна быть выполнена в форме утвердительного предложения. Обязательным является условие — одно предложение описывает только одно действие. Например, отображается сообщение об ошибке.
Area (область) — используется при составлении тестов для множества однотипных и имеющих небольшие различия модулей.

Разберем составление таблицы на примере тестирования формы авторизации.

  Сценарий использования стандартный: пользователь указывает атрибуты учетной записи и щелкает по кнопке Login. 

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

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

В общем виде таблица принятия решений имеет следующий вид (я использую в работе MS Excel, но подойдет и любой другой редактор электронных таблиц):

Во всех проектах, в которых мне довелось работать действует единое соглашение относительно нумерации наборов данных — используются числа от 001 до 999. Поэтому, в дальнейшем я буду использовать данный формат, вместо Rule 1…N.

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

Затем выписываем возможные ожидаемые результаты в секцию Actions. На данном этапе обычно корректируется секция Conditions, т.к. в процессе сопоставления ожидаемых результатов и путей их достижения обнаруживаются пропущенные условия.

Затем полученная матрица заполняется возможными комбинациями входных условий. При этом каждая ячейка может иметь одно из трех значений: да, нет, неважно (обозначено текстурной заливкой). Использование значения «неважно» помогает сократить количество описываемых случаев, при этом обеспечить тот же уровень покрытия, что и при описании всех допустимых комбинаций условий. 

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

Для каждой из комбинаций входных условий указывается ожидаемый результат. При этом необходимый action помечается словом «да», все остальные ячейки помечаются заливкой «неважно» для большей читаемости таблицы.

 

И «на десерт» — повторное применение DT. Предположим, тестируемая система состоит из нескольких модулей. Проверки формы авторизации для внешних потребителей мы описали, теперь нужно описать проверки той же формы для внутренних потребителей. Формы идентичны и имеют различие только в поведении кнопки Login (для внутренних потребителей она становится доступна только тогда, когда указаны username и password). Таким образом случаи 001 и 002 недоступны для второй формы.

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

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

 

Текста теории получилось несколько больше, чем я ожидала. Поэтому реальные примеры использования в проектах (удачные и не очень) приведу в следующий раз. To be continued…

Техники тест-дизайна и их предназначение

При создании IT-продукта большую роль играет обеспечение качества – Quality Assurance (QA). Для того, чтобы устранить ошибки и «баги», QA-инженеры в числе прочих инструментов применяют техники тест-дизайна.

Тест-дизайн – это разработка, создание тестов. Каждый тест направлен на проверку конкретного предположения. Например: «Что будет, если пользователь по ошибке кликнет здесь не левой, а правой кнопкой мыши».

QA моделирует набор тестовых случаев (тест-кейсов), чтобы проверить, как приложение ведет себя в разных условиях. Задача специалиста – найти баланс и выявить максимальное количество ошибок при необходимом минимуме тестовых сценариев. При этом нужно проверить все наиболее важные кейсы, поскольку время тестирования ограничено.

Типы тестирования 

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

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

• Техники белого ящика (они же структурное тестирование) применяют в том случае, если специалист хорошо знает архитектуру продукта, его код, «начинку» – то есть может ориентироваться в самой программе. 

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

• Техники серого ящика позволяют тестировать продукт, когда специалист частично знает его внутреннее устройство. Для выполнения тестирования «серого ящика» не нужен доступ к исходному коду. 

Этапы тестирования

1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски. 

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

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

3. Анализ результатов и составление отчетов.  

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

Техники тест-дизайна на примерах

Рассмотрим несколько основных методик, однако, будем помнить, что зачастую их используют в комплексе. Одной техники может быть недостаточно, поскольку она не обеспечит максимальный охват тестовых сценариев. 

Эквивалентное разбиение

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

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

У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.

 

QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке. 

Граничные значения

Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с  вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.   

Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д. 

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

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

Какие возможны сценарии:
1.       Правильный логин и правильный пароль.
2.       Правильный логин, неправильный пароль.
3.       Неправильный логин, правильный пароль.
4.       Неправильный логин, неправильный пароль. 

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

Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее. 

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

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

Попарное тестирование

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

Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок. 

Pairwise testing: пример 

Для Parwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями остальных параметров. Таким образом, матрицу можно значительно сократить. Например:

№	Браузер	Операционная система	Язык
1	Opera	Windows	RU
2	Google Chrome	Linux	RU
3	Opera	Linux	EN
4	Google Chrome	Windows	EN

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

Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT). Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли. Так же результаты по желанию можно выгрузить в файл Excel. 

Пример содержимого файла для программы PICT:

Браузер: Chrome, Opera
ОС: Windows, Linux
Язык: RU, ENG

Пример попарного тестирования

Причина и следствие

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

Примерный алгоритм использования техники:  

1. Выделяем причины и следствия в спецификациях.  
2. Связываем причины и следствия.  
3. Учитываем «невозможные» сочетания причин и следствий.  
4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.  
5. Расставляем приоритеты.

Эта техника помогает: 

• Определить минимальное количество тестов для нахождения максимума ошибок. 

• Выяснить все причины и следствия – таким образом, мы убедимся, что на любые манипуляции с системой у системы будет ответ. 

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

Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита, а также другие параметры.

Предугадывание ошибок

Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами. 

Например, в спецификации указано, что поле должно принимать код из четырех цифр. В числе возможных тестов:

• Что произойдет, если не ввести код?
• Что произойдет, если не ввести спецсимволы?
• Что произойдет, если ввести не цифры, а другие символы?
• Что произойдет, если ввести не четыре цифры, а другое количество?

Преимущества:

1. Эта проверка эффективна в качестве дополнения к другим техникам.
2. Выявляет тестовые случаи, которые “никогда не должны случиться”. 

Недостатки:
1. Техника в значительной степени основана на интуиции.
2. Необходим опыт в тестировании подобных систем.
3. Малое покрытие тестами. 

Итоги

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

Тестирование Таблицы Решений | Как создать таблицу

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

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

В двух словах, Decision Table Testing — это метод проверки черного ящика, в котором мы создаем таблицу решений для сложной бизнес-логики.

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

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

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

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

Как вы увидите ниже, число возможных комбинаций задается как 2 ^x, где X — количество входов, в случаях, когда X — большое число (скажем, 10 для примера), число комбинаций будет слишком большим, чтобы принять все это во внимание. Однако мы все еще можем взять подмножество этих возможных комбинаций для создания дерева решений.

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

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

Шаг 1: Создание первого столбца таблицы с учетом требований.

Мы создадим первый столбец таблицы, взглянув на то, что нам нужно проверить. Для этого примера рассмотрим пример транзакции ATM. Ниже будут его условия и действия:

Условие

Сумма вывода меньше или равна балансу банка

Кредит предоставлен

действие

Запрос на снятие принят

Шаг 2: Добавление дополнительных столбцов.

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

Математически число столбцов равно 2 ^x, где X — количество условий.

Для простоты тестирования мы должны создать меньшие таблицы решений, а затем создать огромные. Закончив с количеством столбцов, мы можем заполнить True или False. Вы можете заполнить ячейки следующим образом:

R1: TF

R2: TTFF

R3: TTTFFF

И так далее.

После этого наша таблица выглядит следующим образом:

Условие
Сумма вывода меньше или равна балансу банка	T	F	T	F
Кредит предоставлен	T	T	F	F
действие
Запрос на снятие принят

Шаг 3: сделать стол меньше.

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

Мы также должны пометить ячейки с незначительными значениями как «-». Например, не имеет значения, предоставляется ли кредит, если сумма <= остаток на счете.

Условие
Сумма вывода меньше или равна балансу банка	T	F	T	F
Кредит предоставлен	—	T	—	F
действие
Запрос на снятие принят

Шаг 4: Определение действий для таблицы.

Теперь, с помощью наших требований, мы определим действия таблицы. Эти столбцы будут названы, например, R1 / Правило 1, R2 / Правило 2 и т. Д.

Условие
Сумма вывода меньше или равна балансу банка	T	F	F
Кредит предоставлен	—	T	F
действие
Запрос на снятие принят	T	T	F

Последний шаг: написание тестовых случаев

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

Например:

Контрольный пример для R1: баланс = 1000, запрос на снятие средств = 1000. Результат: запрос на снятие средств принят

Тестовый пример для R2: Баланс = 500, Запрос на снятие средств = 1000. Предоставленный кредит: Да, Результат: Запрос на снятие принят

Тестовый пример для R3: Баланс = 1000, Запрос на снятие средств = 1500. Предоставленный кредит: Нет, Результат: Запрос на снятие отклонен

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

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

Вывод

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

Рекомендуемые статьи

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

1. Тестирование белого ящика
2. ETL Тестирование Интервью Вопросы
3. Что такое юнит-тестирование
4. Тестирование системы

Таблиці рішень та їх застосування в тестуванні

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

Тестування за допомогою таблиць прийняття рішень – це одна з технік тест-дизайну методом чорного ящика, яка відноситься до динамічного аналізу. Вона також відома як таблиця причинно-наслідкових зв’язків. А схематична демонстрація логіки відома як причинно-наслідковий графік. Це візуальне уявлення використовується для отримання таблиці рішень.

Інші методи досліджень, наприклад, перевірка на еквівалентність або аналіз граничних значень, часто застосовуються тільки для конкретних вхідних даних. Техніка таблиці рішень використовується у тому випадку, коли для різних вихідних використовується комбінація вхідних даних. Основною метою є перевірка бізнес-логіки і тестового покриття.

Таблиця рішень, як правило, має 4 складові:

1. Умови – список можливих умов.
2. Варіанти виконання дій – це комбінація зі списку виконаних або невиконаних умов.
3. Дії – це список всіляких дій.
4. Необхідність дій – вказівка ​​потрібно чи не потрібно виконувати відповідну дію для кожної з комбінацій умов.

 Приклад застосування таблиць рішень.

Умова дуже проста: якщо користувач вводить правильне ім’я користувача і пароль, він буде авторизований і перенаправлений на домашню сторінку. Якщо будь-які з даних, що вводяться є неправильними, то з’явиться повідомлення про помилку.

Умова	1	2	3	4
Ім’я користувача (T/F)	F	T	F	T
Пароль (T/F)	F	F	T	T
Результат (E/H)	E	E	E	H

Умовні позначення:

T – Правильне ім’я користувача/пароль.

F – Неправильне ім’я користувача/пароль

E – Відображається повідомлення про помилку.

H – Користувач авторизований/Відображається домашня сторінка.

Розглянемо окремо кожен із стовпчиків:

Стовпчик 1. Ім’я користувача і пароль були неправильні. Відображається повідомлення про помилку.

Стовпчик 2. Ім’я користувача було правильним, але пароль був неправильним. Відображається повідомлення про помилку.

Стовпчик 3. Неправильне ім’я користувача, але правильний пароль. Відображається повідомлення про помилку.

Стовпчик 4. Ім’я користувача і пароль були правильними, авторизація пройшла успішно, відображається домашня сторінка.

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

Тест-кейс 1. Ввести валідні ім’я користувача та пароль, натиснути кнопку «Увійти».

Очікуваний результат: користувач авторизований і перенаправлений на домашню сторінку.

Тест-кейс 2. Ввести валідне ім’я користувача та невалідний пароль, натиснути на кнопку входу.

Очікуваний результат: відображається повідомлення про помилку.

Тест-кейс 3. Ввести невалідне ім’я та валідний пароль, натиснути кнопку «Увійти».

Очікуваний результат: відображається повідомлення про помилку.

Тест-кейс 4. Ввести невалідне ім’я користувача та пароль, натиснути на кнопку входу.

Очікуваний результат: відображається повідомлення про помилку.

Необхідно звернути увагу на той факт, що всі кейси, крім першого, перевіряють одне і те ж правило. Таким чином, була створена найпростіша таблиця рішень. За необхідності її можна розширити.

Ще один приклад застосування рішень на прикладі працездатності принтера

Умови	Принтер не друкує	Y	Y	Y	Y	N	N	N	N
	Мерехтить червоний індикатор	Y	Y	N	N	Y	Y	N	N
	Принтер не розпізнається	Y	N	Y	N	Y	N	Y	N
Дії	Перевірте дріт живлення			X
	Перевірте дріт принтера	X		X
	Переконайтесь що ПЗ принтера встановлено	X		X		X		X
	Перевірити/замінити чорнила	X	X			X	X
	Перевірте, чи не застряг папір в лотку		X		X

Умовні позначення: Y – так; N – ні.

Цей приклад показує простоту, з якою таблиця рішень демонструє можливі комбінації умов і дій. До того ж її легко модифікувати в разі зміни вихідних даних (наприклад, при включенні індикатора іншого кольору в принтері).

Переваги використання таблиці рішень під час тестування програмного забезпечення:

1. Навіть найскладніша бізнес-логіка, використовуючи цей метод, може бути легко перетворена в тестові сценарії і випадки.
2. Ітеративність роботи. Таблиця, створена на першому етапі, використовується в якості вхідної таблиці для всіх наступних. Ітерація виконується тільки в тому випадку, якщо вихідні дані не є задовільними.
3. Проста і зрозуміла техніка. Кожен може використовувати цей метод для розробки тестових сценаріїв і випадків.
4. Забезпечення повного охоплення тестових випадків, що істотно допомагає скоротити обсяг роботи.
5. Гарантія розгляду всіх можливих комбінацій умов і значень.
6. Надання більш компактної документації.
7. Легка зміна даних.

Недоліки таблиць рішень під час тестування програмного забезпечення.

1. Труднощі в масштабуванні. Потрібно «розділяти» великі таблиці на більш дрібні, щоб запобігти надмірності.
2. Збільшення кількості вхідних даних робить таблицю складнішою.

Таблиці рішень є хорошим способом опису вимог, коли існує кілька бізнес-правил, що взаємодіють один з одним. Використовуючи цей метод, фахівцю стає простіше написати вимоги, які включають в себе всі доступні умови. Застосування цієї техніки допомагає краще проаналізувати тестований продукт, систематизувати всі знання по ньому. В результаті стає легше писати повні тестові приклади, охопити всі можливі комбінації.

таблиц решений, узнайте, как использовать таблицы решений

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

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

Пример таблицы решений:

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

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

В таблице решений условий обычно выражаются как истинное (T) или ложное (F) .Каждый столбец в таблице соответствует правилу в бизнес-логике, которое описывает уникальное сочетание обстоятельств, которое приведет к действиям. В приведенной выше таблице содержатся три различных бизнес-правила, и одно из них — «снятие средств разрешается, если запрошенная сумма покрывается балансом». Создание по крайней мере одного тестового примера для каждого столбца является нормальным, что приводит к полному охвату всех бизнес-правил.

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

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

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

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

Теперь вопрос в том, как создавать таблицы решений? Вот шаги, которые необходимо использовать для создания таблиц решений.

Шаги по созданию таблиц решений:

Шаг 1. Проанализируйте требование и создайте первый столбец

Требование: «Вывод средств предоставляется, если запрошенная сумма покрывается балансом или если клиенту предоставлен кредит для покрытия суммы вывода».

Выразите условия и результирующие действия в списке так, чтобы они были ИСТИННЫМИ или ЛОЖНЫМИ. В этом случае есть два условия: «сумма вывода ≤ остаток» и «кредит предоставлен». Результат один, вывод разрешен.

Шаг 2. Добавьте столбцы

Подсчитайте, сколько столбцов необходимо в таблице. Количество столбцов зависит от количества условий и количества альтернатив для каждого условия. Если есть два условия, и каждое из них может быть истинным или ложным, вам нужно 4 столбца. Если есть три условия, будет 8 столбцов и так далее.

Математически количество столбцов составляет 2 ^{условия} . В этом случае 2 ² = 4 столбца.

Количество необходимых столбцов:

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

Теперь пришло время заполнить T (ИСТИНА) и F (ЛОЖЬ) для условий. Как ты это делаешь? Проще всего сказать, что это должно выглядеть так:

Ряд 1: TF

Ряд 2: TTFF

Ряд 3: TTTTFFFF

В каждой строке вдвое больше T и F, чем в предыдущей строке.

Повторите вышеприведенный узор слева направо для всего ряда. Другими словами, для таблицы с 8 столбцами первая строка будет читать TFTFTFTF, вторая строка будет читать TTFFTTFF, а третья строка будет читать TTTTFFFF.

Совет. Существуют шаблоны Excel для заполнения таблиц решений, если вам нужна помощь.

Шаг 3: Уменьшите стол

Незначительные значения пометьте знаком «-». Если запрошенная сумма меньше или равна остатку на счете, не имеет значения, предоставлен ли кредит.На следующем шаге вы можете удалить идентичные столбцы.

Проверить недопустимые комбинации. Недопустимые комбинации — это те, которых не может случиться, например, что кто-то одновременно младенец и пожилой человек. Отметьте их как-нибудь, например с «X». В этом примере нет недопустимых комбинаций.

Завершите, удалив повторяющиеся столбцы. В этом случае первый и третий столбцы равны, поэтому один из них удаляется.

Шаг 4: Определите действия

Введите действия для каждого столбца таблицы.Вы сможете найти эту информацию в требовании. Назовите столбцы (правила). Их можно назвать R1 / Правило 1, R2 / Правило 2 и так далее, но вы также можете дать им более описательные имена.

Шаг 5: Напишите тестовые примеры

Напишите тестовые примеры на основе таблицы. По крайней мере, один тестовый пример в столбце дает полное покрытие всех бизнес-правил.

• Тестовый пример для R1: баланс = 200, запрошенное снятие = 200. Ожидаемый результат: снятие разрешено.
• Тестовый пример для R2: баланс = 100, запрошенный вывод = 200, кредит предоставлен.Ожидаемый результат: отзыв разрешен.
• Тестовый пример для R3: баланс = 100, запрошенный вывод = 200, без кредита. Ожидаемый результат: отказано в выводе.

Сводка

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

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

Присоединяйтесь к 60000+ подписчиков

Для последних блогов, отраслевых новостей и эксклюзивных советов.

* Ваша электронная почта в безопасности с нами, мы также ненавидим спам

A Пример таблицы решений

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

Менеджеры понимают, что определенные постоянные клиенты делают заказы из каждого каталога, а некоторые люди из списка рассылки никогда не делают этого. Эти схемы заказа легко заметить, но решить, какие каталоги отправлять клиентам, которые заказывают только из выбранных каталогов, сложнее. После того, как эти решения приняты, создается таблица решений для трех условий (C1: клиент заказал из осеннего каталога; C2: клиент заказал из рождественского каталога; и C3: клиент заказал из специального каталога), каждое из которых имеет две альтернативы (Y или N). .Можно предпринять три действия (A1: разослать рождественский каталог этого года; A2: разослать новый специализированный каталог; и A3: разослать оба каталога). Итоговая таблица решений имеет шесть строк (три условия и три действия) и восемь столбцов (две альтернативы, две альтернативы, две альтернативы).

Условия и действия	1	2	3	4	5	6	7	8
Заказчик из каталога Fall.	Y	Y	Y	Y	N	N	N	N
Клиент заказал из рождественского каталога.	Y	Y	N	N	Y	Y	N	N
Заказчик заказал по специальному каталогу.	Y	N	Y	N	Y	N	Y	N
Разошлите рождественский каталог этого года.		X		X		X		X
Разошлите специализированный каталог.			X				X
Разошлите оба каталога.	X				X

Теперь проверяется таблица решений, чтобы увидеть, можно ли ее уменьшить. Не существует взаимоисключающих условий, поэтому невозможно обойтись менее чем тремя строками условий.Никакие правила не допускают совмещения действий. Однако можно комбинировать некоторые правила, как показано на рисунке ниже. Например, Правила 2, 4, 6 и 8 могут быть объединены, потому что все они имеют две общие черты:

1. Они предписывают нам разослать рождественский каталог в этом году.
2. Альтернативой Условию 3 всегда является N.

Правила комбинирования для упрощения таблицы решений для каталога клиентов.

Не имеет значения, каковы альтернативы для первых двух условий, поэтому можно вставить тире [-] вместо Y или N.

Остальные правила — Правила 1, 3, 5 и 7 — не могут быть сведены к одному правилу, потому что остаются два разных действия. Вместо этого правила 1 и 5 можно комбинировать; аналогично правила 3 ​​и 7 можно комбинировать.

Проверка на полноту и точность

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

Обеспечение выполнения всех условий, альтернатив условий, действий и правил действий имеет первостепенное значение.Предположим, что важное условие — если покупатель заказал менее 50 долларов — было исключено из описанной ранее проблемы с магазином по каталогу. Вся таблица решений изменится, потому что нужно будет добавить новое условие, новый набор альтернатив, новое действие и одно или несколько новых правил действий. Предположим, существует правило: ЕСЛИ клиент заказал не более 50 долларов, ТО не отправляйте никакие каталоги. Новое Правило 4 будет добавлено в таблицу решений, как показано ниже.

Условия и действия	1 ‘	2′	3 ‘	4′
Заказчик заказал из каталога Fall.	_	_	_	_
Заказчик заказал по Рождественскому каталогу.	Y	_	N	_
Заказчик заказал по специальному каталогу.	Y	N	Y	_
Клиент заказал на 50 долларов или больше.	T	Y	Y	N
Разошлите рождественский каталог этого года.		X
Разошлите специализированный каталог.			X
Разошлите оба каталога.	X
Не рассылать каталог.				X

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

Важна проверка таблицы решений на невозможные ситуации.

Противоречия возникают, когда правила предполагают разные действия, но удовлетворяют одним и тем же условиям. Ошибка может заключаться в способе построения таблицы аналитиком или в информации, полученной аналитиком. Часто противоречия возникают, если дефисы [-] неправильно вставлены в таблицу.Избыточность возникает, когда идентичные наборы альтернатив требуют одного и того же действия. Рисунок ниже иллюстрирует противоречие и избыточность. Аналитик должен определить, что правильно, а затем разрешить противоречие или избыточность.

Важна проверка таблицы решений на случайные противоречия и избыточность.

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

Работа с таблицами решений

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

Операция разделения таблицы создает правило для каждой комбинации значений в условиях.Например, в таблице решений с 3 логическими условиями создается 2 x 2 x 2 = 8 правил. В таблице решений с 32 логическими условиями создается 2 ** 32 ~ 2 миллиарда правил. Таким образом, вы используете разделенную таблицу только тогда, когда количество созданных правил достаточно мало, чтобы заполнить ячейки действий.

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

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

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

Таблица 5-3 Сводка по разделению

Оператор	Описание
Ячейка состояния	Создает одну родственную ячейку условия для каждого значения, представленного ячейкой. Если значением ячейки условия является «безразлично», то ячейка разделяется на одну соседнюю ячейку для каждого значения в наборе значений, которое не представлено соседней ячейкой условия, и «безразлично» больше не представляется.
Строка условий	Для каждой ячейки условия в продолжающемся выражении условия создайте родственную группу, которая содержит ячейку для каждого значения в наборе значений.Эффект от этой операции такой же, как при добавлении «безразлично» к каждой одноуровневой группе и вызове split для каждой ячейки условия в каждой одноуровневой группе.
Таблица решений	То же, что и вызов split для каждой строки условий в таблице решений.

В зависимости от того, что выбрано в таблице решений, операции компактной таблицы или объединения ячеек удаляют ячейки условий. Операция с компактным столом может применяться ко всей таблице решений. Кроме того, операция слияния может выполняться для одноуровневых ячеек или для всей строки условия. Таким образом, используя компактную таблицу или слияние, вы можете удалить правила из таблицы решений.В Таблице 5-4 приведены сводные данные по компактной таблице и операциям слияния.

Таблица 5-4 Сводная информация об операции слияния

Оператор	Описание
Ячейка состояния	Объединение двух или более ячеек условий добавляет все значения в ячейках к одной ячейке и удаляет все ячейки, кроме одной.Если одна из ячеек представляет «безразлично», то объединенная ячейка представляет «безразлично». Эта операция может объединять ячейки действий, и это может создавать предупреждения для повторяющихся ячеек действий, например, RUL-05847: Повторяющийся параметр действия таблицы решений .
Строка условий	Объедините все значения в каждой группе одноуровневых в одну ячейку «безразлично» для каждой ячейки условия в продолжающемся выражении условия.Эффект от этого такой же, как при вызове слияния для всех ячеек в каждой группе братьев и сестер. Эта операция может объединять ячейки действий, и это может создавать предупреждения для повторяющихся ячеек действий, например, RUL-05847: Повторяющийся параметр действия таблицы решений .
Таблица решений	Сжимает таблицу решений, объединяя условия правил с идентичными действиями.

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

Если есть конфликтующие значения для ячеек действий, операция слияния объединяет ячейки действий в форме, которая требует дополнительных действий вручную. Таким образом, если две ячейки действия имеют конфликтующие параметры, после слияния ячейка действия будет содержать несколько конфликтующих значений параметров. Эти конфликтующие значения добавляются к ячейке действия и должны быть разрешены вручную путем выбора и удаления нежелательных повторяющихся параметров.Например, см. Рис. 5-12, на котором показаны конфликтующие значения в ячейке действия.

Ячейка действия, содержащая несколько значений свойства, недопустима. Когда вы выбираете ячейку действия, в конструкторе правил отображается всплывающее окно с флажками, позволяющими выбрать одно значение для ячейки действия. Как показано в журнале проверки на рис. 5-12, конструктор правил показывает предупреждение проверки, пока вы не выберете одно значение.

5.3.1.1 Общие сведения об операциях перемещения таблицы решений

Вы можете перемещать условия или действия в таблице решений. Кнопки «Переместить» позволяют изменять порядок строк условий в области «Условия» и действий в области «Действия». Перемещение условий вверх или вниз может изменить порядок визуального отображения правил, но эти операции никоим образом не изменяют логику. Например, если ( x.a == 1 и x.b == 1 ) логически совпадает с if ( x.b == 1 и x.a == 1 ).

Когда вы работаете с таблицами решений, некоторые операции применяются только к ячейкам условий, которые являются одноуровневыми. Используя кнопку «Переместить», вы можете изменить порядок строк, чтобы операции таблицы решений применялись к дереву с желаемой степенью детализации. Например, если вы хотите изменить действие ячейки условия для одного правила, вам нужно переместить эту ячейку условия в последнюю строку в области условий таблицы решений.Например, рассмотрим таблицу решений, показанную на рисунке 5-13.

Чтобы просмотреть эту таблицу с детализацией для Driver.age , переместите условие Driver.age из первой строки в третью, как показано на рисунке 5-14.

Теперь, чтобы сделать условия Driver.age «безразличными» для первых двух правил, когда водитель прошел тест на зрение и прошел обучение водителя, вы можете легко применить изменения к этим конкретным условиям, когда драйвер Driver .Возраст находится в последней строке. Таким образом, в этой таблице легче просматривать и изменять правила, связанные с возрастом, когда Driver.age находится в последней строке с максимальной детализацией. В общем, операции перемещения могут помочь вам, когда вы хотите разделить, объединить, или назначить определенные значения, которые могут быть подходящими только на определенном уровне в дереве, в зависимости от местоположения ячейки условия или в зависимости от местоположения родителя, дочерних элементов или братьев и сестер ячейки условия.

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

5.3.1.2 Общие сведения о проверке пробелов в таблице решений

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

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

Например, используя пример драйвера, если вы создаете пробел, удаляя правило, которое охватывает случай для Driver.age <20 и Driver.has_training false , а затем вы нажимаете Gap Analysis, конструктор правил показывает Диалог анализа пробелов, как показано на рисунке 5-15. Щелчок OK с установленными флажками добавляет либо все правила, либо выбранные правила в таблицу решений (в этом примере показано только одно правило для добавления).

Проверка пробелов генерирует различные новые правила для следующих случаев:

• Одноуровневые правила: несколько отсутствующих одноуровневых правил добавляются как одно новое правило. Например, рассмотрим правило с двумя условиями: Driver.age и Driver.hair . Когда отсутствуют два правила для разных цветов волос, а правила являются родственными, то есть у них есть общий родительский элемент, тогда проверка пробелов показывает одно правило, как показано на рисунке 5-16.

• Несобственные правила: несколько пропущенных несобственных правил добавляются как отдельные новые правила. Например, если отсутствуют два разных правила, у которых нет одного и того же родителя, тогда проверка пробелов предоставляет два правила, как показано на рисунке 5-17.

В обоих случаях, показанных на рис. 5-16 и рис. 5-17, есть два пропущенных значения, но для правил родственных связей несколько значений объединяются в одно новое правило.Таким образом, в целом проверка пробелов предлагает меньше более общих правил, а не более конкретных правил.

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

5.3.1.3 Понимание анализа конфликтов таблицы решений

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

Rules Designer находит конфликты, и вы можете увидеть конфликты в строке «Разрешение конфликтов» в таблице решений, нажав «Показать конфликты». То, как вы обрабатываете и разрешаете конфликты, зависит от указанной политики конфликтов.Вы можете выбрать политику конфликта или использовать политику конфликта вручную по умолчанию. Когда вы устанавливаете политику конфликтов с помощью параметра «Политика конфликтов» в области «Дополнительные параметры», конструктор правил устанавливает политику конфликтов для таблицы решений. Политика конфликтов определяет политику конфликтов Таблицы решений и является одной из следующих:

• Руководство

  : Конфликты разрешаются путем ручного определения разрешения конфликта для каждого конфликтующего правила.

• auto override: Конфликты разрешаются автоматически с использованием переопределения разрешения конфликтов, когда это возможно, с использованием политик автоматического разрешения конфликтов Oracle Business Rules.

• ignore: конфликты игнорируются.

Для получения дополнительной информации см. Использование дополнительных настроек с правилами и таблицами решений. Например, на рис. 5-18 показана таблица решений с конфликтующими правилами, которые вы разрешаете с помощью политики ручного управления конфликтами по умолчанию.

Нажимая на ячейки в области разрешения конфликтов таблицы решений, Конструктор правил позволяет разрешать конфликты между правилами следующим образом:

• Override (Override and OverriddenBy): вы отменяете одно правило другим.Переопределение указывает, что срабатывает одно правило. Переопределение — это сочетание приоритезации и взаимного исключения. Приоритезация является транзитивной, а не симметричной. Взаимное исключение бывает транзитивным и симметричным. Если A переопределяет C, а B переопределяет C, то A или B запускаются перед C, но только один из A, B или C.

• Run Before (RunBefore and RunAfter): вы устанавливаете приоритет правил.Выполнить до позволяет двум правилам срабатывать в установленном порядке. Приоритезация является транзитивной, но не симметричной. То есть, если A запускается до того, как B запускается до C, тогда A запускается до C, но B не запускается перед A. Это использует список runBefore таблицы решений, указывающий, что правило, которое выполняется до этого, имеет более высокий приоритет, чем правила в списке.

• Игнорировать (NoConflict): конфликт разрешен.Игнорировать позволяет двум правилам срабатывать в произвольном порядке. Например, рассмотрите следующие конфликтующие правила в таблице решений:

   правило 1: каждый получает прибавку на 10% (как указано в значении «безразлично» в ячейке условия таблицы решений)
  Правило 2: сотрудник, для которого установлено значение «Лучший результативный» в значении «Истина», получает повышение на 5%.
   

  В этих правилах, если правило 2 отменяет правило 1, то лучший исполнитель получает повышение на 5%, а все остальные получают повышение на 10%. Однако в этом случае вы бы хотели, чтобы оба правила активировались.Поскольку не имеет значения, какое правило срабатывает первым и нет конфликта, лучший исполнитель в любом случае получит прибавку на 15,5%. В этом случае используйте список NoConflict для устранения конфликта. Обратите внимание, что отсутствие конфликта — это то, что вы получаете с правилами IF / THEN с равными приоритетами, только вас не предупреждают о конфликте, и вам нужно хорошо подумать, если вы хотите, чтобы одно правило перекрывало другое.

На рис. 5-19 показано диалоговое окно «Разрешение конфликтов конструктора правил», которое отображается при выборе конфликтующего правила в области «Разрешение конфликтов».Это диалоговое окно позволяет разрешать конфликты между правилами, выбирая переопределения, устанавливая приоритеты с помощью параметров RunBefore или RunAfter и параметра NoConflict.

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

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

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

• Игнорировать конфликты, выбирая политику конфликтов, а затем игнорировать параметр в таблице решений.

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

• Измените таблицу решений, чтобы удалить перекрытие.

• Комбинируйте действия для устранения конфликтов.

Разработка программного обеспечения | Решение о покупке-покупке или таблица решений

Таблица решений — это краткое визуальное представление для указания, какие действия выполнять в зависимости от заданных условий. Информация, представленная в таблицах решений, также может быть представлена ​​в виде деревьев решений или на языке программирования с использованием операторов if-then-else и switch-case.

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

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

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

Таблица решений при разработке теста:
Пустая таблица решений

 УСЛОВИЯ ШАГ 1 ШАГ 2 ШАГ 3 ШАГ 4
Состояние 1
Условие 2
Условие 3
Условие 4 

Таблица решений: Комбинации

 УСЛОВИЯ ШАГ 1 ШАГ 2 ШАГ 3 ШАГ 4
Условие 1 Да Да Нет Нет
Состояние 2 Д Н Д Н
Условие 3 Д Н Н Д
Условие 4 Нет Да Да Нет 

Таблица преимуществ решения:

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

Вниманию читателя! Не прекращайте учиться сейчас. Ознакомьтесь со всеми важными концепциями теории CS для собеседований SDE с помощью курса CS Theory Course по доступной для студентов цене и станьте готовым для отрасли.

Разъяснение таблицы решений

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

Таблица решений

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

Условия

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

Действия

Возможные действия, которые необходимо предпринять при принятии определенного бизнес-решения.

Правила

Комбинации условий и действий, которые формируют бизнес-решение.

Эффективное общение

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

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

Таблица решений

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

• Условия и действия определены
• Действия, связанные с выбранным условием, выделенные жирным шрифтом
• Условия выбранного действия, выделенные жирным шрифтом
• Выбрать условия и действие выбранного правила

Пример страхования

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

Скачать проект Тестирование таблицы решений

| Решения MST

Основная цель группы тестирования — создание надежного качественного программного продукта. Для создания качественного программного обеспечения используются два метода тестирования — это методы статического и динамического тестирования. При тестировании программного обеспечения мы часто используем термины «валидация» и «проверка», чтобы определить, соответствует ли продукт требованиям. Эти два термина технически указывают на динамическую и статическую технику

.

Статический анализ — включает проверку документов, дизайна, плана и т. Д.… На каждом этапе

Динамический анализ — включает проверку данных бизнес-требований различными способами

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

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

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

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

Диаграмма причинно-следственных связей — графическое представление

Он предоставляет спецификацию требований в виде логического i.

ИЛИ обозначается как v

НЕ обозначается как ~

ВЗАИМНО ИСКЛЮЧИТЕЛЬНО Символизирует ————-

Общее графическое изображение:

И — обе причины должны быть истинными, чтобы эффект E1 был истинным

ИЛИ — Причина C1 или C2 должна быть истинной, чтобы эффект E1 был истинным

НЕ — причина C1 должна быть ложной, чтобы эффект E1 был истинным

ВЗАИМНО ИСКЛЮЧИТЕЛЬНО — используется для представления, когда истинна только одна из существующих причин.

Как построить диаграмму причинно-следственных связей?

1. Сначала нарисуйте круги причин и следствий в соответствии с ситуацией, Причина слева Эффект справа
2. Отсортируйте сценарии данной ситуации и представьте их на логической диаграмме
3. Начните с Следствия и двигайтесь к причине
4. Ищите взаимоисключающие причины

Формат таблицы решений:

Условия / причины	Правила
Действия / эффекты	Результаты

Как разработать таблицу решений:

1. Сначала мы должны обнаружить подмножество функциональных возможностей
2. Затем сформировать таблицу с условиями / причинами, которые были идентифицированы
3. Отсортировать истинную или ложную комбинацию с идентифицированными условиями

ПРИМЕЧАНИЕ: Отсутствие комбинаций ( Истина / Ложь) можно отсортировать с помощью формулы 2 power n, где n представляет количество условий, обнаруженных на первом этапе

1. Далее следует определить правильный результат на основе отсортированных комбинаций
2. Иногда есть возможности столкнуться с дополнительными результатами (т.е. из коробки логики нет), поэтому мы должны предположить способ продолжить с этим

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

Сценарий: В важных городах нашей страны проводится научная космическая выставка, чтобы рассказать о космической науке людям, которым они только что предложили скидки на билеты. скидка 34% на любой билет, который вы покупаете. Если вы входите с ребенком (до 16 лет), вы можете получить скидку 50% на любой билет, если у вас есть семейная карта, в противном случае вы получите скидку 10%.Вы можете иметь только один тип въездной карты.

Сначала мы должны разработать причинно-следственную связь для сценария

Причины этого сценария:

1. E1 — Предлагает скидку в размере 34%
2. E2 — Предлагает скидку в размере 50%
3. E3 — Предлагает скидку в размере 10%
4. E4 — Предлагает скидку в размере 0%

Первый розыгрыш причины и следствия

Для подтверждения E1 следующие причины:

— C1 должно быть правдой

— C1 ИЛИ C2 должно быть истинным, а C3 должно быть ложным, чтобы действительным был только эффект E1

Для истинности E2 следующие причины:

• C2 и C3 должны быть истинными
• C1 и C2 не могут быть истинными вместе. 3 — 8

  Таблица решений

  9015 %) 9 0257

  Правило 1:

  Согласно Правилу 1 человек соответствует всем трем условиям, что невозможно.Как объясняется в сценарии, человек не может иметь более одной карты входа, и ничего не упоминается, что происходит в случае наличия двух карт входа; Итак, предположим, что человек, имеющий две карты входа, использует карту с высокой скидкой, поэтому для правила 1 скидка будет 50% (семейная карта входа + с ребенком)

  Причины

  R1

  R2

  R3

  R4

  R5

  R6

  R7

  R8

  Y015 9015 9015 9015 9015 9015 9015 9015

  F

  F

  F

  F

  Семейная карта для въезда

  Y

  Y

  F

  F

  Y

  Y

  F

  F

  ребенок

  Y

  F

  Y

  F

  Y

  F

  Y

  F

  Эффекты

  9015 %)

  Причины

  R1

  R2

  R3

  R4

  R5

  R6

  R7

  R8

  Y153 9015 9015 9015 9015 9015 9015 9015 9015 9015 Карта входа 9015

  F

  F

  F

  F

  Семейная карта доступа

  Y

  Y

  F

  F

  Y

  Y

  F

  ребенок

  Y

  F

  Y

  F

  Y

  F

  Y

  F

  Эффекты

  50%

  Правило 2:

  Согласно Правилу 2, лицо соответствует двум условиям: у него / нее есть «Въездная карта старше 60 лет» и «Въездная карта для семьи»; Итак, здесь случай Посещения с ребенком ложен; итого, человек получает скидку 34% (карта входа старше 60 лет)

  9015 %) 9025 6

  Причины

  R1

  R2

  R3

  R4

  R5

  R6

  R7

  R8

  Y153 9015 9015 9015 9015 9015 9015 9015 9015 9015 Карта входа 9015

  F

  F

  F

  F

  Семейная карта доступа

  Y

  Y

  F

  F

  Y

  Y

  F

  ребенок

  Y

  F

  Y

  F

  Y

  F

  Y

  F

  Эффекты

  50%

  34%

  Правило 3:

  Согласно Правилу 3, человек соответствует двум условиям, но влияние этих двух является лишь предположением, поскольку скидка 10% за «иначе», которая упоминается в сценарии, подробно не дается; Итак, предположим, что человек путешествует с «входной картой старше 60 лет» и, следовательно, человек получает скидку в размере 34%

  9015 %) 90 256

  Причины

  R1

  R2

  R3

  R4

  R5

  R6

  R7

  R8

  Y015 9015 9015 9015 9015 9015 9015 9015 9015 9015 Карта входа 9015

  F

  F

  F

  F

  Семейная карта доступа

  Y

  Y

  F

  F

  Y

  Y

  F

  ребенок

  Y

  F

  Y

  F

  Y

  F

  Y

  F

  Эффекты

  50%

  34%

  34%

  Правило 4:

  В Правиле 4 очень ясно и прямо, что у человека есть только одна Въездная карта «Въездная карта старше 60», и, следовательно, скидка составляет 34%.

  9015 %)

  Причины

  R1

  R2

  R3

  R4

  R5

  R6

  R7

  R8

  Y153 9015 9015 9015 9015 9015 9015 9015 9015 9015 Карта входа 9015

  F

  F

  F

  F

  Семейная карта доступа

  Y

  Y

  F

  F

  Y

  Y

  F

  ребенок

  Y

  F

  Y

  F

  Y

  F

  Y

  F

  Эффекты

  50%

  34%

  34%

  34%

  Правило 5:

  В Правиле 5 также очень ясно, что у человека есть «Семейная карта для въезда» и «Посещение с ребенком»; Итак, в данном случае скидка составляет 50%

  9015 %)

  Причины

  R1

  R2

  R3

  R4

  R5

  R6

  R7

  R8

  Y015 9015 9015 9015 9015 9015 9015 9015 9015 9015 Карта входа 9015

  F

  F

  F

  F

  Семейная карта доступа

  Y

  Y

  F

  F

  Y

  Y

  F

  F

  ребенок

  Y

  F

  Y

  F

  Y

  F

  Y

  F

  Эффекты

  50%

  34%

  34%

  34%

  50%

  Правило 6:

  В Правиле 6 у человека есть только «Семейная карта входа» из упомянутого сценария, это не имеет смысла или карта не действует, если человек не навещает ребенка, поэтому сценарий полностью не имеет смысла, а человек получает скидку 0%

  9015 %) 9014 9

  Причины

  R1

  R2

  R3

  R4

  R5

  R6

  R7

  R8

  Y153 9015 9015 9015 9015 9015 9015 9015 9015 9015 Карта входа 9015

  F

  F

  F

  F

  Семейная карта доступа

  Y

  Y

  F

  F

  Y

  Y

  F

  ребенок

  Y

  F

  Y

  F

  Y

  F

  Y

  F

  Эффекты

  50%

  34%

  34%

  34%

  50%

  0%

  Правило 7:

  Согласно Правилу 7 человек просто навещает ребенка, что означает, что у него нет семейной въездной карты / въездной карты старше 60 лет, и, следовательно, этот случай подпадает под действие «В противном случае», как указано в Сценарии, и, следовательно, человек получает скидку. 10%

  9015 %) 90 149

  Причины

  R1

  R2

  R3

  R4

  R5

  R6

  R7

  R8

  Y015 9015 9015 9015 9015 9015 9015 9015 9015 9015 Карта входа 9015

  F

  F

  F

  F

  Въездная карта для семьи

  Y

  Y

  F

  F

  Y

  Y

  F

  F

  ребенок

  Y

  F

  Y

  F

  Y

  F

  Y

  F

  Эффекты

  50%

  34%

  34%

  34%

  50%

  0%

  10%

  Правило 8:

  В Правиле 8 у человека нет карты входа, поэтому этот сценарий полностью не имеет смысла, и человек получает скидку 0%.

  9015 %) 9 0149

  Причины

  R1

  R2

  R3

  R4

  R5

  R6

  R7

  R8

  Y015 9015 9015 9015 9015 9015 9015 9015 9015 9015 Карта входа 9015

  F

  F

  F

  F

  Въездная карта для семьи

  Y

  Y

  F

  F

  Y

  Y

  F

  F

  ребенок

  Y

  F

  Y

  F

  Y

  F

  Y

  F

  Эффекты

  50%

  34%

  34%

  34%

  50%

  0%

  10%

  0%

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

  Подлежит тестированию — Правило1, Правило2, Правило3, Правило4, Правило5, Правило7

  Тестирование не требуется — Правило 6, Правило 8

  Итак, мы разработаем около 6 тестовых примеров для приведенной выше таблицы.

  Преимущества:

  1. Облегчает тестировщикам разработку тестов для сложных сценариев
  2. Обеспечивает ясность для сложных бизнес-сценариев
  3. Это следует за итеративным процессом: таблица, созданная для первого ввода, может использоваться для второго, а вторая используется для третьего и т. д.
  4. Это уменьшает переделку при написании тестовых случаев и тестовых сценариев

  Заключение:

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

  Таблица решений

  | Руководство пользователя Enterprise Architect

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

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

  поддерживаются типами элементов Decision и Business Knowledge Model . Они обозначаются значком в правом верхнем углу элемента на схеме.

  Доступ

  На схеме дважды щелкните элемент Decision или элемент BusinessKnowledgeModel. Отображается окно DMN Expression, показывающее подробную информацию о выбранном элементе.

  Обзор

  На этом изображении показано окно DMN Expression в том виде, в котором оно отображается для таблицы решений.

  Таблица решений состоит из:

  • Политика попадания в таблицу (C +, U, A, P и т. Д.), Которая определяет, как применяются правила
  • Список правил (1, 2, 3, 4 и т. Д.), Где каждая строка правила содержит определенные входные записи и соответствующие выходные записи
  • Список предложений ввода (под синими заголовками), определенных как выражения, которые обычно включают одно или несколько входных значений
  • Список предложений вывода (под розовым заголовком), определяющий вывод, соответствующий определенному набору входов
  • Дополнительные аннотации для каждого правила (под зеленым заголовком), которые можно добавить через панель инструментов окна

  Предложение ввода состоит из выражения и необязательного списка допустимых значений (строка сразу под заголовками столбцов).Очень часто выражение — это просто неизмененное входное значение; однако это также может быть выражение, включающее более одного входного значения, или, возможно, условное выражение, такое как «Оценка риска приложения> 100». Допустимые значения применяются к результату выражения , а не к используемым входным значениям.

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

  Таблица решений должна содержать все входы — и только те входы — необходимые для определения выхода.

  При определении применяемых правил выражения, определенные во входных предложениях, оцениваются для заданных входных данных, а результаты выражения затем используются для поиска правил с совпадающими входными записями.

  Если окно DMN Expression недостаточно широкое или глубокое для отображения всех столбцов и строк, вы можете использовать полосы прокрутки для доступа к скрытому содержимому или перетащить границы, чтобы увеличить ширину каждого столбца. Ширина столбца «Входной» и «Выходной» изначально одинакова, но вы можете настроить ширину каждого столбца независимо от других, перетащив границу столбца либо внутри таблицы, либо на серую полосу сразу под названиями вкладок.

  Панель инструментов редактора таблицы решений

  Когда выбрана таблица решений, доступ к функциям, доступным в окне DMN Expression, осуществляется через панель инструментов в верхней части окна, как показано:

  Для получения дополнительных сведений см. Раздел справки Toolbar for Decision Table Editor .

  Параметры

  В случае элементов модели бизнес-знаний (BKM) параметры используются для передачи входных значений, предоставленных вызывающим элементом.Логика принятия решения BKM оценивается с использованием входных параметров, и результат возвращается вызывающему элементу. По умолчанию элемент BKM создается с двумя входными параметрами: «Вход 1» и «Вход 2».

  Щелкните значок на панели инструментов окна DMN Expression, чтобы отобразить диалоговое окно «Редактировать параметры».

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

  Политика обращения

  Щелкните правой кнопкой мыши «Индикатор политики попаданий», затем выберите нужную политику попаданий во всплывающем меню.Различные политики совпадений таблиц подробно описаны в разделе справки Политика совпадений таблиц решений .

  Условия ввода

  Входной пункт таблицы решений определяется как выражение. Очень часто выражение — это просто неизмененное входное значение; однако это также может быть выражение, включающее более одного входного значения, или оно может быть определено как условное выражение, например «Оценка риска приложения> 100». Допустимые значения применяются к результату выражения , а не к используемым входным значениям, и, как таковые, тип значений должен соответствовать типу результата выражения.

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

  создаются с двумя условиями ввода по умолчанию: «Вход 1» и «Вход 2». Тип данных для обоих предложений — «число». В окне DMN Expression входные предложения отображаются в виде заголовков столбцов в таблице решений. Чтобы изменить предложение ввода, щелкните заголовок столбца, чтобы выбрать ячейку, затем щелкните еще раз или нажмите F2 для редактирования.

  Автозаполнение поддерживается при редактировании предложений ввода. Это означает, что для элементов Decision любые входы, связанные с элементом Decision, становятся доступными для выбора из списка.Точно так же для элементов модели бизнес-знаний параметры вызова доступны для выбора из списка. Дополнительную информацию см. В разделе справки DMN Expression Auto-Completion .

  Чтобы добавить дополнительные столбцы входных записей в Таблицу решений, щелкните значок на панели инструментов окна DMN Expression.

  Чтобы удалить столбцы ввода из таблицы, щелкните правой кнопкой мыши ненужный столбец ввода, затем выберите параметр «Удалить столбец ввода» во всплывающем меню.

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

  Допустимые значения

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

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

  • Номер — [18 ..35]
  • Строка — «Высокая», «Низкая», «Средняя»
  • Boolean — истина, ложь

  Допустимые значения для быстрого заполнения

  Выражение ввода / вывода, на которое ссылается данный объект, может быть простым значением или сложным выражением FEEL; однако, если он напрямую связан с полем «Допустимые значения» в ItemDefinition, то нажатие кнопки шага S включит опцию быстрого заполнения для установки «Разрешенных значений», как определено в ItemDefinition (обычно указывается через элемент InputData).

  Быстрое заполнение рядов

  После определения поля «Разрешенные значения», а также ограничения значений, которые могут использоваться при определении правил в таблице, поле «Разрешенные значения» также предоставляет пользователю возможность быстрого заполнения. Это вызывается в ячейке правила путем нажатия кнопки ритма S и выбора необходимого элемента:

  Дополнительные сведения см. В разделе справки Автозавершение выражения DMN .

  Положения о выходе

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

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

  Чтобы удалить столбцы вывода из таблицы, щелкните правой кнопкой мыши ненужный столбец вывода, затем выберите опцию «Удалить столбец вывода» во всплывающем меню.

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

  Тип данных для предложений ввода / вывода

  Для работы симуляции критически важно установить тип данных для всех предложений Input и Output. Проверки диапазона, разрыва и перекрытия поддерживаются для предложений типа ‘number’, но проверка не может быть выполнена, если тип не был указан. Генерация кода для типизированных языков, таких как C ++, C # и Java, требует указания типов данных.Если тип данных указан как «строка», нет необходимости заключать каждый строковый литерал в кавычки. Строковые значения отображаются курсивом, если тип был объявлен.

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

  Определение правил таблицы решений

  Правила таблицы решений

  определяются путем указания входных записей и соответствующих выходных записей в ячейках строки таблицы.Для типов данных ‘number’ входные записи могут быть указаны как одно значение или как диапазон чисел, например ‘<10', '> 100′ или ‘[2..8)’. (При определении диапазонов номеров использование круглых скобок означает, что ограничивающее число НЕ включено; использование квадратных скобок означает, что ограничивающее число включено.) Выходные записи должны указывать одно значение для каждой ячейки.

  Дополнительные правила можно добавить к списку правил, щелкнув значок на панели инструментов. Нежелательные правила можно удалить из таблицы, щелкнув правило правой кнопкой мыши и выбрав пункт «Удалить строку правила» во всплывающем меню.

  Существующие правила можно скопировать и вставить в таблицу, сначала выбрав правила (используйте «Ctrl + щелчок», чтобы добавить / удалить из выбора), затем используя пункты меню «Копировать правила в буфер обмена» и «Вставить правила из буфера обмена». для выполнения копирования и вставки. Скопированные правила затем можно изменить, выбрав и отредактировав отдельные записи ячеек.

  Если поле «Допустимые значения» установлено для строки или логического выражения, клавишу «Пробел» можно использовать для отображения списка значений для выбора, как показано в предыдущем разделе Допустимые значения — Быстрое заполнение строк .

  Правила также можно отсортировать в таблице по:

  • Щелкнув значок на панели инструментов, затем выбрав «Сортировать по входу» или «Сортировать по выходу», или
  • Щелчок правой кнопкой мыши по отдельным правилам в таблице и выбор опции «Переместить правило вверх» или «Переместить правило вниз» во всплывающем меню

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

  «Политика совпадений» таблицы решений определяет, как соответствующие строки таблицы затем используются для вывода результатов.

  Форматы правил

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

  Формат «Правило как строка», где правило разрабатывается по строкам с вводом, выводом и аннотациями, установленными в столбцах:

  Формат «Правило как столбец», где правила развернуты по столбцам с вводом, выводом и аннотациями, установленными вдоль строк:

  Формат «Правило как кросс-таблица», в котором правила формируются из входных данных, определенных как набор строк И комбинация столбцов, с выходными данными, установленными в пересекающихся ячейках.(Обратите внимание, что этот формат скрывает поля «Аннотация»):

  В конце моделирования в таблице решений кросс-таблицы соответствующие входные и выходные записи выделяются. Например, в этом моделировании обработка привела к получению скидки 0,10 для бизнес-клиента, если размер заказа был меньше или равен 10, а доставка не применима.

  Настройки кросс-таблицы

  В формате Rule-as-Crosstab, поскольку входные данные образуют как строки, так и столбцы, а выходы находятся на пересечении, шаги для установки значений немного отличаются от шагов для двух других форматов.

  1. Чтобы добавить другой тип ввода, щелкните правой кнопкой мыши заголовок столбца ввода и выберите параметр «Добавить ввод». Вам будет предложено ввести имя входа; ввод добавляется как набор полей под полями текущего столбца.
     Чтобы удалить тип ввода из столбцов, щелкните его набор полей правой кнопкой мыши и выберите параметр «Удалить ввод». Имя входа и его набор полей удаляются из заголовков столбцов.
  2. Чтобы добавить другой тип вывода, щелкните правой кнопкой мыши блок вывода в верхнем левом углу окна и выберите опцию «Добавить вывод».Вам будет предложено ввести имя вывода; имя добавляется в блок вывода, и новая строка добавляется к каждой ячейке в теле окна.
     Чтобы удалить тип вывода, щелкните правой кнопкой мыши имя типа в блоке вывода в верхнем левом углу окна и выберите опцию «Удалить вывод». Имя вывода и его поля в сетке будут удалены.
  3. Вы можете переключаться между типами ввода, чтобы выбрать один для заголовков строк. Щелкните строку правой кнопкой мыши и выберите параметр «Выбрать ввод как заголовок строки».Это отображает список типов ввода; щелкните тип, который будет использоваться в качестве заголовка строки; остальные типы объединены в столбцы.
  4. Чтобы добавить строку или столбец ввода значения к входам, щелкните правой кнопкой мыши текущую строку или столбец и выберите параметр «Добавить строку ввода ввода» или «Добавить столбец ввода ввода», в зависимости от ситуации. Появится подсказка для имени входной записи; когда вы вводите это, соответствующая строка или столбец добавляется в таблицу решений.
     Чтобы удалить строку или столбец ввода значения, щелкните его правой кнопкой мыши и выберите параметр «Удалить строку ввода ввода» или «Удалить столбец ввода ввода».Выбранная строка или столбец удаляется из таблицы.
  5. В столбцах ввода каждая строка соответствует типу ввода. Если вы хотите переместить строку для одного типа ввода выше или ниже другого, щелкните ее правой кнопкой мыши и выберите параметр «Переместить ввод вверх» или «Переместить ввод вниз». Контекстное меню предоставляет только те параметры, которые могут быть задействованы, поэтому, поскольку невозможно переместить, скажем, последнюю строку вниз, параметр «Переместить ввод вниз» отсутствует в списке.

  Учить больше

  .

  No related posts.