Хорошее пограничное тестирование - PullRequest
4 голосов
/ 21 июня 2011
  1. Если, скажем, я создал входной текст, который должен принимать только любое десятичное число от 1 до 100, как его проверить?

    ИМХО, я проверю в этом потоке:

    «0», «1», «50», «100», «101», «0,9», «100,1», «A»

    Достаточно ли этого? Есть ли структурированный поток, как проверить этот вид пограничного тестирования? (любая хорошая статья?) Должен ли я также проверить "1 + 1"?

  2. Что, если вопрос изменился на «принять любое целое число от 1 до 100», достаточно ли этой серии испытаний? Должна ли последовательность ввода отличаться от десятичной?

    «0», «1», «50», «50,5», «100», «101», «0,9», «100,1», «A»

Ответы [ 2 ]

2 голосов
/ 21 июня 2011

Для # 1 вы на правильном пути, и я думаю, что у вас может быть даже слишком много дел в эквивалентных классах. Как правило, если у вас есть нижняя граница L и верхняя граница U, достаточно проверить, что L и U действительны и что L - e и L + e недопустимы (где e - наименьшее или достаточно малое приращение, чтобы выйти из граница). Если вы хотите добавить дополнительную ценность для здравомыслия, тогда тестирование для чего-то между L и U также работает. Некоторые скажут, что выбор случайного значения между L и U также работает, но я предпочитаю, чтобы мои тесты были детерминированными.

Таким образом, в приведенном выше примере L равно 1, а U равно 100. Поскольку это десятичное значение, значение e является хитрым, поскольку теоретически e может быть бесконечно малым. Там хорошо выбрать что-то разумное, исходя из сценария вашего клиента. Например, если это сумма в долларах, выбор 0,01 будет хорошим выбором. В этом случае это оставило бы нас с «1», «100», «0,99» и «100,01».

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

Для # 2 сценарий немного меняется. L равно 1, а U равно 100, но теперь e равно 1, потому что единственными допустимыми значениями являются целочисленные значения. Если вы хотите проверить, что десятичные значения приводят к ошибкам, это другой класс случаев, не связанный с границами. Таким образом, «50,5» и «А» будет достаточно для условий ошибки. Или, если вы хотите округлить десятичные дроби, вы также можете проверить это.

0 голосов
/ 22 июня 2011

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

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

Так что я бы сказал, что ваш набор тестов может быть немного легким.

Где у вас есть: «0», «1», «50», «100», «101», «0,9», «100,1», «А»

Я был бы более склонен добавить несколько между: «0», «1», «10», «20», «30», «40», «50», «60», «70», «80», «90», «100», «101 "," 0,9 "," 100,1 "," A "

Вы также можете рассмотреть возможность добавления некоторых экстремальных случаев, таких как очень большие числа или несколько миллионов символов.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...