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

Все зависит от того, что именно это за надписи. Если это что-то типа Group-box, то есть оконный объект с надписью сверху, то он должен распознаваться во фрейме как StaticText или как производный от данного класса объект. Если же это рисовка ( просто рисунок ), то тогда уже надо использовать для главного окна CaptureBitmap метод, а затем уже сравнивать полученное изображение с некоторым эталоном при помощи метода VerifyBitmap. Но это врядли то, что нужно

У меня есть приложение, написаное на Java. Мне надо открыть окно и проверить наличие в нем 3 группы критериев поиска.
Группы включают в себя комбобоксы, текстовые поля, радиобаттоны. Силктест их видит, их можо получить методом GetContent().
А вот мне еще нужно проверить "встроенный" текст в самом окне, тот что озаглавливает комбобоксы, например. Силктест их не видит! Есть какой то способ проверить этот "встроенный в окно" текст? Подскажите, пожалуйста.
Приаттачила скриншот окна с обведенным полем для примера, чтоб было понятно, что я имею ввиду под "встроенным текстом".

Файл не загрузился, к сожалению. Господа админы, исправьте, пожалуйста этот баг!:

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

Попробуем предположить без картинки. Если это текст перед комбо-боксом, то есть просто некоторый Label, то можно попробовать у этого комбо-бокса вызвать метод GetPriorStatic() . Он вернет текст, ассоциированный с этим элементом управления. Как вариант, можно попробовать GetCaption(), тоже может что-то схожее вернуть.

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

wSomeWin.JavaJFCStaticText( "Some text:" ).Exists()

проверит существование текста "Some text:" у окна wSomeWin

Не могли бы вы подсказать, где можно поменять настройки Default Base State. Для этого обязательно нужно использовать Enable Exstensions или еть другой способ?

При активации расширений, действительно DefaultBaseState корректируется. Можно избежать вызова Default Base State можно несколькими способами:

• В каталоге, куда установлен Силк есть файл defaults.inc. Там этот DefaultBaseState и определен, его можно подредактировать, как нужно, но делать это нежелательно
• DefaultBaseState срабатывает, когда не задан явно appstate для тесткейса. Поэтому, его надо задавать явно. Если никакого аппстейта не нужно, то для этого используется none, например
  
  

  testcase MyTest() appstate none

  
  Также, если используется свой аппстейт, то он должен базироваться на none, то есть объявлен должен быть как-то в виде:
  
  

  appstate MyAppState basedon none

  
  То есть все подготовительные действия лучше реализовывать в аппстейте. Не надо системе доверять специфические вещи.
  
• Возможно, для хранения оконных деклараций вы использовали меню File > New и выбирали пункт Test Frame. В этом случае в сгенерированном файле присутствует строка вида
  

  const window wMainWin = <некоторое окно>

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

Подскажите, пожалуйста, каким образом можно описать класс с помощью винклассов.

В СилкТесте только винклассы и есть . Если речь идет о расширении существующего класса, то это делается по такому шаблону

winclass <New Class Name > : <Base Class Name>
tag "<Here specify some required tag>" // Это необязательная часть

// Дочерние элементы класса

И еще с чем может быть связано то, что в Record->Class->Scripted не доступны кнопки Paste to Editor и Copy to Clipboard?
Я использую триал-версию силктеста

Триал особой роли не играет. Он полнофункциональный. Когда вы записываете классы и поймали нужную декларацию, то нажмите Ctrl + Alt , чтобы приостановить процесс записи, тогда нужные кнопки активируются

Добрый день!
Столкнулась с такой проблемой: иногда!!! возникает такая ошибка "Error: Control is not responding", это происходит тогда, когда тест должен выбрать radio-button. В хелпе советуют: Set the following option just before the line causing the error: Agent.SetOption(OPT_VERIFY_RESPONDING, FALSE). Но мне это не помогает, если устанавливаю данную опцию, radio-button не выбирается, тест просто идет дальше. Пожалуйста, помогите разобраться в чем причина. Спасибо

Подобную проблему доводилось наблюдать при работе с выпадающими списками. Иногда перед работой с ними доводилось ставить sleep( 1 ), скрипт протормозит всего секунду, зато потом с объектом работа идет нормально. Попробуйте просто небольшую паузу поставить

Я новичек, с silkTestом работаю недавно. Занимаюсь тестирование web-приложения. И у меня возникла проблема: Мне нужно получить текст сообщения об ошибке, который появляется на форме в виде надписи, но при декларации окна этого поля на форме нет и соответственно этого поля нет в описании окна. Точно также и с другими элементами. Например таблица появляется на форме только после нажатия на кнопку. К ней я тоже не могу обратиться, т.к. она не описана.
Обобщу: как быть с теми контролами, которые появляются на форме после совершения каких-либо действий и не входят в описание окна?
Мож я задаю глупые вопросы, но пожалуйста, помогите разобраться.

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

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

Пример:

У нас есть декларация окна вида:

window BrowserChild wPage
		   tag "Page"

		   HtmlText txtSomeText
					 tag "Some Text"
		   HtmlPushButton btnButton
					 tag "Button"

И после некоторых манипуляций у нас исчезает кнопка (это просто пример, когда часть контента варьируется) и появляется еще текстовое поле, после чего данное окно записывается в виде:

window BrowserChild wPage
		   tag "Page"

		   HtmlText txtSomeText
					 tag "Some Text"
		   HtmlTextField edtValue
					 tag "Value"

Чтобы сделать описание окон более удобным, мы совмещаем обе дакларации под одним окном и получаем:

window BrowserChild wPage
		   tag "Page"

		   HtmlText txtSomeText
					 tag "Some Text"
		   HtmlPushButton btnButton
					 tag "Button"
		   HtmlTextField edtValue
					 tag "Value"

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

Здравствуйте.

СилкТест может записывать объекты типа RadioList двумя способами:

1) Несколько объектов группируются и записываются как один контрол (в данном случае типа HtmlRadioList).

2) Каждый элемент радиогруппы записывается отдельно и имеет тип HtmlRadioButton.

В вашем случае, очевидно, используется первый варинт. Для того, чтобы выбрать в этом списке элемент, необходимо использовать метод Select (или свойство sValue).

Если вы хотите, чтобы СилкТест распознавал каждый элемент списка как отдельный контрол, включите галочку Options - Agent - Compatibility - Don't group radio buttons into a list.

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

И все наши форумы будут начинаться такой страничкой? :)

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

Но в итоге, да, получится так, что в каждом форуме, посвященном тому или иному продукту, будут такие темы.

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

Интересно было бы узнать, как часто в поиске по сайту используются слова crack, кряк, и т.п.

Думаю эксперимент удачный :)
Правила читал и помню... Но в глаза бросилось сразу :) И не удержался чтобы не просмотреть содержание.
Вобщем +10 за эксперимент :)

Да, действительно получилось хорошо. За более чем 8 месяцев - ни одного вопроса на эту тему, зато более 1200 просмотров темы.

Надо будет популяризовать этот способ на других форумах.

Есть ли функция, которая возвращает вчерашнюю дату? сегодняшнюю понятно... а вот минус один день... не очень хочется в ручную все описывать...

Пример:

DATETIME dt = AddDateTime( GetDateTime() , -1 )

Как раз вернет вчерашнюю дату. Более детально смотрите в хелпе функцию AddDateTime

Вам поможет планировщик Windows (Пуск - Программы - Стандартные - Системные - Планировщик).

Кроме того можно посмотреть команду at (просто наберите at /? в командной строке).

Только надо будет правильно передать SilkTest'у все параметры в командной строке. Про параметры можно прочитать вот в этом руководстве, глава 11.5

Ребята, как запустить .bat файл из SilkTest скрипта?

SYS_Execute( <command-line string> )

Большое спасибо. Может, найдется решение поэлегантнее? Просто там кнопки разной длины, а на некоторых - выпадающие меню.

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

Расширение то оно понятно подключено,

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

Возможна ли разбивка объекта на buttons?

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

Проблема: Toolbar. Как добраться до кнопок в SilkTest
Есть приложение, написанное на Дельфи. Toolbar опреляется как Toolbar, но доступ к отдельным кнопкам невозможен. Покоординатная запись ничего не дает - выдается ошибка - что объект не найден.
Если кто-то решил данную проблему - поделитесь методами решения.

Одной из особенностей Делфи является то, что во многих случаях кнопки на тулбаре не являются отдельными окнами, чтобы распознаваться как отдельный объект. В таких случаях придется все-таки привязываться к координатам. Как вариант, можно создать набор фейковых (не существующих в системе) кнопок, которые привязать к тулбару и переопределить метод Click, который бы делал клик с учетом смещения этой кнопки. Выглядит это примерно так:

winclass FakeButton : AnyWin
		 POINT pos = { 0 , 0 }
		 
		 VOID ClickButton( INTEGER iButton optional, INTEGER x optional, INTEGER y optional, BOOLEAN bRawEvent optional )
					 if( IsNull( iButton ) )
							iButton = 1
					 if( IsNull( x ) )
							x = 0
					 if( IsNull( y ) )
							y = 0
					 if( IsNull( bRawEvent ) )
							bRawEvent = FALSE
					 this.Click( iButton, x + this.pos.x, y + this.pos.y , bRawEvent )

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

Toolbar tlbMyToolbar
		 tag "Some tag"

		 FakeButton btnButton
				 POINT pos = { 10 , 5 } // Смещение кнопки относительно левого верхнего угла тулбара

Вот подобный принцип можно использовать для работы с кнопками, которые не распознаются.

Добрый день.
Панели инструментов постоянно распознаются как один объект, приложение сконструированно в PowerBuilder 9.0.3.
Возможна ли разбивка объекта на buttons?
Или возможно написать методы работы с нуля?! и какие они?
Помогите разобраться.

Код:
window MainWin w_mdi_appl
...
[-] CustomWin FNFIXEDBAR901
[-] msw multitag "[FNFIXEDBAR90]#1"
[ ] "[FNFIXEDBAR90]$0"
[ ] "[FNFIXEDBAR90]@(640,13)"

Вы работаете с нестандартными контролами, для которых надо подключить расширения.
Поддерживается ли вашей версией СилкТеста PowerBuilder указанной вами версии, надо смотреть в Release Notes к данной версии СилкТеста. Процедуру активации расширений вы пожете просмотреть, прочитав FAQ к этому разделу форума (буквально 2-й пункт). Для всех поддерживаемых видов расширений способ автоматической активации идентичен

Добрый день!
Столкнулась с такой проблемой: есть в веб-приложении такая табличка (см. картинку)

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

Тэг для плюсика:

Browser.BrowserChild("Administrator?").HtmlImage("&id='VI:noticeEditApproversDT:0:approverSelectionImage'|Select the Approver(s) that must review and approve the plan by clicking the + image.[4]")

Тэг для текста рядом с картинкой плюса:

Browser.BrowserChild("Administrator?").HtmlText("Administrator, System")

Спасибо

Для подобных конструкций слишком плоская иерархия. Судя по картинке эти надписи и кнопки помещены в некоторую таблицу, но при настройках по умолчанию она не видна. Попробуйте зайти в меню Options > Extensions, выбрать используемый браузер и нажать кнопку Extensions. В появившемся диалоге в секции Borderless Table level установите значение 0,76 (по умолчанию обычно стоит 0,5) и нажмите ОК. После этого попробуйте перезаписать декларации. По идее в иерархии объектов должны появиться таблицы и колонки. Это уже первый шаг к решению текущей проблемы. Проверьте, работает ли это так

если ввести неправильный логин и пароль, то возникает oкно - error - login failed
если ввести три раза то возникает - error - user locked
можно ли понять какой текст в окне ?

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

1.Что делать с Custom class ? У меня похоже тот самый случай :(

В вашем случае у вас не активированы расширения. Во-первых, это расширения для веб, а во-вторых, это расширения для Flash-объектов. Насчет второго надо уточнять, поддерживает ли ваша версия элементы данного типа. Как активировать расширения, можно посмотреть в "Руководстве по Borland SilkTest" в разделе "Работа с расширениями". В этой ветке форума есть страница FAQ и в ней есть ссылка на книгу.

2. как в Silk понять что тест Ok - по caption окна Error or information или есть лучшие способы ?

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

3. Как лучше DDT - читать из file данные ?

С DDT обычно используются таблицы (часто Excel, Access). Все-таки более структурировано и наглядно.

4. Про логи - был вопрос автоматически узнать Pass/Fail тест - что не смотреть каждый раз, а получать письмо или отчет. Вроде на форуме видела мельком ответ про собственный лог...

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

E-mail нотификации сам SilkTest не делает. Для подобных целей надо дописывать свои утилиты

5. есть написаные тест-кэйсы их надо автоматизировать за 3 месяца. С системой не знакома. Нужен не очень трудоемкий, но работающий способ автоматизации.

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

Вопрос к Гуру:
1.Как посмотреть какие тесты прошли а какие нет ?
Можно ли узнать значения файла с результатами - 0 или 1 ?

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

2. Как лучше автоматизировать - через GUI или через DB ?
Спасибо

Конкретно SilkTest лучше приспособлен тестировать на уровне GUI, работа с БД - это несколько вспомагательная для него фича. Тем не менее, отказываться от нее не стоит. Я бы вначале посоветовал определиться, что же вам надо конкретно протестировать, затем подумать, как это протестировать, а уже потом можно думать об автоматизации

вопрос - как посмотреть почему ошибки при компиляции возникает ?

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

есть ли детализация ошибки ? мне видимо после Robot на Silk тяжело переключится... :( Все время ищу параллели...

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

Ну, на такой вопрос ответ будет только тут http://software-test...?showtopic=9647
(там линка на лектронное ководство по силку, так что просвещайтесь )

Более детально:

Руководство по Borland SilkTest

А также:
Уроки по SilkTest. Урок 1. Типы данных, работа с переменными
Уроки по SilkTest. Урок 2. Стандартные синтаксические конструкции, операторы
Уроки по SilkTest. Урок 3. Функции, определенные пользователем
Уроки по SilkTest. Урок 5. Декларация окон, классов

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

Какие например имеются ввиду подходы? Из дампа, с помощью специально созданных функций по вводу данных через гуи? Еще?

1) Из заготовленного дампа базы данных (уже залитого в тестовую среду ).
2) Создание записи через непосредственное обращение к базе или через вспомагательные элементы (веб-сервисы например)
3) Создание записи специальными функциями через ГУИ
4) Произвольный выбор существующих записей во время выполнения скрипта
5) Случайное заполнение/выбор (как правило, это используется для заполнения форм, не привязанных к другим записям)

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

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

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

Вот это очень похоже на data-driven тест, который в тестплане описывается фактически 2-3 строчками. И это более резонная форма.
Кстати, если вам так важна наглядность тестплана, то я бы порекомендовал поработать немного в другом направлении. Лучше позаботиться о том, чтобы у тесткейсов были информативные имена, чтобы они были сгруппированы тематически (все-таки каждый отдельный тесткейс выполняет некоторую узкую активность), тут можно и комментарии приписать для наглядности.

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

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

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

А что в этом плане меняется? По-моему, возможность выборки не зависит от того, как реализованы тесткейсы. Удобство выборки зависит скорее от удобной группировки.

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

То есть, при таком подходе тестплан играет роль исключительно перечня тестов, не более того. И если посмотреть на его логический смысл, то можно увидеть, что тестплан в СилкТесте - это не соответствие тест плану - документу, описывающему стратегию тестирования некоторого продукта, а это скорее Execution List. Поэтому, вкладывать в тестплан некий серьезный логический смысл я считаю малоцелесообразным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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