В заказе нет заранее известной эталонной суммы. Как по данным ответа проверить, что итог рассчитывается сог...

{
  "позиции": [
    {"цена": 250, "количество": 2},
    {"цена": 300, "количество": 1}
  ],
  "скидка": 100,
  "итого": 700
}

Краткий ответ

Нужно проверить инвариант — постоянное соотношение между связанными данными. Для приведённого заказа сумма позиций равна 250 × 2 + 300 × 1 = 800, после скидки 100 ожидаемый итог составляет 700. Такой подход позволяет обнаружить нарушение согласованности даже без заранее подготовленного эталонного результата.

Исторический контекст

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

Для таких случаев применяют проверки отношений между данными: сумма строк должна совпадать с итогом, количество доступных объектов — с суммой по категориям, а изменение входного значения должно предсказуемо изменять результат. Такой подход снижает зависимость от заранее сохранённых ожидаемых ответов.

Постановка проблемы

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

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

Подробное решение

Сначала выделяют инвариант на основании требования. Для упрощённого примера он выглядит так:

итого = сумма(цена × количество) − скидка

По данным вопроса расчёт такой:

250 × 2 + 300 × 1 − 100 = 700

Затем тестировщик проверяет не один пример, а несколько изменений входных данных:

• изменить количество одной позиции и убедиться, что итог меняется пропорционально цене;
• добавить или удалить позицию и проверить соответствующее изменение суммы;
• применить скидку и убедиться, что она учитывается ровно по правилу;
• проверить нулевое количество, минимальную цену, дробные значения и округление, если они разрешены.

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

Инвариант можно проверять на разных уровнях: в ответе сервера, в пользовательском интерфейсе и при повторном открытии заказа. Если данные в JSON согласованы, но на экране показана другая сумма, это уже отдельная проблема отображения или преобразования данных.

Ограничение метода состоит в том, что согласованность не доказывает абсолютную правильность бизнес-правила. Система может одинаково ошибочно применить неверную ставку скидки, но сохранить внутреннюю арифметическую связь. Поэтому инвариантные проверки дополняют проверки конкретных бизнес-правил, а не заменяют их.

Ситуация из практики

В интернет-магазине тестировщик не имел полного набора эталонных заказов: цены и скидки рассчитывались динамически. В одном ответе сумма позиций составляла 1 250 рублей, скидка — 150 рублей, но поле итого содержало 1 250 рублей.

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

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

Что кандидаты часто упускают

1. Достаточно ли проверить только арифметическую сумму позиций?

Нет. Нужно учитывать все компоненты, предусмотренные правилами: скидку, налог, доставку, бонусы и округление. Если тестировщик проверяет только сумму строк, он может пропустить ошибку в порядке применения скидки или в расчёте налога.

2. Доказывает ли совпадение итога с формулой корректность расчёта?

Нет. Инвариант подтверждает согласованность данных, но не обязательно правильность самой формулы. Например, система может использовать скидку 5% вместо требуемых 10% и при этом безошибочно вычислять итог по своей неверной формуле.

3. Как отличить ошибку расчёта от ошибки отображения?

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