Одними из техник проектирования проверок являются классы эквивалентности и анализ граничных значений
Возьмем пример: есть требование “Возраст пользователя должен быть от 18 до 65 лет включительно”. Так как возраст - целое неотрицательное число, то можно разбить числовой промежуток $[0; +\infty)$ на три диапазона: $[0; 17]$, $[18; 65]$ и $[66; +\infty)$
Из этих трех только один диапазон, $[18; 65]$, является валидным, а классы $[0; 17]$ и $[66; +\infty)$ невалидны. Тут важно не только проверять числа из каждого диапазона, но и проверять числа на границах между диапазонами, чтобы исключить дефекты из-за неправильной реализации (например, поставлено условие > 18 вместо >= 18)
Так как обычно всё множество значений (например, множество значений цены) перебрать дорого или невозможно, то возникает потребность не перебирать все значения, а перейти к моделированию областей значений, для значений внутри которых система имеет одинаковое поведение. Для примера выше такими областями являются $[0; 17]$, $[18; 65]$ и $[66; +\infty)$
Такие области называются классами эквивалентности - множества входных или выходных данных, элементы которого, согласно требованиям или спецификации системы, предполагаются обрабатываемыми одинаковым образом, что позволяет использовать отдельные значения этого множества как представителей всего класса при формировании тестовых случаев
В тестировании по технике черного ящика (то есть, когда конкретная реализация неизвестна) применяют разбиение множества входных значений на классы эквивалентности (Equivalence Partitioning, EP)
Помимо числовых диапазонов также классами эквивалентности могут быть элемент из множества перечисления (например, “самовывоз” как способ доставки), пустое значение или некорректный формат (например, строка вместо числа)
Далее при создании тестов выбираются представители классов - одно значение внутри класса эквивалентности, которое будет проверяться, вместо всех значений в этом классе. Поскольку мы предполагаем, что система работает одинаково для всех значений в классе эквивалентности, то может случится ситуация, что дефект может обнаружиться на другом значении, которое не является представителей (принцип, говорящий, что “исчерпывающее тестирование невозможно”)
Другая техника - это анализ граничных значений (Boundary Value Analysis, BVA), при котором тесты проектируются прежде всего для значений на границах классов эквивалентности и непосредственно рядом с ними
Анализ граничных значений хорошо работает с упорядоченной последовательностью значений (например, числа, длина строки, количество элементов), но не с категориальными значениями (такими как цвет, способ оплаты и так далее)
Для примера выше границами классов эквивалентности являются числа $18$ и $65$. Важно также проверять не только границы, но и соседние элементы, где шаг между элементами определяется требованиями (например, для возраста - это $\pm 1$, а для цены - это $\pm 0.01$)
Здесь есть два подхода выбора соседних элементов:
Например, для проверки диапазона $1 \leq x \leq 10$ в двухточечном подходе выбираются точки $0$, $1$, $10$ и $11$, а в трехточечном - $0$, $1$, $2$, $9$, $10$ и $11$
Выбор подхода зависит от тяжести риска, который может нести дефект в этой функции, и стоимости тестирования
Если параметров много, то сочетания их классов эквивалентности образуют декартовое произведение множеств
В случае, когда поведение системы не зависит от сочетания конкретных значений параметров, проверка каждого сочетания не имеет смысла, поэтому можно проектировать тесты так, чтобы каждый значимый класс эквивалентности проверялся хотя бы в одном тесте
Если какие-либо сочетания меняют поведение системы, то они проверяются отдельно, причем важно, чтобы негативные тесты нарушали ровно одно правило, чтобы было понятно в случае дефекта, почему проверка не прошла
На основе этих техник определяется число тест-кейсов, которые проверяют разные границы и классы эквивалентности. Лучше всего проектировать один тест-кейс для проверки одного правила, если важно понять причину провала проверки, но также допустимо делать совместную проверку правил, например, для проверки подсчета цены, зависящей от разных условий
Чтобы тест-кейсы не дублировались, нужно рассматривать цель тест-кейса. Если какие-либо тест-кейсы имеют одинаковую цель, то можно оставить один тест-кейс