?

Log in

No account? Create an account

Previous Entry | Next Entry

вот скажите мне

как ботаник ботанику.
Как современная наука справляется с так называемым "отрицательным" тестированием?
Предположим по спецификации некое событие должно наступать только в том случае, если в одном ряду встречаются 4 красных кружочка.
И допустим вы отвечаете за проверку того, что система работает в соответствии с требованиями.
Вы сначала проверите, что действительно - если в один ряд поставить 4 красных кружочка, то событие неизбежно наступает. И первый раз, и при повторах.
А также вы проверите, что будет, если сразу в 2-х рядах образовалось по 4 красных кружочка. И что будет, если в одном ряду их, скажем, 10.
Потом вы проверите, что если в одном ряду есть только 3 красных кружочка, а 4-ый попал в другой ряд, то событие не наступает.
Еще вы сделаете тест, в котором в одном ряду есть 4 синих кружочка - и убедитесь, что событие по-прежнему не наступило.
Ну и для 4-е красных квадратов в одном ряду - тоже проверите.
Но вы же, черт побери, не будете делать отрицательные тесты для всех цветов видимого спектра, для всех плоских геометрических фигур и для всех сочетаний комбинаций количества предметов в соседних и далеких друг отдруга рядах.
Не будете.
А существуют ли универсальные критерии относительно "покрытия" отрицательными тестами? 

Comments

( 13 comments — Leave a comment )
shvedka
May. 26th, 2014 09:06 pm (UTC)
Мммм, мне кажется, классы эквивалентности для положительных тестов работают точно так же, как для отрицательных...
baba_lyuba
May. 27th, 2014 10:29 am (UTC)
ну вся ж проблема в том как эти классы правильно определить...
shvedka
May. 26th, 2014 09:23 pm (UTC)
А вообще универсальных критериев тестирования не бывает же, критерии определяются тест-планом, хоть положительные, хоть отрицательные. У кардиостимулятора покрытие совсем другое, нежели у флешки на сайте, в первом случае действительно вплоть до того, что тест-тим будет как чижики полное покрытие делать :))
baba_lyuba
May. 27th, 2014 10:29 am (UTC)
естественно, что в конечном итоге все упирается во время и деньги.
Как правило, люди, которые решают сколько бабла им не жалко потратить на тестирование, любят спрашивать у ответственных персон шо-то вроде "сколько человеко-дней нужно чтобы покрытие было 80%" (покрытие чего?.. но надо отвечать уверенно!), "какие риски, если мы не проверим то-то и то-то" и прочую фигню.
_layman
May. 26th, 2014 10:13 pm (UTC)
А чем отрицательные от положительных отличаются?
Всякий инпут, не имеющий смысла, должен быть отсечен фильтром (и это тоже надо тестировать :))) (но обычно это юнит-тесты)
Всякий инпут, имеющий смысл - должен быть положительно оттестирован, поскольку на всякий осмысленный инпут нужен осмысленный оутпут :)

Edited at 2014-05-26 10:15 pm (UTC)
baba_lyuba
May. 27th, 2014 10:55 am (UTC)
все горе от неточных реквайрментов.
Но мне сложно обвинять продакт менеджеров, они тоже люди :)
Особенно все плохо, если инпут ограничен лишь человеческой фантазией, а она, как известно, безгранична :) Очень сложно сказать, что мы будем считать "осмысленным" инпутом.
Когда продакт менеджер пишет "только для 4-х красных кружочков в одном ряду" - он представляет себе какой-то типичный с его точки зрения бизнес-кейс. Он может быть вообще и не в курсе того, что бывают еще какие-то редкие схожие случаи - они его не интересуют. Если даже его спросить.. не знаю.. например, "имеет ли значение размер кружочка" - он скорее всего скажет, что никогда не видел, что бывают кружки разных размеров.. С его точки зрения таких случаев просто нет.
Но с нашей-то точки зрения они есть.. Потому что на них-то все и падает. А как предусмотреть все?
javax_slr
May. 27th, 2014 05:49 am (UTC)
Есть ответ.
Сначала - о задаче. Есть чип. Большой чип. Как его тестировать? Ножек у него много, инпутов разных может прийти много, что делать?

Делают так:
1. Создают ограничения на возможный инпут, чтобы отсечь то, что прийти не может
2. Создают ассерты, чтобы при любом инпуте проверить что работает правильно
3. Запускают миллионы случайных тестов (т.е. тестов со случайным инпутом)
baba_lyuba
May. 27th, 2014 11:08 am (UTC)
"миллионы" меня пугают :(
javax_slr
May. 27th, 2014 11:11 am (UTC)
Когда тестируют чипы, для тестов держат свои сервер фармы.

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

Каждый упаший тест записывает на каком инпуте упал и можно дебажить
gava
May. 27th, 2014 07:54 am (UTC)
Один из способов отредуцировать количество тестов - это применить факторный анализ, т.е. доказать, что между входними данными существует связь.

А так, да, как говорит Паша, гоняют кучу случайных тестов.
baba_lyuba
May. 27th, 2014 12:04 pm (UTC)
печально это все.. :)
Как большой специалист по Scrum могу сказать, что короткие спринты спасут отца..:) В каждый спринт будем "обнаруживать" и чинить реально встретившийся и упавший инпут :) А те, которые не встретились - пусть так живут пока..
gava
May. 27th, 2014 12:33 pm (UTC)
Чинить и тут же добавлять соответствующий тест. За несколько спринтов обычно всё вычищается. До следующего рефакторинга :)
baba_lyuba
May. 27th, 2014 01:39 pm (UTC)
Именно!
( 13 comments — Leave a comment )