Что такое дымовое тестирование? Что такое позитивное тестирование? Что такое негативное тестирование? Позитивный взгляд на негативное тестирование По уровню тестирования.

Мы (не такой уж это и секрет) очень переживаем за качество своих продуктов и с трепетом наблюдаем за обваливанием системы. Это оправдывает существование тестировщиков в мире. Это заставляет нас чувствовать себя героями: пришёл великий Тестер и спас своих пользователей от ужасных критических багов!

И наши тестировщики никогда не забывают про негативное тестирование, хотя не всех прогеров это радует. Но такие проверки не прихоть «злых тестеров», они вызваны необходимостью закрыть уязвимости и обезопаситься от проникновения в систему хакеров и ботов, Dos/DDos атак.

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

Понимаете, программисты-то пишут софт, нацеливаясь на результат, на запланированный релиз, летят на крыльях вдохновения! А тут наступает этап проверки и многочисленных исправлений и правок «идеального» кода. И всё, прячься кто куда, система на тестировании.

Чтобы никого не нервировать, некоторые специалисты могут откладывать негативное тестирование на потом или вообще игнорировать его (ужас!) в угоду сокращения сроков и бюджета. Ну а чего проверять, если прога не делает даже того, что должна, правда? Не-а.

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

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

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

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

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

Поэтому, по нашему мнению,

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

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

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

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

Проверяет всё по ТЗ и тестовым сценариям, смотрит, как данные обрабатываются, которые юзер должен ввести в поля (не факт, что введёт, кстати) и тут вот оно – озарение! Ему кажется, что если ввести вот в это поле для login какой-нибудь «%адынадын/>», а не обычный текст, то что-то точно произойдёт. Что-то тёмное и мрачное неправильное.

И что? Он должен сказать себе: «Нет. Сейчас я должен заниматься позитивным тестированием и ничем другим. Вот у меня назначено негативное на следующей неделе, тогда и настанет время для %адынадын/>. Наверное»?

Мы считаем такой подход к негативному тестированию неэффективным, и вот почему:

1. Если проводить позитивное и негативное тестирование по отдельности, то это будет дольше. Как минимум потому, что это будут уже две итерации тестирования.
2. Тестеры и кодеры живут в условиях дедлайнов. И если время строго ограничено, то откладывание негативного тестирования на потом повышает риск того, что про него вообще в итоге забудут. Ведь чем ближе к моменту Х, тем быстрее летит время, скорее требуется выполнить поставленные задачи, исправить дефекты, применить финальные бизнес требования (которые могут измениться) и доделать ещё кучу дел. Дедлайн – время горячее!
3. Разделение негативного и позитивного тестирования, по нашему мнению, просто противоречит природе тестера! Ведь основная его задача – это проверка системы на все возможные действия конечного юзера. А люди в большинстве своём нелогичны, и могут делать с софтом самые разные непотребства;)

Мы, как тестировщики, очень переживаем, если система содержит ошибки по проверкам из категории негативных. И особенно, если последствия таких ошибок критичны для всей системы. Но репортить их не боимся. Особенно с таким козырем в рукаве – у нас в команде есть девочки-тестировщицы. И кто сможет упорно отстаивать «идеальность» кода, когда они нежными голосками в пух и прах разносят работоспособность проекта? То-то же.

Так какие выводы мы можем сделать?

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

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

Очень обеспокоены качеством продуктов. Это объясняет всемирную доступность тестировщиков программного обеспечения. Предоставляя , эти люди обеспечивают его качество.

Многие тестировщики никогда не забудут о негативном тестировании, хотя не все программисты этим довольны. Такой контроль нужен для защиты от хакеров, ботов, Dos/DDos атак.

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

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

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

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

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

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

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

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

В конце концов, чем ближе час Х, тем быстрее идет время и тем скорее нужно выполнять задачи, исправлять дефекты, применять бизнес-требования (которые могут варьироваться) и сделать еще много дел. Дедлайн – это самое жаркое время!

Разделение негативного и позитивного тестирования просто противоречит природе тестировщика! Его задача – проверить систему на все возможные действия конечного пользователя.

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

· Дымовое тестирование. На этой стадии необходимо проверитьработает ли система вообще (правильно ли работает, правильно лиобрабатывает ошибки и пр.). Это делается для того, чтобы понятьпригодно ли приложение для дальнейшего тестирования или оноизначально работает неправильно.

· «Позитивное» тестирование». На этой стадии необходимо проверить результат работы приложения при получении им «правильных» входных данных.

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

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

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

1) проверьте, как работает приложение, когда оно получает навход корректные данные;

2) если все работает правильно, как описано в спецификацииследующим шагом является проверка граничных значений (минимальные и максимальные значения корректных данных);

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

В первых двух пунктах описан процесс, который называется «позитивным» тестированием.

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

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

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

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

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

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

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

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

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

Вопросы к теме 18

Для чего люди проходят психологические тесты? Естественно у каждого свои мотивы. Кто-то хочет разобраться в себе и «понять какой Я». Кто-то жаждет подтвердить, сложившееся мнение о своем характере. Кто-то просто убивает свободное время и развлекается. Но все, пусть часто и не осознавая этого, то есть чисто , желают услышать о себе что-то хорошее. Зачем? Да затем, что и поднимает настроение. Тест, который мы Вам предлагаем пройти имеет единственную цель - привнести в Ваше нынешнее состояние капельку позитива. По сути это и не тест вовсе, а что-то вроде позитивного предсказания. А они, как известно, очень часто сбываются!

06.10.2018 16947 +67

Хотите узнать как другие люди воспринимают Ваше имя? Бесплатный онлайн сервис фоносемантического анализа позволяет узнать как воспринимается то или иное слово на уровне подсознания. С его помощью можно, например, подобрать имя ребенку или название для фирмы.
Узнайте какое самочувствие будет у Вас через месяц! Прямо сейчас на нашем сайте Вы можете расчитать свои биоритмы абсолютно бесплатно. По результатам расчета Вы получите персональные рекомендации и график изменения биоритмов на ближайший месяц.
Популярные психологические тесты Огромное количество популярных психологических тестов на любой вкус. Для мужчин, для женщин, эзотерические, профессиональные... И все это онлайн, бесплатно и без регистрации!

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

1. Функцию вычисления корня в калькуляторе.
2. Работу с корзиной (добавление / удаление / редактирование) в интернет-магазине.

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

Поэтому я решила написать поясняющую статью.

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

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

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

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

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

Посмотрим на примере:

Основной тест-кейс - проверить, что корень из корректного числа действительно вычисляется.

Разбить можно на следующие классы эквивалентности:

• После вычисления корня остается целое число (корень из 4 = 2)
• После вычисления корня остается дробное число (корень из 3)

Хм, а что, если дробное число у нас будет не только после вычисления корня, но и до ? Можем же мы взять корень из числа 2,2 ? Позитивный тест? Позитивный!

Также можно разделить числа на небольшие, до 100, например. Потом взять интервал от 100 до размера int и третий будет еще больше, сколько влезает в наш калькулятор. 3 класса эквивалентности, проверяем по одному значению из интервала.

Не забудем и про граничные значения, проверим 0. Позитивный тест? А как же! Корень из 0 равен 0, а не ошибке!

Из основного, пожалуй, все.

О, вот где простор для воображения!

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

Думаете, будет работать, если работает по отдельности? Не-е-е-ет, ребята, вы же тестировщики! Никогда не верьте программам "на слово"! Придумали сценарий? Проверьте!

Тем более что такой сценарий вполне может упасть, мы же уже удалили данный товар из корзины, так? Так вот система вполне может не дать нам его снова добавить. Типа "ты уже отказался, але, я все помню!". Корректно такое поведение? Нет!

А сам сценарий позитивный? Да! Хотя уже и с нотками извращения, надо признать

Негативное тестирование

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

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

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

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

Поэтому мы проводим негативное тестирование. Что такое негативное тестирование? Это ввод заведомо некорректных данных. Вводим и смотрим, как ведет себя программа, понятные ли сообщения об ошибке выдает...

Но как составлять такие тесты? Посмотрим на примерах:

1. Функция вычисления корня в калькуляторе.

Первое, что приходит на ум - а что будет, если вычислить корень из отрицательного числа?

Но что еще тут можно придумать?

• Корень из пустоты - вспоминаем о граничных значениях, мы не можем ввести строку отрицательной длины, но вот граничное значение (строка нулевой длины) можем!
• Корень из символов - надо проверить, что скажет система, если ввести или вкопипастить туда что-то символьное. Причем символы мы делим на русские, английские и спецсимволы!
• Корень из значения "четыре" - также символы можно поделить на абракадабру и "типа число". Кстати, если уж говорить о таких "типа числах"...
• Попробуем ввести строку, которая обозначает число . И взять корень уже из нее.

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

В корне можно не вводить максимально большое число, а ввести такое число, чтобы корень из него (дробное значение) получился очень длинный и не уместился на экран, вот что тогда будет, обрежется или сломается?

2. Работа с корзиной в интернет-магазине.

Тут, опять же, можно найти числовое поле и поиграться с ним, как мы это только что проделали с калькулятором. Поле "количество товара" тут очень подойдет! Но, с другой стороны, скучно же, такие разные приложения и одни и те же тесты?

Запомните всего 2 слова - разные вкладки !

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

• Открыли корзину в 2 вкладках браузера. Сначала нажали "удалить" в одной, потом во второй. То есть попытка удалить то, что ты сам уже удалил из своей же корзины.
• Попытка удалить удаленный админом товар. В 1 вкладке под админом удаляем товар вообще, в принципе, а в другой пытаемся его под пользователем удалить из корзины.

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

А что будет, если админ не передвинул товар в иерархии магазина (в другую категорию переместил, исходно неверно был размещен товар), а просто поправил, отредактировал описание? Тоже ничего сломаться не должно!

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

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

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

Хочется привести еще один пример из реальной практики. Тоже web-интерфейс, в котором можно нажать "создать" и добавить новую карточку. Пользователь добавляет, а у него через раз формочка падает. Почему?

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

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

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

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

Заходите к нам на огонек! ツ