Отрицательный тестовый пример

Этот вопрос является продолжением моего предыдущего вопроса в Положительные тестовые случаи и отрицательные тестовые случаи < /а>.

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

Ожидается, что если я введу любое значение, кроме алфавитов, система отобразит сообщение об ошибке «Разрешены только алфавиты!».

И если я проверю его с числовыми значениями, и он выдаст сообщение об ошибке «Разрешены только алфавиты!» (как и ожидалось), то это будет отрицательный тест или положительный?


testing testcase qa
person a Learner    schedule 14.10.2013    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Ввод неправильных данных в поля — это Negative test case. Вы пишете отрицательные тестовые случаи, и у этого может быть два результата:

  1. Либо это will work as expected, это означает, что вы получите сообщение об ошибке, и вы скажете, что тест пройден, т.е. negative test passed

  2. Или это will break означает, что он примет ввод, в этом случае тест не пройден, то есть ваш negative test case has failed, this is a bug.

person Rupesh    schedule 14.10.2013

arrow_upward
1
arrow_downward

Извините, мой ответ будет не по теме, но (мое) обоснование будет объяснено ниже.

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

Это мое определение классификации тестов. Это мои слова (заимствованные из сторонних статей, с четкими определениями). Это полезно для меня, потому что я сначала пишу/выполняю первичные тесты, а затем альтернативные тесты. Я пишу первичные тесты, думая о том, что пользователь хочет сделать и как. (UX-режим) Я пишу альтернативные тесты, думая о том, что на самом деле может «пойти не так», например, поврежденные системные данные, утечка корпоративной информации и все другие пороки, которые я могу придумать. (режим контроля качества)

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

person Laurent LA RIZZA    schedule 14.10.2013

arrow_upward
1
arrow_downward

Если ваше описание функции похоже на «В поле yiffy разрешены только буквенные символы», то тестирование цифр является отрицательным тестовым случаем.

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

Но не будьте слишком строги в этом, потому что тестирование — это поиск серых линий. В моем языке ij — совершенно нормальный символ, в то время как в Германии очень распространен ß. ٠١٢٣٤٥٦٧٨٩ Цифры/цифры (на самом деле это арабские цифры). Как тестер, вы должны думать об этих тестовых примерах и оценивать, насколько важна функция (какой риск, если кто-то сделает это) во время тестирования. Вы же не хотите тратить драгоценное время на тестирование ерунды.

person AutomatedChaos    schedule 14.10.2013