Комментарии 7
Спасибо за статью. Очень познавательно.
Всегда задумывался о том, почему негативное тестирование, это негативное тестирование.
Мы же предполагаем, что юзер может войти в систему с валидными credentials.
НО так же мы предлагаем, что юзер не может войти в систему в плохими credentials.
Так вот почему в первом случае у нас позитивное тестирование, а во втором примере негативное?
Мы же заранее знаем, что юзер не должен войти.
Или же, мы знаем, что если пошлем не валидный userId, то бэкенд вернёт 404 или 400 или 204 или 422 (в зависимости от реализации), то почему этот тест негативный?
Негативное тестирование в моем понимании, это когда ты посылаешь валидные/не валидные данные и сервис ведёт себя совсем не так, как задумывалось
Добрый день, Антон! Благодарю за интересный комментарий.
Ваш вопрос поднимает интересную точку зрения о терминах "негативное" и "позитивное" тестирование. Давайте разберем эти концепции и постараемся внести ясность в то, почему тестирование с использованием некорректных данных называется "негативным", несмотря на предсказуемость результата.
Позитивное и негативное тестирование: разница в подходах
Позитивное тестирование направлено на проверку того, что система работает правильно при вводе корректных данных и в нормальных условиях.
Цель позитивного тестирования — убедиться, что система выполняет свои функции так, как ожидается. Например, если пользователь вводит правильные учетные данные, система должна успешно аутентифицировать пользователя и предоставить доступ.
Негативное тестирование, с другой стороны, направлено на проверку того, как система обрабатывает некорректные, неожиданные или невалидные данные.
Цель негативного тестирования — убедиться, что система правильно реагирует на ошибки, невалидные данные или некорректные действия. Например, если пользователь вводит неправильные учетные данные, система должна предотвратить вход и выдать соответствующее сообщение об ошибке.
Почему тесты на некорректные данные считаются негативными?
Когда мы говорим о "негативном тестировании", термин "негативный" не обязательно означает, что результат теста непредсказуем или нежелателен. Скорее, это относится к самой природе входных данных или действий, которые считаются некорректными или выходящими за рамки нормального использования системы. В этом контексте:
Позитивное тестирование проверяет, что система работает правильно, когда все данные и действия корректны.
Негативное тестирование проверяет, что система правильно обрабатывает ошибки и отклонения, когда данные или действия некорректны.
Примеры для лучшего понимания
Позитивный тест: Пользователь вводит правильный логин и пароль. Мы ожидаем, что система предоставит доступ. Это позитивный тест, так как данные корректны, и мы проверяем, что система выполняет свою основную функцию.
Негативный тест: Пользователь вводит неправильный пароль. Мы ожидаем, что система откажет в доступе и выведет сообщение об ошибке. Это негативный тест, так как мы проверяем поведение системы при некорректных данных.
Почему тесты на предсказуемое поведение системы при некорректных данных все равно негативные?
Даже если мы точно знаем, что система должна вернуть определенный код ошибки (например, 404 или 400), когда ей передаются невалидные данные, такой тест все равно считается негативным. Это связано с тем, что основной акцент в этом тесте делается на том, как система справляется с ненормальными, некорректными или ошибочными вводами, а не с тем, выполняет ли она свои функции при корректных условиях.
Если мой endpoint должен принимать int только и я пишу обработчик, который приводит пришедшее значение к int и если это не int то мы выдаём ошибку, а если int - идём дальше - с моей стороны в обоих случаях у нас валидные данные.
Вы же ожидаете, что придет или то или то? Ожидаете :) А если ожидаете, значит данные валидные. Но если вы не обрабатывает ошибки или допустим у вас пришёл отрицательный int, а всегда должны быть положительные и вы это нигде в коде не предусматриваете - то тут уже негативный кейс.
В общем мое видение этой "проблемы": все то, что не предусмотрено в коде - негативные кейсы
Антон, спасибо за дополнение — это действительно интересное мнение!
Вы правы в том, что граница между валидными и невалидными данными часто зависит от контекста и того, как именно система обрабатывает входные данные. Если мы заранее ожидаем, что данные могут быть как корректными (например, int), так и некорректными (например, не int), и у нас есть соответствующая логика обработки, то можно сказать, что с точки зрения системы такие данные ожидаемы и могут считаться "валидными" в широком смысле.
Тем не менее, концепция негативного тестирования основывается не столько на том, что данные предсказуемы или ожидаемы, сколько на том, что они выходят за пределы нормального сценария использования системы. Например, если API ожидает положительные int, но получает отрицательные значения, и если это не предусмотрено в коде (нет проверки или обработки), это действительно может считаться негативным кейсом.
В итоге, негативные кейсы — это те, которые проверяют систему на устойчивость к непредусмотренным или некорректным вводам, даже если они потенциально "валидны" с точки зрения типа данных. Если система сталкивается с такими данными и не обрабатывает их должным образом, то это сигнал о возможной уязвимости или недоработке.
Ваш подход, где негативные кейсы — это все, что не предусмотрено в коде, тоже имеет право на жизнь, так как он фокусируется на обнаружении проблемных мест, которые могут быть упущены при разработке. И это как раз то, что делает негативное тестирование столь важным в общем процессе обеспечения качества ПО.
Антон, спасибо за дополнение — это действительно интересное мнение!
Вы правы в том, что граница между валидными и невалидными данными часто зависит от контекста и того, как именно система обрабатывает входные данные. Если мы заранее ожидаем, что данные могут быть как корректными (например, int), так и некорректными (например, не int), и у нас есть соответствующая логика обработки, то можно сказать, что с точки зрения системы такие данные ожидаемы и могут считаться "валидными" в широком смысле.
Тем не менее, концепция негативного тестирования основывается не столько на том, что данные предсказуемы или ожидаемы, сколько на том, что они выходят за пределы нормального сценария использования системы. Например, если API ожидает положительные int, но получает отрицательные значения, и если это не предусмотрено в коде (нет проверки или обработки), это действительно может считаться негативным кейсом.
В итоге, негативные кейсы — это те, которые проверяют систему на устойчивость к непредусмотренным или некорректным вводам, даже если они потенциально "валидны" с точки зрения типа данных. Если система сталкивается с такими данными и не обрабатывает их должным образом, то это сигнал о возможной уязвимости или недоработке.
Ваш подход, где негативные кейсы — это все, что не предусмотрено в коде, тоже имеет право на жизнь, так как он фокусируется на обнаружении проблемных мест, которые могут быть упущены при разработке. И это как раз то, что делает негативное тестирование столь важным в общем процессе обеспечения качества ПО.
Негативное тестирование. Что это такое и с чем его «едят»? Особенности применения невалидных проверок