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

[Spock]

 

 

"Вопрос на засыпку"

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

[Spock]

 

 

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

 

если о самом конкретном вопросе который был задан, то Слон прав, и программист сделает эту ошибку очень легко, типа:

 

- Программист получает задание, в котором много "воды" ну и указано что "интервал" и "5" и "10"

- Программист по запарке не замечает/пропускает слово "интервал" и делает код для "=5" и "=10"

 

вот тогда и понадобятся тесты внутри интервала, чтобы обнаружить ошибку

[Vasiliy]

Вставлю свои 5 копеек.

 

Тестировать границы и +-1. Внутри интервала одно любое значение.

Все - не надо!

Ответ на вопрос "Почему не надо все?":

Если интервал 5 - 10, то у вас будет минимум значений. Если же интервал 10 - 1000000, то вы тоже будете тестировать перебором? Это лишено смысла.

Для исключения перебора и сделаны модели тестирования. Данная модель предполагает, что программист делал условия A>5 and A<10. И мог напутать знаки равенства, не дай Бог. Если мы делаем допущение, что разработчик из злого умысла задал интервал [5..7], [9..10] и упустил 8, то наша модель не работает в принципе. Мы исходим из того, что разработчик нам не враг. Если он враг, то мы переходим в тестирование безопасности и там другие тесты.

[Spock]

"Мы исходим из того, что разработчик нам не враг. "

Не враг. Но вот не задумался о наших тестах когда зарефакторил код, а именно: поменял интервал на набор. Понадеялся вот тоже на НАШИ тесты которые типа "зафейлятся" если он допустит ошибку

Ведь наши тесты вроде как должны ловить ошибки? Значит и пропущенную семёрку должны поймать? Или не должны?

[Spock]

"Если мы делаем допущение, что разработчик из злого умысла задал интервал [5..7], [9..10] и упустил 8, то наша модель не работает в принципе."

Логика тут такая что разработчик задал набор [5, 6, 8, 9, 10] чтобы "улучшить" код, и только случайно упустил "7". Наборы в программировании вообще склонны к "исчезновению" нужных элементов, либо к добавлению ненужных

[Vasiliy]

Ок. Исходные данные меняются с набора целых чисел на набор рациональных. Интервал тот же. Что теперь должны ловить ваши тесты в случае допущения полного перебора?

[Vasiliy]

"Мы исходим из того, что разработчик нам не враг. "

Не враг. Но вот не задумался о наших тестах когда зарефакторил код, а именно: поменял интервал на набор. Понадеялся вот тоже на НАШИ тесты которые типа "зафейлятся" если он допустит ошибку

Ведь наши тесты вроде как должны ловить ошибки? Значит и пропущенную семёрку должны поймать? Или не должны?

На мой текущий взгляд - не должны. Точнее должны, но не поймают:)

Готов выслушать и обсудить другую точку зрения.

[Spock]

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

"На мой текущий взгляд - не должны. Точнее должны, но не поймают:)
Готов выслушать и обсудить другую точку зрения."

Тут уже получается философский вопрос - должны ли тесты быть такими чтобы найти баги? Или тесты должны быть "по книжке" и "согласно модели", чтобы получить "полное покрытие", несмотря на неспособность найти баги?

Какие тесты принесут value?

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

[Vasiliy]

1. Если не усложнять, то да интервал из 5 цифр стоит проверить весь)
Но это же не реальная задача.
2. Зачем менять модель на неправильную, если предыдущая уже обкатана?
3. Пример из личного опыта. Идет разработка системы для заказчика. Есть функционал отправки почтовых извещений. Все протестировано и работает. Систему ставят на боевой стенд и у заказчика не ходят письма.
Начинаем разбираться. Выяснилось, что наши разрабы использовали службу Яндекса для отправки писем, а у заказчика свой закрытый контур и там стоит почтовый сервак еще под DOS и 20-ти летней давности. И он нашу программу не вразумеет))
Есть ли претензии к тестированию? Могли ли найти такой баг заранее?

[Freiman]

 

Есть ли претензии к тестированию? Могли ли найти такой баг заранее?

Ну если в требованиях не было оговорено, какие технологии надо использовать для отправки писем - то претензии к аналитикам :)

[Vasiliy]

Технологии в требованиях не оговаривались, насколько я помню.

[Spock]

 

 

1. Если не усложнять, то да интервал из 5 цифр стоит проверить весь)
Но это же не реальная задача.

это задача реальная/близка к реальной. очень часто в программе есть интервалы и наборы

 

тут вопрос больше "какие должны быть тесты". Если проверим все 5 цифр, то тесты будут ловить больше багов, но зато "по теории" у нас будут лишние тесты

 

 

 

2. Зачем менять модель на неправильную, если предыдущая уже обкатана?

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

[Spock]

история из серии "мы сделали тесты по книжке, а зря"

 

тестировался шлюз платежей, суммы от 0.01 до 9999999999.99

 

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

 

аналитики пробовали руками, всё работает как часы

 

подключили клиента

 

через некоторое время посыпались жалобы: "ошибка на 1 цент в сумме платежа"

 

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

 

например посылаешь 0.56 на шлюз - и получаешь 0.57 на выходе! Хотя 0.55 выходит как 0.55, и 0.57 выходит как 0.57!

 

быстренько создали юнит тест который перебирает все суммы например до 10.000, с интервалом в 1 цент - и оказалось что 5% всех сумм обрабатываются с ошибкой в 1 цент! Например на первом долларе это были 0.56 0.63 0.74 0.83 0.95 - и так далее...

 

отдебажили, сумма хранится в BigDecimal, и функция перевода в сумму "без центов" и обратно с центами перемножала на 100 и делила на 100, в результате в BigDecimal только на некоторых числах происходила потеря точности в 1 цент!

 

Что получается: протестировали "по книжке", и в результате критическая ошибка попала в продакшн, фирма понесла потери (имиджевые в основном, и на хотфикс и релиз, и на восстановление правильных данных и возвраты этих центов)

 

Вопрос: где же тут прокол? почему так получилось?

[Little_CJIOH]

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

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

Убранный префикс не отменяет того, что эти требования относятся к годным к работе, примерно, как 88 ко всему анекдоту.

[Little_CJIOH]

история из серии "мы сделали тесты по книжке, а зря"
 
тестировался шлюз платежей, суммы от 0.01 до 9999999999.99
 
сделали автотесты по лучшим практикам, конечно используя эквивалентные партиции (так как знали что метод обработки для любых чисел тот же самый): то есть тестировались верхние и нижние границы, ну и плюс несколько значений в середине для спокойствия. Автотесты зелёные, все суммы правильные
 
аналитики пробовали руками, всё работает как часы
 
подключили клиента
 
через некоторое время посыпались жалобы: "ошибка на 1 цент в сумме платежа"
 
все забегали, не понимают как такое возможно, но воспроизводится на деве
 
например посылаешь 0.56 на шлюз - и получаешь 0.57 на выходе! Хотя 0.55 выходит как 0.55, и 0.57 выходит как 0.57!
 
быстренько создали юнит тест который перебирает все суммы например до 10.000, с интервалом в 1 цент - и оказалось что 5% всех сумм обрабатываются с ошибкой в 1 цент! Например на первом долларе это были 0.56 0.63 0.74 0.83 0.95 - и так далее...
 
отдебажили, сумма хранится в BigDecimal, и функция перевода в сумму "без центов" и обратно с центами перемножала на 100 и делила на 100, в результате в BigDecimal только на некоторых числах происходила потеря точности в 1 цент!
 
Что получается: протестировали "по книжке", и в результате критическая ошибка попала в продакшн, фирма понесла потери (имиджевые в основном, и на хотфикс и релиз, и на восстановление правильных данных и возвраты этих центов)
 
Вопрос: где же тут прокол? почему так получилось?

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

ЗЫ: я такую ситуацию встречал дважды. Первый раз сам аккуратно обошел как разработчик, второй - не позволил выпустить в продакшен как тестировщик.

ЗЗЫ: в начале топика я приводил ссылку на видео. Еще раз настоятельно рекомендую посмотреть, там мало того что полезный материал на тему, так еще и докладчик жжет напалмом.

[Spock]

 

 

Убранный префикс не отменяет того, что эти требования относятся к годным к работе, примерно, как 88 ко всему анекдоту. 

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

 

просто задачка, например интервьюер попросит кандидата на позицию тестировщика решить за пару минут. Интервьюер например захочет узнать разбирается ли кандидат в тестировании

[Spock]

 

 

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

смотри:

 

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

[Spock]

 

 

ЗЫ: я такую ситуацию встречал дважды. Первый раз сам аккуратно обошел как разработчик, второй - не позволил выпустить в продакшен как тестировщик.

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

 

НО, если создать набор тестов "по теории", "по книжке", используя только границы - тогда баги пойдут в прод

[Little_CJIOH]

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

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

Значит не нашлось человека который ткнул бы пальцем в эти переходы и сказал вот здесь мы можем иногда терять цент, особенно на переходе из центов в доллары.
Как в итоге решили? преобразованием через строку? деление нацело с остатком? вместо /100 *10/1000 ?

[Spock]

 

 

Значит не нашлось человека который ткнул бы пальцем в эти переходы и сказал вот здесь мы можем иногда терять цент, особенно на переходе из центов в доллары.
Как в итоге решили? преобразованием через строку? деление нацело с остатком? вместо /100 *10/1000 ? 

да, не заметили при кодировании, хотя и был код-ревью. Наверное потому что "работало" (ну точнее все думали что алгоритм работает). и потом не заметили на тестах, так как фокусировались на границах и пара значений в середине

 

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