TestPlan
#1
Отправлено 05 декабря 2006 - 17:54
Читала в книжке, не нашла.
Можно ли в тестплане сделать условный запуск тесткейсов? то есть - если тексткейс А был пройден успешно ,то можно запускать тесткейсы В и С. и наоборот - не запускать тесткейсы В и С ,если А был с ошибкой.
или надо так писать тесткейсы, чтоб эти проверки делались внутри?
#2
Отправлено 05 декабря 2006 - 19:35
Лично я ничего не нашел, хотя перелопатил много, и думаю что такое нужно делать внутри.
#3
Отправлено 06 декабря 2006 - 07:21
1) Либо вы реализуете управляющий скрипт в виде main функции и запускаете именно ее
2) Либо объединяете взаимозависимые тесткейсы в один, который будет в достаточной мере автономным. Тогда в тестплане он будет работать как надо и никаких условий не надо проверять
#4
Отправлено 06 декабря 2006 - 11:46
План тестирования должен включать в себя данные по управлению процессом тестирования. В нём указываются (обычно):
-Область тестирования (какие виды тестирования будут использоваться)
-Тестируемые требования
-Список тестов (по которым будут писаться тест-кейсы)
-График работ
-Тестовое оборудование и окружение
-Кто чем занимается
В тестплане пишется список тестов, которые сами по себе независимые. Потому как сказано в нашей любимой книжке С.Канера - каждый тест обязан быть независимым. А тест-кейсы пишутся по списку тестов. (Я это делаю в другом документе.)Можно ли в тестплане сделать условный запуск тесткейсов?
Также хотелось бы отметить, что если тест -план говорит ЧТО тестировать, КТО будет тестировать и КОГДА будем тестировать, то тест -кейсы говорят КАК именно нужно тестировать.
Пример:
В тестплане есть пункт тестирования:
1...
2....
3. Запуск приложения НашеПриложение
А в тесткейсах уже пишутся реализации этого пункта...
3. Запуск приложения НашеПриложение
3.1. Загрузить приложение НашеПриложение по пути "С:\НашеПриложение\"
3.1.1. Открыть эксплорер.
3.1.2. Найти по указанному пути файл НашеПриложение.exe
3.1.3. Дважды кликнуть по нему.
3.2. Проверить, что в реестр прописался путь.
...
Другое дело, что часть тестов не пройдёт без других "тестов".
В вышеуказанном примере - если Запуск приложения не пройдёт, то и все зависимые тесты провалятся.
Так вот - различайте Тесты и Действия.
Пока вы тестируете - это Тесты.
Как только эти Тесты становятся частью других тестов, то их воспринимают как Действия (и оттуда выкидывается весь проверочный код).
Т.е. благодаря этим действиям, которые подготовят нам систему - мы можем выполнить таки другой Тест.
Много получилось объяснений, возможно излишних, но надеюсь, что помог :)
#5
Отправлено 06 декабря 2006 - 12:23
Пока вы тестируете - это Тесты.
Как только эти Тесты становятся частью других тестов, то их воспринимают как Действия (и оттуда выкидывается весь проверочный код).
вот с этого места поподробнее. писать отдельно шаги с проверками и шаги без?
#6
Отправлено 06 декабря 2006 - 12:34
#7
Отправлено 06 декабря 2006 - 12:42
Пока вы тестируете - это Тесты.
Как только эти Тесты становятся частью других тестов, то их воспринимают как Действия (и оттуда выкидывается весь проверочный код).
вот с этого места поподробнее. писать отдельно шаги с проверками и шаги без?
Не, шаги, естественно с проверками. Но если набор каких-то действий переиспользуется (в контексте реализации в СилкТесте), то эти повторяющиеся фрагменты лучше вынести в отдельную функцию, в которой проверки, скажем, не такие строгие или просто часть проверок пропускается. И эту самую функцию лучше уже вызывать в тесткейсах там, где это нужно. И получается, что Тест, являющийся частью какого-то теста, становится фактически Действием.
В общем, я уже указал варианты решения данной проблемы. Уже проверено, что все равно к какому-то из этих вариантов рано или поздно придется прийти
#8
Отправлено 07 декабря 2006 - 05:24
Не согласен.Не, шаги, естественно с проверками.
Смотрите ещё пример.
Есть функционал1 - Ф1 и функционал2 - Ф2.
Ф2 зависит от Ф1 таким образом, что пока не выполним Ф1, то не получится сделать Ф2.
По ним нужно сделать тесты - Т1 и Т2 на Ф1 и Ф2 соотвественно.
Т1 - подразумевает Ф1 с набором Проверочных Действий для Т1 - ПД1.
Т2 - подразумевает Ф1!(не Т1) плюс Ф2 с набором проверочных действий для Т2(ПД2).
Получаем...
1. T1 = Ф1 + ПД1
2. T2 = Ф1 + Ф2 + ПД2 ( а не T1 + Ф2 + ПД2)!
Почему Ф1, а не Т1 в случае с Т2.
Потому что проверив Ф1 с помощью Т1 - мы подразумеваем (гарантируем), что Ф1 не падает. Если упадёт, то это проблема исключительно Ф1, а не Ф2. Пока не будет отлажен Ф1 - Ф2 проверять смысла нет (в общем случае, не рассматривая заглушку на Ф1). И поэтому излишне загромождать Т2 тестовыми проверками от Т1.
Спасибо, что дочитали :)
#9
Отправлено 07 декабря 2006 - 07:32
Не согласен.Не, шаги, естественно с проверками.
Смотрите ещё пример.
Есть функционал1 - Ф1 и функционал2 - Ф2.
Ф2 зависит от Ф1 таким образом, что пока не выполним Ф1, то не получится сделать Ф2.
По ним нужно сделать тесты - Т1 и Т2 на Ф1 и Ф2 соотвественно.
Т1 - подразумевает Ф1 с набором Проверочных Действий для Т1 - ПД1.
Т2 - подразумевает Ф1!(не Т1) плюс Ф2 с набором проверочных действий для Т2(ПД2).
Получаем...
1. T1 = Ф1 + ПД1
2. T2 = Ф1 + Ф2 + ПД2 ( а не T1 + Ф2 + ПД2)!
Почему Ф1, а не Т1 в случае с Т2.
Потому что проверив Ф1 с помощью Т1 - мы подразумеваем (гарантируем), что Ф1 не падает. Если упадёт, то это проблема исключительно Ф1, а не Ф2. Пока не будет отлажен Ф1 - Ф2 проверять смысла нет (в общем случае, не рассматривая заглушку на Ф1). И поэтому излишне загромождать Т2 тестовыми проверками от Т1.
Спасибо, что дочитали :)
То, что есть шаг или используется как шаг, то должно проверяться. Действия тоже должны бы проверяться, особенно в тех случаях, когда происходит переход приложения из одного состояния в другое ( нужно свести к минимуму такое явление как "полет над пропастью", когда скрипт выполняет действия и при этом не удостоверяется, что все идет так, как задумано ). Тут уже никак без проверок (теоретически можно, но ошибки, выскакиваемые при прогоне скрипта будут совсем неинформативными). В том же примере T2 = Ф1 + Ф2 + ПД2 нужно проверить, что Ф1 будет выполнено успешно. Проверки менее детальные и не требуют ПД1, но тем не менее это нужно, особенно если в этой функции выполняются какие-то критичные операции.
#10
Отправлено 07 декабря 2006 - 09:16
1. T1 = Ф1 + ПД1
2. T2 = Ф1 + Ф2 + ПД2
3. Т3 = Ф1 + Ф2 + Ф3 + ПД3
4. Т4 = Ф1 + Ф2 + Ф3 + Ф4 + ПД4
.......
20. Т20 = Ф1 + Ф2 + ...... +Ф20 + ПД20
И Т3 = False
Зачем запускать еще 17 тесткейсов, про которые уже известно, что они не сработают?
#11
Отправлено 07 декабря 2006 - 10:42
Но, это не решает все проблемы. У меня есть регрессион тест план, что тестирует всю аппликацию. И если, например, перестала открыватся корзина, то уже нет смысла тестировать ее функциональность, а переходить к тесту других объектов и окон. К несчастью тест план этого не позволяет, поэтому надо чтобы упали ВСЕ тесты корзины (что является лишней тратой времени) и продолжилось выполнение тест плана.
Пока лучшего решения я не нашел.
#12
Отправлено 07 декабря 2006 - 10:52
#13
Отправлено 07 декабря 2006 - 11:10
В том же примере T2 = Ф1 + Ф2 + ПД2 нужно проверить, что Ф1 будет выполнено успешно. Проверки менее детальные и не требуют ПД1, но тем не менее это нужно, особенно если в этой функции выполняются какие-то критичные операции.
Зачем проверять, что Ф1 будет выполнено успешно, если это покажет тест на Ф1? А что значит проверки менее детальные? Вы хотите сказать, что тест Т1 может пройти, а Ф1 в Т2 может не пройти? Тогда у вас тест Т1 плохо написан.
Если же вы ставите Ф1 в такое условие, в котором оно может "свалиться" в тесте Т2, то опять таки, либо Т1 плохо написан, либо нужен отдельный тест на Ф1 с тем условием\состоянием, которое вы используете в Т2.
Остаётся только случай, если внешнее воздействие было на Т2 таким, что Ф1 свалилось незапланировано. А для этого подготавливается среда для начала тестирования Ф2 (входные данные,состояния и условия :-) ...)
Зачем запускать еще 17 тесткейсов, про которые уже известно, что они не сработают?
А эти тесты и не будут запускаться, если при подготовке тестового окружения получим ошибку подготовки среды для тестирования.
Вот смотрите.
Ф1 - соединение клиента с сервером.
Ф2-17 - работа клиента собственно.
Понятно, что если Ф1 не сработает, то и Ф2-Ф17 не сработают.
Для Ф1 пишем Т1.
Для Ф2-Ф17 пишем на входе - нечто вроде - ЕСЛИ ЕСТЬ КОННЕКТ, ТО <T2-T17>, ИНАЧЕ <сообщение об ошибке - нет коннекта>.
Обрамление тестов Т2-Т17 в этом случае делает некоторую долю вложенности (для всех вместе, либо по отдельности), но это всё же не тест для Ф1 (хотя может в частном случае вылиться в него).
И если под
понималась такая проверка, то я согласен, что да, проверки нужны, но они не имеют отношения непосредственно к тестам T1-T17, а имеет отношение к подготовке для тестирования Ф2-Ф17.Проверки менее детальные и не требуют ПД1, но тем не менее это нужно, особенно если в этой функции выполняются какие-то критичные операции.
Таким образом хотелось бы выделить следующие понятия:
Подготовка среды для тестирования.
Собственно независимые тесты.
А вообще для таких действий,
Действия тоже должны бы проверяться, особенно в тех случаях, когда происходит переход приложения из одного состояния в другое
когда вы неуверены, что переход из состояния в другое пройдёт гладко, начните строить окружение, исходя из того, что вы уже перешли в состояние необходимое вам. А переходы вынесите либо над этими тестами, либо делайте драйвера\заглушки - иммитаторы с набором готовых данных (или как вот тут сказали - хранилища).
#14
Отправлено 07 декабря 2006 - 11:51
Я вообще-то говорил про случай переиспользования Ф1 (в частности в тесте Т2). В Т1 естественно нужен полный набор проверок, так как Ф1 задумывается для Т1. И я вообще-то говорил, что при переиспользовании Ф1 в других тестах достаточно делать базовые проверки, в особенности на правильность переходов между состояниями приложения. Это наиболее важный момент с точки зрения устойчивости выполнения скриптов.В том же примере T2 = Ф1 + Ф2 + ПД2 нужно проверить, что Ф1 будет выполнено успешно. Проверки менее детальные и не требуют ПД1, но тем не менее это нужно, особенно если в этой функции выполняются какие-то критичные операции.
Зачем проверять, что Ф1 будет выполнено успешно, если это покажет тест на Ф1? А что значит проверки менее детальные? Вы хотите сказать, что тест Т1 может пройти, а Ф1 в Т2 может не пройти? Тогда у вас тест Т1 плохо написан.
Если же вы ставите Ф1 в такое условие, в котором оно может "свалиться" в тесте Т2, то опять таки, либо Т1 плохо написан, либо нужен отдельный тест на Ф1 с тем условием\состоянием, которое вы используете в Т2.
Остаётся только случай, если внешнее воздействие было на Т2 таким, что Ф1 свалилось незапланировано. А для этого подготавливается среда для начала тестирования Ф2 (входные данные,состояния и условия :-) ...)
В Силке это все реализуется функцией, у которой проверяется возвращаемое значение или отлавливается исключение. И никакой уже теории тут не надо. Вылез результат, которого не ожидали - всё, начальное условие не выполнено, а вот уже имеет ли смысл что-то дальше делать или стоит ли как-то обойти данную ситуацию - это тема другого разговора
#15
Отправлено 08 декабря 2006 - 03:51
Конечно, лучше исключить подобные переходы из тестов :-)И я вообще-то говорил, что при переиспользовании Ф1 в других тестах достаточно делать базовые проверки, в особенности на правильность переходов между состояниями приложения. Это наиболее важный момент с точки зрения устойчивости выполнения скриптов.
Вот пример из практики - нужно протестировать передачу данных на модемах.
А связь неустойчивая и рвётся. Лучше взять эмулятор модема и на нем написать тесты, а потом по желанию перевести на модемную связь с проверками...
В целом интересная беседа получилась, надеюсь, что
OlgaV получила ту информацию, которую хотела получить :)
Всем спасибо :)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных