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

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

Тест-дизайн – одна из самых непростых тем в тестировании программного обеспечения. В блоге ЛАНИТ на Хабр я предлагаю вашему вниманию гайд, который поможет вам вспомнить тест-дизайн и его техники. Мы также проанализируем все нюансы и механики, которые могли ускользнуть от вашего внимания раньше. Осознание этих деталей позволит глубже понять инструментарий тест-дизайна и применять его более гибко в работе, определяя оптимальные методы для каждого случая.

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

Блок 1. Кратко о тест-дизайне, тест-анализе и матрице покрытия
Блок 2. Комбинирование значений ввода в базовых техниках тест-дизайна
Блок 3. Техники комбинирования значений ввода
3.1. Техника «Полный перебор»
3.2. Техника «Метод всех пар» («pairwise»)
Блок 4. Техники выявления сценариев тестирования
4.1. Таблица принятия решений
4.2. Тестирование переходов и состояний

Блок 1. Кратко о тест-дизайне, тест-анализе и матрице покрытия

Кратко вспомним несколько основных понятий.

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

Тест-дизайн как процесс направлен на решение двух основных задач:

• сделать набор тестов более компактным по количеству тестов;

• сохранить качество тестового покрытия более полно.

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

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

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

Полезное, неочевидное: как сократить количество тестов с помощью матрицы покрытия

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

Стремление тестировщика максимально избегать этого варианта трассировки повлияет на количество и качество работы. Но стоит понимать, что избежать его на 100% не всегда возможно, и это нормально. 

Тест-анализ и тест-дизайн

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

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

Перед разбором других техник важно обратить внимание на то, что не всем понятен один нюанс – назначение каждой техники тест-дизайна. Чаще всего на вопрос о предназначении той или иной техники люди отвечают, что «эта техника нужна, чтобы снизить количество тестов». Это лишь одна из задач тест-дизайна. И тут важно понимать, что на снижение количества тестов в чистом виде работает только одна техника – техника эквивалентного разбиения. Так как, выделив классы эквивалентности, мы можем взять из них по 1-2 представителя и проверить каждого из них путём создания несложных комбинаций значений для тестов. Остальные техники тоже способствуют этому, но на первый план они выводят сохранение полноты покрытия тестирования. Каждая из них для этого покрывает какой-то определённый риск. Например, анализ граничных значений, в отличие от предыдущей, часто вынуждает брать для тестирования не меньше двух значений: с верхней и нижней границы интервала. Больше значений – больше тестов для их покрытия. Но взамен увеличения числа тестов эта техника  позволяет покрыть риск наличия дефектов на границах, где программа переходит от одной логики вычислений к другой.

Теперь с этим знанием давайте перейдем к тому, как покрыть тестирование данных ввода с помощью разных техник тест-дизайна.

Блок 2. Комбинирование значений ввода в базовых техниках тест-дизайна

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

«Магия — это всего лишь наука, которую мы пока не понимаем»
Сэр Артур Чарльз Кларк

Базовая комбинаторика

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

Пример

Для примера рассмотрим нередко встречаемую учебную задачу.

Есть поле ввода «Фамилия», для которого действуют следующие правила ввода: 

• позволяется кириллица обоих регистров;

• позволяется спецсимвол «-»;

• значение может содержать максимум 55 символов включительно;

• поле не может быть пустым;

• к вводу запрещены символы латиницы обоих регистров;

• к вводу запрещены цифры;

• к вводу запрещены спец символы кроме «-».

Разобрав эти правила на классы эквивалентности и проанализировав границы, получим следующее:

• валидные:
  - кириллица верхнего регистра;
  - кириллица нижнего регистра;
  - значения с использованием кириллицы из 1 символа;
  - значения с использованием кириллицы из 55 символов;
  - значения, содержащие спецсимвол «-».

• невалидные:
  - латиница верхнего регистра;
  - латиница нижнего регистра;
  - пустое поле;
  - значения с использованием кириллицы из более чем 55 символов;
  - значения, содержащие спецсимволы кроме «-»;
  - цифровые значения.

Если делать тесты на каждый выделенный класс, получим 11 тестов. Но если приглядеться, картина может сильно измениться.

Начнем с валидных классов. Если обратить внимание на свойство регистров для кириллицы, станет понятно, что целесообразнее проверить значение, которое содержит оба типа символов в одном тесте. Так как фамилии по правилам русского языка пишутся с заглавной буквы. Если такое смешанное значение программой будет принято как валидное, то значит и по отдельности она воспримет их так же. Раздельный тест по регистрам нужен, когда смешанное принимается как невалидное, и надо провести диагностику того, кто же «виновник торжества». Здесь сразу же можем протестировать значение с 55 символами в составе. Это будет логичнее, так как при тестировании нижней границы мы не сможем протестировать оба регистра. Как бонус в 55 символов мы сможет хотя бы 1 раз уместить еще и проверку спецсимвола «–».

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

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

Если нарушить правило буквенного ввода (по регистрам) и символьного ввода (для «-»), получим сообщение вроде «Значение содержит недопустимые символы». Чем больше правил проверок уложим в тест, тем больше диагностических действий: дело в каком-то из регистров или в наличии «-», которое не добавили в список разрешенных спецсимволов или в сочетании условий. В таком случае больше времени уйдёт на диагностику, чем на дальнейшее прохождение тестов. 

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

То есть если следовать этому правилу, можем получить следующий вариант набора тестов.

• Проверка верхнего и нижнего регистра кириллицы.

• Проверка значений, содержащих 55 символов: состоящих из кириллицы и символа «-».

• Проверка значений, содержащих 1 символ кириллицы.

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

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

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

Поэтому здесь мы получим все так же 6 негативных тестов.

Итоги

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

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

• На каждое правило невалидного ввода стоит сделать по одному тесту, скомбинированному с каким-либо валидным значением.

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

Правила хорошего тона. Техника «Эквивалентное разбиение»

1. Валидные классы нескольких переменных объединяются в один тест-кейс. 

2. Невалидные классы тестируются каждый по отдельности.

Правила хорошего тона. Техника «Анализ граничных значений»

1. Минимальные значения валидных границ объединяются в один тест-кейс.

2. Максимальные значения валидных границ объединяются в другой тест-кейс.

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

Для верного понимания этих правил стоит вспомнить, что такое негативные и позитивные тест-кейсы. 

Позитивные тест-кейсы – это тесты, в которых мы во все поля интерфейса вводим исключительно валидные данные.

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

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

Работа правил хорошего тона на примерах

1. Валидные классы нескольких переменных объединяются в один тест-кейс.

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

• количество единиц товара;

• торговая точка (по городу);

• рабочий E-mail сотрудника. 

Условия для этих полей следующие.

• Количество единиц товара – поле для ввода.
  - Количество указывается только в формате целых чисел;
  - количество товара от 1 до 10 будет доставлено в точку назначения в срок до 4 дней;
  - количество товара от 11 до 15 будет доставлено в точку назначения в срок до 7 дней;
  - количество товара от 16 до 20 будет доставлено в точку назначения в срок до 14 дней.

• Поле «Торговая точка» – выпадающий список.

• ТЦ «Кит»

• Магазин ProPhoto на Ленина, 24б

• БЦ «Обсидиан»

• Магазин ProPhoto на Гарбышева, 144

• Магазин ProPhoto на проспекте Савицкого, 80

• Рабочий e-mail сотрудника:
  - имеет маску ввода: <имя почтового ящика>@prophoto.ru;
  - имя почтового ящика может содержать:
  а) символы латиницы обоих регистров;
  б) спецсимволы;
  в) цифры;
  - суммарная максимальная длина значения в поле равна 55 символов (включительно).

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

Для поля «Количество единиц товара» у нас сразу явно выделены 3 класса эквивалентности. Для тестирования из каждого поля мы берем по одному значению.

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

На примере этого поля мы видим действие сразу двух нюансов.

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

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

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

Вернемся к таблице. По логике правил хорошего тона все значения валидных классов объединяются в один тест-кейс. Однако, судя по таблице, у нас есть три полных комбинации. И у нас не могут быть покрыты тестами еще 2 значения торговых точек и 1 вариант значения ввода почты сотрудников. Что же с ними делать?

Все предельно просто. Есть два варианта, не сильно различающиеся по сути.

1. Проставить любые значения из ранее протестированных в прошлых трех тестах в пустых ячейках двух полей.

2. Использовать другие значения из тех же классов эквивалентности, расширяя тестовое покрытие. 

Как видно из обновленной таблицы, в столбце «Количество единиц товара» мы применили второй подход к выбору значений. А для поля «Рабочий e-mail сотрудника» первый.

2. Верхние границы валидных классов объединяются в один тест-кейс, нижние  границы валидных классов объединяются в другой тест-кейс.

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

В уже использованном примере у нас есть два поля, к которым можно применить данный подход. Это «Количество единиц товара» и «Рабочий e-mail сотрудника».

Применим этим полям технику анализа граничных значений и получим следующее.

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

- 1-10 – в срок до 4-х дней. Значения для тестирования: 1, 10.
- 11-15 – в срок до 7-ми дней. Значения для тестирования: 11, 15.
- 16-20 – в срок до 14-и дней. Значения для тестирования: 16, 20.

Чтобы прикинуть, каким должен быть минимальный валидный ввод электронной почты сотрудника, представим, что каждый элемент адреса должен содержать по одному символу, а региональный домен – 2 символа. Например, k@m.ru – 6 символов. Тогда получим следующие значения для тестирования.

Рабочий e-mail сотрудника:
- Длина значения 6-55 символов. Значения для тестирования: 6, 55.

Теперь снова составим базовую таблицу.

По первому правилу хорошего тона получим следующее.

По второму правилу хорошего тона – таблица ниже. 

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

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

Итого 6 тестов.

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

Строгое следование правилам хорошего тона в анализе граничных значений - не бюрократия и педантизм, а инструмент обеспечения более полного и уверенного покрытия тестирования продукта. Используйте объединение значений ТОЛЬКО в тех случаях, когда значений и параметров (полей) сравнительно немного и когда вы понимаете, что можете сделать это без потерь в покрытии значений.

Блок 3. Техники комбинирования значений ввода

Как вы уже знаете, техники анализа граничных значений и эквивалентного разбиения позволяют нам выявить значения для тестирования полей форм интерфейсов. Однако только выявить значения мало. Как показала многолетняя практика тестирования во всем мире, даже при вводе валидных значений их сочетания в позитивных тестах порой вызывают не ожидаемое поведение системы. Поэтому инженеры тестирования озаботились тем, что надо такие случаи выявлять и ликвидировать. Так появились техники комбинирования значений ввода или комбинаторные техники. Это «Полный перебор» (он же brute force) и «Метод всех пар» (он же Pairwise или попарное тестирование).

3.1. Техника «Полный перебор»

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

Когда применяется

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

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

Механика применения на примере

Представим небольшой пользовательский интерфейс. Он включает следующие поля:
- имя пользователя – однострочное поле текстового ввода; 
- дата рождения – однострочное поле текстового ввода с маской ввода;
- наличие авто – чек-бокс.

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

Невалидные классы и значения мы не учитываем по двум причинам.

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

Даже из первоначального описания понятно, что третье поле будет иметь только 2 значения: true и false.

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

- кириллица обоих регистров;
- значения с длиной символов от 3 до 55 символов (включительно).

А для поля «Дата рождения» валидным считается ввод значения:

- по маске: dd/mm/yyyy;
- значение маски dd  может быть в интервале от 1 до 31; 
- значение маски mm может быть в интервале от 1 до 12;
- значение маски yyyy может быть в интервале от 1900 до 2150.

Рассмотрев эти правила, можем выявить для тестирования следующие значения:

• Имя пользователя:
  - кириллица - верхний регистр;
  - кириллица - нижний регистр;
  - кириллица из двух символов;
  - кириллица из пятидесяти пяти символов.

• Дата рождения:
  - значение по маске со значениями компонентов в указанных интервалах, например, 15.09.2077.

Для тестирования всех возможных комбинаций валидных значений этих полей нам потребуется 8 тест-кейсов (4 х 1 х 2).

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

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

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

• Создаём основу таблицы, указываем названия полей и выделенные для них значения.

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

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

• Нам надо, чтобы все значения поля «Имя пользователя» сочетались с указанной датой и вариантами значения «Наличие авто». Значений у последнего поля два, значит, столько должно быть и сочетаний для каждого значения поля «Имя пользователя». 

• Как видим, теперь первое значение поля «Имя пользователя» встречается со всеми вариантами поля «Наличие авто», что не удивительно с тестовой датой рождения. Оставшиеся комбинации получаем, копируя значения поля «Наличие авто» по всему столбцу.

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

• Повторяем ту же механику составления таблицы. Теперь даты три. Значит, и тест-кейсов будет 24 (4 х 3 х 2).

• Создаём сочетание значений первого столбца и второго.

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

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

Итоги

1. Техника полного перебора применима только для малого количества тестируемых полей (параметров) и небольшого количества вариантов тестового ввода.

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

• техника очень трудозатратна;

• многие комбинации ввода труднодостижимы в реальной пользовательской практике;

• часть выявляемых дефектов с ее помощью могут иметь низкую серьезность и приоритетность.

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

3.2. Техника «Метод всех пар» (pairwise)

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

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

Когда применяется

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

Механика применения на примере

Допустим, что у нас есть система-реестр, в которой размещается информация о банках. Перед нами стоит задача – протестировать функционал создания страницы с описанием банка. Для демонстрации техники мы выбрали 3 параметра из формы: «Полное наименование банка», «Сокращённое наименование» и «Статус лицензии». Каждое поле обладает определенными правилами ввода.

• Поле «Полное наименование банка» содержит 3 позитивных значения;

• поле «Сокращенное наименование» – 5 позитивных значений и 1 потенциально позитивное значение (ввод спецсимволов);

• поле «Статус лицензии» – 2 позитивных значения.

Если бы мы использовали технику «Полный перебор», то общее количество комбинаций тест-кейсов у нас было 36 (3 х 6 х 2 = 36).

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

Для работы с данной техникой нам необходимо составить pairwise-таблицу. Первым делом важно выявить параметры с самым большим количеством вариаций позитивных значений. Это поле «Сокращенное наименование». Вторым столбцом будет поле «Полное наименование». Третьим – «Полное наименование банка». 

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

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

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

Каждому уникальному параметру присвоим свой номер. Сначала пронумеруем все позитивные значения для первого параметра. Это будут номера 1, 2, 3, 4, 5, 6…

А затем значения второго параметра, продолжив нумерацию после первого параметра. Это будут номера 7, 8, 9.

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

Если присмотреться, то в получившихся шести комбинациях таблицы присутствует три варианта пар:

• пара значений первого и второго столбца;

• пара значений первого и третьего столбца.

• пара значений второго и третьего столбца.

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

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

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

В итоге у нас получилось 18 комбинаций вместо 36. 

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

Важно!

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

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

• ресурс pairwise.teremokgames.com  

И десктопные приложения:

• PICT от Microsoft

• ACTS от NIST

• Hexawise

• Jenny

• VPTag

Итоги

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

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

3. Существуют сервисы для генерации комбинаций тестов, которые экономят время на составлении комбинаций. 

Блок 4. Техники выявления сценариев тестирования

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

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

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

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

Таблица принятия решений (Decision Table) – техника тест-дизайна, в фокусе внимания которой находится проверка поведения системы при вводе различных комбинаций входных параметров, как правило, зависящих друг от друга.

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

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

Она состоит из трех компонентов.

1. Условия – это входные данные для системы. Они представляют различные сценарии, которые могут произойти. Обозначаются как True(T) и False(F) или 0 и 1.

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

2. Действия – это выходные данные системы. Они представляют ожидаемые результаты для каждой входной комбинации. Находятся в конце таблицы.

3. Правила – это различные комбинации входов и соответствующих им выходов. Это будущие тест-кейсы.

Когда применяется

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

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

Из данной таблицы видно, что от условия «Состоит в браке» будет зависеть результат действия «Скидка».

Для тестирования одного интерфейса.

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

Механика применения на примере

Существует 5 шагов для построения таблицы.

1. Определить/записать все условия, которые нам нужно учесть.

2. Посчитать количество возможных комбинаций условий.

3. Заполнить таблицу комбинациями.

4. Записать действия (ожидаемые результаты).

5. Убрать лишние комбинации.

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

1. клиенты типа A, B получают стандартное письмо;

2. клиенты типа C получают специальное письмо;

3. клиентам, совершившим пять и более покупок или купившим на сумму больше 500$, в письме сообщается о дополнительной скидке в 20% на следующую покупку.

Шаг 1. Определяем/записываем все условия. В данном случае это:

• тип клиента – А, B и С (возможно существует ещё тип клиентов, который не относится к клиентам типа А, B и С; обозначим его типом D);

• 5 и более покупок;

• сумма больше $500.

Шаг 2. Рассчитаем возможное количество комбинаций, перемножив все условия.

4 варианта типов клиента – A, B, C, D.
2 варианта – 5 покупок и больше 5 покупок.
2 варианта – сумма меньше, чем 500$ и больше, чем 500$.
Перемножив 4 х 2 х 2, получаем 16. Всего может быть 16 комбинаций.

Шаг 3. Заполняем таблицу данными комбинациями. Для каждого типа клиента есть по 4 варианта комбинаций. Заполним таким образом верхнюю часть таблицы значениями «да» и «нет».

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

- стандартное письмо,
- специальное письмо,
- дополнительное сообщение о скидке.

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

Любой знак вопроса в нижней части таблицы – повод спросить аналитика, что должно происходить в этой ситуации, может ли быть такая ситуация и т.д. Заполняем действия. Для клиентов типа А или B отправится стандартное письмо.

Для клиентов типа С будет специальное письмо.

Далее рассмотрим условие, когда сумма 5 и более покупок или сумма больше, чем 500$.

Так как из документации сказало «или-или», то если:
- клиент совершил 5 и более покупок на сумму меньше, чем 500$, то сообщения о скидке будет (отметим в таблице);
- покупок было совершено мало, но сумма больше, чем 500$, при этом сообщение о скидке тоже должно подходить условию (отметим в таблице);
- оба условия не выполняются – сообщения о скидке не будет; при этом, как будет работать система, когда выполняются оба условия, в правилах не оговорено, поэтому можно предположить, а лучше уточнить у аналитиков/разработчиков (отметим знаком вопроса).

Шаг 5. Видим, что лишних условий здесь пока не обнаружено. Однако, возможно, лишними условиями будут комбинации 13, 14, 15 и 16, если узнаем у аналитиков, что типа D не существует. 

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

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

Правила хорошего тона. Техника  «Таблица принятия решений»

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

2. Если состояния этого правила бинарные (да/нет), то должно быть достаточно одного теста для каждого сочетания.

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

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

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

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

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

Итак, техника состоит из следующих компонентов: состояние, событие и переход.

Состояние – это такое фиксированное положение системы, в котором система ожидает одно или более событий. Само по себе состояние пассивно.

Например, вы хотите снять 1000 рублей в банкомате банка. Состоянием этой операции будет «Достаточно средств» или «Недостаточно средств».

• Состояние также может быть новым (в предыдущей операции было «0 средств» – после пополнения счёта стало «Достаточно средств») или прежним (в предыдущей операции было «Достаточно средств» – в следующей операции также «Достаточно средств»).

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

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

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

• События могут вызывать другие события. 

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

• Событие может изменить состояние системы в том или ином масштабе. 

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

• События могут быть независимыми или причинно-связанными.

Пример причинно-связанных событий: пришёл срок истечения карты (событие А), поэтому карта заблокирована (событие Б).

Переход – это преобразование одного состояния в другое, происходящее из-за события. 

Рассмотрим на примере абстрактного электронного магазина. 

Клиент находится каталоге товаров. Каждый раз когда на нужной карточке товара он нажимает кнопку “Добавить в корзину”, система спрашивает его “Перейти к оформлению?” или “Продолжить выбор покупок?”. При нажатии на первый вариант он перейдет к интерфейсу корзины. То есть произойдет переход от состояния “Каталог” к состоянию “Корзина“. 

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

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

Что ещё важно знать про данные компоненты техники?

• Когда происходит событие, система может изменить свое состояние или остаться в том же.

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

• Одно и то же событие может привести к разным конечным состояниям.

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

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

Когда применяется

Техника переходов и состояний применима в случаях, когда:

• критично важно протестировать, что все состояния продукта достижимы всеми запланированными способами, и удостовериться в отсутствии обратного; 

• нужно протестировать, какие состояния системы затрагивает тот или иной процесс. 

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

Способы визуализации техники

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

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

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

Способ 1. Диаграмма переходов состояний или граф зависимостей.

Диаграмма применяется, когда:

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

• возможен правильный и неправильный порядок операций.

Пример условной диаграммы. Круг – это состояние, стрелка указывает на переход из одного состояния в другое. Описание под стрелкой – событие, которые вызывает переход состояний. Чёрные точки указывают на стартовую и конечную позиции диаграммы.

Пример

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

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

В этот момент происходят два события: извне – ввод информации менеджером бронирования и в системе – старт таймера.  

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

Если событие «Оплата» происходит до истечения времени на таймере, то есть  бронирование оплачивается, тогда система переходит из состояния «Осуществлено​» в состояние «Оплачено​».

Из состоянии «Оплачено​» выполняются события «Печать билета» и «Выдача билета» и бронирование переходит в состояние «Билет выдан​», так как система выдает билет​.

Из состояния «Билет выдан​» происходит переход в состояние «Использовано», так как случается событие «Вручение билета», которое позволило зайти на борт самолета.

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

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

Но и сейчас указаны еще не все возможные состояния. Заказчики иногда отменяют свои заказы. Из состояния «Осуществлено» заказчик через менеджера бронирования просит отменить заказ. Требуется новое состояние «Отменено заказчиком»​. 

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

Обратите внимание, что диаграмма состояний и переходов представляет один конкретный объект «Бронирование». Она описывает состояния бронирования, события, которые влияют на бронирование, переходы из одного состояния в другое. Распространенная ошибка – смешивание различных объектов в одной диаграмме состояний и переходов. Например, смешивание бронирования​ и пассажира​ с событиями.

Может быть так, что заказчик захочет отменить бронирование из состояния «Билет выдан​». В этом случае должен быть сформирован возврат денег и следующим должно быть состояние «Отменено заказчиком​». Но авиакомпания произведет возмещение только тогда, когда получит от заказчика распечатанный билет. 

Это вводит еще одно обозначение – квадратные скобки [ ].  Они содержат условие, которое может принимать одно из двух значений: истина (True) или ложь (False). Данное условие ведет себя как охранник, позволяющий сделать переход, только если условие истинно.

Пока что диаграмма всё еще не завершена. Нет стрелки для перехода в «Конец» из состояний «Отменено». Возможно, можно восстановить бронирование из состояния «Отменено (не оплачено)».

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

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

Способ 2. Таблица переходов состояний, или матричное представление.

В зависимости от подхода к разработке таблицы состояний и переходов таблица может состоять из столбцов: Исходное состояние, Событие, Новое состояние, Ожидаемый результат или Способы перехода. 

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

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

Пример

Разбор создания таблицы переходов состояний на том же примере бронирования авиабилета для прибытия в университет. 

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

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

n/a – not available

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

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

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

Анализ способов перехода

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

Новая таблица будет состоять из трёх столбцов: «Старое состояние», «Новое состояние» (в которое должен произойти переход), а также столбец, который можно назвать «Способы перехода», или «Событие» или «Как?»

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

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

Механика применения на примере 

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

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

1. Набор тестов, в котором все события​ выполнятся как минимум один раз. Следует отметить, что не стоит путать само событие и переход. Событие «Отмена» одно, а проявиться может в разных переходах. Также тест-кейсы, которые покрывают каждое событие, могут быть теми же, которые покрывают каждое состояние. Но это низкий уровень покрытия.

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

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

A->B
A->B->A
A->B->A->B->A->B
A->B->A->B->A->B->A
A->B->A->B->A->B->A->B->A->B…
и так до бесконечности. 

В примере с заказом билета такой ситуации скорее не произойдёт. 

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

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

Кроме этого, такие проверки проводят программными средствами в автоматическом режиме.

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

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

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

Правило хорошего тона. Техника «Тестирование переходов и состояний»

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

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

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

***

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

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