Сообщений в теме: 53

[Nat8]

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

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

 

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

 

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

 

[Little_CJIOH]

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

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

https://fsharpforfunandprofit.com/pbt/

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

[Spock]

 

 

if a==5 or a==10

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

 

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

[Little_CJIOH]

if a==5 or a==10

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

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

[Spock]

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

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

[Nat8]

 

 

 

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 проверки с каждой стороны считаются достаточными? 

[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" не поймают ошибку

 

 

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

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

[Little_CJIOH]

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

[Little_CJIOH]

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

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

[Spock]

 

 

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

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

 

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

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

 

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

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

 

 

время пошло!

[Spock]

подсказка 1:

 

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

 

5, 6, 7, 8, 9, 10

4, 5, 10, 11

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

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

 

примечание:

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

[Little_CJIOH]

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

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

88

[Spock]

 

 

88

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

[Nat8]

 

 

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" вряд ли напишут.

[Little_CJIOH]

88

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

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

[Spock]

 

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

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

 

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

 

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

[Spock]

 

 

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

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

 

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

 

 

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

[Little_CJIOH]

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" вряд ли напишут.

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

[Little_CJIOH]

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

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

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

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

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

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

ЗЫ: У меня эта задача в явном виде не встречается почти никогда.

[Spock]

 

 

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

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

 

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

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

 

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

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

 

подсказка 1:

 

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

 

5, 6, 7, 8, 9, 10

4, 5, 10, 11

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

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

 

примечание:

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

 

 

 

ЗЫ: У меня эта задача в явном виде не встречается почти никогда. 

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