Как тестировать сложный фильтр с несколькими полями
Что проверяют
Умеете ли вы сократить комбинаторный взрыв до разумного набора тестов и объяснить, почему его достаточно. Пять полей по пять значений дают 3125 комбинаций, и перебирать их все никто не ждёт. Следом спрашивают про pairwise и про то, как убедиться, что выдача действительно правильная.
Как отвечать
Сначала выясните логику: поля объединяются через И, а значения внутри мультиселекта через ИЛИ или тоже через И; что значит пустое поле; включаются ли границы диапазонов; как фильтр сочетается с сортировкой и пагинацией.
Дальше техники:
- каждое поле отдельно: классы эквивалентности и границы. Для диапазона цены: «от» равно «до», «от» больше «до», одна граница пустая. Для дат: один день, переход месяца, часовой пояс;
- pairwise: набор, где каждая пара значений любых двух полей встречается хотя бы раз. Большинство дефектов взаимодействия проявляется уже на парах, а число тестов падает с тысяч до десятков. Генерируют утилитой PICT или аналогами;
- таблица решений: для зависимых полей, когда выбор страны меняет список городов или одно поле блокирует другое;
- оракул: ожидаемую выдачу проверяйте не глазами, а запросом к базе или к API с теми же параметрами. Сверяйте и состав, и счётчик «найдено N»;
- поведение: сброс одного поля и всех сразу, фильтр в URL и после обновления страницы, понятное сообщение при пустой выдаче, переход на вторую страницу с активным фильтром.
Нефункциональная часть: время ответа на тяжёлых комбинациях и на большой базе, быстрые клики подряд, когда ответ старого запроса приходит позже нового и затирает свежую выдачу.
Автоматизация: параметризованные API-тесты по таблице pairwise и лишь несколько сквозных UI-сценариев.
Где спотыкаются
Проверяют только «каждое поле по одному». Баги фильтров почти всегда живут во взаимодействии полей.
Сверяют выдачу глазами на первой странице. Лишняя запись на пятой странице так не находится.
Не уточняют логику И и ИЛИ и заводят баги на ожидаемое поведение.