Вольный перевод статьи "Top 10 Negative Test Cases" Steve Miller.
Негативные тест кейсы используются для проверки работоспособности приложения при условии поступления на его вход «неправильных» данных. Такие тест кейсы должны обязательно использоваться в ходе тестирования. Ниже приведены десять самых популярных негативных тестовых сценариев:
Внутренние одинарные кавычки (Embedded Single Quote)
- У большинства SQL баз данных возникают проблемы при наличии одинарных кавычек в запросе (например, Jones’s car).
Используйте одинарные кавычки при проверке каждого поля ввода работающего с базой данных.
Обязательный ввод (Required Data Entry)
- В спецификации вашего приложения должны быть четко определены поля требующие обязательного ввода данных.
Проверяйте, что формы, которые имеют поля, определенные как обязательные для ввода, не могут быть сохранены при отсутствии данных в них.
Типы данных полей (Field Type Test)
- В спецификации вашего приложения должны быть четко определены типы данных для каждого из полей (поля даты/времени, числовые поля, поля для ввода номера телефона или почтового кода и т.д.)
Проверяйте, что каждое из полей позволяет вводить или сохранять данные только определенного спецификацией типа (например, приложение не должно позволять вводить или сохранять буквы или специальные символы в числовых полях).
Размер поля (Field Size Test)
- В спецификации вашего приложения должно быть четко определено максимально допустимое количество символов в каждом из полей (например, количество символов в поле с именем пользователя не должно привышать 50).
Проверяйте, что приложение не позволяет вводить или сохранять большее количество символов, нежели указано в спецификации. Не забывайте и о том, что данные поля, не только должны правильно функционировать, но и предупреждать пользователя об ограничениях, например, с помощью пояснительных надписей или сообщений об ошибках.
Числовые граничные значения (Numeric Bounds Test)
- Числовые поля вашего приложения могут иметь ограничения допустимых числовых значений. Эти ограничения могут быть указаны в спецификации вашего приложения либо вытекать из логики работы программы (например, если вы тестируете функциональность связанную с начислением процентов на счет, то вполне логичным будет предположение, что начисленные проценты не могут принимать отрицательное значение).
Проверяйте, что приложение выдает сообщение об ошибке в случае, если значения лежат за пределами допустимого диапазона (например, сообщение об ошибке должно появляться при вводе значений 9 или 51 в поле с допустимым диапазоном значений от 10 до 50, либо при вводе отрицательного значения в поле, значения которого должны быть положительными).
Числовые ограничения (Numeric Limits Test)
- Большинство баз данных и языков программирования определяют числовые значения как переменные с некоторым типом (например, integer или long integer), которые, в свою очередь, имеют ограничения допустимых числовых значений (например, значения integer должны находиться в диапазоне от -32768 до 32767, а long integer от -2147483648 до 2147483647).
Проверяйте граничные значения используемых переменных, для числовых полей, граничные значения которых четко не определены спецификацией.
Граничные значения даты (Date Bounds Test) - Очень часто в приложениях существуют логические ограничения для полей содержащих дату и время. Например, если вы проверяете поле содержащее дату рождения пользователя, то вполне логичным будет запрет ввода еще не наступившей даты (т.е. даты в будущем), либо ограничение на ввод даты отличающейся от сегодняшней более, чем на 150 лет.
Валидность даты (Date Validity) - Поля даты всегда должны иметь проверку валидности введенных значений (например, 31-11-2009 - не валидная дата). Также, не забывайте и о проверке дат в високосном году (годы кратные 4м и кратные 100 и 400 одновременно - високосные).
Веб сессии (Web Session Testing) - Множество веб приложений используют браузерные сессии для отслеживания пользователей вошедших в систему, применения специфических настроек приложения для конкретного пользователя и т.д. При этом, многие функциональные части системы не могут или не должны работать без предварительного входа в систему. Проверяйте, что функциональность или страницы, находящиеся за паролем, недоступны пользователю не прошедшему авторизацию.
Терминология Quality assurance
В этой статье мы будем рассматривать QA (Quality Assurance) в разработке программного обеспечения. Все это относиться к тестированию программного обеспечения, но в этой статье мы не будем изучать тонкости, а лишь разберемся с терминологией. Терминология в QA очень важна, без неё не возможно будет провести тестирования продукта. Как уже могли догадаться, QA расшифровывается как Quality Assurance что в переводе - обеспечение качества (контроль качества). Перейдём непосредственно к терминологии:
Позитивное тестирование (positive testing)
Это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. Основной целью “позитивного” тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.
Негативное тестирование (negative testing)
Это тестирование на данных или сценариях, которые соответствуют нештатному поведению. Основной целью “негативного” тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных.
Функциональное тестирование (functional testing)
Это тестирование в целях проверки реализуемости функциональных требований для решения задачи пользователя.
Функциональные тестирование включают в себя:
Тестирование производительности (performance testing)
Это тестирование, которое проводится с целью определения, как быстро работает вычислительная система или её часть под определённой нагрузкой. Также может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов.
Тестирование производительности включают в себя:
Тестирование удобства использования (usability testing)
Это тестирование удобство использования определяет степень простоты доступа пользователя к функциям системы, предоставляемым через пользовательский интерфейс.
Тестирование пользовательского интерфейса (UI testing)
Тестирование графического интерфейса пользователя предполагает проверку соответствия приложения требованиям к графическому интерфейсу, профессионально ли оно выглядит, выполнено ли оно в едином стиле.
Тестирование безопасности (security testing)
Процесс оценки уязвимости программного обеспечения к различным атакам.
Тестирование локализации (localization testing)
Это процесс тестирования локализованной версии программного продукта. Проверка правильности перевода элементов интерфейса пользователя, проверка правильности перевода системных сообщений и ошибок, проверка перевода раздела “Помощь”/“Справка” и сопроводительной документации.
Тестирование совместимости (compatibility testing)
Вид нефункционального тестирования, основной целью которого является проверка корректной работы продукта в определенном окружении.
Окружение может включать в себя следующие элементы:
Тестирование чёрного ящика (black box)
Метод тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта.
Тестирование белого ящика (white box)
Выполняется с целью обнаружения проблем во внутренней структуре программы. Это требует от проверяющего глубокого знания внутренней структуры и следовательно, не может быть выполнено обычным пользователем. Общая задача такого тестирования обеспечить проверку каждого шага по алгоритму программы.
Тестирование серого ящика (grey box)
Представляет собой сочетание тестирования белого ящика и черного ящика. Целью данного тестирования является поиск дефектов, если таковые из-за неправильного структуры или неправильного использования приложений.
Ручное тестирование (manual testing)
Это процесс поиска дефектов в работе программы, когда происходит тестирования работоспособность всех компонентов программы, как если бы он был пользователем.
Автоматизированное тестирование (automated testing)
Этот процесса тестирования использует программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс.
Модульное тестирование (component/unit testing)
Процесс позволяющий проверить на корректность отдельные модули исходного кода программы.
Интеграционное тестирование (integration testing)
Тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.
Системное тестирование (system/end-to-end testing)
Это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования чёрного ящика и тем самым, не требует знаний о внутреннем устройстве системы.
Мы рассмотрели лишь небольшую часть терминологии, но достаточно важную в QA. Возможно, мы еще затронем тему тестирования, а на сегодня это все.
Похожие статьи:
Решение проблем Adobe Flash на примере YouTube - Читать
Статья была переработана с учётом полученной в форуме критики и рекомендаций.
Этой статьей я хотел бы описать своё понимание тестирования программного обеспечения - процесса не тривиального, как мне всегда казалось, и, я даже не мог себе представить, весьма интересного.
Меня всегда интересовало, что такое тестирование ПО. Зачем нанимать кого-то для тестирования программного продукта, если разработчик и сам может потратить пару часов на такое не значительное по приоритету задание. И, наконец-то, зачем вообще тестировать? Ведь программисты ребята умные - пишут правильно. Но
не все так просто как мне казалось.
Перейдя из программистов в тестеры, не имея достаточного количества теории за пазухой, я достаточно долго пытался «поломать» программный продукт, давая на вход заведомо неверные входные данные. И, как не странно, ломалось. Создавалось сообщение об ошибке, и очередной день считался прожитым не зря.
Позже, я начал сталкиваться с тем, что, сколько тесты не гоняй, а ошибки все равно выплывают. Не имея какого-либо представления о том, что и как должно даваться «на вход» тестируемому приложению процесс тестирования казался бесконечным. Как результат - замкнутый круг, в котором сорванные сроки на тестирование, злой ПМ и уставшие от «глупостей» разработчики.
И только многим позже я выделил для себя четкую последовательность действий, которые необходимо выполнять для тестирования программного обеспечения:
Итак, рассмотрим все по порядку.
Как определить когда и как должно работать само приложение, когда и как оно должно «ломаться» (то есть как система или её модуль должен реагировать на невалидные данные или неверное поведение пользователя)? Что должно быть в результате правильной отработки, при каких условиях и входных данных правильная отработка должна иметь место? Что должно быть в результате не правильной отработки тестируемого приложения, при каких условиях она должна иметь место?
На все эти вопросы есть ответ в документации тестируемого приложения. Во всяком случае, он, ответ, должен там быть, иначе документация не полная, что равняется ошибке в документации. Хочу оговориться, что уже на этой стадии могут возникать первые дефекты - дефект в спецификации (в требованиях) такой же по важности для системы (а порой и более высокий по приоритету!) дефект. Стоит также оговориться, что тестирование требований это такой полноценный же вид тестирования, которому незаслуженно уделяют мало внимания. Основными показателями успешного тестирования требований является достижение критериев полноты (тестопригодности) и непротиворечивости требований.
Документация дает возможность понять для себя основные ступеньки проверки приложения, где и как должно приложение работать, где «ломаться». И, что не мало важно, как ломаться. Что «говорить» при успешной отработке, какие сообщения на ошибку могут/должны появляться при отработке.
Поняв все «премудрости» требований к приложению и особенности реализации этих требований разработчиком, можно приступать к тестированию конечного результата.
Этот процесс можно описать следующими шагами:
В первом и втором пункте описан процесс, который называется «позитивным» тестированием. «Позитивное» тестирование - это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению тестируемой системы.
Третий же пункт описывает противоположный «позитивному» процесс - «негативное» тестирование. Это тестирование на данных или сценариях, которые соответствуют нештатному поведению тестируемой системы - различные сообщения об ошибках, исключительные ситуации, «запредельные» состояния и т.п.
Однако предшествовать «позитивному» и «негативному» тестированию должны работы по выполнению «дымового» тестирования.
Информационный словарь дает достаточно четкое определение термина «дымовое тестирование»:
Почему «позитивное» тестирование считается на порядок более важным, чем «негативное»?
Предположим, что система не слишком устойчива к «плохим» вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить «подводные камни», не будут делать «опасные» или «неразрешённые» действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа «ни в коем случае не оставляйте это поле пустым, а то...».
Но - всего этого не будет вовсе, если система не выполняет свое основное предназначение, если пользователи (заказчики) не могут решить свои бизнес задачи, если они все делают правильно, вводят хорошие данные, но не получают результата. И посоветовать им ничего в этой ситуации нельзя. И они уходят...
Именно поэтому «позитивное» тестирование гораздо, гораздо важнее «негативного».
Впрочем, это не означает, что «негативными» тестами можно пренебречь, т.к. не на всех этапах жизненного цикла ПО приоритеты ценностей сохраняются неизменными.
Теперь, сделав первые удачные шаги в тестировании приложения и получив положительный результат, можно думать о более мудреных способах протестировать приложение, как говорится: «Дальше - больше». Все зависит от глубины необходимого уровня тестирования, желания и возможности проверить приложение. Естественно, описанные выше четыре стадии не покрывают полного цикла тестирования приложения, однако являются обязательными для начального тестирования.
Очень обеспокоены качеством продуктов. Это объясняет всемирную доступность тестировщиков программного обеспечения. Предоставляя , эти люди обеспечивают его качество.
Многие тестировщики никогда не забудут о негативном тестировании, хотя не все программисты этим довольны. Такой контроль нужен для защиты от хакеров, ботов, Dos/DDos атак.
Каково призвание специалистов по тестированию? Они должны найти проблемы, которые не видны другим. Не затягивайте с негативным тестированием, иначе вы подвергаете систему опасности.
Давайте начнем с самого начала. Есть 2 вида контроля, когда тест-кейсы включены в тестирование: позитивный и негативный. Преимущество у последнего.
Позитивное тестирование – это процесс проверки на корректное поведение согласно техническим требованиям и документации. Позитивное тестирование выполняется для обеспечения того, что система делает именно то, что ожидается.
Негативное тестирование – это процесс проверки на некорректное поведение. В ходе такого тестирования мы можем узнать, что система справится с непредвиденными ситуациями.
Чтобы выполнять тестирование программного обеспечения, нужно обладать интуицией либо охотничьим инстинктом. Специалист по тестированию – это разносторонний человек, который может выполнять и бизнес анализ, и тестирование.
Тестировщики проверяют, корректно ли выполняется процесс: есть ли соответствие с техническими требованиями и тестовыми сценариями. Проведение позитивного и негативного тестирования отдельно займет больше времени, чем их одновременное выполнение. Это потому что есть две тестовые итерации.
В конце концов, чем ближе час Х, тем быстрее идет время и тем скорее нужно выполнять задачи, исправлять дефекты, применять бизнес-требования (которые могут варьироваться) и сделать еще много дел. Дедлайн – это самое жаркое время!
Разделение негативного и позитивного тестирования просто противоречит природе тестировщика! Его задача – проверить систему на все возможные действия конечного пользователя.
Люди в основном нелогичны и могут спровоцировать проблемы в программном обеспечении. Негативное тестирование поможет избежать возникновения проблем.
Ииииииии... Это последняя запись из цикла! Она самая короткая, самая простая и практически целиком состоит из реальных историй. По возможности — глупо-смешных. Даже есть видео, снятое специально для записи вот прямо в момент написания. Свежачок-с. К сожалению, я не догадался снять скриншот с сообщением о падении Youtube клиента, он бы подошёл. Упал прямо при заливке того ролика, который вставлен в статью. Ладно, пусть будет мой экран блокировки.
На старте тестирования, вне зависимости от того, новый это проект или такой, что его стоило бы уже похоронить, в целом всегда ясно, с чего начинать. Если, конечно, к момент старта тестирования ни одно из звеньев цепи не слажало. Обычно тестировщики вычитывают требования и прочие документы с нерусскими названиями, типа «БиЭрКью», «ЭсАрки» и «Юзер стори» и прикидывают, как написать тест кейс, чтобы он проверил выполенения всех этих документов. Это всё понятно, на поверхности и нет смысла на этом задерживаться. Но есть ещё поведение самого Android, о котором иногда не знают не то что аналитики, но даже архитекторы и некоторые разработчики. А помня, что , только с кастомами, таких особенностей всплывает довольно много. И я говорю не о стрессовых сценариях, когда памяти нет или батарейку внезапно вынули (как-то встречал негодование человека на терминал GNU/Linux, что тот не показывает пароль при вводе, а у него глючная клавиатура и он не понимает, вводит пароль или же это клавиатура снова не работает), а о штатном поведении кастомизации Android и даже поведении, заложенном в AOSP. То есть штатные поведения системы, которые могут отрицательно сказаться на тестируемом продукте. Так называемые, негативные сценарии.
Я кратко опишу некоторые негативные сценарии и попытаюсь дать конкретные примеры.
Реальная история провала. Родительский контроль в KIS для Windows появился в версии 7.0 в 2006 году. В то же время в продукте существовал встроенный новостной агент, вовсе не такой, как сейчас. Предполагалось, что через него будут рассылаться разные новости об угрозах, всякие «что нового» и подобное. В релизной версии, которая уже была установлена у пользователей, был баг. Если перевести время в Windows назад, до начала действия лицензии, то защита отключалась. Строго говоря, не администраторы не могут переводить время, но 10 лет назад в фирмах особо не следили за правами пользователей и там каждый бухгалтер был локальным администратором. Один из наших клиентов в своём маленьком офисе настроил родительский контроль так, чтобы пользователи не могли шариться по Интернету, кроме как в дозволенные сайты. Драконовски настроил и паролем защитил настройки. Всё работало нормально до тех пор, пока во встроенный новостной агент не прислали новость, что пора обновиться на новую версию 7.0.1 где, помимо прочего, исправлена ошибка, из-за которой отключается защита при переводе времени в обратную сторону до начала старта лицензии. Пользователь прочёл новость, обрадовался и вырубил защиту предложенным методом. Через несколько дней эта история от него попала на тогда ещё популярный bash.org.ru. С тех пор новости подобного рода больше не приходили пользователям.
И не думайте, что подобные ошибки не допускает. Вспомните историю с iOS, которая произошла в этом году, хотя прошло то всего 3 месяца с начала года (Примечание: да, это достаточно старая лекция, я давно хотел её выложить ). Телефоны вырубались, если перевести время ближе к началу исчисления unix time. И как Apple исправил эту ошибку? Они запретили переводить время дальше, чем критичная дата, что НЕ являлось исправлением проблемы. Злоумышленники стали поднимать свои Wi-Fi точки с названиями, которые обычно есть во всяких МакДоналдсах и через них передавать поддельное время. Устройства подключались к таким точкам автоматически и обнаруживали NTP серверы, у которых запрашивали время. Apple банально не позаботилась о том, чтобы iOS не использовала поддельные NTP серверы. Таким образом iOS вновь окирпичивались.
Итог таков, что ваш продукт гарантированно попадёт под ООМ Киллер. Ваша задача состоит в том, чтобы убедиться, что ни к чему плохому это не приводит и продукт поднимется, как только приложение-жиробасина будет схлопнута системой (если это требуется от продукта, конечно). А система сделает это при первой возможности, жить в фоне такой жиробасине она не даст.
Ещё один вывод — ваше приложение также не должно быть жиробасиной. Любые утечки должны обнаруживаться разработчиком ещё до того, как он напишет реальный код. Ваши тесты производительности обязательно должны иметь сценарии проверки, когда monkey генерирует тонну событий. Если код написан качественно, то сборщик мусора освободит память и система не убьёт процесс приложения. Если всё плохо и приложение течёт из всех щелей, система его пристрелит. Конечно, оно взлетит после этого вновь и память есть уже не будет, потому что после убийства процесса сборщик мусора подчищает всё, но если манки показал, что приложение течёт в его тесте за 15 минут, то у пользователя эти течи хоть и позже, но всё равно проявят себя.
Боевым примером могу назвать классное приложение Talon for Twitter. Я не делал сброс устройства уже очень давно и потому не знаю, исправил ли автор эту ошибку. Когда я сообщил ему о ней, он мне ответил, почему ошибка возникла (хотя я и так знаю, почему!), но не сказал, будет ли он исправлять поведение. В общем, в этом приложении есть своеобразный мастер установки, который рассказывает о возможностях этого Twitter клиента, по пути запрашивая нужные пермишены. Всё чётко по гайдлайнам Google, прямо по нотам. Когда мастер настройки пройден и нужные пермишены получены, взводился флаг об этом, чтобы повторно не проходить настройку каждый раз. И приложение бэкапилось вместе с этим флагом. Вместе с ним оно и восстанавливалось. Хотя по умолчанию для всех приложений нового типа (т.е. targetApi level >= 23) разрешения отключены. Запускаешь приложение, а оно не может нормально работать. Потому что нет проверки на доступность пермишенов, все проверки остались в мастере первоначальной настройки, который не запускался, потому что флаг был выставлен в значение «мастер уже пройден». Кроме того, после запуска клиент не загружал твиты, давая отлуп от самого Twitter. Потому что прикопанный токен был не валиден на новой инсталляции и нужно было запрашивать новый, а этот запрос также делался в мастере установки на первом же шаге!