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

[gira13]

Добрый день!

Версия  TestComplete'a 10.30, trial, использую Java Script, приложение написано на Delphi.Приложение открытое

Решила попробовать написать скрипт с помощью Alias

  var f_client = Aliases.FormEngine.frmMain;
  f_client.BTN_CLIENT.Click();
  var cat_cl = f_client.WaitAliasChild("F_CCATEG",50000);
  f_client.F_IDCODE.WaitProperty("ReadOnly",False,50000);
  cat_cl.TWinControl.Click(); 

Что-то не срабатывает WaitProperty. Уже поле стало недоступным для редактирования, но ожидает 50000(при загрузке формы, поле сначало редактируемое, а когда полностью загружено - не редактируемое)

 

Вообще хотела узнать, может не стоит их использовать, будут ли какие-то проблемы с этими Alias 

[Genka]

Так если вы ждете, пока оно станет недоступным для редактирования, то нужно ждать значения True

 

WaitProperty("ReadOnly",True,50000);

[gira13]

Так если вы ждете, пока оно станет недоступным для редактирования, то нужно ждать значения True

 

WaitProperty("ReadOnly",True,50000);

точно, спс, а я извращаюсь, а оказывается все так просто

[gira13]

А чем чревато то, что я использую Alias, да и еще не переношу все поля к главной форме, например:

 

было

Aliases.FormEngine.frmMain.SUBABasePanel.SUBAForm10.PC_MAIN.TS_Basic.GB_General.F_IDCODE

стало

Aliases.FormEngine.frmMain.F_IDCODE

 

Просто я так решила,т.к. как-то работал кусок кода, работал, а потом вдруг поменялось название формы

Или,если снова поменяется, то Alias тоже не будет работать?

[Genka]

Использовать Алиасы удобно, для того их и сделали.

 

Единственное, чем может быть чревато: если поменяется ГУИ приложения (изменятся имена контролов и их иерархия), придется переделывать эти самые Алиасы.

 

Но это так везде, независимо от инструмента автоматизации.

[gira13]

Использовать Алиасы удобно, для того их и сделали.

 

Единственное, чем может быть чревато: если поменяется ГУИ приложения (изменятся имена контролов и их иерархия), придется переделывать эти самые Алиасы.

 

Но это так везде, независимо от инструмента автоматизации.

в моем случае не просто поменялось название формы, а там получилось, я сначала открывала форму 1, а потом форму 2 и форму 3, так форма 1 назвалась форма 1_1, форма 2: форма 1_2, форма 3: форма1_1

в другой раз я не открывала форму 1, и тогда моя форма 2 стала уже форма 1_1 вместо форма 1_2

т.к. я там ожидала WaitVCLObject("форма1_*",15000),  то все ок

А в случае с Альясами скрипт не заглохнет?

[gira13]

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

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

[Genka]

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

 

Объект теперь добавлять руками, да, через Object Browser, а потом переносить на нужный уровень иерархии

[gira13]

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

 

Объект теперь добавлять руками, да, через Object Browser, а потом переносить на нужный уровень иерархии

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

[alk2alk]

[...] Единственное, чем может быть чревато: если поменяется ГУИ приложения (изменятся имена контролов и их иерархия), придется переделывать эти самые Алиасы.[...]

Не совсем так. При правильной настройке, алиасы и, соответственно тестовый код, переделывать не прийдется, а прийдется только подстроить NameMapping.

Дело в том, что архитектура распознавания/работы с тестируемым объектом при использовании NameMapping такова:

-- Есть тестируемый объект (например - F_IDCODE);

-- Этот объект зарегистрирован и может быть идентифицирован в NameMapping-редакторе (например, как элемент по пути NameMapping.FormEngine.frmMain.SUBABasePanel.SUBAForm10.PC_MAIN.TS_Basic.GB_General.F_IDCODE);

-- Для этого-же объекта создан alias (например, как Aliases.FormEngine.frmMain.F_IDCODE).

 

Теперь, когда вы из кода обращаетесь к объекту Aliases.FormEngine.frmMain.F_IDCODE, TestComplete находит данный alias, по нему находит соответствующий NameMapping элемент и по этому элементу находит реальный объект тестируемого приложения. Т.е. здесь имеют место быть три таблицы ссылок, из которых третья (Aliases) используется тестовым кодом, первая (параметры идентификации объекта в редакторе NameMapping) - runtime-средой TestComplete для работы с объектом, а вторая (NameMapping) - для связи первой и третьей таблиц.

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

Заметьте, что при регистрации объекта в таблице NameMapping, вы можете двигать зарегистрированный объект вверх по иерархии. Т.е., например, при регистрации объекта Sys.Process.FormEngine.frmMain.SUBABasePanel.SUBAForm10.PC_MAIN.TS_Basic.GB_General.F_IDCODE, вы можете поместить его по пути NameMapping.FormEngine.frmMain.SUBABasePanel.F_IDCODE и создать его alias как Aliases.FormEngine.frmMain.F_IDCODE. Это упростит последующую подстройку таблицы NameMapping.

[alk2alk]

Мой ответ был адресован, конечно, gira13 :)