Что такое позитивные и негативные тесты

Тестировщик «с нуля»

Страницы

1 апреля 2011 г.

“Негативное” и “позитивное” тестирование

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

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

Однако предшествовать “позитивному” и “негативному” тестированию должны работы по выполнению “дымового” тестирования.

Почему “позитивное” тестирование считается на порядок более важным, чем “негативное”?

Предположим, что система не слишком устойчива к “плохим” вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить “подводные камни”, не будут делать “опасные” или “неразрешенные” действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа “ни в коем случае не оставляйте это поле пустым, а то…”.

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

Именно поэтому “позитивное” тестирование гораздо, гораздо важнее “негативного”.

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И а), и б) — это позитивные сценарии, „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 в браузере отключился) или данные передаются неверно.

Источник

говориМ о тестировании
простым языком

Виды тестирования по позитивности сценария

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Стратегия тестирования REST API: что именно вам нужно тестировать?

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

Знаменитая пирамида тестов Майка Кона помещает тесты API на сервисный уровень (интеграционный), что предполагает, что около 20% или более всех наших тестов должны быть сосредоточены на уровне API (точный процент зависит от наших потребностей).

Пирамида тестов

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

Стратегия тестирования API

Основными задачами функционального тестирования API являются:

гарантировать, что реализация API работает в соответствии со спецификацией требований (которая позже становится нашей документацией по API).

предотвратить регрессий между написанным кодом(merge) и релизом.

эндпоинты правильно именованы;

ресурсы и их типы правильно отражают объектную модель;

нет отсутствующей или дублирующей функциональности;

отношения между ресурсами правильно отражаются в API.

Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. После публикации и использования API любые внесенные вами изменения могут внести ошибки в код клиента.(Конечно, когда-нибудь вы сможете опубликовать новую версию API (например, /api/v2 /), но даже в этом случае обратная совместимость скорее всего будет обязательной).

Итак, какие аспекты API мы должны протестировать?

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

Этапы тестирования API

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

Проверьте корректность кода состояния HTTP. Например, создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т. Д.

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

Проверьте заголовки ответа. Заголовки HTTP-сервера влияют как на безопасность, так и на производительность.

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

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

Категории тестовых сценариев

Наши тест-кейсы делятся на следующие общие группы тестовых сценариев:

Основные позитивные тесты (прохождение успешного сценария по умолчанию)

Расширенное позитивное тестирование с дополнительными параметрами

Негативное тестирование с валидными входными данными

Негативное тестирование с недопустимыми входными данными

Тесты безопасности, авторизации и доступности (которые выходят за рамки этой статьи)

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

Тестовые потоки

Давайте разделим и обозначим три вида потоков тестирования, которые составляют наш план тестирования:

Мы выполняем запросы через API и проверяем действия через пользовательский интерфейс веб-приложения и наоборот. Цель этих потоков проверки целостности состоит в том, чтобы гарантировать, что, хотя на ресурсы влияют различные механизмы, система по-прежнему поддерживает ожидаемую целостность и согласованный поток данных.

Пример API и тестовая матрица

Теперь мы можем отобразить все в виде матрицы и использовать ее для написания подробного плана тестирования (для автоматизации тестирования или ручных тестов).

Предположим, что подмножеством нашего API является конечная точка /users, которая включает следующие вызовы API:

Источник

Как писать тест-кейсы: полное руководство

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

Что такое тест-кейс и зачем он нужен

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

Тестировщик создает тест-кейс, чтобы проверить, работает ли определенная фича должным образом, и чтобы подтвердить, что функционал, UI/UX и другие параметры системы удовлетворяют всем соответствующим стандартам, руководствам и требованиям клиентов.

Чем отличаются тест-кейс и чеклист

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

Чеклист QA — это список того, что нужно протестировать. Благодаря ему процесс тестирования проходит более четко и аккуратно.

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

Позитивные, негативные и деструктивные тест-кейсы

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

В целом позитивное тестирование гарантирует, что система соответствует требованиям при позитивных сценариях нормального использования.

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

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

Если вернуться к нашему примеру, пользователь не должен иметь возможность создать пароль, состоящий из 11 символов.

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

Для деструктивного тестирования QA-специалисты могут применять следующие методы:

Атрибуты тест-кейса для ручного тестирования

Как и все тестировочные документы, тест-кейс имеет определенный формат. Он содержит следующие атрибуты:

Кроме того, для некоторых тест-кейсов могут потребоваться дополнительные атрибуты:

Характеристики хорошего тест-кейса

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

Короче говоря, хороший тест-кейс:

Best practices в написании тест-кейсов

Под best practices мы подразумеваем правила, которые помогают создавать простые, понятные и полезные тест-кейсы:

Формирование тест-кейсов

Обычно при написании тест-кейсов тестировщики пользуются таблицами Excel. Но вы также можете использовать инструменты управления тестированием, такие как TestRail.

Примеры тест-кейсов для ручного тестирования

Позитивный тест-кейс

Давайте попробуем создать наш собственный тест-кейс для ручного тестирования функции поиска на e-commerce сайте компании FootWear. Начнем с позитивного теста.

ID: FWSF-1. (Лучше использовать числа в возрастающем порядке. FWSF = FootWear Search Functionality. Попробуйте придумать комбинацию букв, имеющую отношение к проекту или функции, которую вы собираетесь тестировать).

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

Предусловия: Нужно иметь предварительно настроенные продукты из разных категорий, отображаемые на сайте. (Для проверки функциональности нам необходимо иметь элементы, доступные для поиска. Вы можете настроить это в панели администратора или в базе данных).

Шаги:

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

Деструктивный тест-кейс

Еще один пример — деструктивный тест-кейс.

ID: FWSF-2.

Заголовок: Проверить устойчивость поиска к SQL-инъекциям.

Предусловия: Подготовьте SQL-запрос, который вы собираетесь вставить в поиск.

Шаги:

Ожидаемый результат: Для защиты от SQL-инъекций отображение предупреждающих сообщений должно быть отключено.

Негативный тест-кейс

Наконец, вот вам негативный тест-кейс.

ID: FWSF-3.

Заголовок: Проверить ввод на недопустимые значения.

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

Шаги:

Ожидаемый результат: Отображается предупреждающее сообщение «Пожалуйста, используйте только допустимые символы». Поиск можно продолжить.

Итоги: тестирование тест-кейса

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

Источник