Негативный сценарий тестирования это

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

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

Что такое негативное тестирование
Почему тестировщики его не любят
Техники негативного тестирования
Сценарии
Разница между позитивным и негативным тестированием
Преимущества и недостатки негативного тестирования

Итак, что такое негативное тестирование

Тестирование в целом — это проверка, работает ли софт должным образом, соответствует ли требованиям заказчика; как софт выдерживает челенджи и нестандартные ситуации.

Негативное тестирование олицетворяет “негативный подход” к тестированию. Его можно назвать “тестированием на сбой” или “тестированием на пути ошибок”. Его цель — найти негативные стороны приложения, путем написания специфического тест-кейса; другими словами, все крутится вокруг того как приложение реагирует на некорректные данные, и в таком подходе есть смысл, как будет видно далее.

Почему тестировщики не любят негативное тестирование

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

Некоторые тестировщики вообще смотрят на этот подход как на бесполезную трату времени и денег. И действуют только в рамках позитивного тестирования.

Недостаточность скиллов и знаний о преимуществах такого подхода мешает им применять его. А правда в том, что негативное тестирование, если хорошо организовано, ведет к высокому качеству софта, при малых усилиях. Такое тестирование по возможности должно внедряться в процессы в QA-отделе, потому что оно:

Повышает ответственность в команде

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

Клиенты довольны

Как ни банально звучит, негативное тестирование повысит конечное качество софта, что скажется на customer satisfaction. Особенно это будет заметно в кейсах онлайн-магазинов и вообще е-коммерции.

Негативное тестирование это вещь, в которую можно и нужно инвестировать, невзирая на возросшие расходы.

Техники негативного тестирования

Далее приведены техники, применяемые при негативном тестировании.

Анализ граничных значений

Метод подразумевает написание тест-кейсов в стандартном для тестировщиков виде: проверка значений, выходящих за пределы, например для поля со значениями от 1 до 100.

Разделения по классам эквивалентности

Метод проверки функциональности, путем группирования тестовых значений по нескольким “классам эквивалентности”.

Угадывание ошибок

В ходе процедуры тестировщик задает специальные условия, выдающие сообщения об ошибке. Если возможно, тестировщик пытается идентифицировать и исправить проблему не допуская падения приложения.

Чеклисты

Базовый, и все еще критически важный метод в QA, документирующий условия, в которых проводится тестирования. Обычно применяется в работе в команде.

Антипаттерны

Если есть паттерны дизайна, то могут быть и антипаттерны. Если паттерн — лучший способ решить проблему, то антипаттерн — решение которое точно не работает. Антипаттерны — идеальный источник негативных тестов.

Исследовательское тестирование

Метод, повышающий скиллы тестировщика, и его понимание приложения, в процессе работы. Применяется параллельно с другими тестами. Делает «общую картину» приложения яснее — в каких условиях приложение работает, в каких нет.

Небольшая автоматизация

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

Фаззинг-тестирование

Ввод случайных данных, которые могут вызвать неожиданные сбои, крэши системы, и другие ошибки. В этом методе нет “ожидаемых результатов” (в отличие от других негативных тест-кейсов). Грубо говоря, это просто наблюдение, а что случится, когда подаются какие-то произвольные данные.

Тестирование перехода состояний

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

Сценарии

Далее потенциальные ситуации, когда случаются (могут случиться) ошибки и крэши:

Сбор данных из обязательных полей

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

Несооответствие между типом данных и типом поля

Большинство форм и диалогов способны получать данные в определенной форме; самые частые это текст, число, дата и время. Пишется тест-кейс, в котором в поле вводятся данные другого типа, и проверяется реакция приложения.

Допустимые границы и лимиты

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

Разрешенное количество символов

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

Тестирование сессий

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

Специфические данные

Существуют приложения и страницы с полями ввода, принимающими данные со специфическими ограничениями. Негативный тест проверяет некорректные данные вне этих ограничений.

Разница между позитивным и негативным тестированием

“Позитивное тестирование должно проверить, что приложение нормально работает в нормальных условиях. Негативное — в ненормальных”.

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

Преимущества негативного тестирования

Проявляет некорректную обработку ошибок

Позволяет избежать сбоев, вызванных неправильной обработкой ошибок.

Идентифицирует слабые места в безопасности

Негативное тестирование позволяет гарантировать, что например клиент не получит персональный аккаунт в приложении с уровнем допуска, не предусмотренным его организацией.

Поддерживает «чистоту баз данных»

Базы данных будут в отличном состоянии, если в них только корректные данные. Негативное тестирование (почти) гарантирует, что там хранятся только корректные данные.

Недостатки

Негативное тестирование может занимать много времени, и бывает достаточно дорогим процессом.

Источник

Позитивное тестирование – это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана.

Примеры:

умножить на калькуляторе цифр 3 и 5,
в игре посадить морковь на грядку для овощей,
оплатить покупку действующей картой.

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

Пример:

умножить на калькуляторе числа 3 на грушу (значение «груша» не является валидным для калькулятора),
в игре посадить морковь на реку,
оплатить покупку несуществующей картой.

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

Реакция продукта на тесты

Какой результат мы ждем от позитивных и негативных тестов?

Позитивное тестирование должно нам всегда давать результат в виде отсутствия багов.

Негативные проверки могут дать 2 результата:
1. На данный ввод у продукта есть ответ в виде сообщения/контроля.
2. Система не знает, как реагировать на введенные данные.

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

Для чего важно различать?

Для чего нам различать негативное и позитивное тестирование? Чтобы верно расставлять приоритеты в тестировании в зависимости от ситуации.

Создание позитивных сценариев (тест-кейсов), как правило, предшествует созданию негативных.

Сначала мы проверяем работу системы, когда наш условный пользователь работает с системой «правильно». А уже потом приступаем к проверке отклика системы на пользователя, который допускает различные ошибки (ввод неверных данных, например). И наша система должна быть готова ответить на неверный запрос. Это и есть цель негативного тестирования.

Почему важно сначала провести позитивное тестирование? Большинство пользователей использует наш продукт так, как необходимо. То есть, если в поле ввода просят указать «Имя», то большинство пользователей напишут в него именно имя, а не набор цифр. Если мы не проверим верно ли распознаются корректные данные, то в случае ошибки большинство пользователей не смогут воспользоваться нашим продуктом.

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

Пример позитивных и негативных тестов

Давайте рассмотрим эти виды тестирования немного подробнее на примере формы авторизации на сайте.

^{Авторизация на сайте}

С помощью позитивных тестов мы проверим, что наша форма регистрации работает верно. Для этого проведем следующие тесты:

Авторизация с правильным логином и паролем

К негативным тестам можно отнести следующие сценарии:

Авторизация с неправильным логином
Авторизация с неправильным паролем
Авторизация с неправильным логином и паролем
Авторизация с пустым логином
Авторизация с пустым паролем
Авторизация с пустым логином и паролем

***

Повторюсь, при тестировании очень важно соблюдать приоритет.

________________________________

Сначала мы выполняем позитивные тесты, а потом негативные.

________________________________

Это связано с тем, что для продукта и пользователей важно, чтобы все фичи работали правильно, так как задумывались изначально.

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

Источник

#1

Oleeg

Новый участник

Members
15 сообщений

ФИО:Oleg Novikov

Отправлено 30 августа 2020 — 19:21

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

Позитивные тестовые сценарии

Ввести номер телефона. Нажать кнопку отправить. Все хорошо.

Ввести слишком длинный номер телефона.Нажать кнопку отправить. Ошибка(позитивный или негативный?)

Негативный тестовый сценарий.

Ввести спецсимволы. Нажать кнопку отправить. Ошибка

В позитивных тест кейсах, могут быть какие-либо сценарии при воспроизведении которых мы ожидаем статус ошибки.

Наверх

#2

Сергей

Отправлено 30 августа 2020 — 19:28

Ну а что определения говорят?

«Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество.» © Стив Джобс

Наверх

#3

Oleeg

Oleeg

Новый участник

Members
15 сообщений

ФИО:Oleg Novikov

Отправлено 30 августа 2020 — 20:04

Из того что я понял почитав определения. Тестовые сценарии деляться на черное и белое. Если нужно ввести 10-ть цифр — вводи десять, это позитивный сценарий, а если вводишь 9-ть — негативный сценарий.

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

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

Наверх

#4

Vasiliy

Vasiliy

ФИО:Касимов Василий
Город:Москва

Отправлено 31 августа 2020 — 07:13

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

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

Наверх

#5

astenix

Отправлено 31 августа 2020 — 17:34

Не совсем понимаю разницу между позитивными и негативными тестовыми сценариями.

При логине на этот форум вы
а) можете указать правильные логин/пароль,
б) можете указать неправильные логин/пароль или любую абракадабру, что одно и то же (вот вам и класс эквивалентности вводимых данных).

В обоих случаях у вас есть ожидаемый результат:
а) добро пожаловать,
б) не добро, но попытайтесь ещё раз.

И а), и б) — это позитивные сценарии, „happy path”. Вы точно знаете, что должно произойти, вы создаёте эти ситуации, и вы наблюдаете ожидаемый результат.

Ваш случай с телефоном сплошной позитив:

Ввести номер телефона. Нажать кнопку отправить. Все ОЖИДАЕМО хорошо. Позитив.
Ввести слишком длинный номер телефона. Нажать кнопку отправить. Ошибка, всё ОЖИДАЕМО нехорошо. Позитив.
Ввести дурацкие спецсимволы (к слову — как именно? Какой современный телефон позволяет в поле набора номера ввести что-то кроме цифр, «*», «#» и «+»? Ну, допустим…) Нажать кнопку отправить. Ошибка. ПРЕДСКАЗУЕМАЯ и ОЖИДАЕМАЯ. Сплошной позитив.

И пусть для первого сценария логина на форуме есть только один набор символов, а для второго сценария их «12345!»№;%йцукенqwerty67890» вариантов — у вас есть ожидаемый результат и система ведёт себя точно так, как это было [кем-то когда-то] предусмотрено. Три тысячи раз вводите абракадабру в поля ввода и каждый раз должен быть один ответ: «Логин или пароль неверны». Система не ломается, не отказывает вам в обслуживании, не умирает, а продолжает работать так, как задумано. Это позитивное тестирование.

Негативное тестирование — это поиск и создание ситуаций, при которых происходит отклонение от „happy path” и наблюдается непредусмотренный результат. Это отклонение от предусмотренных сценариев и поиск непредусмотренных.

Тут слово «негатив» не в смысле ПЛОХОЕ или ДАВАЙ ЛОМАЙ, а в смысле «противоположное позитивному», как в классической лёгонькой фотографической промышленности.

Каким может быть негативное тестирование для формы логина этого форума? «В лоб» — да особо ничего не сделать, разве что вводить sql-инъекции, но современные системы к таким штукам уже устойчивы, и чем менее самодельная система, тем меньше шансов её так просто разломать.

Раньше, когда ПО было более наколеннописанным, программист мог что-то завтыкать и не предусмотреть, что в поле ввода зарплаты бухгалтер может ввести что-то ещё кроме цифр — нарочно или случайно. Ну и всё на этом, такие значения невозможно суммировать, бо integer и string хоть и могут содержать цифры, но по сути они несовместимы. Надо сперва привести тип string к типу integer и ещё много всякого, а это целый список того, что надо сделать и проверить. Из древней древности на вас смотрят тени тестировщиков, которые положили свои жизни только на ввод абракадабры в поле логина… а сегодняшние фреймворки это всё обрабатывают заранее, и бухгалтер получит алерт об ошибке ввода задолго до того, как им будет нажата кнопка «Enter» — если ему вообще позволят эту кнопку нажать.

А давайте посмотрим, как этот форум вообще устроен. Неудачный логин выводит нас на страницу /forum/index.php?app=core&module=global&section=login&do=process — что это за модули вызываются? Что это за система вообще? ipboard? Какие у них есть уязвимости? Как до них можно добраться? Какие данные и условия передачи данных они обрабатывают, а какие нет? Берите лопату и начинайте копать в сторону — с голубого ручейка начинается река, и её можно перебить там, где ручей начинается, а не там, где река уже впадает в море.

Просто подумайте не о вводе значений, а о „happy path”, о сценарии, по которому что-то происходит. Бо если вы будете всегда привязываться к вводу данных, какие-то штуки останутся непротестированными.

Например, кнопка «Добавить товар в корзину» на любом сайте-магазине — вы ей никакие символы не передадите, однако она как раз запускает сценарий, при котором множество данных начинают свой путь откуда-то куда-то, и данные должны быть переданы без искажений. Негативное тестирование для этой кнопки — поиск ситуаций, при которых она может быть нажата, вплоть до ситуаций, когда она по каким-то причинам не может быть нажата (экран мелкий или js в браузере отключился) или данные передаются неверно.

Наверх

#6

Oleeg

Oleeg

Новый участник

Members
15 сообщений

ФИО:Oleg Novikov

Отправлено 01 сентября 2020 — 09:58

Спасибо за потраченное на меня время и столь развернутый ответ. Я его не просто прочитаю, я его законспектирую.

Наверх

Источник

Если вдруг вам лень читать, то у нас есть еще и видео на эту тему 🙂 https://youtu.be/JOCqwgRO_JQ

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

На практике же не существует проектов, в которых нужно тестировать со всех сторон единственное поле. Таких полей может быть тысячи и сроки дедлайна (в нашем мире, где они обычно обозначены как «вчера») порой не позволяют провести полностью даже позитивные проверки, не говоря о негативных.

Как быть? Какой приоритет должен быть у негативных проверок? А, может, не проверять негатив вообще? Как это часто бывает, универсального ответа нет, но я постараюсь рассказать о том, как тестирую сама. 🙂

Для начала давайте разберемся с терминами. Какие проверки называть позитивными, а какие негативными.

Общепринятое определение звучит так:

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

С тем, что мы подаем на вход системы, разобрались. Теперь нужно понять, какой результат ждем от выполнения проверок.

С позитивными кейсами ответ однозначный: ввели «хорошие» данные — получили результат “success”. А если вводим «плохие»? Здесь мы столкнулись с некоторой неоднозначностью. У негативных проверок может быть два результата:

на данный ввод у системы есть ответ в виде сообщения/контроля;
система не знает, как реагировать на введенные данные.

То есть у системы есть как минимум три реакции на наши действия по вводу данных:

Действие: создание сущности, переход на новый шаг и т.п.
Контроль: сообщение с контролем, блокировка дальнейших действий и т.п.
Отказ: возникает исключение Exception, 404-ой ошибки и т.п.

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

Теперь вернемся к тому вопросу, который был задан в самом начале: когда и какие негативные проверки стоит проводить?

Для себя я ввела некий условный «Жизненный цикл ПО в негативе». Его идея в том, что количество и тип негативных проверок будет зависеть от того, в какой стадии находится проект.

I этап.
NEWBORNПроект пока еще как младенец. ЦА вроде бы изучена, аналитики написали первые варианты Технических Заданий (ТЗ), разработчики уже сделали первый вариант продукта и позвали нас тестировать.

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

II этап.
TEENAGER

На проекте исправлены все «детские болячки», учтены замечания с предыдущего уровня. В ТЗ, при необходимости, добавлены новые контроли. Проект стал похож на тинейджера — почти взрослый, все знает и умеет, но жизненного опыта недостаточно, чтобы справиться с нестандартными ситуациями. На этом этапе более внимательно тестируем позитивные состояния, проводя сложные проверки и применяя различные техники тест-дизайна. При этом уделяем не меньшее внимание и условно-негативным проверкам, ведь наша задача — убедиться, что на каждое действие есть реакция из п.1 или п.2, то есть не возникает отказов.

III этап.
ADULT

Проект готов! Он перешел с тестового стенда на прод, стабильно работает и живет взрослой жизнью. Все ошибки давно исправлены, а узкие места известны. На этом этапе мы чаще всего проводим регрессионное тестирование, используя в основном позитивные проверки. Что касается негатива, то оптимальным для данного этапа будет проверка контролей (то есть условно-негативные кейсы) с помощью автотестов. Тем самым на этом этапе время, потраченное на ручное негативное тестирование, минимально и только в случае падения автотестов.

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

Конечно, на деле все не так просто, именно поэтому в начале статьи я сказала о том, что универсального правила когда, сколько и где проводить негативное тестирование — нет. Как нет однозначного ответа на вопрос, где заканчивается позитивное и начинается негативное тестирование, и что вообще понимать под этим процессом.

Например, куда отнести следующий кейс (все совпадения случайны и, наверняка, он был учтен “Амазоном”, но давайте пофантазируем): покупатель зашел в магазин Amazon Go за покупками, съел сэндвич на месте, вернул коробочку из-под него на место и вышел с пустыми руками, без оплаты покупки. С точки зрения линейного процесса и реализованного кода все отработало идеально. С точки зрения бизнес-процесса — это явный fail. Задумались? Куда бы вы отнесли данный кейс? Может, у вас есть свои примеры, доказывающие, что в этом мире нет ничего однозначно черного или белого? Поделитесь в комментариях 😉

Источник