Как проверишь функционал скидки

Стратегия тестирования функционала скидок

Тестирование функционала скидок — это комплексный процесс, требующий проверки бизнес-логики, пользовательского интерфейса, интеграций и защиты от злоупотреблений. Вот моя поэтапная стратегия.

1. Анализ требований и классификация скидок

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

• Фиксированная сумма (например, скидка 500 рублей).
• Процентная скидка (например, 15% от суммы заказа).
• Накопительная/сегментная скидка (например, "Постоянным клиентам — 10%").
• Скидка на конкретный товар/категорию.
• Промокод (может совмещать несколько типов).
• Скидка от суммы чека (например, "При заказе от 5000 рублей — скидка 7%").
• Комбинированные скидки (например, "Скидка 10% + бесплатная доставка").
• Временные/сезонные акции (скидка действует в определенный период).

Для каждого типа составляю чек-лист сценариев, основанный на специфичных пограничных значениях и условиях применения.

2. Тестирование логики расчета (Backend-тестирование)

Это ядро тестирования. Проверяю корректность математических расчетов в различных сценариях.

• Позитивные сценарии:

    *   Применение одной скидки к товару/заказу.
    *   Применение нескольких скидок (проверка приоритетов — какая применяется первой, можно ли комбинировать). Важно проверить документацию: скидки могут быть **аддитивными** (суммируются) или **мультипликативными** (применяются последовательно).
    *   Корректность округления (до копеек, согласно политике компании: математическое, в пользу покупателя или магазина).
    *   Скидка не должна применять к стоимости доставки, если это не оговорено отдельно.

• Негативные сценарии и граничные условия:

    *   Скидка 100% — итоговая сумма должна быть равна 0 или стоимости доставки (не отрицательной).
    *   Скидка больше 100% — система должна отклонять такую скидку или ограничивать расчет на уровне бизнес-логики.
    *   Скидка на товар с нулевой стоимостью.
    *   Применение скидки к корзине, где сумма после скидки становится меньше минимальной суммы заказа.
    *   **Проверка целостности данных:** после применения скидки финальная сумма в заказе должна быть равна сумме всех позиций с учетом скидок + доставка. Я часто пишу для этого небольшие **SQL-запросы** или скрипты для сверки данных.

-- Пример запроса для проверки корректности расчета в заказе
SELECT
    order_id,
    total_calculated, -- Сумма, рассчитанная системой
    (items_sum - discount_amount + delivery_cost) as total_manual, -- Ручной пересчет
    (total_calculated - (items_sum - discount_amount + delivery_cost)) as discrepancy -- Расхождение
FROM orders
WHERE order_id = 12345;

3. Тестирование условий применения и бизнес-правил

Здесь я проверяю контекст, в котором скидка становится активной или, наоборот, блокируется.

• Валидность по времени: активация/деактивация в точное время начала и окончания акции (с учетом часовых поясов!).
• Валидность по аудитории: правильно ли применяются скидки для разных сегментов пользователей (новые, VIP, из определенной геолокации).
• Валидность по товарам/категориям: скидка применяется только к указанным товарам, исключая те, что в black-листе (например, товары по акции).
• Ограничение количества использований: на один аккаунт, один промокод, общее количество активаций промокода.
• Минимальная и максимальная сумма корзины для применения.
• Конфликты скидок: что происходит, если пользователь одновременно попадает под действие двух скидок? Какой алгоритм выбора?

4. Тестирование пользовательского интерфейса и UX (Frontend-тестирование)

Пользователь должен четко видеть выгоду. Проверяю:

• Отображение скидки: правильный вывод старой и новой цены, размера скидки (в рублях или %) на карточке товара, в корзине, в избранном.
• Информативность: сообщения об успешном применении промокода, об ошибках (например, "Промокод недействителен", "Не выполнены условия").
• Работоспособность элементов: кнопка "Применить промокод", поле ввода, удаление примененной скидки.
• Адаптивность: корректное отображение на всех типах устройств.

5. Интеграционное и кросс-системное тестирование

Скидка не существует в вакууме. Необходимо проверить:

• Интеграция с платежными системами: итоговая сумма, списанная с карты клиента, должна в точности совпадать с суммой заказа после всех скидок, отраженной в системе.
• Интеграция с CRM и системами аналитики: информация о примененной скидке и ее типе должна корректно передаваться для построения отчетов о маркетинговых активностях.
• Формирование чека (54-ФЗ): в фискальном чеке должна быть правильно отражена сумма скидки как отдельная позиция или как коррекция стоимости товара, согласно законодательству.

6. Тестирование безопасности и защита от фрода

Это критически важный аспект.

• Защита от подбора промокодов (brute-force). Должно быть ограничение на количество попыток ввода.
• Валидация формата промокода (регистр, использование спецсимволов).
• Нельзя применить один промокод дважды в одном заказе.
• Проверка на манипуляции: попытка изменить сумму скидки или условия путем передачи модифицированных данных через API (например, в POST-запросе). Backend должен повторно валидировать все правила.
• Тестирование API: прямой вызов методов применения скидки с некорректными или неполными данными.

// Пример негативного API-теста (используя синтаксис JS/fetch)
// Попытка применить несуществующий промокод
fetch('/api/cart/apply-promo', {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({ promoCode: 'NON_EXISTENT_999' })
})
.then(response => {
    // Ожидаем статус ответа 400 (Bad Request) или 404, а не 200
    assert(response.status === 400);
    return response.json();
})
.then(data => {
    // Ожидаем четкое сообщение об ошибке
    assert(data.message === 'Promo code is invalid or expired');
});

7. Регрессионное и нагрузочное тестирование

• Регрессия: добавление новой скидки не должно ломать расчет старых. Изменение логики для одного типа скидок не должно влиять на другие.
• Нагрузка: как ведет себя система в период масштабной распродады (например, Black Friday), когда тысячи пользователей одновременно применяют скидки? Не падает ли расчетный引擎?

Итог: Мой подход к тестированию скидок — это сочетание глубокого анализа бизнес-логики, скрупулезной проверки расчетов, внимания к пользовательскому опыту и обязательного тестирования на уязвимости. Только так можно гарантировать, что маркетинговая функция будет работать корректно, приносить прибыль и не станет источником финансовых потерь или недовольства клиентов.