Что такое позитивное тестирование
Что такое позитивное тестирование
Мы (не такой уж это и секрет) очень переживаем за качество своих продуктов и с трепетом наблюдаем за обваливанием системы. Это оправдывает существование тестировщиков в мире. Это заставляет нас чувствовать себя героями: пришёл великий Тестер и спас своих пользователей от ужасных критических багов!
И наши тестировщики никогда не забывают про негативное тестирование, хотя не всех прогеров это радует. Но такие проверки не прихоть «злых тестеров», они вызваны необходимостью закрыть уязвимости и обезопаситься от проникновения в систему хакеров и ботов, Dos/DDos атак.
Конечно, ведь в чём состоит призвание тест-специалистов? Нужно найти проблемы. Проблемы, о которых никто чаще всего не успевает подумать, не хочет их видеть и иметь с ними дело. А уж если проверяется не только правильная работа системы, но и её ненормальное поведение, то напряжённости в команде добавляется.
Понимаете, программисты-то пишут софт, нацеливаясь на результат, на запланированный релиз, летят на крыльях вдохновения! А тут наступает этап проверки и многочисленных исправлений и правок «идеального» кода. И всё, прячься кто куда, система на тестировании.
Чтобы никого не нервировать, некоторые специалисты могут откладывать негативное тестирование на потом или вообще игнорировать его (ужас!) в угоду сокращения сроков и бюджета. Ну а чего проверять, если прога не делает даже того, что должна, правда? Не-а.
Позитивное и негативное тестирование
Но обо всём по порядку. При тестировании ПО с помощью тест-кейсов, существует два набора проверок: позитивные и негативные. Причем вторых обычно больше, чем первых.
Позитивное тестирование — это проверка работы системы на соответствие её нормальному (штатному, ожидаемому) поведению, согласно ТЗ и документациям. То есть здесь мы смотрим, делает ли ПО то, чего от него ждут, соответствует ли реализация современным требованиям, поддержаны ли гайдлайны пользовательского интерфейса и т.д.
А негативное тестирование — это тестирование системы на нештатное поведение. Смотрим, устойчиво ли ПО к неверному вводу данных, как обрабатываются исключительные ситуации, какая информация показывается в сообщениях об ошибках, возможно ли нарушить функционирование продукта и/или повлиять на производительность решения и так далее.
Мы уже сказали, что некоторые специалисты оставляют негативное тестирование на потом или вообще про него забывают, что почти одно и то же. Сами знаете, отложенное на потом почти всегда остается не выполненным.
Поэтому, по нашему мнению,
Негативное и позитивное тестирование вообще не нужно разделять и разносить во времени.
Поскольку можем ли мы сказать, что система работает как надо, если проверяем её реакцию только на правильных входных данных?
Позитивно-негативное тестирование
При тестировании ой как важны интуиция, чуйка, охотничьи инстинкты – зовите, как хотите. И вот сидит такой наш инженер, проверяет форму регистрации, допустим.
Проверяет всё по ТЗ и тестовым сценариям, смотрит, как данные обрабатываются, которые юзер должен ввести в поля (не факт, что введёт, кстати) и тут вот оно – озарение! Ему кажется, что если ввести вот в это поле для login какой-нибудь «%адынадын/>», а не обычный текст, то что-то точно произойдёт. Что-то тёмное и мрачное неправильное.
И что? Он должен сказать себе: «Нет. Сейчас я должен заниматься позитивным тестированием и ничем другим. Вот у меня назначено негативное на следующей неделе, тогда и настанет время для %адынадын/>. Наверное»?
Мы считаем такой подход к негативному тестированию неэффективным, и вот почему:
Мы, как тестировщики, очень переживаем, если система содержит ошибки по проверкам из категории негативных. И особенно, если последствия таких ошибок критичны для всей системы. Но репортить их не боимся. Особенно с таким козырем в рукаве – у нас в команде есть девочки-тестировщицы. И кто сможет упорно отстаивать «идеальность» кода, когда они нежными голосками в пух и прах разносят работоспособность проекта? То-то же.
Так какие выводы мы можем сделать?
Не забывайте про негативное тестирование, объедините его с позитивным, соберите в команде опытных специалистов и старайтесь перекладывать задачу репортинга на плечи девочек! Всё, кроме последнего, советуем на 100%, а уж с этим разберётся ваш проект-менеджер.
И, конечно, обязательно проверяйте свой продукт, не думайте, что программисты сразу напишут код чисто и красиво – без багов всё равно не обойдётесь! Не говоря уже о многочисленных уязвимостях, что подтверждают регулярно утекающие в сеть персональные и конфиденциальные данные.
Тестировщик «с нуля»
Страницы
1 апреля 2011 г.
“Негативное” и “позитивное” тестирование
“Позитивное” тестирование – это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы.
Основной целью “позитивного” тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.
“Негативное” тестирование – это тестирование на данных или сценариях, которые соответствуют нештатному поведению тестируемой системы – различные сообщения об ошибках, исключительные ситуации, “запредельные” состояния и т.п.
Основной целью “негативного” тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных, проверка обработки исключительных ситуаций (как в реализации самих программных алгоритмов, так и в логике бизнес-правил).
Однако предшествовать “позитивному” и “негативному” тестированию должны работы по выполнению “дымового” тестирования.
Почему “позитивное” тестирование считается на порядок более важным, чем “негативное”?
Предположим, что система не слишком устойчива к “плохим” вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить “подводные камни”, не будут делать “опасные” или “неразрешенные” действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа “ни в коем случае не оставляйте это поле пустым, а то…”.
НО – всего этого не будет вовсе, если система не выполняет свое основное предназначение, если пользователи (заказчики) не могут решить свои бизнес задачи, если они все делают правильно, вводят хорошие данные, но не получают результата. И посоветовать им ничего в этой ситуации нельзя.
Именно поэтому “позитивное” тестирование гораздо, гораздо важнее “негативного”.
Ошибки в нормальном поведении, мешающие пользователям выполнять бизнес задачи обходятся в разы дороже, чем редкие падения системы, связанные с тем, что кто-то ввел некорректные данные.
Впрочем, это не означает, что “негативными” тестами можно пренебречь, т.к. не на всех этапах жизненного цикла ПО приоритеты ценностей сохраняются неизменными.
Негативное тестирование зачастую позволяет найти большее количество ошибок, но это становится важным только когда все положительные тесты уже сделаны.
говориМ о тестировании
простым языком
Виды тестирования по позитивности сценария
Позитивное тестирование – это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана.
Негативным называют тестирование, в рамках которого применяются сценарии, которые соответствуют внештатному поведению тестируемой системы. Это могут быть исключительные ситуации или неверные данные.
Прежде всего негативное тестирование направлено на проверку устойчивости системы к различным воздействиям, валидации неверных данных, обработку исключительных ситуаций. Сценарии позитивного тестирования, в свою очередь, направлены на проверку работы системы с теми типами данных для которых, она разрабатывалась.
Реакция продукта на тесты
Какой результат мы ждем от позитивных и негативных тестов?
Позитивное тестирование должно нам всегда давать результат в виде отсутствия багов.
Негативные проверки могут дать 2 результата:
1. На данный ввод у продукта есть ответ в виде сообщения/контроля.
2. Система не знает, как реагировать на введенные данные.
Получается, есть три реакции на действия по вводу данных:
— Действие: создание сущности, переход на новый шаг и т.п.
— Контроль: сообщение с контролем, блокировка дальнейших действий и т.п.
— Отказ: возникает исключение Exception, 404-ой ошибки и т.п.
Для чего важно различать?
Для чего нам различать негативное и позитивное тестирование? Чтобы верно расставлять приоритеты в тестировании в зависимости от ситуации.
Создание позитивных сценариев (тест-кейсов), как правило, предшествует созданию негативных.
Сначала мы проверяем работу системы, когда наш условный пользователь работает с системой «правильно». А уже потом приступаем к проверке отклика системы на пользователя, который допускает различные ошибки (ввод неверных данных, например). И наша система должна быть готова ответить на неверный запрос. Это и есть цель негативного тестирования.
Почему важно сначала провести позитивное тестирование? Большинство пользователей использует наш продукт так, как необходимо. То есть, если в поле ввода просят указать «Имя», то большинство пользователей напишут в него именно имя, а не набор цифр. Если мы не проверим верно ли распознаются корректные данные, то в случае ошибки большинство пользователей не смогут воспользоваться нашим продуктом.
Именно поэтому мы делим все тесты на позитивные и негативные и начинаем тестировать с позитивных. Именно с позитивных, так как они приоритетней. Лучше не останется времени на негативные тесты, чем мы не проверим основной функционал продукта на способность корректно отвечать пользователю на корректные запросы.
Пример позитивных и негативных тестов
Давайте рассмотрим эти виды тестирования немного подробнее на примере формы авторизации на сайте.
С помощью позитивных тестов мы проверим, что наша форма регистрации работает верно. Для этого проведем следующие тесты:
К негативным тестам можно отнести следующие сценарии:
Повторюсь, при тестировании очень важно соблюдать приоритет.
Сначала мы выполняем позитивные тесты, а потом негативные.
Это связано с тем, что для продукта и пользователей важно, чтобы все фичи работали правильно, так как задумывались изначально.
К примеру, ошибка при авторизации с правильным логином и паролем гораздо опаснее, чем проблема возникающая, когда пользователь вводит неправильный пароль. А критичные ошибки лучше всегда находить как можно раньше, чтобы было время их исправить и внимательно проверить.
Положительный против отрицательного
Тестирование программного обеспечения — это процесс проверки и подтверждения правильности работы программного приложения. Цель состоит в том, чтобы найти дефекты и улучшить качество продукции. Существует два способа тестирования программного обеспечения, а именно: положительное тестирование и отрицательное тестирование.
Что такое положительное тестирование?
Позитивное тестирование — это тип тестирования, который можно выполнить в системе, предоставив в качестве входных данных действительные данные . Он проверяет, работает ли приложение так, как ожидается, с положительными входными данными. Этот тест проводится для проверки того, что приложение делает то, что должно делать.
В приложении есть текстовое поле, которое может принимать только цифры. Ввод значений до 99999 будет приемлемым для системы, и любые другие значения, кроме этого, не должны быть приемлемыми. Чтобы выполнить положительное тестирование, установите допустимые значения ввода от 0 до 99999 и проверьте, принимает ли система эти значения.
Что такое отрицательное тестирование?
Отрицательное тестирование может быть выполнено путем ввода символов от A до Z или от a до z. Либо система программного обеспечения не должна принимать значения, либо она должна выдавать сообщение об ошибке для этих неверных входных данных.
В обоих случаях необходимо учитывать следующее:
Методика тестирования, используемая для положительного и отрицательного тестирования:
Следующие методы используются для положительной и отрицательной проверки:
Анализ граничных значений:
Это один из методов тестирования программного обеспечения, в котором тестовые примеры предназначены для включения значений на границе. Если входные данные используются в пределах граничных значений, то это называется положительным тестированием. Если входные данные выбраны за пределами граничных значений, то это называется отрицательным тестированием.
Эквивалентность
Это метод тестирования программного обеспечения, который делит входные данные на множество разделов. Значения из каждого раздела должны быть проверены хотя бы один раз. Разделы с действительными значениями используются для положительного тестирования. В то время как разделы с недопустимыми значениями используются для отрицательного тестирования.
Вывод:
Тестирование помогает доставить качественное программное приложение и гарантирует, что оно не содержит ошибок до его запуска. Для эффективного тестирования используйте как положительное, так и отрицательное тестирование, которое дает достаточную уверенность в качестве программного обеспечения. Пользователи в режиме реального времени могут вводить любые значения, которые необходимо проверить перед выпуском.
понедельник, 10 февраля 2014 г.
Позитивное и негативное тестирование
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
36 комментариев:
Две из трех основных парадигм расписаны, это хорошо )
Впринципе, можно было бы уложиться в несколько строчек.
1. Тестирование на позитивных значениях.
Обычно используются пользовательские сценарии с корректными значениями.
Проверяем работоспособность заявленного функционала.
3. Тестирование в невозможных конфигурациях.
Своеобразный эд-хок. Проверка того, что система правильно обрабатывает нештатные ситуации и эксепшны.
Впринципе, две последних парадигмы некоторые объединяют в одну, но я бы не стал этого делать.
Да, Андрей, спасибо 🙂
Согласна, что негативные тесты можно разделить на простые ошибки и эксепшены. Это хороший подход 🙂
Кстати, чем отличается тест-дизайнер от проектировщика тестов?
И часто ли приходят люди, проработавшие несколько лет, но не знающие разделения на негативное и позитивное тестирование и претендующие на позиции тест-дизайнера?
Я согласен, что базовые негативные тесты (вроде корня из отрицательного числа, хотя это внезапно может оказаться и позитивным тестом, если вспомнить, что существует мнимая единица :)) стоит прогнать где-то в серединке. И необходимо уметь придумывать негативные тесты. Но прежде чем начинать тестировать квадратные корни из иврита хорошо бы подумать, какие позитивные кейсы были пропущены в базовом наборе.
Да, ты прав, пожалуй, стоит просить дать полный комплект, а не несколько тестов 🙂
Хотя все, что ты тут нафлудил, мы проходим, просто немного дальше, на уроке по классам эквивалентности 🙂 А первые лекции вводные, так, просто чтобы понять, какие виды тестирования вообще существуют ))