Как система обрабатывает создание дублирующихся адресов и ошибки фильтрации

Что проверяют

Как вы тестируете правило уникальности и фильтрацию на всех уровнях: интерфейс, API, база. Главное, что хотят услышать: вы сначала выясняете, что система считает дублем, и только потом пишете проверки. Следом часто спрашивают, как поймать дубль от двойного клика.

Как отвечать

Начните с требований. Дубль это совпадение один в один или после нормализации: регистр, лишние пробелы, «ул.» против «улица», «ё» против «е», для email регистр доменной части. Без этого ответа тест-кейсы писать не на чем.

Дальше каркас проверок:

• основной сценарий: новый адрес сохраняется, повторный отклоняется с понятным сообщением, а API возвращает ожидаемый код, чаще всего 409 Conflict или 422;
• варианты написания: классы эквивалентности по правилам нормализации, каждый в отдельном кейсе;
• параллельные запросы: два одинаковых POST одновременно через Postman Runner, JMeter или скрипт. Если в базе нет уникального индекса, проверка «есть ли такой адрес» в коде пропустит оба;
• база: после сценария SQL-запросом убедиться, что запись одна и у неё правильный статус;
• фильтрация: пустой результат, спецсимволы и кавычки в параметре, очень длинная строка, сочетания фильтров (для них подходит pairwise), фильтр вместе с пагинацией и сортировкой. Отдельно убедитесь, что фильтр работает на сервере, а не прячет строки только на текущей странице.

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

Где спотыкаются

Проверяют только интерфейс. Кнопка блокируется, но прямой запрос к API спокойно создаёт дубль.

Не уточняют правило дубля и заводят баг на то, что по требованиям считается разными адресами.

Забывают про мягко удалённые записи: адрес удалили, а создать такой же снова уже нельзя, или, наоборот, появляется второй активный.