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

[VDmitry]

Простой пример.

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

Так вот чтобы это сделать, мне пришлось писать отдельную функцию инициализации, которую и вызывать первой строкой в тесткейсах. Так какую роль играет механизм аппстейтов во всем этом, если их длвя всех тесткейсов мне пришлось всеравно вырезать (appstate none)

В чем соль?

[Dmitry_NS]

Простой пример.

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

Так вот чтобы это сделать, мне пришлось писать отдельную функцию инициализации, которую и вызывать первой строкой в тесткейсах. Так какую роль играет механизм аппстейтов во всем этом, если их длвя всех тесткейсов мне пришлось всеравно вырезать (appstate none)

В чем соль?

Соль в том, что имеющиеся средства надо использовать тогда, когда они нужны, а не ради того, чтобы их использовать в принципе. Так, например, в СилкТесте есть такое ключевое слово как rendezvous, но если у вас нет задачи распараллеливать выполнение некоторых участков кода, то вам это ключевое слово использовать просто не нужно. То же самое и с аппстейтами. Вы задизайнили свои тесты, чтобы нужные параметры передавались из тестплана. Стало быть, если вам и нужны аппстейты, то они должны выполнять действия, не зависящие от передаваемых данных. Что это может быть?

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

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

Если в приложении подразумевается авторизация пользователя, то вполне логичным будет завести некоторого основного тестового пользователя, с которым будут работать большинство тестов (как правило, с максимальными правами, чтоб иметь доступ ко всем тестируемым компонентам приложения).
Логин и пароль этого пользователя можно занести в некоторые глобальные переменные, их можно считывать из внешнего файла, А уже аппстейт запустит приложение и залогинится под пользователем по умолчанию. А там уже перелогиниться тоже не проблема.

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

[VDmitry]

Вот напримере аппстейта для логина - как раз ну никак не катит. Я знаком с методом тестирования одним юзером с максимальными правами. Но этого как-то недостаточно. Поэтому у меня каждый тесткейс имеет дополнительный параметр - под каким юзером его выполнять. А в начале тесткейса - вызов функции (не аппстейта), которая логинится данным юзером. Аппстейты так не умеют - не знают они под кем логиниться (или нужно делать свой аппстейт под каждого юзера, и свой тесткейс затем под каждый аппстейт). А коль не умеют, и мне всеравно фызов функции инициализации писать, то какой смысл юзать и фунцию инициализации, и функцию аппстейта?

Но идея о том, что можно и не использовать - понятна.

[Dmitry_NS]

Вот напримере аппстейта для логина - как раз ну никак не катит. Я знаком с методом тестирования одним юзером с максимальными правами. Но этого как-то недостаточно. Поэтому у меня каждый тесткейс имеет дополнительный параметр - под каким юзером его выполнять. А в начале тесткейса - вызов функции (не аппстейта), которая логинится данным юзером. Аппстейты так не умеют - не знают они под кем логиниться (или нужно делать свой аппстейт под каждого юзера, и свой тесткейс затем под каждый аппстейт). А коль не умеют, и мне всеравно фызов функции инициализации писать, то какой смысл юзать и фунцию инициализации, и функцию аппстейта?

Когда я говорил про использование основного юзера, я подразумевал, что его данные будут либо занесены с глобальные переменные явно, либо считаны из заготовленного конфига на этапе, предшествующем запуску аппстейта (например, при вызове функции ScriptEnter). В этом случае аппстейт уже может знать о данных пользователя. Соответственно, большинство тестов, где данные пользователя нужны просто для залогинивания не будет требовать передачи параметров из тестплана. Если же нужно те же тесты скопом прогнать для разных пользователей, то можно сделать несколько конфигов, пути к ним занести в опции (есть опции для Compiler Constants), что потом можно сохранить в файл опций. А для тестпланов есть директива optionset, которая подгружает нужный файл с настройками СилкТеста. То есть аппстейт за вас уже решит, под кем логиниться. Но факт в том, что аппстейты должны уже заранее знать все нужные данные (причем внешние). Как это сделать, я написал.

[VDmitry]

optionset вполне вероятно будет ответ на мой вопрос. Спасибо.

Но хотелось бы обсудить другую сторону вопроса. Помимо логинов, мои функции инициализации получают еще один параметр - имя стартового окна. Я вообще сделал следующую структуру объяления окон:

myBaseClass - описывает универсальный таг (годится для любого окна сайта) для browserchild и всю "шапку" страницы, которая юзается везде

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

В итоге, если функция инициализации (ну или пусть аппстейт), получает в качестве имени страницы "wNews", то она проверяет сперва wNews.Exists(), если того нет то, wBase.Exists() и т.д. Кстати, насколько удачно я нагородил иерархию для веб-приложения?)

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

...
testcase: test1(<user1ID>, <window1ID>, ...)
testcase: test1(<user2ID>, <window1ID>, ...)
testcase: test1(<user1ID>, <window2ID>, ...)
testcase: test1(<user2ID>, <window2ID>, ...)
...

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

USER 1 ENTER
TESTSTATE Init
USER 2 ENTER
USER 1 CONT
SET button1.Click 1
USER 2 CONT
WAIT
TESTSTATE Action1Done
USER 1 QUIT
USER 2 QUIT

[Dmitry_NS]

optionset вполне вероятно будет ответ на мой вопрос. Спасибо.

Но хотелось бы обсудить другую сторону вопроса. Помимо логинов, мои функции инициализации получают еще один параметр - имя стартового окна. Я вообще сделал следующую структуру объяления окон:

myBaseClass - описывает универсальный таг (годится для любого окна сайта) для browserchild и всю "шапку" страницы, которая юзается везде

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

В итоге, если функция инициализации (ну или пусть аппстейт), получает в качестве имени страницы "wNews", то она проверяет сперва wNews.Exists(), если того нет то, wBase.Exists() и т.д. Кстати, насколько удачно я нагородил иерархию для веб-приложения?)

Идея понятна. Насчет иерархии. Возможно, дополнительные классы-наследники некоторого базового класса уже немного лишние, особенно, если конкретный экземпляр данного класса всего в единственном экземпляре. Тут уже можно описывать прямо окном. Например, у нас есть некоторый базовый класс:

winclass MyClass:BrowserChild
		 tag "some tag"
		 // Здесь уже общие элементы для класса

Если нам после этого надо будет описать окно, которое основано на данном классе, но с небольшими дополнениями, при этом окно в единственном экземпляре, то в этом случае лучше все-таки объявлять окно:

window MyClass MyWin
	   tag "some specific tag" // опционально. Если устраивает тег винкласса, то тут тег переопределять необязательно

	   // Здесь уже объявление специфических элементов окна

То есть классы мы штампуем до тех пор, пока есть необходимость испоользовать более одного экземпляра данного класса

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

...
testcase: test1(<user1ID>, <window1ID>, ...)
testcase: test1(<user2ID>, <window1ID>, ...)
testcase: test1(<user1ID>, <window2ID>, ...)
testcase: test1(<user2ID>, <window2ID>, ...)
...

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

[VDmitry]

То есть классы мы штампуем до тех пор, пока есть необходимость испоользовать более одного экземпляра данного класса

Выгода только в уменьшении количества объявлений? Наверное это просто привычка у меня такая, сперва определить тип, а потом переменную данного типа.

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

...
testcase: test1(<user1ID>, <window1ID>, ...)
testcase: test1(<user2ID>, <window1ID>, ...)
testcase: test1(<user1ID>, <window2ID>, ...)
testcase: test1(<user2ID>, <window2ID>, ...)
...

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

Ну этот параметр "определить" нельзя. Он задается на уровне тестплана, с целью _задать_ на какой странице начинать выполнение тесткейса. Например хоть у всех страниц и есть шапка с набором общих линков, один тест может проверять их работоспособность с разных страниц.

[Dmitry_NS]

То есть классы мы штампуем до тех пор, пока есть необходимость испоользовать более одного экземпляра данного класса

Выгода только в уменьшении количества объявлений? Наверное это просто привычка у меня такая, сперва определить тип, а потом переменную данного типа.

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

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

Да, и насчет привычки определять тип, а затем экземпляр. Учтите такую вещь, что winclass от класса отличается тем, что класс формирует тип данных, а winclass формирует тип окна и применяется исключительно к величинам типа WINDOW и то при объявлении.

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

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

Ну этот параметр "определить" нельзя. Он задается на уровне тестплана, с целью _задать_ на какой странице начинать выполнение тесткейса. Например хоть у всех страниц и есть шапка с набором общих линков, один тест может проверять их работоспособность с разных страниц.

Ааа, то есть все упирается в начальную навигацию? Оставьте этот параметр и выполняйте навигацию в самом начале тесткейса. А в аппстейт вынесите только код, по которому будете открывать приложение и логиниться (если это возможно). Вполне сносно.

Есть другой вариант. Если у вас тест один и тот же, но выполняется на разных страницах, то вполне логично вынести его в отдельную функцию, затем наплодить тесткейсов, которые тупа вызывают эту функцию с разными параметрами. А навигацию на нужную страницу реализовать в виде аппстейта. Я уже видел вполне нормальную реализацию, когда было много аппстейстов, ответственных за переход на некоторую начальную страницу, с которой начиналось выполнение тесткейса. Это, возможно, потребует реструктуризации ваших скриптов, но таким образом вы вполне можете избавиться от параметров в тестплане. Вам останется только указать optionset.

[VDmitry]

Есть другой вариант. Если у вас тест один и тот же, но выполняется на разных страницах, то вполне логично вынести его в отдельную функцию, затем наплодить тесткейсов, которые тупа вызывают эту функцию с разными параметрами. А навигацию на нужную страницу реализовать в виде аппстейта. Я уже видел вполне нормальную реализацию, когда было много аппстейстов, ответственных за переход на некоторую начальную страницу, с которой начиналось выполнение тесткейса. Это, возможно, потребует реструктуризации ваших скриптов, но таким образом вы вполне можете избавиться от параметров в тестплане. Вам останется только указать optionset.

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

[Dmitry_NS]

Есть другой вариант. Если у вас тест один и тот же, но выполняется на разных страницах, то вполне логично вынести его в отдельную функцию, затем наплодить тесткейсов, которые тупа вызывают эту функцию с разными параметрами. А навигацию на нужную страницу реализовать в виде аппстейта. Я уже видел вполне нормальную реализацию, когда было много аппстейстов, ответственных за переход на некоторую начальную страницу, с которой начиналось выполнение тесткейса. Это, возможно, потребует реструктуризации ваших скриптов, но таким образом вы вполне можете избавиться от параметров в тестплане. Вам останется только указать optionset.

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

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