Ответ
Хранимая процедура (stored procedure) — это предварительно скомпилированный набор SQL-инструкций, хранящийся в базе данных. С точки зрения QA, это критически важный объект для тестирования, так как в нем часто содержится бизнес-логика.
Как я тестирую хранимые процедуры:
-
Проверка функциональности: Запускаю процедуру с различными входными параметрами и сверяю результат с ожидаемым.
-- Пример: тестирование процедуры, которая возвращает заказы клиента EXEC dbo.GetCustomerOrders @CustomerId = 123; -- Проверяю, что возвращаются именно заказы клиента 123 и что набор данных корректен. -
Проверка граничных значений и ошибочных сценариев: Что будет, если передать
NULL, отрицательный ID или несуществующий ID?EXEC dbo.GetCustomerOrders @CustomerId = NULL; -- Должна быть обработка EXEC dbo.GetCustomerOrders @CustomerId = -1; -- Должна быть обработка -
Проверка влияния на данные: Убеждаюсь, что процедуры, изменяющие данные (
INSERT,UPDATE,DELETE), делают это корректно и в рамках транзакции.BEGIN TRANSACTION; EXEC dbo.ApplyDiscount @OrderId = 456, @Discount = 10; -- Проверяю, что скидка применилась к нужному заказу и пересчиталась итоговая сумма ROLLBACK TRANSACTION; -- Откатываю изменения после теста -
Интеграционное тестирование: Проверяю, как процедура работает в связке с другим кодом приложения (например, вызывается ли она корректно из бэкенд-сервиса).
Основные риски, на которые я обращаю внимание: некорректная логика условий, ошибки производительности при работе с большими объемами данных, отсутствие откатов при ошибках (rollback).
Ответ 18+ 🔞
Да ты посмотри, какая тема подъехала — хранимые процедуры! Это ж, бля, целая вселенная в недрах базы данных, где спрятана вся соль бизнес-логики. Если её проебать при тестировании — потом сиди и разгребай последствия, овердохуища работы.
Вот как я с этим делом обычно вожусь, чтобы не облажаться:
-
Функциональность — основа основ. Беру эту процедуру и начинаю её дёргать со всеми возможными параметрами. Надо понять — работает ли она вообще так, как задумано, или это пизда рулю.
-- Допустим, процедура должна отдавать заказы клиента EXEC dbo.GetCustomerOrders @CustomerId = 123;После запуска смотрю: а точно ли это заказы клиента 123? Не подсунула ли мне заказы всего мира? Данные целые? Порядок правильный? Всё должно быть чисто.
-
Граничные значения и адский негатив. Вот тут включается паранойя. Что будет, если на вход прилетит какая-то дичь?
NULL, минус единица, число размером с телефонный номер?EXEC dbo.GetCustomerOrders @CustomerId = NULL; -- Не должна рухнуть вся система! EXEC dbo.GetCustomerOrders @CustomerId = -1; -- Должна дать внятный ответ, а не молча сдохнуть.Если процедура на таком упадёт — это прям пидарас шерстяной, а не код. Надо, чтобы она либо корректно обрабатывала, либо явно сообщала об ошибке.
-
Влияние на данные — святое. Если процедура что-то меняет (добавляет, обновляет, удаляет), тут доверия ебать ноль. Надо проверять в изоляции, чтобы не накосячить в рабочей базе.
BEGIN TRANSACTION; -- Страховочный трос, ёпта! EXEC dbo.ApplyDiscount @OrderId = 456, @Discount = 10; -- Сразу лезу смотреть: скидка прицепилась к тому заказу? Сумма пересчиталась? Ничего лишнего не зацепило? ROLLBACK TRANSACTION; -- Всё проверил — и откатил, как будто и не было ничего.Это правило номер один: никогда не тестируй такие штуки на живых данных без возможности отката.
-
Интеграция. Мало того, что процедура сама по себе работает. Надо ещё понять, как её дергает бэкенд. Может, он параметры криво передаёт? Или результат не так читает? Бывает, что в процедуре всё гуд, а на стыке — полная жопа.
На что глаз-алмаз держу:
- Логика условий. Особенно эти
IF-ELSEиCASE. Один неверный знак — и уже пошло не туда. - Производительность на больших данных. Может, на сотне записей летает, а на миллионе — накрылась медным тазом и всех приконнектила.
- Транзакции. Самое страшное — когда в середине процедуры ошибка, а отката нет. Получается каша в данных, потом только плакать. Чистая хитрая жопа, которую искать потом неделями.
Короче, тестирование процедур — это не просто запустил и забыл. Это вдумчивый разбор полётов, где надо предугадать, какую дичь может выкинуть система или пользователь. Подозрение ебать чувствую ко всякому коду, который не проверил лично.