Какие агрегатные функции существуют

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

Умеете ли вы сами проверить данные в базе, а не только верить интерфейсу. Тестировщику агрегаты нужны, чтобы сверить итоги отчёта, найти дубли и убедиться, что после операции записалось ровно столько строк, сколько должно. Следом часто просят написать запрос, например найти повторяющиеся email.

Как отвечать

Агрегатная функция сворачивает несколько строк в одно значение. Пять базовых, с поведением, которое важно для проверок:

• COUNT: COUNT(*) считает все строки, COUNT(column) пропускает NULL, COUNT(DISTINCT column) считает уникальные значения;
• SUM: сумма без учёта NULL. Если строк нет или все значения пустые, вернёт NULL, а не ноль;
• AVG: среднее только по непустым значениям;
• MIN и MAX: работают с числами, датами и строками.

Дальше покажите применение в тестировании:

• поиск дублей: SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1;
• сверка отчёта: итог в интерфейсе или выгрузке сравниваете с SUM(amount) по тем же фильтрам и за тот же период;
• проверка после действия: после массового импорта COUNT(*) по новым записям совпадает с числом строк в файле;
• поиск «сирот»: заказы без позиций через LEFT JOIN и HAVING COUNT(i.id) = 0.

Отдельно скажите, что GROUP BY и HAVING не функции: WHERE фильтрует строки до группировки, HAVING фильтрует группы после. В автотестах такие запросы удобно держать как проверку состояния базы после вызова API: тест создаёт заказ через эндпоинт и сверяет количество и сумму позиций в таблице.

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

Не учитывают NULL: сверяют COUNT(phone) с числом пользователей и заводят ложный баг, хотя у части пользователей телефон просто не заполнен.

Пишут условие на агрегат в WHERE вместо HAVING и получают ошибку.

Сверяют итог интерфейса с суммой без тех же фильтров: забывают про удалённые записи, статусы или часовой пояс. Расхождение оказывается ошибкой запроса, а не продукта, и баг возвращают обратно.