Что такое негативный результат?

Что такое негативный результат в тестировании?

В контексте QA-инженерии и тестирования программного обеспечения негативный результат (или негативное тестирование) — это метод валидации поведения системы при передаче ей некорректных, неожиданных или недопустимых входных данных или действий. Цель такого тестирования — убедиться, что приложение корректно обрабатывает ошибочные сценарии: не ломается, не приводит к утечке данных или иным критическим проблемам, а выдаёт понятные сообщения об ошибках и сохраняет стабильность.

Если позитивное тестирование отвечает на вопрос: «Работает ли система так, как должна, при корректных условиях?», то негативное тестирование проверяет: «Как система ведёт себя, когда условия не корректны?». Это ключевой аспект обеспечения отказоустойчивости и безопасности приложения.

Ключевые цели негативного тестирования:

• Проверка обработки ошибок: Убедиться, что система выдаёт адекватные, понятные пользователю сообщения об ошибках, а не технические «кракозябры» или падает.
• Обеспечение стабильности: Предотвратить сбои, зависания, «падения» приложения (crashes) или утечки памяти при некорректных действиях.
• Валидация граничных значений: Проверить поведение на границах допустимых диапазонов и за их пределами.
• Повышение безопасности: Выявить потенциальные уязвимости, такие как инъекции (SQL, XSS), переполнение буфера или несанкционированный доступ при передаче злонамеренных данных.
• Улучшение пользовательского опыта (UX): Гарантировать, что даже в случае ошибки пользователь не останется в недоумении и сможет понять, что делать дальше.

Примеры сценариев негативного тестирования:

1. Поля ввода:

    *   Ввод букв в поле, ожидающее только числа (например, возраст).
    *   Ввод спецсимволов (`<`, `>`, `'`, `"`) или скриптов в текстовые поля.
    *   Ввод строки длиннее максимально допустимого предела.
    *   Отправка пустой формы при обязательных к заполнению полях.

1. Авторизация и аутентификация:

    *   Ввод неверного пароля или логина.
    *   Попытка доступа к защищённому ресурсу без токена или с истёкшей сессией.
    *   Многократный ввод неверных данных для проверки блокировки учётной записи.

1. Работа с API:

    *   Отправка HTTP-запроса с неверным методом (например, `PUT` вместо `GET`).
    *   Передача в теле запроса (JSON/XML) некорректной структуры данных или неверного типа данных.
    *   Отправка запроса без обязательных заголовков или с пустым телом.

Практический пример: тестирование API

Рассмотрим API endpoint для создания пользователя: POST /api/users.

Позитивный тест (корректные данные):

{
  "username": "ivan_ivanov",
  "email": "ivan@example.com",
  "age": 25
}

Ожидаемый результат: HTTP статус 201 Created и тело ответа с данными нового пользователя.

Негативные тесты (различные некорректные данные):

1. Неверный тип данных для поля age:

{
  "username": "ivan_ivanov",
  "email": "ivan@example.com",
  "age": "двадцать пять" // строка вместо числа
}

Ожидаемый результат: HTTP статус 400 Bad Request с сообщением об ошибке валидации, например {"error": "Field 'age' must be an integer"}.

1. Отсутствие обязательного поля email:

{
  "username": "ivan_ivanov",
  "age": 25
}

Ожидаемый результат: 400 Bad Request с указанием на отсутствующее поле.

1. Попытка отправить пустой запрос:

{}

Ожидаемый результат: 400 Bad Request с перечнем всех обязательных полей.

1. Передача SQL-инъекции в поле username:

{
  "username": "admin' OR '1'='1",
  "email": "test@example.com",
  "age": 25
}

Ожидаемый результат: 400 Bad Request (без деталей в ошибке, чтобы не помогать злоумышленнику). Система должна безопасно отклонить такую попытку, а не выполнить инъекцию.

Важность в жизненном цикле разработки (SDLC)

Негативное тестирование — неотъемлемая часть тест-дизайна. Техники, такие как анализ граничных значений (Boundary Value Analysis) и классы эквивалентности (Equivalence Partitioning), активно используются для построения этих сценариев. Оно должно быть включено в тест-кейсы на всех уровнях: модульные тесты (Unit), интеграционные тесты (Integration) и, особенно, системные (E2E) и пользовательские (UAT) тесты.

Вывод: Нахождение и документирование негативных результатов — это не менее, а часто и более важная задача QA-инженера, чем подтверждение позитивных сценариев. Именно негативное тестирование в значительной степени формирует устойчивость, безопасность и надёжность конечного продукта в реальных, далёких от идеальных, условиях эксплуатации. Хорошо протестированная система должна быть «защищена от дурака» и злоумышленника, и негативное тестирование — главный инструмент для достижения этой цели.