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

Добрый вечер!

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

Один из подходов тестирования граничных значений предлагает при тестировании поля, принимающего целочисленные значения в промежутке [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 проверок могут не спасти.

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

 

 

if a==5 or a==10

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

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

if a==5 or a==10

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

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

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

https://fsharpforfunandprofit.com/pbt/

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

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

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

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

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

Поясню:

если в коде (а >=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" не поймают ошибку

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

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

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

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

https://fsharpforfunandprofit.com/pbt/

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

Такую кривую имплементацию мы, действительно, отловим проверкой 9. Но можно придумать другие кривые варианты закодить промежуток от 5 до 10. Например, написать, что значения a находятся в (5,6,8,9,10), пропустив число 7 внутри перечисления. И проверки 6 и 9 пройдут без проблем. 
 
Я пытаюсь найти описание предпосылок этого подхода граница -1, граница, граница +1, но нахожу только описание что вот так надо. А почему надо..? Какого рода баги мы можем пропустить, ограничившись проверками граница -1, граница? Почему 3 проверки с каждой стороны считаются достаточными?

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

 

 

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

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

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

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

задание тестировщику:

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

время пошло!

подсказка 1:

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

5, 6, 7, 8, 9, 10

4, 5, 10, 11

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

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

примечание:

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

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

вопрос на засыпку:
 
требования к ПО:
целые числа от 5 до 10 включительно
 
задание тестировщику:
создать тесты используя классы эквивалентности и граничные значения
 
 
время пошло!

 

 

88

это троллинг?

 

 

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

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

https://fsharpforfunandprofit.com/pbt/

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

Такую кривую имплементацию мы, действительно, отловим проверкой 9. Но можно придумать другие кривые варианты закодить промежуток от 5 до 10. Например, написать, что значения a находятся в (5,6,8,9,10), пропустив число 7 внутри перечисления. И проверки 6 и 9 пройдут без проблем. 
 
Я пытаюсь найти описание предпосылок этого подхода граница -1, граница, граница +1, но нахожу только описание что вот так надо. А почему надо..? Какого рода баги мы можем пропустить, ограничившись проверками граница -1, граница? Почему 3 проверки с каждой стороны считаются достаточными?

 

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

 

88

это троллинг?

 

Я правильно понимаю, что тестирование (границы - 1), (границы) и (границы + 1) //1 пишу для случая целочисленного промежутка// предполагает отлов всех указанных типовых ошибок? 

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

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

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

 

 

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

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

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

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

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

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

https://fsharpforfunandprofit.com/pbt/

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

Такую кривую имплементацию мы, действительно, отловим проверкой 9. Но можно придумать другие кривые варианты закодить промежуток от 5 до 10. Например, написать, что значения a находятся в (5,6,8,9,10), пропустив число 7 внутри перечисления. И проверки 6 и 9 пройдут без проблем. 
 
Я пытаюсь найти описание предпосылок этого подхода граница -1, граница, граница +1, но нахожу только описание что вот так надо. А почему надо..? Какого рода баги мы можем пропустить, ограничившись проверками граница -1, граница? Почему 3 проверки с каждой стороны считаются достаточными?

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

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

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

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

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

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

 

 

Вы более чем небрежно сформулировали требования. предварив их префиксом "Вопрос на засыпку"

ок, давайте, убираем префикс: