Негативное тестирование. Что это такое и с чем его едят? Особенности применения невалидных проверок.

Негативное тестирование. Что это такое и с чем его едят? Особенности применения невалидных проверок.

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

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.4. Минималки и Атомарки

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

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

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

5.5. Таблицы принятия решений (Decision Tables)

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

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

5.6. Диаграммы состояний и переходов (State Transition Diagrams)

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

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

Заключение

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

Подписывайтесь на мой ТГ канал QA❤Life о тестировании, аналитике и UX\UI -дизайне для начинающих 🧑 и опытных 🧔 специалистов 👨‍👩‍👦‍👦 в указанных областях. Здесь регулярно публикуется 🗃 полезный контент (статьи, обучающие видео, новости, ИТ-юмор, опросы и обсуждения).

реклама
разместить
Начать дискуссию