Я не буду обсуждать здесь хорошо известные и широко используемые методы проектирования тестов, такие как классы эквивалентности, тестирование граничных значений и парное тестирование, я обсужу другие, менее распространенные методы. Вы также можете прочитать мою статью о   . проблемах с комбинаторными методами проектирования тестов  Тестирование таблицы решений  Таблицы решений — отличный инструмент для документирования требований и описания функциональности приложения. Эти таблицы очень удобны для описания бизнес-логики приложения, а кроме того, могут служить прочной основой для создания тест-кейсов. Если у тестируемого приложения отсутствует надлежащая документация, это хороший повод использовать таблицы решений. Представление требований в компактной и простой форме позволяет легко создавать тестовые примеры.   Подход:  Таблицы решений описывают логику приложения на основе объектов (свойств/условий) состояния системы. Каждая таблица решений должна описывать только одно состояние системы.  правило 1  правило 2  …  правило N   Сущности  Недвижимость 1  …  Недвижимость М   Действия  Действие 1  …  Действие П  Сущность (Свойство) от 1 до М представляет различные свойства системы; они представлены в таблице как входные данные, которые можно ввести в систему. Действия от 1 до P — это действия, которые могут произойти с указанной комбинацией сущностей. В зависимости от комбинации всех входных данных сущностей действия принимают необходимые значения. Каждое правило определяет уникальный набор входных данных для всех свойств, которые приводят к выполнению определенных действий.  После составления таблицы решений обычно ее можно упростить, например, удалив некоторые или все невозможные сценарии. Затем таблицу можно преобразовать в тестовые примеры.  Тестирование перехода состояний  Тестирование перехода состояний, как и тестирование таблицы решений, является ценным инструментом для документирования требований и описания структуры и дизайна системы. В отличие от тестирования таблиц решений, которое описывает конкретное состояние системы, тестирование перехода состояний описывает, как эти состояния системы могут измениться. Диаграммы определяют все события, происходящие во время работы приложения, и то, как приложение реагирует на эти события.   Подход:  Существует два типа визуального представления этой техники:  Диаграммы перехода состояний  Таблицы переходов состояний  Диаграммы перехода состояний  В качестве примера рассмотрим бронирование авиабилетов. Он работает примерно следующим образом: первоначально клиенты предоставляют авиакомпании информацию для бронирования — место вылета, пункт назначения, дату и время вылета. Сотрудник авиакомпании служит интерфейсом между клиентом и системой бронирования билетов, используя информацию, предоставленную клиентом, для создания бронирования. После этого бронь клиента находится в состоянии «Сделано». Дополнительно после создания резервации система запускает таймер. Когда время таймера истекает и зарезервированный билет не оплачен, система отменяет бронирование этого билета.   Круг представляет состояние системы бронирования авиабилетов, состояние «Сделано». Стрелка указывает на переход в состояние «Сделано». Описание под стрелкой («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»).  ряды  переменная 1  переменная 2  переменная 3   1  1  1  1   2  2  1  1   3  1  2  1   4  1  1  2   5  2  2  1   6  1  2  2   7  2  1  2   8  2  2  2  Ортогональный массив представлен как - L_4(2^3), где L_4 указывает, что ортогональный массив имеет четыре строки, а (2^3) указывает, что массив имеет три столбца со значениями, которые могут быть либо «1», либо «2». ".  ряды  переменная 1  переменная 2  переменная 3   1  1  1  1   2  1  2  2   3  2  1  2   4  2  2  1  L_4, где 4 — количество строк  2^3, где 2 — максимальное значение (== 2, 3,…, N), а 3 — количество столбцов.  Ортогональный массив – это двумерный массив, обладающий следующим свойством: выберите любые два столбца массива, и вы найдете в этих столбцах все комбинации значений.  Использование ортогональных массивов:  Определить переменные (количество входных данных). Необходимо выбрать входные данные, любые комбинации значений, которые могут логически существовать.  Определите, сколько значений может принимать каждая переменная. К моменту определения количества значений уже должны быть применены другие методы проектирования тестов для уменьшения количества значений (например, граничные значения, классы эквивалентности и любые другие).  Определите ортогональный массив, в котором для каждой переменной будет свой столбец (столбец ортогонального массива имеет столько же вариантов значений, сколько и переменная).  Спроецируйте задачу тестирования на ортогональный массив.  Напишите тестовые случаи.  Алгоритм всех пар  Суть алгоритма AllPairs в том, что нет необходимости проверять все комбинации значений всех переменных. Вместо этого он фокусируется на тестировании всех комбинаций значений для каждой пары переменных.  Для специалиста по обеспечению качества важно понимать эти нюансы. Хотя в некоторых случаях это теоретический подход, понимание сложности методов комбинаторного проектирования тестов позволяет специалистам по обеспечению качества эффективно тестировать сложную бизнес-логику приложений и предоставлять своим пользователям высококачественное программное обеспечение.

This story contains new, firsthand information uncovered by the writer.

About Me

Read My Articles

Hire Me

Этот звук создан на языке оригинала истории!

Слишком долго; Читать

Make resilience your competitive advantage

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

About Author

КОММЕНТАРИИ

БИРКИ

ЭТА СТАТЬЯ БЫЛА ПРЕДСТАВЛЕНА В

Related Stories

Создание криптопродуктов, ориентированных на пользователя: важность отзывов клиентов

Модель Bitcoin UTXO, обеспечивающая работу уникальной экосистемы

Руководство архитектора по созданию эталонной архитектуры для озера данных AI/ML

От форумов до лент новостей: как алгоритмы социальных сетей формируют цифровое взаимодействие

Создание криптопродуктов, ориентированных на пользователя: важность отзывов клиентов

Модель Bitcoin UTXO, обеспечивающая работу уникальной экосистемы

Руководство архитектора по созданию эталонной архитектуры для озера данных AI/ML

От форумов до лент новостей: как алгоритмы социальных сетей формируют цифровое взаимодействие

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps