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

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

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

Пример 1: Алгоритм расчета итоговой стоимости товара с учетом скидки в зависимости от общей стоимости выбранного товара

Ниже представлена «таблица решений» для этого алгоритма.

Пример 2: Алгоритм определения возможности возврата/обмена или ремонта товара

Ниже представлена «таблица решений» для этого алгоритма.

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

Один из самых сложных тест-дизайнов в виде «таблицы решений», которые мне приходилось делать для алгоритмов – был тест-дизайн для алгоритма выбора «приоритетного диапазона цен».

Пример 3: Алгоритм выбора «приоритетного диапазона цен».

Сначала кратко опишу суть этого алгоритма.

Есть сущность «Торговая точка» (сокращенно ТТ), у которой в карточке могут быть заполнены (не обязательные) поля:

• Страна

• Регион

• Ритейлер

• Сегмент

Но если не заполнена страна, то регион тоже не заполнен.

Есть сущность «Диапазон цен», у которой в карточке также могут быть заполнены (не обязательные) поля:

• Страна

• Регион

• Ритейлер

• Сегмент

Также для «Диапазона цен» указывают тип ценника («обычный» (без акции), «по акции»).

Для выбора приоритетного «Диапазона цен» есть следующие уровни приоритета:

• 1 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Страна + Регион + Сегмент + Ритейлер»

• 2 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Страна + Сегмент + Ритейлер»

• 3 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Сегмент + Ритейлер»

• 4 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Страна + Регион + Ритейлер»

• 5 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Страна + Ритейлер»

• …

• 11 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Страна»

• 12 уровень: Для ТТ и «Диапазона цен» не заполнены поля Страна, Регион, Ритейлер, Сегмент

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

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

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

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

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

Для каждого из 4 полей ТТ значение либо будет выбрано, либо нет. Значит может быть по 2 варианта для каждого их 4 полей, значит всего вариантов 2*2*2*2 = 16. Но так как есть условие, что если не заполнена страна, то регион тоже не заполнен, то 4 варианта для ТТ исключаются (выделены красными квадратами). Поэтому в итоге всего 12 вариантов заполнения нужных полей карточки ТТ.

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

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

Эти 4 поля для ТТ я первыми добавила в таблицу в самом верху блока условий.

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

• пусто

• заполнено и имеет такое же значение, как в карточке ТТ (в таблице “Да(заполнено)”)

• заполнено и имеет другое значение, чем в карточке ТТ (в таблице “Нет(заполнено)”)

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

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

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

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

Пример таблицы №1: Для ТТ заполнены все поля «Страна», «Регион», «Ритейлер», «Сегмент»:

Пример таблицы №6: Для ТТ заполнены только поля «Страна» и «Сегмент»:

Тесты по таким таблицам я проводила следующим образом:

1. Подготовила 12 ТТ с разным заполнением данных в карточке согласно тест-дизайну

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

3. Затем делала GET-запрос для каждой ТТ и проверяла, что в его ответе выводятся два нужных «Диапазона цен» и не выводятся другие (для каждой из 12 таблиц - свои)

4. Потом удаляла первые два «Диапазона цен» из базы

5. Снова делала GET-запрос для каждой ТТ и проверяла, что в его ответе выводятся два нужных «Диапазона цен» и не выводятся другие (для каждой из 12 таблиц - свои)

6. Потом удаляла следующие два «Диапазона цен» из базы

7. Снова делала GET-запрос для каждой ТТ и проверяла, что в его ответе выводятся два нужных «Диапазона цен» и не выводятся другие (для каждой из 12 таблиц - свои)

8. Потом удаляла следующие два «Диапазона цен» из базы

9. И т.д.

При этом «Диапазоны цен», которые должны были пропускаться во всех тестах (ячейки выделены светло-синим) не удалялись во время тестов, так как их наличие никак не должно было влиять на данные в ответе GET-запроса.

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

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

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

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

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