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

[Little_CJIOH]

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

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

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

[Spock]

 

 

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

вот тут у меня и вопрос:

 

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

 

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

 

Если кандидат на позицию тестера переберёт все числа, то возможно он и не пройдёт собеседование ;) Так как от кандидата будут ожидать "теоретическое решение с интервалами и границами"

[Vasiliy]

Выделил

 

вот тут у меня и вопрос:

 

 

 

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

 

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

 

Если кандидат на позицию тестера переберёт все числа, то возможно он и не пройдёт собеседование ;) Так как от кандидата будут ожидать "теоретическое решение с интервалами и границами"

 

Ну конкретно здесь неверно найденный интервал и классы эквивалентности. Перебор вам все равно не нужен! Нужно знание работы функций. 

Вы же перебирали не весь интервал, а только до 10$, так?

[Spock]

 

Ну конкретно здесь неверно найденный интервал и классы эквивалентности. Перебор вам все равно не нужен! Нужно знание работы функций. 

Вы же перебирали не весь интервал, а только до 10$, так?

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

 

именно в нашем случае хватило перебрать даже до 1 доллара чтобы понять что за баг

 

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

 

 

 

Выделил

ну а почему такое допущение делается? это уже как "конь в вакууме"

 

мы ведь не знаем как там что обрабатывается и как будет обрабатываться в будущем после изменений

[Vasiliy]

 

Ну конкретно здесь неверно найденный интервал и классы эквивалентности. Перебор вам все равно не нужен! Нужно знание работы функций. 
Вы же перебирали не весь интервал, а только до 10$, так?

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

Выделил

ну а почему такое допущение делается? это уже как "конь в вакууме"
 
мы ведь не знаем как там что обрабатывается и как будет обрабатываться в будущем после изменений

1. Если программисты рефакторят код, то вы не пересматриваете свои тесты? Вам точно нужны тесты, которые отловят ошибки, которые еще не сделали ваши разработчики?)

2. Почему в книге сделано такое допущение это вопрос к авторам книги:)

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

[Spock]

 

 

1. Если программисты рефакторят код, то вы не пересматриваете свои тесты? Вам точно нужны тесты, которые отловят ошибки, которые еще не сделали ваши разработчики?)

 

вот что сказал Слон по этому поводу, считаю "золотые слова":

 

 

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

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

 

 

 

2. Почему в книге сделано такое допущение это вопрос к авторам книги:)

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

 

 

 

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

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

[Spock]

 

 

1. Если программисты рефакторят код, то вы не пересматриваете свои тесты? 

в идеале тестировщик должен просматривать каждый коммит в приложении, и соответственно этим коммитам менять тесты. Но в реале такое вряд ли осуществимо

[Vasiliy]

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

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

[Spock]

 

 

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

тогда странно, что книга не может даже рассказать как _правильно_ протестировать интервал от 5 до 10, целые числа... только могут рассказать как создать тесты которые будут работать только с _допущением_ что интервалы правильно определены (без указаний что во многих случаях допущение неверно)

 

получается люди читают книги и потом думают что они создают правильные наборы тестов (и я в том числе так думал)

 

если книга не может ответить на такой простой вопрос как "тесты для интервала 5-10 целые числа" - по-моему ну не очень тогда эта книга, как минимум

[Little_CJIOH]

 

Ну конкретно здесь неверно найденный интервал и классы эквивалентности. Перебор вам все равно не нужен! Нужно знание работы функций. 
Вы же перебирали не весь интервал, а только до 10$, так?

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

 

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

 

Выделил

ну а почему такое допущение делается? это уже как "конь в вакууме"
 
мы ведь не знаем как там что обрабатывается и как будет обрабатываться в будущем после изменений

 

Потому, что весь тест-дизайн - это допущения и аппеляции к здравому смыслу, статистике и теории вероятностей.
Иначе - полный перебор.
Да, не знаем, black box testing называется. Похер на реализацию, тестируем функциональность.

[Spock]

 

 

Потому, что весь тест-дизайн - это допущения и аппеляции к здравому смыслу, статистике и теории вероятностей.
Иначе - полный перебор.

так получается что иногда вот и нужно добавлять перебор. например перебрать все значения от 5 до 10, а не только граничные. Ну или перебрать суммы хотя бы несколько сотен, или ещё какой перебор

 

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

[Little_CJIOH]

 

 

 

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

тогда странно, что книга не может даже рассказать как _правильно_ протестировать интервал от 5 до 10, целые числа... только могут рассказать как создать тесты которые будут работать только с _допущением_ что интервалы правильно определены (без указаний что во многих случаях допущение неверно)

 

получается люди читают книги и потом думают что они создают правильные наборы тестов (и я в том числе так думал)

 

если книга не может ответить на такой простой вопрос как "тесты для интервала 5-10 целые числа" - по-моему ну не очень тогда эта книга, как минимум

 

А в учебниках алгебры врут что на 0 делить нельзя.

А в начальных классах уверяют что при делении остается какой-то остаток.

Вы уверенны что в вас зашел бы учебник 70% объема которого составляли бы сноски и дисклаймеры? Особенно с упоминанием ситуаций которые вы не понимаете.

 

Я вот видел тестировщика, который тестируя видеорегистратор ни разу за пол года не подключил к нему источник видеосигнала. И что-то мне подсказывает что дело не в том, что ему об этом в книге не написали.

[Little_CJIOH]

 

 

 

Потому, что весь тест-дизайн - это допущения и аппеляции к здравому смыслу, статистике и теории вероятностей.
Иначе - полный перебор.

так получается что иногда вот и нужно добавлять перебор. например перебрать все значения от 5 до 10, а не только граничные. Ну или перебрать суммы хотя бы несколько сотен, или ещё какой перебор

 

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

 

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

Истинные аксакалы постигшие дзен заводят баги ДО написания кода, а потом подтверждают что разработчики эти баги реализовали.

[Nat8]

 

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

 

 

Не поверите, была аналогичная проблема. Правда, нам повезло, потому что мы случайно поймали эту ошибку при тестировании. Как ее чинили - отдельная песня. Разработчики-аутсорсеры чинили, ошибка на 0.56 исчезала, но появлялась на 0.58. И т.д. Пока я не подняла вопрос о том, что что-то там в реализации не то и мы подтираем лужу под текущим краном вместо его починки.

 

А насчет моего изначального вопроса хочу добавить. Он возник в том числе после ревью тест-кейсов со множеством итераций, которые пока приходится проходить вручную. Соответственно, н. граница + 1 и в. граница -1 составляют 1/3 вариантов. Вот я для себя и пыталась понять, насколько больше багов отловит теория с 6 проверками, нежели с 4. По своему опыту скажу, что обычно мне было достаточно 4 точек для проверки границ. И косяки программиста типа < вместо <= или != вместо == отлавливались на ура. Если функционал критичный, конечно тестировали в хвост и в гриву, вплоть до полного перебора всех значений промежутка. Когда я писала про a in (5,6,8,9,10), я это не с потолка взяла. У нас был случай, когда примерно так и было реализовано. Т.к. разрабатывали и ревьюили аутсорсеры, а мы лишь тестировали черным ящиком, мы этот баг пропустили, тк никто не мог предположить такую "реализацию" :(