Концептуальный вопрос про граничные значения и классы эквивалентности

Наверно, самые известные вещи в тест-дизайне - это граничные значение и классы эквивалентности.

Один из подходов тестирования граничных значений предлагает при тестировании поля, принимающего целочисленные значения в промежутке [5,10], проверять 6 следующих значений: 4, 5, 6, 9, 10, 11. Если использовать разбиение на классы эквивалентности, то сюда добавятся, например, 3, 7 и 14.

У меня возник вопрос, который не дает покоя: зачем проверять значения 6 (нижняя граница + 1) и 9 (верхняя граница - 1)? Ведь если разработчик ошибся и проставил границы шире, мы это выявим при проверке значений 4 и 11. Если проставил границы уже, то выявим на 5 и 10. Какую доп. полезную информацию дадут нам проверки значений 6 и 9?

И еще один вопрос уже к вашему опыту. Станете вы в таком случае добавлять проверки точек внутри классов эквивалентности (выше я выбрала для этого значения 3, 7 и 14)? Если да, то почему? Ведь точки, проверенные в рамках граничных значений также входят в классы и мы их уже проверили.

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

Спасибо за ответы

#2 Little_CJIOH

ФИО: Власкин Павел
Город: Санкт-Петербург

if a==5 or a==10 then тесты не проверяющие 6 и 9 не найдут косяка.

Кто так пишет? Evil Developer From Hell :)

настоятельно рекомендую к просмотру

#3 Spock

ФИО: Роман

вот это и есть скрытые классы, что 5 и 6 принадлежат разным классам

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

#4 Little_CJIOH

ФИО: Власкин Павел
Город: Санкт-Петербург

вот это и есть скрытые классы, что 5 и 6 принадлежат разным классам

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

Это не скрытые классы, это ошибка в определении границы.

#5 Spock

ФИО: Роман

"Это не скрытые классы, это ошибка в определении границы."

А ведь может быть ошибка в требованиях, может программист правильно написал код. Может "а=5 или а=10" это правильная имплементация. Неправы или требования, или код, или оба

#6 Nat8

ФИО: Наталья

if a==5 or a==10 then тесты не проверяющие 6 и 9 не найдут косяка.

Кто так пишет? Evil Developer From Hell :)

настоятельно рекомендую к просмотру

Такую кривую имплементацию мы, действительно, отловим проверкой 9. Но можно придумать другие кривые варианты закодить промежуток от 5 до 10. Например, написать, что значения a находятся в (5,6,8,9,10), пропустив число 7 внутри перечисления. И проверки 6 и 9 пройдут без проблем.

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

#7 Spock

ФИО: Роман

вроде есть ответ:

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

если в коде (а >=5 and a <=10)

тогда Теоретические тесты должны быть на 4, 5, 10, 11

если в коде набор [5, 6, 7, 8, 9, 10]

тогда Теоретические тесты должны быть 5, 6, 7, 8, 9, 10

получается без кода тестировщик даже не знает какие классы эквивалентности существуют в аппликации

НО, даже если мы знаем что используются например "больше/меньше", и создадим Правильные Теоретические тесты для "больше/меньше" это будут "4, 5, 10, 11" - то через месяц программисты могут поменять наш "больше/меньше" на набор! причём на ошибочный набор типа "[5, 6, 8, 9, 10]" пропустив "7" - и тогда наши Правильные Теоретические тесты "4, 5, 10, 11" не поймают ошибку

если набор тестов не ловит ошибку - значит это плохой набор тестов

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

#8 Little_CJIOH

ФИО: Власкин Павел
Город: Санкт-Петербург

if a==5 or a==10 then тесты не проверяющие 6 и 9 не найдут косяка.

Кто так пишет? Evil Developer From Hell :)

настоятельно рекомендую к просмотру

Это не кривая имплементация, это типовые ошибки в границах.ошибка в цифре +-1Включение/невключение границыПеревернутое сравнениеПопутанные !=, ==, <=, >=ошибка выбора and/or

#9 Little_CJIOH

ФИО: Власкин Павел
Город: Санкт-Петербург

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

#10 Spock

ФИО: Роман

вопрос на засыпку:

требования к ПО:

целые числа от 5 до 10 включительно

создать тесты используя классы эквивалентности и граничные значения

#11 Spock

ФИО: Роман

рассматриваемые возможные наборы тестов:

4, 5, 6, 7, 8, 9, 10, 11

может и какие другие с +1 и -1

нули, отрицательные и дробные и т.п. тут не будем рассматривать, их потом отдельно добавят. Нас интересуют именно тесты интервала

#12 Little_CJIOH

ФИО: Власкин Павел
Город: Санкт-Петербург

Ваш "теоретически правильный" набор тестов проверяет что? корректность работы компилятора/интерпретатора? Тесты пишутся ДО кода Тесты пишутся ПО требованиям Задача тестов проверить что код соответствует требованиям.

вопрос на засыпку:

требования к ПО:целые числа от 5 до 10 включительно

задание тестировщику:создать тесты используя классы эквивалентности и граничные значения

#13 Spock

ФИО: Роман

#14 Nat8

ФИО: Наталья

if a==5 or a==10 then тесты не проверяющие 6 и 9 не найдут косяка.

Кто так пишет? Evil Developer From Hell :)

настоятельно рекомендую к просмотру

Это не кривая имплементация, это типовые ошибки в границах. ошибка в цифре +-1 Включение/невключение границы Перевернутое сравнение Попутанные !=, ==, <=, >= ошибка выбора and/or

#15 Little_CJIOH

ФИО: Власкин Павел
Город: Санкт-Петербург

Это цитата из анекдота и ответ адекватный требованиям.

#16 Spock

ФИО: Роман

нет не предполагает отлов

в случае если программист реализовал интервал как набор [5, 6, 7, 8, 9, 10] и нечаянно пропустил "7", то эти тесты с границами +-1 ошибку не отловят

#17 Spock

ФИО: Роман

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

у многих эта задача встретится на работе при написании тестов, у многих на собеседованиях, у кого-то на экзаменах по тестированию

и видимо задача не такая простая, что ответа даже гуру не могут дать

#18 Little_CJIOH

ФИО: Власкин Павел
Город: Санкт-Петербург

if a==5 or a==10 then тесты не проверяющие 6 и 9 не найдут косяка.

Кто так пишет? Evil Developer From Hell :)

настоятельно рекомендую к просмотру

Я правильно понимаю, что тестирование (границы - 1), (границы) и (границы + 1) //1 пишу для случая целочисленного промежутка// предполагает отлов всех указанных типовых ошибок? Правда, я не могу припомнить ни одного случая, когда был перепутан and и or подобно указанному случаю. Все остальные приведенные примеры в моей практике встречались. Ну, еще кроме перепутанной цифры +-1, тк обычно если сказано "меньше 5", то "меньше 4" вряд ли напишут.

Про все не скажу, когда-то я это разбирал но это было очень давно. and и or путают в сложных комбинированых условиях с множеством параметров и скобок.+-1 это не про условия с целыми числами. Это или индексы или условия с вещественными числами, там >4 не эквивалентно >=5

#19 Little_CJIOH

ФИО: Власкин Павел
Город: Санкт-Петербург

нет не предполагает отлов

Передергиваете, вопрос был про конкретные ошибки, в которые ваш пример не попадает.

Это цитата из анекдота и ответ адекватный требованиям.

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

и видимо задача не такая простая, что ответа даже гуру не могут дать

Вы более чем небрежно сформулировали требования. предварив их префиксом "Вопрос на засыпку"Полностью анекдот звучит как:Василий Иваныч с Петькой пилотируют самолет.ВИ: - Петька, прибры!П: - 88ВИ: - Что 88?П: - А что приборы?

📎📎📎📎📎📎📎📎📎📎