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

[Pet]

Привет, может кто-нибудь может помочь.

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

[-] window BrowserChild Window1
    [ ] tag 'Window1'
    [-] HtmlTable Table	
	[ ] tag "#1"
  [-] HtmlColumn Column1
 	 [ ] tag "#1"
 	 [-] HtmlPopupList PopupList1
    [ ] tag "#1"
 	 [-] HtmlTextField Field	
 	 [ ] tag "#1"
  [-] HtmlColumn Column2
 	 [ ] tag "#2"
 	 [-] HtmlPushButton Submit
 	 [ ] tag "#1"

в другом - без таблички:

[-] window BrowserChild Window1
	[-] tag 'Window1'
  [-] HtmlPopupList PopupList1
 	 [ ] tag "#1"
  [-] HtmlTextField Field
 	 [ ] tag "#1"
  [-] HtmlPushButton Submit
 	 [ ] tag "#1"

Можно ли как-нибудь описать эти контролы один раз, чтобы Силк находил их в любом из этих случаев? Я пробовала так:

[-] HtmlTextField Field
   [-] multitag  "[HtmlTable]#1/[HtmlColumn]#2/[HtmlTextField]
#1"                  [ ] [HtmlTextField]#1"

Но так не работает: во стором случае филд не находит.

[KaNoN]

Тут может быть одна из 2-х проблем:
1) Неоптимальные настройки таблиц.
2) Реально изменчивый контент.

В первом случае нужно убедиться, что на странице таблицы реально есть (просмотр ХТМЛ-кода). Если они имются, значит это проблема с низким значением уровня распознавания таблиц без border-ов. Для настройки уровня выбираем меню Options > Extensions , в появившемся диалоге выбираем нужный броузер и жмем кнопку Extensions. В появившемся окне будет ползунок. Его можно установить в достаточно высокое значение (можно и максимум, если не накладно). Если таблицы есть, то они увидятся.

Во втором случае нужно поиграться с тегами. Можно вот этот текст:

HtmlTextField Field
  [-] multitag  "[HtmlTable]#1/[HtmlColumn]#2/[HtmlTextField]#1" 
                 [ ] [HtmlTextField]#1"

перекорежить вот так:

HtmlTextField Field
  [-]tag  "[HtmlTextField]#1|[HtmlTable]#1/[HtmlColumn]#2/[HtmlTextField]#1"

Это примерно то же самое, что и мультитэг, только в линейной записи.

На худой конец можно написать функцию, которая определяет какой из вариантов тэгов соответствует существующему окну и применить её следующим образом:

[+]HtmlTextField Field
           [ ]tag OneOfTheTags(wParent,{"[HtmlTextField]#1","[HtmlTable]#1/[HtmlColumn]#2/[HtmlTextField]#1"})

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

P.S.Проверь сначала настройки, затем попробуй таги записать через "или", а если нет, то 3-й вариант.

[Pet]

Спасибо за ответ.

В первом случае нужно убедиться, что на странице таблицы реально есть (просмотр ХТМЛ-кода). Если они имются, значит это проблема с низким значением уровня распознавания таблиц без border-ов.

Уровень borderless table достаточно высок = 0,96. Именно при таком значении у меня получилось распознать все необходимые таблицы. А при более высоком я получаю огромное количество вложенных таблиц. На самом деле описанные мною случаи - это просмотр одной и той же страницы под разными юзерами. Одни из них видит на один контрол больше - именно в этом случае силк тест распознает там табличку. Если поставить уровень borderless table ниже, то все контролы распознаются одинаково для все юзеров -без таблицы, но в этом случае не распознается таблица с данными, которая находится ниже. Вот такая вот загогулина получается...

Во втором случае нужно поиграться с тегами.

HtmlTextField Field
  [-]tag  "[HtmlTextField]#1|[HtmlTable]#1/[HtmlColumn]#2/[HtmlTextField]#1"

Это примерно то же самое, что и мультитэг, только в линейной записи.

к сожалению не получилось. Такая же ошибка что и при использовании мультитэга. При попытке написать что-нить в поле "[HtmlTextField]#1" я получаю ошибку: *** Error: Window '[HtmlTable]#1' was not found.


Все-таки придется писать функцию, а так хотелось сделать это красиво -через декларацию.

Еще раз спасибо за ответ.

[KaNoN]

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

Я недавно разбирался с подобной проблемой, но решением было только использование юзера с правами администратора

[Pet]

Силк тест запускается под одним и тем же пользователем с админскмим правами. Я наверно непонятно написала, под юзерами я имела ввиду
разные логины для работы с самим приложением.

[KaNoN]

М-да, с логинами для работы с Силкм я не сталкивался, но скорее всего проблема сходная. Либо нужно использовать только тот логин, на котором все таблицы видятся, либо (если есть необходимость работать с разными юзерами) придется таки писать функцию. Если вариации тэгов на одном уровне еще можно сделать использованием "или" в тэгах, то прыжки по иерархии делаются более изощренными способами

[VegaX]

Можно попробовать сделать через инициализацию тага при запуске тест кейза в зависимости от запущеного юзера. Т.е.

const STRING sUserTag = LOGGED_USER == "User1" ? "":"[HtmlTable]#1/[HtmlColumn]#2/"

HtmlTextField Field
 [-]tag  "{sUserTag}[HtmlTextField]#1"

Если юзеров больше чем 2, то тогда лучше создать функцию, которую тоже можно вставить в декларацию. Пример:

STRING GetLoggedUserTag()
  STRING sRet = ""
  switch LOGGED_USER
    case "User1", "User3"
       sRet = ""
    case "User2"
       sRet = "[HtmlTable]#1/[HtmlColumn]#2/"
  return sRet

В отличии от OneOfTheTags - тебе не нужно родительское окно, а также не нужно никаких обращений к обьектам Браузера, что повысит производительность скриптов.

[KaNoN]

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

В отличии от OneOfTheTags - тебе не нужно родительское окно, а также не нужно никаких обращений к обьектам Браузера, что повысит производительность скриптов.

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

[VegaX]

KaNoN, безусловно OneOfTheTags является более универсальным примером и может использоватся и в описании других окон. Но как ты верно подметил

Этот вариант потормознутей да и сложнее технически, но в принципе достаточно удобный.

Я пердложил другой способ, который тоже не идеален, т.к.

Иначе замучаетесь потом это все настраивать

Тут все уже зависит от ситуации - что важнее - скорость или стабильность.

Следует еще учесть, если использовать функцию в таге - она будет вызыватся неявно при любом обращении к этому окну, а также иногда и к другим окнам этого уровня!!! А функция Exists (без которой OneOfTheTags не обойдется) является довольно тяжелой функцией (впрочем как и другие функции Силка для работы с НТМЛ обьектами). Не знаю как у кого, а у меня функция Exists на больших страничках выполняется до 1.5 секунды!!! Выбор за вами

[KaNoN]

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

Кэширование значительно ускоряет этот процесс

А функция Exists (без которой OneOfTheTags не обойдется) является довольно тяжелой функцией (впрочем как и другие функции Силка для работы с НТМЛ обьектами). Не знаю как у кого, а у меня функция Exists на больших страничках выполняется до 1.5 секунды!!!

Все зависит от того, сколько окон вообще имеется, насколько глубоко в иерархии сидит нужный объект и т.п. , а также в каком состоянии нужное окно (например, если оно только открывается, то там будет задержка, длительность которой устанавливается в опциях агента)

Выбор за вами!!!

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

[Pet]

Однако... Вы тут такую дисскуссию развели.

Я решила свое решение написать. Я использую код похожий на предложенный VegaX - создаю нужный контрол в зависимости от юзера.

Типа такого:

[-] window BrowserChild Window1
	[+]  HtmlTable Table 
  	[ ] tag "#1"
  [+]  HtmlColumn Column1
  	[ ]  tag "#1"
  	[-] HtmlPopupList PopupList1
    [ ] tag "#1"
  	[-] HtmlTextField Field 
    [ ] tag "#1"
  [+]  HtmlColumn Column2
  	[ ] tag "#2"
  	[-]  HtmlPushButton Submit
    [ ]  tag "#1"
	[+]  HtmlTextField Field 
  [ ] tag "#1"
	[+]  HtmlPushButton Submit
  [ ]  tag "#1"
	[ ] 
	[ ] window wField
	[ ] window wPopup
	[ ] window wSubmit
	[ ] 
	[-] CreateControls()
  [-] if UserType=='admin'
  	[ ] wField = this.Table.Column1.Field
  	[ ] wPopup = this.Table.Column1.PopupList1
  	[ ] wSubmit = this.Table.Column2.Submit
  [-] else
  	[ ] wField = this.Field
  	[ ] wPopup = this.Table.Column1.PopupList1
  	[ ] wSubmit = this.Submit
  	[ ] 
	[ ] //функция использующая контролы
	[-] GetReport (string Text1, string Text2)
  [-] with Window1
  	[ ] .CreateControls()
  	[ ] .wField.TypeText(Text1)
  	[ ] .wPopup.Select (Text2)
  	[ ] .wSubmit.Click()

Работает отлично.

[KaNoN]

Работать-то оно работает, но есть еще несколько моментов, которые надо учитывать:
1) Представь, сколько записей вида

      wField = this.Field

придется сделать, когда фрейм разрастется или нужно много окон использовать.
2) При такой записи как правило не прослеживается иерархия объектов
и не работает автозаполнение

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

Мое мнение остается прежним: не имеет смысл использовать "обрезанного" юзера вообще, так как сейчас это вызывает трудности с таблицами, потом возникнут еще какие-то проблемы. К тому же имена тех же юзеров могут быть различными на разных машинах (как пользователь поставит) и нужно делать дополнительные и совсем ненужные настройки.