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

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

Самый распространённый из таких строгих методов во всех статьях по тест дизайну – метод граничных значений.

Вспомним для начала пару определений:

(1) Эквивалентный класс – подмножество всех входных значений, которые должны быть обработаны приложением одинаково и дать на выходе одинаковый результат.

(2) Граничное значение – входное или выходное значение, находящееся на границе класса эквивалентности или на минимальном инкрементном расстоянии по обе стороны от границы (ISTQB).

Таким образом, из (1) и (2) можно сформулировать следующее:

(3) Граничные значения – значения входных данных, на которых должно меняться поведение приложения.

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

Обычно BVA описывают как применимый к числовым переменным из-за специфики его применения. Типичными примером является валидация возраста: есть ли пользователю 18 лет? Стандартным ответом для проверки ≥ 18 являются два кейса со значениями 17 и 18 лет.

Замечание: с точки зрения поиска ошибок в конкретно этой ситуации двух кейсов может не хватить. Если разработчик вместо ≥18 в условии поставил =18, то проверки на 17 и 18 дадут ожидаемые результаты и ошибка будет пропущена. Для поиска этой ошибки нужен кейс с большим значением, не на границе класса, например, 19. Это всё ещё не убережёт от более хитрых ошибок, вроде условия 18|19, но такое уже маловероятно и выходит за границы метода. Здесь нужно подчеркнуть, что суть метода не в том, чтобы найти все возможные ошибки. А в том, чтобы минимальным числом проверок показать соответствие программы требованиям.

Но только ли к числам можно применить этот метод?

Перепишем определение (1) и утверждение (3) чуть более формальным математическим языком.

Пусть x∈X, где x – входное значение, X – множество всех возможных входных значений, а f(x) – результат работы приложения при вводе входного значения x. Тогда можем определить эквивалентный класс U так: ∀ x ∈ A:f(x)=a, где a – одинаковый результат работы программы для всех входных значений класса.

Если на множестве X задано отношение порядка, то это множество будет частично упорядоченным множеством. Тогда если U⊂〈 X, ⩽ 〉, то элемент u∈ X называется верхней гранью, если ∀ a ∈ X: a⩽ u. А наименьшей верхней гранью (супремумом множества) будет наименьшее такое u. Аналогично определяются нижняя грань и инфимум соответственно.

Замечание: супремум и инфимум в общем случае не обязаны принадлежать своим множествам. Если sup A ∈ A, то он называется максимумом A. Аналогично inf A ∈ A ⇒ inf A = min A (минимум).

Что это даёт? Если мы можем упорядочить множество всех возможных входных значений, то мы можем выделить грани подмножества. И, таким образом, можем сразу же выбрать значения для тестов по методу границ. Для каждой грани одной точкой будет сама грань, а второй – точка с другим значением f(x). Например, если первая точка x_1 = inf A ∈ A ⇒x_1=maxA и f(x_1)=a, то вторая точка x_2 должна быть такой, чтобы |x_1-x_2| было минимальным и f(x_2)≠ a. Можно сказать, что x2 в данной ситуации должен быть предыдущим элементом для x_1. И обратно, если первая точка x_1=infA∉ A ⇒x1≠maxA и f(x1)≠a,  то вторая точка x_2 должна быть такой, чтобы |x_1-x_2| было минимальным и f(x_2)=a. То есть x_2 будет следующим элементом для x_1.

Аналогичное рассуждение можно провести для sup A. В итоге получим четыре точки для проверки работы программы на множестве A.

Рассмотрим два примера.

Пусть множество A⊂ℕ и A=[1;18]. Тогда гранями очевидно будут точки 1 и 18, а ближайшими к ним соседними точками, где f(x)≠a будут 0 и 19. Кейсы можно описать так:

x

f(x)

0

¬ a

1

a

18

a

19

¬ a

Теперь пусть множество A ⊂ ℝ и A=[0;1). Это полуинтервал, в котором нижняя граница включена в него, а верхняя выколота. Грани вновь очевидны, это 0 и 1, а вот соседние точки выделить немного сложнее. Это будут точки (0-ε) и (1-ε).

Здесь ε - наименьшее значение, имеющее смысл в рамках нашей задачи. Если программа принимает переменную x с точностью до второго знака после запятой, то ε =0,01. А если же используется число двойной точности (binary64 из IEEE 754 / IEC 60559), то обычно стоит принимать ε=0,0000000000000001, но в зависимости от порядка используемых чисел это значение может меняться. Получаются следующие кейсы:

x

f(x)

-0,0000000000000001

¬a

0

a

0,9999999999999999

a

1

¬a

Можно ли было получить эти кейсы методом границ без всей этой математики? Конечно же, можно! А если множество допустимых значений будет не числовым? Если это строки? Файлы? Списки элементов? Да, большинство QA инженеров не раз сталкивались с подобными задачами и знают как, например, протестировать поле для ввода имени. На основании опыта и здравого смысла они с лёгкостью составят кейсы ти "валидное значение", "невалидное значение", "пустое поле", "максимум символов", "недопустимый символ"... Скорее всего, таких кейсов может набраться штук 10 или 20 в зависимости от требований к полю. Допустим, что нам нужно протестировать код, который для каждого месяца по его номеру возвращает разные результаты. Составим список из всех тестовых значений, использованных в кейсах. Какую последовательность таких номеров проще всего проверить? Вот два примера:

3, 11, 1, 8, 5, 12, 2, 9, 6, 4, 10, 8

1, 2, 3, 4, 5, 6, 7, 7, 8, 10, 11, 12

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

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

Как можно задать отношение порядка на разных типах входных данных? Рассмотрим несколько примеров.

Пример 1. На вход программе подаётся два числа: x и y – координаты точки. Условие выполняется, если точка лежит внутри окружности с центром (0;0)  и радиусом 1.

Это условие можно переписать, используя формулу окружности: x^2+y^2⩽ 1⇒ (x:y) ∈ A. Входными данными здесь является пара действительных чисел, то есть, по сути, вектор. Для вектора можно определить его длину как z=\sqrt{x^2+y^2}. Тогда предыдущее условие превращается всего лишь в z⩽1. Очевидно, что для z отношение порядка — это обычное сравнение ⩽. Гранью будет 1, а тестовыми значениями z_1=1 и z_2=1+ ε. Но исходные данные состоят из пары чисел, поэтому получается, что y_i=\sqrt{1-x_i^2}. Достаточно подставить сюда x∈ [-1;1] для получения пары чисел для тест кейса.

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

Пример 2. Программа отображает данные в таблице, у которой есть фильтр по одному из полей. Фильтр позволяет выбирать любое количество значений из представленного списка (dropdown + multiselect). Требуется проверить работу фильтра при разных значениях.

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

Есть несколько способов задания отношения порядка. Например, можно получить частично упорядоченное множество по включению A⊆ B. Или можно получить линейно упорядоченное множество по мощности |A|⩽ |B|. В любом случае? мы очевидно видим грани в виде пустого множества ∅ и исходного множества всех элементов A. Соседними точками с другим поведением будут подмножество из одного элемента и подмножество из всех, кроме одного элемента.

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

Тогда упорядоченная последовательность тест кейсов может выглядеть так:

  • пустой список

  • список из одного элемента, возвращающий пустую таблицу

  • список из одного элемента, возвращающий одну строк

  • список из одного элемента, возвращающий несколько строк

  • список из всех элементов, кроме одного, возвращающий все строки, кроме нескольких

  • список из всех элементов, кроме одного, возвращающий все строки, кроме одной

  • список из всех элементов, кроме одного, возвращающий все строки

  • список из всех элементов

Удобно для проверки на полноту, не так ли?

Пример 3. На вход программе подаётся строка. Условие выполняется, если строка не пуста, длиной не более n символов, все символы принадлежат множеству допустимых символов.

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

Так же можно задать отношение порядка  

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

Вместо этого разобъём задачу на две части. Рассмотрим отдельно количество символов и допустимость символов.

Для количества символов определим отношение порядка очевидным образом: |x| < |y|. Тогда гранями оказываются 0 и n, кейсами будут пустая строка, строка из одного допустимого символа, строка из n допустимых символов и строка из n+1 допустимых символов.

Для проверки на допустимость символов нужно определить порядок на множестве символов. Самым простым способом будет использовать сравнение кода символа в используемой кодировке (utf8, unicode и т.п.). В большинстве случаев почти все символы будут собираться в последовательности символов одного языка, идущие подряд в таблице символов: символы латиницы, кириллицы, цифры, китайские иероглифы и арабская вязь. Таким образом, согласно выбранной нами стратегии нужно будет проверить только первые и последние символы таких блоков и соседние с ними недопустимые символы.

На практике такое решение для проверки на допустимость символов является не очень надёжным, т.к. решение в коде программы может оказаться нетривиальным и содержать неожиданные наборы разрешённых/неразрешённых символов. Или использовать готовые наборы вместо диапазона. Например, если по требованию разрешены только цифры, то предлагаемый метод указывает проверить только 0, 9 и соседние символы в таблице. Однако, если разработчик использовал встроенный в фреймворк числовой тип данных для поля, то поле может принимать "-", десятичный знак "." или "," (зависит от локали), символ разделения разрядов " " или "." (так же зависит от локали).

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

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