Сервис принимает корректный запрос, но не проверяет поведение при нарушении одного обязательного поля. Какой риск должен выявить отрицательный тест?
Отрицательный тест должен выявить, что сервис некорректно обрабатывает недопустимый вход: например, принимает его, возвращает неверный статус, раскрывает внутреннюю информацию или изменяет данные. Главный вывод — корректность системы проверяется не только на валидных сценариях, но и на ожидаемых ошибочных условиях.
Отрицательное тестирование сформировалось из практической необходимости проверять не только предусмотренный пользовательский путь, но и нарушения входных ограничений. Реальные пользователи, интеграции и внешние системы могут отправлять неполные, неверные или противоречивые данные.
Проверка только позитивных сценариев показывает, что система работает при ожидаемом использовании, но не подтверждает её устойчивость к ошибкам. Поэтому обработка отказов стала отдельной частью тестового анализа.
Если обязательное поле не задано, система должна предсказуемо отклонить запрос и сообщить о причине в согласованном формате. При отсутствии такой проверки возможны частично сохранённые данные, некорректные расчёты, непонятные сообщения пользователю или ошибка во внутреннем компоненте.
Особенно опасно молчаливое принятие невалидного запроса: внешне операция может выглядеть успешной, хотя данные уже повреждены. Такой дефект способен проявиться значительно позже и усложнить поиск первопричины.
Сначала определяют контракт поля: обязательно ли оно, какие значения допустимы, может ли быть пустым и на каком этапе выполняется проверка. Затем формируют отрицательный сценарий с отсутствующим полем и проверяют не только факт отказа, но и его последствия.
Ожидаемый результат обычно включает:
Отрицательный тест не означает отправку случайно испорченных данных во всех возможных формах. Набор следует строить по ограничениям требования: проверять отсутствие поля, пустое значение, неверный тип и пограничные недопустимые значения, если они имеют разные ожидаемые реакции.
У подхода есть компромисс: чрезмерное количество малозначимых невалидных комбинаций увеличивает стоимость тестирования. Приоритет следует отдавать нарушениям, которые могут привести к потере данных, обходу бизнес-правил, проблемам безопасности или сбою интеграции.
Платёжный сервис требует идентификатор заказа. Тестировщик отправил запрос без этого поля. Возможны три варианта: проверить только HTTP-статус, проверить статус и тело ответа либо дополнительно убедиться, что платёж не создался и событие не ушло в бухгалтерскую систему.
Первый вариант дешевле, но может пропустить побочные эффекты. Второй лучше проверяет контракт, однако не обнаруживает изменения во внешних системах. Выбран третий вариант: запрос должен быть отклонён с понятной ошибкой, запись платежа и внешнее событие не должны появиться.
Такой выбор обоснован тем, что ошибочный платёж опаснее некорректного текста ответа. Проверка выявила дефект: сервис возвращал ошибку, но успевал создать незавершённую платёжную запись. Исправление валидации до изменения данных устранило риск накопления «осиротевших» операций.
Нет. Нужно проверить отсутствие побочных эффектов и соответствие ошибки контракту. Сервис может вернуть ошибочный статус, но до этого записать данные или отправить событие, поэтому одной проверки ответа недостаточно.
Отрицательное тестирование шире: оно проверяет ожидаемую реакцию системы на нарушение входных или бизнес-условий. Исключение — лишь один возможный технический механизм; корректным результатом может быть контролируемый отказ без аварийного исключения.
Обычно нет: полный перебор может быть неограниченным и не даст пропорциональной пользы. Значения выбирают по классам эквивалентности, границам, бизнес-рискам и известным типовым ошибкам, отдельно проверяя случаи, для которых ожидаются разные реакции системы.