testomat.io управление авто тестамиhttp://automated-testing.info/knowledgebase/article/avtotesting-i-test-dizajn Второй пункт в списке из текста по ссылке подразумевает независимость тестов для того, чтобы в случае обнаружения ошибки при тестировании можно было избежать появление "эффекта домино" и продолжать выполнять тесты из пакета. Всвязи с чем возник вопрос. Насколько целесообразно продолжать выполнять тесты при обнаружении ошибки? Зачем это нужно? Не будет ли это бессмысленным? Если скрипт обнаружил баг, то, кроме создания скриншота экрана, который может дать неполную картину или может быть сделан не совсем в тот момент, было бы полезно остановить выполнение скрипта, чтобы на экране остались следы ошибки, например, сообщение об ней. То есть в случае дальнейшего выполнения снижается информативность. "Вывод, осуществляемый тестом, должен быть информативным - хорошо написанный тест после выполнения позволит указать, были ли ошибки, если были, то выдаст сообщение, четко объясняющее проблему, а также место возникновения ошибки" (отсюда http://automated-testing.info/knowledgebase/article/avtotesty-kriterii-zavershennosti). Поведение приложения при его выходе из строя определить никак нельзя, оно может быть любым. Поэтому непонятно, каким образом можно откатить для проведения следующего теста программу из состояния, которое невозможно детерминировать?
Отвечая на вопрос целесообразности, все зависит от ваших тестов. Если тесты полностью независимы, то тогда нахождения одного бага недолжно останавливать выполнения всех тестов, зачем?! Ведь там может быть еще баги в другой области и цель не найти один баг и остановиться, а пройтись по всей функциональности и определить ее состояние.
Иначе, что получается, вы запустили 100 тестов, на 10м нашли баг, остановились и ждете когда баг пофикситься. Как только пофиксили багу, вы снова запускаете все тесты (потому что фикс может поламать и функциональность которая работала до этого) и 10й прошел, а вот 11 свалился - нашел еще один баг. Так можно запускать вечность.
Согласен, в случае, например, если вы тестируете одну и ту же функциональность, только с разными наборами данных, то найденный баг может определять последующее выполнение всех тестов. Или же вы проганяете смоук тесты, которые проверяют базовую функциональность, тут тоже найденный баг может определять последующее выполнение.
А на счет восстановления состояния, для каждого теста есть начальные условия. Нарпимер, интернет-магазин, для покупки вам надо аккаунт. Для теста покупки товара вы каждый раз создаете аккаунт. Так вот, вы создали аккаунт (т.е. данные), произошел баг и все что вам нужно сделать в этом случае удалить аккаунт из системы, т.е. как было до того как тест был запущен.
После нахождения бага разумно занести его в трекер и до починки временно исключить из пакета 10й тест и все идущие до него (результат их работы получен) и дальше прогонать остальные 90 (результата по ним не было). После починки этого бага снова прогнать все тесты (проверка на регрессию). Если этот баг пока не пофиксен, а пофиксен другой, ранее найденный, прогнать все тесты кроме 10 и в случае успешного результата 10й прогнать отдельно. Дольше, но качественнее.
Да, я имел ввиду тестирование одной фунуциональности.
По поводу восстановления состояния: создание аккаунта каждый раз для новой покупки выглядит разумным с точки зрения независимости (и корректности запуска их набора). Но каждый из тестов распухает - создать юзера, сделать покупку, удалить юзера. Суммарное время прогона пакета, особенно, если он большой, ощутимо увеличивается. Тоже дольше, но качественнее.
После нахождения бага разумно занести его в трекер и до починки временно исключить из пакета 10й тест и все идущие до него (результат их работы получен) и дальше прогонать остальные 90 (результата по ним не было). После починки этого бага снова прогнать все тесты (проверка на регрессию). Если этот баг пока не пофиксен, а пофиксен другой, ранее найденный, прогнать все тесты кроме 10 и в случае успешного результата 10й прогнать отдельно. Дольше, но качественнее.
Исходный посыл был по поводу независимости тестов. В первую очередь это подразумевает, что каждый отдельно взятый тест работает одинаково, как отдельно, так и при пакетном запуске на любом наборе тестов и не использует данные/артефакты, полученные другим тестом. Если у вас этого нет, то описанный вами сценарий не сработает, так как далеко не все тесты получится исключить безболезненно. Если все-таки такая автономность наблюдается, то зачем такие волнообразные запуски вообще, если можно сразу прогнать всё, выявить все баги по результатам одного прогона и просто потом запустить отдельные тесты, чтобы проверить, что баги пофикшены? Качество то же, а времени требуется на порядок меньше (в вашем сценарии время проведения тестирования экспоненциально растет при росте числа багов).
По поводу восстановления состояния: создание аккаунта каждый раз для новой покупки выглядит разумным с точки зрения независимости (и корректности запуска их набора). Но каждый из тестов распухает - создать юзера, сделать покупку, удалить юзера. Суммарное время прогона пакета, особенно, если он большой, ощутимо увеличивается. Тоже дольше, но качественнее.
Это вообще подход к подготовке данных. Тут главное не вдаваться в крайности. Существование каких-то данных в системе изначально может быть обеспечено дампом базы. То у нас есть окружение, в котором загружаются данные с некоторого дампа. То есть некоторые данные уже изначально подразумеваются существующими в системе.
Что-то надо предварительно создать.
Если мы делаем какие-то настройки, то в конце мы можем их восстановить в исходное состояние.
В-общем, это просто надо выработать подход к подготовке данных и recovery. Тут нужно выдержать баланс, чтобы если уж тесты и распухают, то в разумных пределах. Время прогона тестов возрастет, естественно. Но в ряде случаев все-таки стоит задуматься и о надежности тестов, ведь вам врядли понравиться по десять раз из-за всяких мелких чихов перезапускать одни и те же тесты.
KaNoN, спасибо за пояснения. Честно говоря, у меня есть некоторые иррациональные опасения потерять возможность перевоспроизвести баг на упавшем тесте. А вдруг не повторится? То есть тестируемая программа в этом случае конечный автомат, но недетерминированный (при одинаковом входе дает разные выходы). Например, (чисто гипотетически) если в программе рандомизировать размер выделяемой памяти, то падать она будет в случайные моменты времени, если память в один из них не выделится. Неясно, как учитывать подобную возможность?
Если при подобной ошибке снимок экрана был сделан не совсем в тот момент, когда на экране находился сигнал об ошибке (например, он быстро исчез или не появлялся), то никакой информации об ошибке за исключением ее существования прогон теста не дает. Всвязи с чем возникает вопрос о необходимости использования дополнительного ПО для создания периодических снимков экрана и их сохранения. В документации WinRunner (как пример) я подобную функцию не нашел.
KaNoN, спасибо за пояснения. Честно говоря, у меня есть некоторые иррациональные опасения потерять возможность перевоспроизвести баг на упавшем тесте. А вдруг не повторится?
Ну почему же опасения иррациональны? Опасаться есть чего. Например, есть такой класс ошибок, как ghost bug, который воспроизводится крайне редко, спонтанно.
То есть тестируемая программа в этом случае конечный автомат, но недетерминированный (при одинаковом входе дает разные выходы). Например, (чисто гипотетически) если в программе рандомизировать размер выделяемой памяти, то падать она будет в случайные моменты времени, если память в один из них не выделится. Неясно, как учитывать подобную возможность?
Зависит от того, что вы тестируете. Например, если вы проверяете работоспособность системы при выделении определенного количества памяти, то этот показатель лучше не рандомизировать, а наоборот сделать фиксированным, чтобы четко проследить сценарии поведения. Это как пример. А вообще идея проста: нужно четко представлять цели, для которых делается каждый конкретный тест и все, что касается непосредственно проверяемых элементов, нужно как можно четче детерминировать. В этом случае, если у вас и будут какие-то спонтанные ошибки, то они скорее всего не будут связаны именно с проверяемым функционалом.
Если при подобной ошибке снимок экрана был сделан не совсем в тот момент, когда на экране находился сигнал об ошибке (например, он быстро исчез или не появлялся), то никакой информации об ошибке за исключением ее существования прогон теста не дает. Всвязи с чем возникает вопрос о необходимости использования дополнительного ПО для создания периодических снимков экрана и их сохранения. В документации WinRunner (как пример) я подобную функцию не нашел.
На самом деле снимок экрана - это далеко не единственный способ снятия ошибки. Например, еще есть различные логи, которые тоже можно было бы просмотреть. А периодические снимки экрана могут даже помешать. Представьте, что снимок делается, допустим раз в минуту, а тест выполняется час (для WinRunner-a вполне реально). Уже имеем 60 снимков. Так ненароком утонуть можно в этом наборе скриншотов. Я думаю, что вопрос детальности описания ошибки решается путем более детализированных проверок. В вашем случае это возможно, так как WinRunner от ошибки может и не прекращать выполнение теста (для примера, в тех же JUnit и им подобных движках после Assert-a выполнение теста останавливается). Соответственно, у вас будет не одна строчка ошибки, а некоторый набор.