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

[OlgaV]

Добрый день.
Читала в книжке, не нашла.
Можно ли в тестплане сделать условный запуск тесткейсов? то есть - если тексткейс А был пройден успешно ,то можно запускать тесткейсы В и С. и наоборот - не запускать тесткейсы В и С ,если А был с ошибкой.
или надо так писать тесткейсы, чтоб эти проверки делались внутри?

[VegaX]

Вопрос в тему :)
Лично я ничего не нашел, хотя перелопатил много, и думаю что такое нужно делать внутри.

[KaNoN]

Тестплан подразумевает, что тесткейсы будут взаимонезависимы. Сам механизм работы тестплана как раз основан на том ,что каждый тесткейс запускается полностью самостоятельно. Поэтому, если уж так надо делать выполнение тесткейса по условию, то возможны варианты:
1) Либо вы реализуете управляющий скрипт в виде main функции и запускаете именно ее
2) Либо объединяете взаимозависимые тесткейсы в один, который будет в достаточной мере автономным. Тогда в тестплане он будет работать как надо и никаких условий не надо проверять

[Darkus]

Давайте разберёмся, что такое тест - план и где место тест-кейсов в этом плане.

План тестирования должен включать в себя данные по управлению процессом тестирования. В нём указываются (обычно):
-Область тестирования (какие виды тестирования будут использоваться)
-Тестируемые требования
-Список тестов (по которым будут писаться тест-кейсы)
-График работ
-Тестовое оборудование и окружение
-Кто чем занимается

Можно ли в тестплане сделать условный запуск тесткейсов?

В тестплане пишется список тестов, которые сами по себе независимые. Потому как сказано в нашей любимой книжке С.Канера - каждый тест обязан быть независимым. А тест-кейсы пишутся по списку тестов. (Я это делаю в другом документе.)
Также хотелось бы отметить, что если тест -план говорит ЧТО тестировать, КТО будет тестировать и КОГДА будем тестировать, то тест -кейсы говорят КАК именно нужно тестировать.


Пример:

В тестплане есть пункт тестирования:
1...
2....
3. Запуск приложения НашеПриложение

А в тесткейсах уже пишутся реализации этого пункта...


3. Запуск приложения НашеПриложение
3.1. Загрузить приложение НашеПриложение по пути "С:\НашеПриложение\"
3.1.1. Открыть эксплорер.
3.1.2. Найти по указанному пути файл НашеПриложение.exe
3.1.3. Дважды кликнуть по нему.
3.2. Проверить, что в реестр прописался путь.
...

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

Так вот - различайте Тесты и Действия.

Пока вы тестируете - это Тесты.
Как только эти Тесты становятся частью других тестов, то их воспринимают как Действия (и оттуда выкидывается весь проверочный код).

Т.е. благодаря этим действиям, которые подготовят нам систему - мы можем выполнить таки другой Тест.

Много получилось объяснений, возможно излишних, но надеюсь, что помог :)

[OlgaV]

Пока вы тестируете - это Тесты.
Как только эти Тесты становятся частью других тестов, то их воспринимают как Действия (и оттуда выкидывается весь проверочный код).

вот с этого места поподробнее. писать отдельно шаги с проверками и шаги без?

[KaNoN]

Не, немного не так. Darkus осветил теоретическую часть касательно тестпланов в тестировании вообще. Это общие принципы и они же реализованы в СилкТесте. И основная идея, которую следует выловить из данного сообщения, заключается в том, что тесткейс не предназначен для переиспользования или использования как часть каких-то других тесткейсов. Вы можете попробовать и убедитесь ,что testcase-функция в СилкТесте не может быть вызвана другой testcase-функцией. Кстати и там же объясняется, почему в тестплане нет условных переходов. Поэтому, если возникает необходимость как-то регулировать порядок выполнения тесткейсов, убедитесь вначале, что тесткейс все-таки содержит полный и самодостаточный сценарий для выполнения действий, а потом окажется ,что несколько тесткейсов чудесно группируются в один более крупный, но более автономный.

[KaNoN]

Пока вы тестируете - это Тесты.
Как только эти Тесты становятся частью других тестов, то их воспринимают как Действия (и оттуда выкидывается весь проверочный код).

вот с этого места поподробнее. писать отдельно шаги с проверками и шаги без?

Не, шаги, естественно с проверками. Но если набор каких-то действий переиспользуется (в контексте реализации в СилкТесте), то эти повторяющиеся фрагменты лучше вынести в отдельную функцию, в которой проверки, скажем, не такие строгие или просто часть проверок пропускается. И эту самую функцию лучше уже вызывать в тесткейсах там, где это нужно. И получается, что Тест, являющийся частью какого-то теста, становится фактически Действием.

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

[Darkus]

Не, шаги, естественно с проверками.

Не согласен.
Смотрите ещё пример.

Есть функционал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.

Спасибо, что дочитали :)

[KaNoN]

Не, шаги, естественно с проверками.

Не согласен.
Смотрите ещё пример.

Есть функционал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, но тем не менее это нужно, особенно если в этой функции выполняются какие-то критичные операции.

[OlgaV]

Хорошо, а если так -
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 тесткейсов, про которые уже известно, что они не сработают?

[VegaX]

Есть возможность остановать выполнение тест плана с тест кейса такой строчкой "@("$StopRunning") ( )". Я ее использую для своего тестового проекта, если тест не смог залогинится в аппликацию, в этом случае нет смысла продолжения тестировани.
Но, это не решает все проблемы. У меня есть регрессион тест план, что тестирует всю аппликацию. И если, например, перестала открыватся корзина, то уже нет смысла тестировать ее функциональность, а переходить к тесту других объектов и окон. К несчастью тест план этого не позволяет, поэтому надо чтобы упали ВСЕ тесты корзины (что является лишней тратой времени) и продолжилось выполнение тест плана.
Пока лучшего решения я не нашел.

[vass]

ЕМНИП в тесплане есть хранилище для данных скриптов и т.о. они могут из него что-то ситывать и сохранять в нем результат своей работы. Копайте в сторону symbols , testdata и Specifying unique and shared data.

[Darkus]

В том же примере 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 (хотя может в частном случае вылиться в него).

И если под

Проверки менее детальные и не требуют ПД1, но тем не менее это нужно, особенно если в этой функции выполняются какие-то критичные операции.

понималась такая проверка, то я согласен, что да, проверки нужны, но они не имеют отношения непосредственно к тестам T1-T17, а имеет отношение к подготовке для тестирования Ф2-Ф17.

Таким образом хотелось бы выделить следующие понятия:
Подготовка среды для тестирования.
Собственно независимые тесты.

А вообще для таких действий,

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

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

[KaNoN]

В том же примере T2 = Ф1 + Ф2 + ПД2 нужно проверить, что Ф1 будет выполнено успешно. Проверки менее детальные и не требуют ПД1, но тем не менее это нужно, особенно если в этой функции выполняются какие-то критичные операции.

Зачем проверять, что Ф1 будет выполнено успешно, если это покажет тест на Ф1? А что значит проверки менее детальные? Вы хотите сказать, что тест Т1 может пройти, а Ф1 в Т2 может не пройти? Тогда у вас тест Т1 плохо написан.

Я вообще-то говорил про случай переиспользования Ф1 (в частности в тесте Т2). В Т1 естественно нужен полный набор проверок, так как Ф1 задумывается для Т1. И я вообще-то говорил, что при переиспользовании Ф1 в других тестах достаточно делать базовые проверки, в особенности на правильность переходов между состояниями приложения. Это наиболее важный момент с точки зрения устойчивости выполнения скриптов.

Если же вы ставите Ф1 в такое условие, в котором оно может "свалиться" в тесте Т2, то опять таки, либо Т1 плохо написан, либо нужен отдельный тест на Ф1 с тем условием\состоянием, которое вы используете в Т2.

Остаётся только случай, если внешнее воздействие было на Т2 таким, что Ф1 свалилось незапланировано. А для этого подготавливается среда для начала тестирования Ф2 (входные данные,состояния и условия :-) ...)

В Силке это все реализуется функцией, у которой проверяется возвращаемое значение или отлавливается исключение. И никакой уже теории тут не надо. Вылез результат, которого не ожидали - всё, начальное условие не выполнено, а вот уже имеет ли смысл что-то дальше делать или стоит ли как-то обойти данную ситуацию - это тема другого разговора

[Darkus]

И я вообще-то говорил, что при переиспользовании Ф1 в других тестах достаточно делать базовые проверки, в особенности на правильность переходов между состояниями приложения. Это наиболее важный момент с точки зрения устойчивости выполнения скриптов.

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

В целом интересная беседа получилась, надеюсь, что
OlgaV получила ту информацию, которую хотела получить :)

Всем спасибо :)