Меню

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

    Вячеслав Зимин 22 января, 2020 No Comments

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также:  Тест какое имя твоей будущей девушки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Правильно пишем тест-кейсы. Памятка начинающему специалисту по тестированию

Правильно пишем тест-кейсы. Памятка начинающему специалисту по тестированию

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

Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB:

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

Определение тест-кейса языком обывателя:

Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат.

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

Обязательные атрибуты для заполнения

  • Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс.
  • Заголовок — краткое, понятное и ёмкое описание сути проверки.
  • Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке.
  • Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки.
  • Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге.

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

Правила написания тест-кейсов

  1. Заголовок:
    • должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
    • не может содержать выполняемые шаги и ожидаемый результат.
  2. Предусловие:
    • может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса;
    • может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…);
    • не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
    • не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
    • не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»;
    • не может содержать ожидаемый результат.
  3. Шаги проверки:
    • должны быть чёткими, понятными и последовательными;
    • следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
      Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»;
    • должны использоваться безличные глаголы.
      Правильно: нажать, ввести, перейти.
      Неправильно: нажмите, введите, идите;
    • не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё;
    • не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида.
  4. Ожидаемый результат:
    • должен быть у каждого шага проверки;
    • должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага;
    • не должно быть избыточного описания.
  5. Общие требования к тест-кейсам:
    • язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц;
    • тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще);
    • тест-кейсы группируются в функциональные блоки по их назначению;
    • в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм.

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

Примеры

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

Тест-кейс №1. Корректный

Номер 1
Заголовок Отправка сообщения через форму обратной связи на странице “Контакты”
Предусловие Открыта главная страница сайта victorz.ru. Есть доступ к почте администратора сайта victorz.ru
Шаг Ожидаемый результат
В верхнем меню сайта нажать на ссылку “Контакты” Открылась страница “Контакты”
Ввести значение в поле “Ваше имя” состоящее из латинских букв, кириллицы В поле “Ваше имя” отображается введённое имя
Ввести корректный email в поле “Ваш e-mail” В поле “Ваш e-mail” отображается введённый email
Ввести в поле “Тема” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел В поле “Тема” отображается введённый текст
Ввести в поле “Сообщение” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел В поле “Сообщение” отображается введённый текст
Ввести в поле капчи требуемое капчей значение В поле капчи отображается введённое значение
Нажать под заполняемой формой на кнопку “Отправить” Под кнопкой «Отправить» появился текст “Спасибо. Ваше сообщение было отправлено.”
Все заполненные поля очищены.
Проверить почту администратора сайта На почту пришло сообщение, отправленное с сайта через форму обратной связи и содержащее в теле сообщения данные введённые на шагах 1-5.
Читайте также:  Консистенция теста для панкейков

Тест-кейс №2. Некорректный

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

Номер 1
Заголовок Отправить сообщение через форму обратной связи (Указываем, что проверяем или что делаем?)
Предусловие Перейти на главную страницу сайта victorz.ru (Это не предусловие, а описание шага)
Шаг Ожидаемый результат
Нажать на ссылку “Контакты” (Где она находится?) Открылась страница (Какая?)
Ввести имя в поле “Ваше имя” (Какие символы вводить?) (Ничего не указано в ожидаемом результате, что должно произойти?)
Ввести email в поле “Ваш e-mail” (корректный или некорректный?) В поле отображается email (Какой? Введённый? В каком поле отображается?)
Ввести в поле значение, состоящее из латинских букв, кириллицы, спецсимволов и чисел (В какое поле?) В поле “Тема” отображается текст (Какой?)
Ввести в поле “Сообщение” текст (Какие символы вводить?) Видим в поле “Сообщение” введённый текст (Видим или отображается?)
Вводим в поле капчи требуемое капчей значение (Помните только безличные глаголы — Ввести). В поле капчи будет введённое значение (Что будет делать? Танцевать?)
Нажать под заполняемой формой на кнопку (На какую?) Появился текст “Спасибо. Ваше сообщение было отправлено.” (Где появится?)
(Последний шаг не заполнен, а это неправильно, так как мы не проверим действительно ли работает отправка писем через форму обратной связи)

Во второй части видео (с 8-й минуты) разбираю на примерах создание тест-кейсов:

Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов.

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

Источник

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

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

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

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

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

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

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

Сегодня нет точного и единого мнения о соотношении позитивного и негативного тестирования.

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

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

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

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

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

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

Классический пример логина/логаута:

  • регистрация: ввод логина и пароля, с логином без пароля, через социальные сети;
  • авторизация: ввод логина и пароля, вход через социальные сети;
  • восстановление пароля.
  • регистрация через пару логин/пароль, через логин, через социальные сети;
  • регистрация при заполнении обязательных полей;
  • регистрация при заполнении всех полей;
  • проверка возможности авторизации после регистрации;
  • регистрация на одном браузере и вход на другом;
  • проверка работы функции восстановления пароля.
  • повторная регистрация (имя/пароль уже заняты);
  • регистрация без заполнения обязательных полей (все поля пусты);
  • регистрация с вводом данных в неверном формате;
  • авторизация с неверным логином/паролем.

И еще один пример создания простого контакта (присутствует возможность просмотра, редактирования и удаления):

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

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

Внутренние одинарные кавычки в запросах SQL.

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

Обязательные поля для ввода данных.

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

Типы данных в полях.

При проверке полей ввода данных нужно понимать, что такие поля могут отличаться тем, данные какого формата они принимают. Например, текстовое поле подразумевает то, что оно принимает любой текст. Здесь можно сделать несколько основных проверок. Во-первых, проверить лимит на ввод символов. Часто разработчики не выставляют лимит на символы. Как результат, при вводе длинного имени, например, такой текст будет неправильно отображаться в других секциях приложения/сайта (выходить за пределы блока, перекрывать другой текст и т.д). Это очень распространенная проблема. Во-вторых, мы должны понимать назначение данного текстового поля. Разница между полем никнейма и имени пользователя существенная. Поле никнейма может принимать любой набор символов, включая цифры и специальные символы. Поле же имени должно принимать только буквы. Также в странах Европы и США принято имя и фамилию обьединять под одним понятием “Full name”. Поэтому это поле должно принимать минимум два слова, разделенных пробелом. Еще стоит учитывать рынок, на который ориентируется продукт. Ведь в тех же французском и немецком языках в именах используются дополнительные символы (известны как “умляуты”). И поле ввода должно принимать эти символы. Для числовых полей и полей выбора даты также работают свои правила. Числовое поле не должно принимать других знаков, кроме чисел. Введенная или выбранная дата должна отображаться в правильном формате и т.д.

Читайте также:  Тест полоски ван тач селект и селект плюс чем отличаются

Размер поля.

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

Числовые граничные значения.

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

Числовые ограничения.

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

Граничные значения даты.

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

Валидность даты.

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

Веб сессии (только для веб приложений).

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

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

Источник

Топ-10 негативных тест-кейсов, используемых во время тестирования ПО

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

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

1. Внутренние одинарные кавычки (Embedded Single Quote)

В большей части базы данных SQL могут возникать некоторые проблемы с наличием одинарных кавычек в теле запроса (к примеру, Ritchie’s car).
Всегда применяйте одинарные кавычки при валидации каждого поля ввода, функционирующего с БД.

2. Обязательный ввод данных (Required Data Entry)

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

3. Виды данных полей (Fields Type test)

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

4. Размеры полей (Fields Size Test)

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

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

5. Проверка числовых ограничений (Numeric Bounds Test)

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

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

Всегда стоит тестировать ПО на выдачу ошибки в ситуации, когда значения находятся за границами валидного диапазона данных. Как пример, информация об ошибке должна отображаться при вводе данных 19 и 26 при возможном значении от 20 до 25.

6. Числовые ограничения (Numeric Limits Test)

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

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

7. Гранично-допустимые значения даты (Date Bounds Test)

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

8. Валидная дата (Date Validity)

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

9. Веб-сессии (Web Session Testing)

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

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

10. Настройки производительности (Performance Changes)

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

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

Источник