Привет, Хабр! На связи Евгений Гусинец - QA Engineer проекта "Бизнес-Инфо" г. Минск, Беларусь, автор ТГ-канала QA❤️Life. Являюсь также ментором на курсе "Инженер по тестированию" в SkyPro и вопросы, которые постоянно задают студенты обучаясь на курсе, побуждают писать развернутые ответы, которые затем могут перерастать в статьи. Именно так и получилось в этот раз.
Негативное тестирование, или тестирование на ошибочные случаи, является важной составляющей процесса обеспечения качества программного обеспечения. Оно направлено на проверку того, как система реагирует на некорректные, невалидные или неожиданные данные, что позволяет выявить уязвимости и улучшить надежность продукта. В отличие от позитивного тестирования, которое проверяет систему на корректное выполнение при правильных входных данных, негативное тестирование исследует сценарии, в которых пользователь или внешний фактор вводит данные, отклоняющиеся от нормы. Эта статья рассматривает ключевые аспекты негативного тестирования, его применение в различных типах тестирования, а также лучшие практики для эффективного использования данного подхода.
1. Цели и задачи негативного тестирования
Главная цель негативного тестирования — убедиться, что система правильно обрабатывает некорректные данные и сохраняет свою стабильность при любых вводных. Это помогает предотвратить потенциальные ошибки, которые могут возникнуть в реальных условиях эксплуатации, где пользователи могут допускать ошибки или вводить данные, которые не соответствуют ожиданиям системы.
Негативное тестирование позволяет:
Проверить, что система корректно сообщает об ошибках при вводе некорректных данных.
Оценить устойчивость системы при экстремальных условиях или непредсказуемом поведении.
Обнаружить уязвимости, которые могут привести к сбоям или критическим ошибкам.
2. Где и когда применять негативное тестирование?
Несмотря на важность негативного тестирования, его применение не всегда уместно в каждом виде тестирования. Основные типы тестирования, где негативные проверки активно используются, включают:
Функциональное тестирование. Здесь негативное тестирование играет ключевую роль, проверяя, как система реагирует на невалидные данные в каждом отдельном компоненте или функции.
Системное тестирование. На уровне системы проверяется, как различные компоненты взаимодействуют при вводе некорректных данных.
Тестирование безопасности. Включает проверки на устойчивость к атакам, таким как SQL-инъекции, XSS и другие виды злоупотреблений, которые можно классифицировать как негативное тестирование.
3. Когда негативное тестирование не применяется?
Существуют виды тестирования, где негативные проверки не применяются или являются менее значимыми:
3.1. Позитивное тестирование (Positive Testing)
Суть. В позитивном тестировании тестировщики проверяют, что система работает как ожидается при использовании корректных, валидных данных. Негативные сценарии, включающие невалидные проверки, здесь не рассматриваются.
Пример. Проверка того, что пользователь может успешно войти в систему при введении правильного логина и пароля.
3.2. Тестирование производительности (Performance Testing)
Суть. Это тестирование направлено на оценку скорости, стабильности и масштабируемости системы. Оно фокусируется на измерении производительности при корректных данных, поэтому негативные проверки, такие как ввод невалидных данных, обычно не выполняются.
Пример. Тестирование времени отклика системы при нормальной или повышенной нагрузке.
3.3. Нагрузочное тестирование (Load Testing)
Цель. Цель нагрузочного тестирования — проверить, как система справляется с определенной нагрузкой (например, количеством пользователей или запросов). Проверка на невалидные данные здесь не производится, так как внимание уделяется устойчивости системы при увеличении нагрузки.
Пример. Проверка работы веб-приложения при одновременном посещении сайта 10 000 пользователей.
3.4. Стресс-тестирование (Stress Testing)
Суть. Стресс-тестирование оценивает работу системы при условиях, выходящих за пределы нормальной эксплуатации (например, чрезвычайно высокая нагрузка или недостаток ресурсов). Негативные проверки здесь неактуальны, так как основная цель — проверить устойчивость системы в условиях экстремальных нагрузок.
Пример. Проверка работы системы при отключении части серверов или резком увеличении числа транзакций.
Стресс-тестирование и его "негативность"
Стресс-тестирование — это процесс проверки того, как система справляется с экстремальными условиями, такими как сверхвысокая нагрузка, нехватка ресурсов (например, памяти или процессорного времени), или сбои в сети. Цель стресс-тестирования — определить пределы устойчивости системы и выяснить, как она будет вести себя, когда эти пределы превышаются.
Негативный аспект стресс-тестирования заключается в том, что оно специально направлено на создание условий, которые система не должна испытывать при нормальной эксплуатации. Например, стресс-тестирование может включать:
Резкое увеличение количества пользователей или запросов к системе.
Преднамеренное отключение части серверов или других ключевых компонентов.
Введение задержек или перебоев в сети.
Создание условий, при которых ресурсы системы (память, процессорное время) становятся недоступными.
Отличие от классического негативного тестирования
Классическое негативное тестирование, о котором мы говорили ранее, сосредоточено на проверке того, как система обрабатывает некорректные, невалидные или неожиданные входные данные. Примеры таких негативных проверок включают ввод неправильного формата данных, пустых значений, или недопустимых комбинаций параметров.
Различие состоит в том, что в стресс-тестировании фокус не на проверке корректности работы системы при некорректных входных данных, а на проверке ее устойчивости и производительности в условиях экстремальной эксплуатации. Стресс-тестирование проверяет, как система справляется с перегрузками, а не с некорректными данными.
Таким образом, хотя стресс-тестирование действительно носит негативный и деструктивный характер, оно не связано с тем типом негативных проверок, которые направлены на выявление ошибок в обработке невалидных данных. Стресс-тестирование проверяет систему на прочность в экстремальных условиях, а не на правильность обработки некорректных входных данных.
3.5. Тестирование юзабилити (Usability Testing)
Суть. Тестирование юзабилити направлено на оценку удобства использования системы с точки зрения конечного пользователя. Здесь тестировщики оценивают, насколько интуитивно понятен интерфейс и удобно ли работать с системой. Негативные проверки на невалидные данные не проводятся, так как тестирование фокусируется на пользовательском опыте.
Пример. Оценка удобства навигации по сайту и интуитивности использования интерфейса.
3.6. Тестирование совместимости (Compatibility Testing)
Суть. В этом виде тестирования проверяют, насколько корректно система работает на различных платформах, браузерах, устройствах и операционных системах. Негативные проверки здесь не применяются, поскольку основное внимание уделяется корректности работы системы в разных средах.
Пример. Проверка работы веб-приложения на различных версиях браузеров (Chrome, Firefox, Safari).
3.7. Регрессионное тестирование (Regression Testing)
Цель. Цель регрессионного тестирования — убедиться, что изменения в коде не вызвали новых ошибок в ранее работавшем функционале. Обычно здесь проводят проверку на валидные данные, чтобы удостовериться, что система работает как прежде. Негативные проверки могут быть частью регрессионного тестирования, но часто ограничиваются позитивными сценариями.
Пример. Повторное выполнение успешных тестов после внесения изменений в код.
3.8. Инсталляционное тестирование (Installation Testing)
Суть. Этот вид тестирования проверяет, насколько корректно система устанавливается и настраивается в различных средах.
Основное внимание уделяется успешной установке и корректной работе системы после установки. Негативные проверки здесь не проводятся.
Пример. Проверка корректности установки приложения на различных версиях операционных систем.
3.9. Приемочное тестирование (Acceptance Testing)
Цель. Приемочное тестирование направлено на подтверждение того, что система соответствует требованиям заказчика и готова к выпуску в эксплуатацию. Оно обычно ориентировано на проверку основных бизнес-сценариев и функциональности, требуемой заказчиком.
Негативные проверки. В большинстве случаев приемочное тестирование фокусируется на позитивных сценариях, то есть на проверке того, что система правильно работает при корректных данных и нормальных условиях использования. Негативные проверки, такие как проверка на невалидные данные, обычно не являются приоритетом в рамках приемочного тестирования, так как его цель — продемонстрировать, что система выполняет то, что от нее ожидается.
Пример. Проверка того, что пользователь может успешно зарегистрироваться и выполнить основные действия в системе, такие как создание заказа или загрузка документов.
3.10. End-to-End (E2E) тестирование
Цель. E2E тестирование направлено на проверку всей цепочки взаимодействий в системе, начиная с пользовательского интерфейса и заканчивая интеграцией с другими системами. Целью является подтверждение того, что все компоненты системы работают вместе в соответствии с требованиями.
Негативные проверки. В E2E тестировании основной упор делается на проверку корректности работы всех бизнес-процессов от начала до конца. В рамках E2E тестов обычно тестируются позитивные сценарии, и реже включаются проверки на невалидные данные, так как цель — подтвердить, что все элементы системы правильно интегрированы и работают вместе.
Пример. Полный сценарий заказа товара в интернет-магазине: от поиска продукта до его оплаты и получения подтверждения.
4. Существующие ограничения на использование негативных проверок
Вопрос о количестве невалидных проверок на одно тестируемое поле — это часто предмет дискуссий в различных командах. Обычно, количество таких проверок зависит от нескольких факторов, включая риск, критичность функционала, сложность системы, требования к качеству и время на тестирование. Вот несколько общих рекомендаций и подходов, которые применяются в разных командах:
4.1. Стандартные Подходы
Минимальное покрытие. Обычно в стандартных случаях на одно поле добавляют от 3 до 5 невалидных проверок. Это включает:Пустое значение (например, отправка формы без заполнения поля).Значение, которое превышает допустимый лимит (например, слишком длинный текст или слишком большое число).Недопустимый тип данных (например, текст в числовом поле).Специальные символы (если они не поддерживаются).Значения за пределами допустимого диапазона (если есть ограничения по диапазону).
Максимальное покрытие. В случае критичных полей (например, поля ввода пароля, номера кредитной карты и т.д.), количество проверок может увеличиваться до 7-10 или даже больше, включив дополнительные проверки, такие как SQL-инъекции, скрипты, и т.д.
4.2. Ограничения в Командах
Команды с ограниченным временем. В командах, где время на тестирование ограничено, могут применять подходы, такие как "самые важные проверки". Например, на каждое поле проверяются только 2-3 наиболее критичные невалидные проверки.
Приоритизация. Некоторые команды используют приоритизацию, определяя, какие невалидные проверки наиболее важны, и выполняют их в первую очередь. Остальные тесты могут быть отложены или выполнены позже.
Риск-ориентированное тестирование. В случае риск-ориентированного подхода команда может ограничиться только теми проверками, которые связаны с наибольшими рисками для бизнеса.
4.3. Политика и процедуры
Документированные стандарты. Некоторые команды имеют документированные стандарты, в которых указано, сколько невалидных проверок должно быть для каждого типа поля. Например, для всех текстовых полей могут требовать как минимум 3 проверки (пустое значение, слишком длинное значение, и недопустимые символы).
Анализ и отзыв. Команды могут проводить регулярные ревью тестов, где обсуждаются и пересматриваются проверки на предмет необходимости и достаточности.
4.4. Инструменты и Автоматизация
Автоматизированное тестирование. В случае автоматизированного тестирования возможно увеличение количества невалидных проверок, поскольку такие тесты легче поддерживать и выполнять. Автоматизация позволяет проверять более широкий спектр невалидных сценариев, не увеличивая существенно трудозатраты.
4.5. Практики других команд
В больших компаниях. В крупных компаниях или проектах с высоким уровнем критичности количество невалидных проверок может быть выше, с обязательным покрытием всех возможных сценариев. Также могут существовать формальные ограничения и процедуры для каждой категории тестов.
В стартапах или небольших командах. Здесь могут стремиться к минимальному необходимому набору проверок, чтобы быстрее выводить продукт на рынок, с последующим добавлением тестов по мере роста продукта.
5. Негативные проверки и методы комбинаторики
Негативное тестирование и невалидные проверки могут быть полезны в некоторых методах комбинаторики, используемых в тестировании программного обеспечения. Важно понимать, что такие методы помогают выявить возможные дефекты в системе, когда она сталкивается с некорректными или неожиданными входными данными.
Вот несколько методов комбинаторики, в которых уместно использовать негативное тестирование:
5.1. Тестирование с использованием метода граничных значений (Boundary Value Testing)
Описание метода. Этот метод включает проверку крайних значений, которые находятся на границах допустимого диапазона для каждого входного параметра. Границы — это точки, где часто возникают ошибки.
Почему уместно использовать негативное тестирование. Негативные проверки в этом методе включают тестирование значений, которые находятся за пределами допустимого диапазона. Например, если допустимый диапазон значений для входного параметра от 1 до 100, нужно протестировать значения 0 и 101, чтобы убедиться, что система корректно обрабатывает невалидные данные.
Пример. Если тестируется поле для ввода возраста, которое принимает значения от 1 до 120, негативные проверки могут включать ввод -1, 0, 121, или 200, чтобы убедиться, что система правильно обрабатывает некорректные данные.
5.2. Тестирование классов эквивалентности (Equivalence Partitioning)
Описание метода. В этом методе вводные данные делятся на группы (классы эквивалентности), и предполагается, что все значения внутри одного класса обрабатываются системой одинаково.
Почему уместно использовать негативное тестирование. В каждом классе эквивалентности могут существовать как валидные, так и невалидные подгруппы данных. Негативное тестирование направлено на проверку тех подгрупп, которые выходят за пределы допустимого диапазона или содержат недопустимые данные.
Пример. Если система ожидает, что в поле для номера телефона будут вводиться только цифры, то тесты должны включать ввод букв или специальных символов (например, «abc» или «#%&») в качестве невалидных данных.
5.3. Метод попарного тестирования (Pairwise Testing)
Описание метода. Этот метод направлен на тестирование всех возможных комбинаций пар параметров, что помогает минимизировать количество тестов, сохраняя при этом достаточное покрытие.
Почему уместно использовать негативное тестирование. В процессе попарного тестирования могут быть созданы комбинации, которые включают невалидные или нежелательные значения для одного из параметров. Это позволяет выявить ошибки, возникающие в результате некорректного взаимодействия параметров.
Пример. Предположим, система имеет два входных поля: возраст и доход. Негативное тестирование может включать комбинации, где возраст имеет отрицательное значение, а доход превышает допустимый предел, чтобы проверить, как система справляется с невалидными комбинациями.
5.3.1 Дискуссионный характер применения негативных проверок в попарном тестировании
Среди тестировщиков существует дискуссия относительно уместности применения негативных проверок в попарном тестировании. Основные аргументы против такого подхода сводятся к следующим пунктам:Цель попарного тестирования. Попарное тестирование изначально ориентировано на проверку всех возможных пар параметров при валидных данных. Это означает, что фокус делается на минимальном наборе тестов, необходимых для покрытия всех комбинаций параметров. Включение негативных проверок в попарное тестирование может привести к значительному увеличению числа тестов, что противоречит самой цели метода — минимизации количества тестов.
Комплексность и избыточность. Поскольку попарное тестирование предназначено для работы с минимальным количеством тестов, добавление негативных проверок может существенно усложнить тестирование. Это может привести к проверке большого количества сценариев, которые маловероятны в реальных условиях эксплуатации, что снизит эффективность метода.
5.3.1.1 Аргументы в пользу использования негативных проверок в попарном тестировании
Несмотря на эти аргументы, существуют ситуации, в которых использование негативных проверок в попарном тестировании может быть оправдано:Идентификация критических ошибок на ранних стадиях. В некоторых системах взаимодействие между параметрами может привести к критическим ошибкам, если данные не валидны. В таких случаях добавление негативных проверок в попарное тестирование может помочь обнаружить дефекты, которые иначе могли бы остаться незамеченными. Например, комбинация двух параметров, где один принимает недопустимое значение, может привести к сбою системы.
Пример. В интернет-магазине есть два параметра: способ оплаты и тип товара. Негативное тестирование может включать проверку, что при выборе недопустимого способа оплаты для определенного типа товара система корректно сообщает об ошибке.
Проверка устойчивости системы. Для критически важных систем, где сбои могут иметь серьезные последствия (например, медицинское оборудование, финансовые системы), проверка взаимодействия параметров с невалидными данными может быть необходима для подтверждения устойчивости системы. В таких случаях негативные проверки помогают убедиться, что система справляется с некорректными данными даже в самых сложных комбинациях.
Пример. В системе управления медицинским оборудованием проверка на взаимодействие параметров (например, дозировка и возраст пациента) с невалидными данными может быть жизненно важной, чтобы убедиться, что система не совершит критическую ошибку.
Усиление надежности:
Негативные проверки в попарном тестировании позволяют удостовериться, что система не только корректно обрабатывает валидные данные, но и устойчиво справляется с невалидными комбинациями параметров. Это особенно важно для систем с высоким уровнем критичности, где ошибки могут привести к значительным последствиям.
Пример 1. В банковской системе комбинация невалидного кода валюты и граничного значения суммы транзакции может вызвать ошибки, которые важно обнаружить на этапе тестирования.
Пример 2. В системе управления медицинским оборудованием проверка на взаимодействие параметров (например, дозировка и возраст пациента) с невалидными данными может быть жизненно важной, чтобы убедиться, что система не совершит критическую ошибку.
Покрытие редких сценариев:
Попарное тестирование может выявить дефекты, которые проявляются только при определенных сочетаниях параметров. Включение негативных проверок в такие комбинации позволяет выявить ошибки, которые могли бы оставаться незамеченными при тестировании только валидных данных.
Пример: В системе бронирования авиабилетов могут быть проверены комбинации, где один параметр (класс обслуживания) содержит недопустимое значение, а другой (количество пассажиров) находится на граничном значении. Негативная проверка может выявить сбои в обработке таких сценариев.
5.3.1.2 Аргументы против использования негативных проверок в попарном тестировании
Увеличение объема тестирования
Включение негативных проверок может значительно увеличить количество необходимых тестов, что противоречит основной цели попарного тестирования — минимизации числа тестов при сохранении покрытия.
Контраргумент. Однако это увеличение объема тестирования можно сбалансировать за счет разумного выбора параметров и приоритетов тестирования.
Фокус на валидных данных:
Попарное тестирование традиционно используется для проверки валидных комбинаций параметров, а негативные проверки можно рассматривать как отдельную задачу.
Контраргумент. Тем не менее, интеграция негативных тестов в попарное тестирование позволяет выявить дефекты, которые могут возникнуть при неявных сочетаниях параметров.
Сложность анализа результатов:
Включение негативных проверок может усложнить анализ результатов тестирования, особенно если система имеет сложные зависимости между параметрами.
Контраргумент. Четкая структура тестов и продуманная стратегия анализа могут помочь избежать этой проблемы, обеспечив более полное понимание поведения системы.
Использование негативных проверок в попарном тестировании — это не однозначный вопрос, и решение об их включении зависит от конкретных целей и контекста тестирования. В случаях, когда критичность системы требует тщательной проверки всех возможных сценариев, включая негативные, применение негативных проверок в попарном тестировании может быть оправдано и полезно.
В то же время, если цель попарного тестирования заключается в минимизации тестов и быстром покрытии основных взаимодействий параметров, негативные проверки могут быть вынесены в отдельный этап тестирования. В конечном итоге, подход к использованию негативных проверок в попарном тестировании должен быть сбалансированным и учитывать специфические требования проекта, а также ресурсы и время, доступные для тестирования.
5.4. Минималки и Атомарки
Минималки. Это минимальные тесты, которые покрывают наиболее важные и критичные случаи использования функционала системы. В минималках могут применяться негативные проверки, если они относятся к критически важным аспектам системы. Например, проверка обязательных полей формы может включать тест на их незаполнение.
Атомарки. Атомарные тесты — это более детализированные тесты, которые проверяют конкретные элементы или небольшие участки функционала. В атомарках обычно уделяется больше внимания как позитивным, так и негативным сценариям, включая тестирование на невалидные данные, такие как ввод некорректных значений в поля ввода.
Применение негативных проверок: в обоих случаях негативные проверки уместны, когда важно удостовериться, что система правильно обрабатывает ошибки на базовом уровне.Пример: в атомарке для текстового поля, куда должен вводиться номер телефона, может быть проверка на ввод букв вместо цифр, что является негативным сценарием.
5.5. Таблицы принятия решений (Decision Tables)
Описание метода. Таблицы принятия решений представляют собой способ систематизации и проверки множества правил и их последствий. Они особенно полезны, когда система имеет сложную логику с множеством условий.Применение негативных проверок: В таблицах принятия решений негативные проверки могут включаться для того, чтобы проверить поведение системы при несоответствии входных данных правилам или при введении невалидных данных.
Пример. Если в таблице принятия решений есть правило, которое определяет скидку на товар в зависимости от суммы заказа и наличия промокода, негативные проверки могут включать ввод некорректного промокода или суммы, не попадающей в диапазон, для проверки правильности обработки таких случаев.
5.6. Диаграммы состояний и переходов (State Transition Diagrams)
Описание метода. Диаграммы состояний и переходов используются для моделирования поведения системы при переходе из одного состояния в другое в зависимости от вводимых событий или данных.Применение негативных проверок: Негативные проверки в этом методе заключаются в проверке недопустимых переходов между состояниями или неправильного реагирования системы на определенные события.
Пример. В приложении для бронирования отелей, где пользователь должен сначала выбрать даты, а затем подтвердить бронь, негативная проверка может включать попытку подтвердить бронь без выбора дат, чтобы убедиться, что система корректно обрабатывает этот случай.
Заключение
Негативное тестирование в контексте комбинаторных методов тестирования помогает выявить дефекты, которые могут возникнуть при вводе некорректных данных. Это особенно важно для обеспечения устойчивости и надежности системы, так как помогает предотвратить сбои и ошибки, вызванные неожиданными вводными данными или их комбинациями. Использование таких методов комбинаторики с включением негативных тестов позволяет обеспечить более полное и качественное тестирование, что является залогом стабильной работы программного обеспечения в реальных условиях эксплуатации.
