Анализ методов комбинаторного проектирования тестов

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

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

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

Подход:

Таблицы решений описывают логику приложения на основе объектов (свойств/условий) состояния системы. Каждая таблица решений должна описывать только одно состояние системы.

Сущность (Свойство) от 1 до М представляет различные свойства системы; они представлены в таблице как входные данные, которые можно ввести в систему. Действия от 1 до P — это действия, которые могут произойти с указанной комбинацией сущностей. В зависимости от комбинации всех входных данных сущностей действия принимают необходимые значения. Каждое правило определяет уникальный набор входных данных для всех свойств, которые приводят к выполнению определенных действий.

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

Тестирование перехода состояний

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

Подход:

Существует два типа визуального представления этой техники:

1. Диаграммы перехода состояний
2. Таблицы переходов состояний

Диаграммы перехода состояний

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

Круг представляет состояние системы бронирования авиабилетов, состояние «Сделано». Стрелка указывает на переход в состояние «Сделано». Описание под стрелкой («get_info») — это событие, происходящее вне системы. Команда в описании под стрелкой (после «/») означает, что система выполнила какое-то действие в ответ на событие — в данном случае, запустив таймер. Черный кружок указывает на начальную/точку входа диаграммы.

Если таймер не истек, и мы оплатили зарезервированный билет, система переходит в состояние «Оплачено». Это показано стрелкой с надписью «payMoney» и переходом из состояния «Сделано» в состояние «Оплачено».

• Состояние (представлено на диаграмме кружком) : это состояние системы, в котором она ожидает одного или нескольких событий. Состояние запоминает полученные на данный момент входные данные и указывает, как система будет реагировать на полученные события. События могут инициировать действия и/или привести к изменению состояния.
• Переход (представлен на диаграмме в виде стрелки) : представляет собой переход из одного состояния в другое, происходящий вследствие какого-либо события.
• Событие (представлено в виде прямоугольника над стрелкой) : Событие — это то, что заставляет приложение изменить свое состояние. События могут поступать извне приложения, например, через пользовательский интерфейс приложения. При этом само приложение может генерировать события, например, событие типа «истёк таймер». При возникновении события приложение может оставаться в том же состоянии, изменять состояние или выполнять действие. События могут иметь параметры; например, событие «pay_money» может иметь такие параметры, как «Наличные», «Чек», «Дебетовая карта» или «Кредитная карта».
• Действие (представлено после «/» в метке над переходом) : это действие, инициируемое изменением состояния. Это могут быть такие действия, как «распечатать билет», «отобразить на экране» и т. д. Обычно действия создают выходные данные, которые служат выходными данными системы. Действия происходят во время переходов; сами государства пассивны.
• Точка входа показана на схеме черной точкой.
• Точка выхода показана на диаграмме в виде символа «яблочко».

Таблицы переходов состояний

Таблицы перехода состояний — это таблицы, состоящие из четырех столбцов: «Текущее состояние», «Событие», «Действие» и «Следующее состояние».

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

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

Ортогональные массивы

Сколько комбинаций существует для пары значений «1» и «2»? {1,1}, {1,2}, {2,1} и {2,2}. Ортогональный массив — это двумерный массив, обладающий особым свойством: в любых двух столбцах массива присутствуют все комбинации значений в этих столбцах. То есть, если вы возьмете любые два столбца из ортогонального массива, где значения могут быть только «1» или «2», вы найдете следующие строки для этих столбцов — {1,1}, {1,2}, { 2,1} и {2,2}.

В качестве примера рассмотрим систему с тремя входными параметрами, каждый из которых является двоичным (т.е. принимает значение «1» или «2»).

Ортогональный массив представлен как - L_4(2^3), где L_4 указывает, что ортогональный массив имеет четыре строки, а (2^3) указывает, что массив имеет три столбца со значениями, которые могут быть либо «1», либо «2». ".

L_4, где 4 — количество строк

2^3, где 2 — максимальное значение (== 2, 3,…, N), а 3 — количество столбцов.

Ортогональный массив – это двумерный массив, обладающий следующим свойством: выберите любые два столбца массива, и вы найдете в этих столбцах все комбинации значений.

Использование ортогональных массивов:

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

Алгоритм всех пар

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