«В предыдущей статье мы рассмотрели разницу между тест-анализом и тест-дизайном и определили пошаговый алгоритм тест-анализа. В этой статье мы подробно рассмотрим основные методы проектирования тестов, или, проще говоря, тест-дизайна.
Некоторые методы намеренно упрощены, а некоторые излишне специфические детали пропущены, для быстрого понимания. Если вас интересует глубокое погружение в тему, рекомендуем официальное руководство ISTQB Test Analyst (на английском).
Традиционно техники тест-дизайна можно разделить на две категории:
- Техники, которые помогают генерировать оптимальный набор тестовых данных для проверки обработки значений, поступающих в систему.
- Техники, которые помогают проверить корректность бизнес-логики системы.
Вот техники, с которыми мы познакомимся далее:
Верификация данных
Эквивалентное разбиение
Разбиение данных на разделы (чаще называемые классами эквивалентности) основано на предположении, что данные в одном и том же разделе обрабатываются системой одинаково и дают одинаковый результат.
Теория этой техники заключается в том, что если тест, проверяющий одно значение из класса эквивалентности, обнаруживает дефект, то этот дефект должен быть обнаружен и тест-кейсами, проверяющими любое другое значение из того же класса. Поэтому должно быть достаточно одного теста для каждого класса.
Попробуем применить эту технику к функции Создания учетки в популярном приложении Slack.
Для создания учетной записи пользователю необходимо заполнить и отправить форму, содержащую следующие параметры, с определенными ограничениями (требованиями):
- Полное имя
От 1 до 50 символов
Обязательный параметр
- Пароль
6-30 символов
Обязательный параметр
- Имейл-рассылка
Отмечено по умолчанию
В соответствии с требованиями, значение параметра Full Name должно принимать от 1 до 50 символов, и мы можем сделать разумное предположение, что любое значение с символами от 1 до 50 будет обрабатываться одинаково, то есть будет выполняться один и тот же код.
Поскольку все значения от 1 до 50 символов находятся в одном разделе эквивалентности, то есть каждый тест, использующий одно из этих значений, получит одинаковую обработку, нам нужно протестировать только одно значение в этом разделе. Вместо 50 тест-кейсов, каждый из которых использует разные значения, нам нужен только один, чтобы проверить правильность обработки любого значения в этом разделе.
Этот раздел называется валидным (допустимым), потому что он содержит допустимые значения, которые система должна обрабатывать нормально.
Существуют также невалидные разделы, содержащие значения, которые система должна отклонить или, по крайней мере, передать пользователю для исправления. Невалидные разделы для параметра «Полное имя» содержат более 50 символов и менее 1 символа, что означает “пусто” в случае ввода текста.
Для параметра «Пароль» у нас есть следующие разделы, основанные на требованиях:
Вот набор тестовых данных для всех параметров этой регистрационной формы:
Имя/пароль:
- Одно положительное значение из валидного раздела.
- Одно отрицательное значение из каждого невалидного раздела.
Обратите внимание, что для параметра Пароль дополнительно добавляется пустое значение, так как всегда имеет смысл проверять значение «0» отдельно.
Email-рассылка:
Этот параметр не имеет недопустимых разделов, просто булево значение.
Поскольку параметры Full Name и Password имеют входные данные текстового типа (кроме длины значения), мы также должны учитывать само содержимое, которое может быть следующим:
- Буквы
- Цифры
- Символы
Кроме того, буквы могут быть на разных языках, поэтому каждый тип алфавита можно рассматривать как подкласс класса Letters, например, мы можем проверять следующие алфавиты:
- Латинский
- Кириллический
- Азиатский
Допустим, у нас есть следующие дополнительные требования:
- Параметр Full Name принимает все алфавиты и цифры, не принимает символы.
- Параметр Password: принимает только комбинацию латинских букв, цифр и символов.
Как теперь будет выглядеть наш набор данных:
Обратите внимание, что это только набор значений, а непосредственно к написанию тест-кейсов мы перейдем позже, после рассмотрения следующей техники (анализа граничных значений).
Применимость
Техника разбиения на эквивалентности подходит, когда все члены тестируемого набора значений должны обрабатываться одинаково.
Разбиения могут существовать во многих местах и не ограничиваться диапазонами. Разделы можно создавать и для таких простых величин, как булевы значения — Yes/True в одном разделе, No/False — в другом, как в случае с параметром Email newsletter.
Кроме того, разделение можно применять не только к входным данным, но и к выходным, тестовым окружениям, типам и версиям ОС и браузера, конфигурациям оборудования и т. д. В общем, его можно применить ко всему, что может повлиять на результат теста.
Типы дефектов
В основном мы ищем ситуацию, когда некоторое разделение эквивалентности обрабатывается неправильно. Это может означать, что значение принимается, когда его следовало бы отклонить, или наоборот, или что значение правильно принимается или отклоняется, но обрабатывается способом, соответствующим другому классу эквивалентности, а не тому, к которому оно на самом деле принадлежит.
Недостатки
Если предположение неверно и значения в разделе обрабатываются не совсем одинаково, эта техника может пропустить дефекты.
Также важно тщательно выбирать разделы. Например, поле ввода, принимающее положительные и отрицательные числа, лучше тестировать как два допустимых раздела, один для положительных, другой для отрицательных чисел, поскольку существует вероятность их различной обработки. В зависимости от того, разрешен ли ноль или нет, этот случай может стать еще одним разделом.
Подробный гайд — Эквивалентное разбиение
Следующая техника — анализ граничных значений, который используется в сочетании с эквивалентным разделением.
Анализ граничных значений
Метод анализа граничных значений используется для проверки правильности работы со значениями, которые существуют на границах разделов эквивалентности. Границы определяются максимальными и минимальными значениями в разделе эквивалентности.
Почему нас интересуют границы и в чем смысл этих дополнительных тестов? Потому что на граничных значениях ошибки возникают чаще всего. Существует два подхода к этой технике:
Двухзначная граница
При тестировании двухзначной границы используется само граничное значение плюс значение, находящееся непосредственно за границей (наименьшее возможное приращение, находящееся за границей).
Например, для сумм в валюте с двумя десятичными знаками, если раздел включает значения от 1,00 до 10,00:
- Нижние граничные тестовые значения — 1,00 и 0,99,
- Верхние граничные тестовые значения — 10,00 и 10,01.
Трехзначная граница
Для тестирования трехзначной границы используются значения до, на и за границей. Для нашего примера, если раздел включает значения от 1,00 до 10,00:
- Тестовые значения нижней границы — 0,99, 1,00 и 1,01,
- Тестовые значения верхней границы — 9,99, 10,00 и 10,01.
Подход с тремя значениями границ обеспечивает более надежное покрытие и рекомендуется для фич с высоким риском, но он также требует больше времени. Решение о том, использовать ли двух- или трехзначное граничное тестирование, должно основываться на оценке риска, связанного с тестируемым элементом.
Применим двухграничный подход к параметрам в форме регистрации из примера выше:
Полное имя
- Валидный раздел: 1-50
— нижние граничные значения: 1 и 0
— значения верхней границы: 50 и 51
- Невалидный раздел: 0
— имеет только одно значение
- Невалидный раздел: 51 и более
— нижние граничные значения: 50 и 51
— значения верхней границы: равны максимальному значению, которое можно ввести в поле ввода. В нашем случае поле не позволяет ввести более 50 символов, поэтому достаточно будет проверить значения нижней границы.
Пароль
- Валидный раздел: 6-30
— нижние граничные значения: 6 и 5
— верхние граничные значения: 30 и 31
- Невалидный раздел: 0-5
— нижние граничные значения: только 0 (за пределами значения нет)
— значения верхней границы: 5 и 6
- Невалидный раздел: 31 и более
— значения нижней границы: 30 и 31
— значения нижней границы: аналогично полю Полное имя, достаточно проверить значения нижней границы.
Нетрудно заметить, что значение за пределами одной границы часто является границей в другом разделе эквивалентности. Если это так, то нет смысла дублировать их в тестах.
Получился расширенный набор данных с граничными значениями:
Применимость
Анализ граничных значений — это расширение методики Разбиения эквивалентности, которое применяется только тогда, когда члены класса эквивалентности каким-либо образом упорядочены. Упорядоченное множество — это множество, про которое можно сказать, что один член больше или меньше другого, если эти два члена не одинаковы. Мы также должны быть в состоянии выразить это осмысленно. Если какой-то элемент находится прямо над или под другим элементом в выпадающем меню, это не значит, что эти два элемента имеют отношение «больше-меньше».
Упорядоченные разделы эквивалентности необходимы из-за концепции “нахождения на границе и за ее пределами”. Если упорядочивание не имеет значения с точки зрения бизнеса или техники, то значения границ не должны быть в центре внимания.
В примере с формой регистрации выше у нас есть два раздела для параметра Email Newsletter — Yes и No, но мы не можем использовать эту технику для него, потому что у этих разделов не определены границы.
В дополнение к диапазонам чисел, разделы, для которых можно применить анализ граничных значений, включают:
- Числовые атрибуты нечисловых переменных (например длина).
- Количество выполнений цикла.
- Количество элементов итерации в хранимых структурах данных, таких как массивы.
- Размер физических объектов (например памяти).
- Продолжительность действий.
- Значения даты и времени.
Типы дефектов
Эта техника предназначена для обнаружения дефектов, связанных с обработкой граничных значений, смещением или пропуском границ, особенно ошибок логики «меньше-чем» и «больше-чем».
Недостатки
Поскольку точность этой техники зависит от четкости определения разделов эквивалентности — для правильной идентификации границ, она имеет те же недостатки.
Еще один недостаток анализа граничных значений: риск уделить слишком много внимания граничным случаям и недостаточно — остальной функциональности. Необходимо соизмерять затрачиваемое время с рисками, которые мы можем уменьшить.
Составление тест-кейсов
Получив набор тестовых данных для каждого параметра, мы можем разработать тест-кейсы. Проверять каждое значение параметра по отдельности неэффективно, и занимает больше времени. Мы будем использовать комбинаторное тестирование для объединения значений различных параметров в тест-кейсы, что позволит нам иметь меньшее количество тест-кейсов с большим покрытием.
Существует правило не объединять несколько невалидных значений в одном тест-кейсе, чтобы избежать ситуации, когда наличие одного невалидного значения может маскировать неправильную обработку другого невалидного значения. Также мы можем получить ошибку «недопустимое значение», но какое значение было определено как недопустимое? При разработке тест-кейсов, использующих невалидные разделы, важно быть уверенным, что тест-кейс даст четкий результат, который покажет правильную обработку всех разделов.
Итак, сначала нам нужно создать набор “положительных” тест-кейсов выбрав допустимое значение для каждого параметра. Количество тест-кейсов равно наибольшему количеству тестовых значений в параметре, в нашем примере это Full Name с четырьмя значениями в разделе Content, поэтому мы получим четыре положительных тест-кейса.
Положительные тест-кейсы
Далее, мы создаем набор отрицательных тест-кейсов, в каждом из которых для одного параметра будет невалидное значение, а для всех остальных — валидное. Количество тест-кейсов равно количеству всех невалидных тестовых значений в наборе данных, которое в нашем примере равно 10.
Отрицательные тест-кейсы
Вы могли заметить, что в наших тест-кейсах нет конкретных значений. Методы тест-дизайна дают нам высокоуровневые тест-кейсы, но нам все равно нужно предоставить конкретные значения и ожидаемые результаты во время реального тестирования.
Такие высокоуровневые тест-кейсы можно использовать в нескольких циклах тестирования с разными конкретными данными, что является хорошим подходом для регрессионного тестирования, поскольку каждый раз мы можем использовать разные значения, которые помогают избежать т.н. парадокса пестицида.
(один из принципов тестирования гласит: тесты с одинаковыми значениями постепенно теряют эффективность для поиска дефектов — так же как пестициды через некоторое время перестают эффективно убивать насекомых.)
В тест-кейсах выше значения комбинируются случайным образом, но эти комбинации могут не совпадать с комбинациями у реальных пользователей, и мы можем пропустить дефекты.
Это может быть допустимо для небольших регистрационных форм, как в приведенном примере, но в сложных приложениях могут быть объекты с большим количеством параметров, каждый из которых имеет несколько возможных значений, что приводит к большему количеству комбинаций.
Единственный способ узнать наверняка, есть ли дефект — проверить все возможные комбинации. Но это бывает невозможно за отведенное тестировщику время.
В таких случаях мы можем использовать технику парного тестирования, которая позволяет контролировать так называемый комбинаторный взрыв и эффективно тестировать большое количество возможных комбинаций параметров с помощью относительно небольшого числа тест-кейсов.
Подробный гайд — Анализ граничных значений
Попарное тестирование
Попарное тестирование (не путать с парным тестированием — работе тестировщика в паре с кем-то) — это техника, при которой тест-кейсы нацелены на отработку всех возможных комбинаций каждой пары входных параметров. Попарное тестирование гарантирует, что каждое значение одного параметра будет проверяться в сочетании с каждым значением другого параметра — вместо того чтобы проверять все возможные комбинации между параметрами.
Покрытия по всем парам достичь гораздо легче, чем по всем комбинациям. Например, если вы хотите протестировать 4 параметра, каждый из которых имеет 5 значений, то для покрытия всех комбинаций понадобится 625 тест-кейсов. Тестирование по всем парам позволяет сделать это в 32 тест-кейсах.
В Интернете существуют различные инструменты, которые помогают автоматизировать процесс разработки тест-кейсов (см. https://www.pairwise.org/tools.html), нам нужно только подготовить тестовые данные для инструмента, а затем инструмент сгенерирует набор тест-кейсов, которые охватывают все возможные комбинации пар параметр-значение.
Попробуем применить эту технику к функции Настройки Уведомлений в Slack, используя специальный инструмент Allpairs.
Шаг 1: Подготовить список параметров с тестовыми значениями
Сначала нам нужно подготовить список параметров и значений, которые мы хотим протестировать, в виде таблицы.
Вот все параметры уведомления и их возможные значения:
Шаг 2: Запуск инструмента с подготовленными тестовыми данными
Далее запустим инструмент и передадим ему наши данные (инструкция к этому инструменту объясняет, как это сделать).
Вот набор тест-кейсов, сгенерированных инструментом:
Мы получили 15 тест-кейсов, которые гарантируют, что каждое значение каждого параметра будет сопоставлено хотя бы в одном тест-кейсе.
Ячейки, отмеченные символом «~», означают, что мы можем подставить любое другое значение, поскольку все его сопоставления уже есть. Мы можем заменить эти значения на более часто используемые, или на значения, которые являются частыми источниками дефектов.
Теперь результаты работы инструмента можно использовать в качестве входных данных для тест-кейсов, но нам все еще нужно предоставить ожидаемый результат для каждой комбинации.
Применимость
Техника попарного тестирования полезна для тестирования функциональности с большим количеством входных параметров с несколькими возможными значениями, но этим она не ограничивается.
Мы также можем использовать эту технику, когда на поведение системы влияют различные факторы или конфигурации, и дефекты могут возникать из-за определенных их комбинаций.
Например, для веб-приложения могут быть прописаны следующие факторы:
- Операционная система
- Браузер
- Язык приложения
- Метод авторизации
Мы можем применить тот же инструмент для создания тест-кейсов, охватывающих все комбинации пар.
Здесь приведен список параметров со значениями:
Вот сгенерированные тест-кейсы:
Просматривая результаты, мы видим, что в кейсах TC 2 и TC 6 есть несколько невозможных комбинаций — Mac OS с Edge и Windows с Safari. Поэтому нам нужно удалить их, но при этом убедиться, что другие комбинации параметров в этих строках (Язык и Авторизация) встречаются в других тест-кейсах.
Мы можем внести следующие изменения:
- TC 2: чтобы сохранить пару испанский и Email/Password, мы можем использовать TC 13 и заменить Windows на Mac, поскольку Windows имеет метку «~», что означает, что она там не требуется.
- TC 6: чтобы сохранить пару испанский и SSO, мы можем использовать TC 14 — сохранить значения Windows & Firefox & Spanish, а Social Network заменить на SSO.
Окончательная таблица выглядит следующим образом:
Типы дефектов
Наиболее распространенным типом дефектов, обнаруживаемых при использовании данной методики, являются дефекты, связанные с комбинированными значениями двух параметров. Неправильная обработка комбинаций и обнаружение комбинаций, которые взаимодействуют, когда не должны, или ошибок, которые могут возникнуть из-за взаимодействия между различными входными параметрами.
Недостатки
Основным ограничением является предположение, что результаты нескольких тест-кейсов являются репрезентативными для всех тест-кейсов, и что эти несколько тест-кейсов представляют ожидаемое использование. Если между определенными параметрами существует неожиданное взаимодействие, оно может остаться незамеченным при использовании данного метода, если эта конкретная комбинация не тестируется.
Чтобы минимизировать риск, важно проанализировать созданные комбинации и при необходимости дополнить их знаниями о предпочтениях клиентов, информацией о прошлых отказах и известными общими конфигурациями.
Попарное тестирование — подробный гайд
Верификация бизнес-логики
Тестирование переходов состояний
Техника тестирования переходов состояний используется для проверки способности тестового объекта входить в определенные состояния и выходить из них через допустимые переходы, а также для проверки недопустимых переходов.
Она позволяет сосредоточиться на различных состояниях объекта и переходах между ними, а не тестировать отдельные функции по отдельности.
Как работает техника тестирования переходов состояний:
Шаг 1: Определить состояния
- Состояния отражают различные стадии, в которых может находиться объект в течение своего жизненного цикла.
- Каждый объект может иметь различные состояния в зависимости от того, что мы с ним делаем.
- Состояние может меняться со временем из-за взаимодействий, процессов или действий, выполняемых над объектом.
- Состояния не должны пересекаться, то есть объект не может находиться в двух состояниях одновременно, и в то же время он всегда существует хотя бы в одном.
Пример: объект User может иметь такие состояния, как Приглашен, Зарегистрирован, Удален.
Шаг 2: Определение действий
- Действия вызывают переход тестового объекта из текущего состояния в новое или из текущего состояния обратно в текущее.
- Действиями могут быть действия пользователя, реакции системы или любые внешние стимулы.
Пример: действиями для объекта User могут быть: Пригласить, Зарегистрировать, Удалить.
Шаг 3: Определить переходы
- Под «переходом» понимается изменение состояния, которое происходит при выполнении какого-либо действия.
Пример: Объект User может переходить из состояния Invited в состояние Active, когда пользователь завершает процесс регистрации.
Шаг 4: Разработка тест-кейсов перехода состояний
Техника тестирования переходов состояний представляется в виде диаграммы или таблицы. Рассмотрим оба варианта.
Применим эту технику к объекту Сообщение в приложении Slack:
Состояния:
- Черновик
- Запланировано
- Отправлено
- Удалено
Действия:
- Отправить
- Запланировать
- Редактировать
- Удалить
Теперь мы готовы рисовать диаграмму перехода состояний. Обозначения здесь — кружки для состояний, и стрелки для действий.
Далее мы можем разработать тест-кейсы. Минимальное покрытие должно включать проверку всех состояний и переходов:
- TC 1: Черновик — Отправлено — Удалено
- TC 2: Черновик — Запланировано — Отправлено
- TC 3: Черновик — Запланировано — Удалено
- TC 4: Черновик — Удалено
Как уже говорилось выше, диаграмма переходов состояний — не единственный способ документировать поведение объекта. Диаграмма может быть проще для понимания, но таблица переходов состояний может быть лучше для постоянного использования.
Таблицы переходов состоят из четырех столбцов:
- Текущее состояние: список всех состояний объекта.
- Действие: список всех действий для каждого состояния.
- Новое состояние: состояние объекта после выполнения действия.
- Ожидаемый результат: как система должна реагировать на действие.
Вот как может выглядеть таблица переходов состояний для объекта Сообщение:
Преимущество таблицы переходов состояний в том, что в ней перечислены все возможные комбинации переходов состояний, а не только допустимые переходы, как на диаграмме.
При создании таблиц переходов состояний часто обнаруживаются комбинации, которые не были определены, документированы или рассмотрены в требованиях, и это хороший момент чтобы выяснить, что именно должно происходить в каждой из этих ситуаций.
Проверка допустимых и недопустимых переходов должна быть обязательной для критически важного программного обеспечения или систем с высоким уровнем риска, таких как авионика, медицинские приборы и для тестирования безопасности.
Применимость
Тестирование переходов состояний применимо для любого программного обеспечения, которое имеет определенные состояния и действия, вызывающие переходы между этими состояниями.
Это отличный инструмент для фиксации определенных системных требований, а именно тех, которые описывают состояния и связанные с ними переходы.
Обратите внимание, что техника тестирования переходов состояний должна применяться к одному конкретному объекту. Она описывает состояния конкретного объекта, действия, которые влияют на этот объект, и переходы объекта из одного состояния в другое. Распространенной ошибкой является смешивание различных объектов в одной диаграмме/таблице переходов состояний.
Типы дефектов
Эта техника позволяет найти упущения и противоречия в требованиях до их реализации. Типичные дефекты:
- Невозможность достижения некоторых состояний.
- Невозможность корректного выполнения допустимых переходов.
- Возможность выполнения недопустимых переходов.
Недостатки
Эффективность этой техники зависит от точности идентификации и представления состояний объектов. Если идентификация состояний неверна, тест-кейсы, полученные на основе модели перехода состояний, могут неточно отражать поведение системы.
Подробный гайд по переходам состояний
Таблицы решений
Таблицы решений — отличный инструмент для проверки сложных бизнес-правил, основанных на наборе условий и соответствующих действий, которые будут происходить при определенных комбинациях условий.
Используя таблицу решений, можно легко представить и проанализировать все возможные входные условия и соответствующие выходные действия, что облегчает выявление пробелов в тестовом покрытии.
Создадим таблицу решений для функции Уведомлений в Slack, когда сообщение отправляется в канал.
Шаг 1: Перечислить набор условий
У нас есть следующие условия, которые влияют на уведомления:
- Настройки уведомлений включены или выключены.
- Режим «Не беспокоить» включен или выключен.
- Канал в муте или нет.
Шаг 2: Перечислить связанные действия
Существуют различные типы уведомлений, которые могут быть отправлены:
- Предпросмотр баннера.
- Название канала становится жирным в боковой панели.
- Значок приложения с красной точкой.
Теперь мы можем начать создавать таблицу решений, помещая условия сверху, а связанные действия — снизу.
Шаг 3: Определить количество столбцов с помощью правил принятия решений
Далее мы определяем количество столбцов (правила принятия решений). Чтобы получить количество столбцов, нужно умножить количество возможных значений каждого условия. В нашем примере у нас три условия, и каждое условие имеет два возможных значения — да или нет, поэтому получится 2 x 2 x 2 = 8 столбцов.
Шаг 4: Заполнение столбцов правилами принятия решений
Сначала заполним строки Условий по следующей схеме:
- Первое условие: половина столбцов — Да, половина — Нет.
- Следующее условие: четверть Да, затем четверть Нет, затем четверть Да, затем четверть Нет.
- Последнее условие: чередование Да, Нет, Да, Нет и т. д.
Затем нам нужно создать Действия, которые должны быть предприняты или не предприняты в зависимости от комбинации условий в каждом столбце.
В результате мы получили таблицу, в которой каждый столбец — это правило, определяющее уникальную комбинацию условий, которые приводят к выполнению действий, связанных с этим правилом.
Создание тест-кейсов на основе такой таблицы очень простое: каждое правило (столбец) становится тест-кейсом, где Условия задают входные данные, а Действия — ожидаемые результаты.
В приведенном выше примере условия имеют булевы значения (Yes/No, False/True). Таблицы решений, в которых условия имеют строго булевы значения, называются таблицами решений с ограниченным вводом.
Иногда условия не являются булевыми и могут принимать несколько значений, в этом случае возможно большее количество комбинаций. Такие таблицы называются таблицами решений с расширенным вводом.
Рассмотрим такую функцию, как Transfer Money, где комиссия за транзакцию зависит от следующих условий:
- Тип карты: Standard, Business, Premium
- Сумма операции: менее 1 тыс., от 1 тыс. до 10 тыс., более 10 тыс.
- Обмен валюты: Да или Нет
И следующие действия могут быть предприняты:
- Комиссия за транзакцию
- Комиссия за конвертацию
Далее подсчитаем количество столбцов в таблице. Первое условие имеет три значения, второе условие — три диапазона значений, а последнее условие — два значения. Чтобы получить количество правил, нужно их перемножить: 3 x 3 x 2 = 18.
Наконец, нам нужно заполнить связанные действия, где размер платы зависит от комбинации условий:
Как мы уже узнали, мы можем использовать каждый столбец в качестве тест-кейса, но вы могли заметить, что условие Transaction Amount имеет диапазон значений в каждом столбце, и во время тестирования нам нужно будет использовать конкретные значения. Чтобы выбрать конкретные тестовые данные для каждого диапазона, мы можем использовать методы эквивалентного разбиения и граничных значений. В результате мы получим более одного тест-кейса на столбец, например, для столбца 1 мы можем иметь следующие тест-кейсы:
- TC 1: Тип карты: Стандартная, Сумма транзакции: 500, Обмен: Да
- TC 2: Тип карты: Стандартная, Сумма транзакции: 1, Обмен: Да
- TC 3: Тип карты: Стандартная, Сумма транзакции: 999, Обмен: Да
- TC 4: Тип карты: Стандартная, Сумма транзакции: 0, Обмен: Да
При попытке проверить все возможные комбинации входных сигналов в соответствии с условиями таблицы решений могут стать очень большими. Если условий много, выполнение всех правил принятия решений может занять много времени, поскольку количество правил растет экспоненциально с увеличением количества условий. В таких случаях, чтобы сократить количество правил, которые необходимо проверить, можно использовать минимизированную таблицу решений или подход, основанный на риске.
Следующие рекомендации помогут минимизировать таблицу решений:
- Удаление столбцов, содержащих невыполнимые комбинации условий.
- Объединение столбцов, в которых некоторые условия не влияют на действия.
- Выбор наиболее часто используемого условия в качестве первого, и рассмотрение всех остальных условий на основе анализа риска.
Применимость
Техника таблиц решений — ценный инструмент для представления бизнес-правил и управления сложной логикой принятия решений, когда существует множество возможных исходов, основанных на различных комбинациях входных значений. Она обеспечивает системный подход к определению всех комбинаций условий, а также помогает найти пробелы или противоречия в требованиях.
Эта техника особенно полезна, когда объект тестирования задан в виде блок-схем или таблиц бизнес-правил, когда мы видим утверждения типа «Если A и B истинны, то выполните действие C» и т. д.
Недостатки
Найти все взаимодействующие условия может быть непросто, особенно если требования нечетко определены или вообще не документированы. Если условий слишком много, количество правил будет расти экспоненциально, что может усложнить создание, чтение и обслуживание таблицы.
Кроме того, таблицы решений по своей сути не отражают последовательность или временные аспекты решений. Они сосредоточены на логике, но не обеспечивают естественного способа представления решений, зависящих от порядка событий.
Типы дефектов
Типичные дефекты для этой методики включают неправильную логическую обработку, основанную на определенных комбинациях условий, что может привести к следующим проблемам:
- Неправильные действия происходят.
- Правильные действия не происходят.
- Условия взаимодействуют нежелательным образом.
Таблицы решений — подробный гайд
Итоги
Методы тест-дизайна являются незаменимым средством анализа требований и разработки тест-кейсов, однако необходимо учитывать приоритеты и риски. Можно задизайнить сколько угодно тест-кейсов, но важно заботиться об эффективности потраченного времени — способности тест-кейсов обнаруживать серьезные дефекты, а не о количестве тест-кейсов.»