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

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

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

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

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

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

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

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

Привет!
Подскажите, пожалуйста, вот есть у меня текстовый файл. В нем 5 строк:
s1
s2
s3
s4
s5

Я могу оттуда получить все строки:
[ ] int i
[ ] STRING sLine
[ ] HFILE hF = FileOpen ("c:\File.txt", FM_READ)
[-] for i =1 to 5
[ ] FileReadLine (hF, sLine)
[ ] Print (sLine)
А мне надо, например одну только четвертую выдернуть. Что-то не могу сообразить как..
Спасибо

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

Кстати, а весь файл в список можно считать функцией SYS_ListRead

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

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

Тогда есть путь попроще :)

1) При записи деклараций окон используйте в тегах используйте не Caption, а, например, порядковый номер контрола (#).

2) А лучше дать вашим пунктам меню правильные теги. Например,

tag "View|Вид|Bekijken"

Этот тег говорит силктесту о том, что меню может иметь один из трех кепшенов (View - для англ версии, Вид - для русской и Bekijken - для немецкой).

View – это меню «Вид» в русском Notepadе (Блокноте).
А мне нужно найти координаты меню View (Вид) для кликов по данной области.
Потому что в зависимости от языка Notepad координаты меню View (Вид) изменяются (на английском Notepadе – это одни координаты, а на немецком или другом Notepadе – другие координаты. )
Так вот, как с помощью GetRect () или другим способом найти координаты View (Вид)?

ясно :) У notepad'a для Win2k такой менюшки нет ;)
в связи с этим присоединяюсь к предыдущему посту - использовать для тега Caption "View", Index "#4" (или - Window ID "$nnn" , хотя для View он неопределен :( )

Я еще немного дополню. В теге также можно указывать местоположение контрола. Например,
tag "@(10, 20)"

Но я бы все-таки посоветовал прежде всего попробовать перечислять возможные теги (View, Вид и т.п.) через символ |.

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, работа с БД - это несколько вспомагательная для него фича. Тем не менее, отказываться от нее не стоит. Я бы вначале посоветовал определиться, что же вам надо конкретно протестировать, затем подумать, как это протестировать, а уже потом можно думать об автоматизации

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

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

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

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

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

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

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

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

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

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

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

SYS_Execute( <command-line string> )

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

Пример:

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

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

Привет!
ПОдскажите пожалуйста. Я работаю с приложением Java-Swing и мне нужно открыть форму и заполнить в ней поля. Когда скрипт записывается с помощью recording, все контролы прекрасно распознаются. SetText вроде бы вставляет в поля тот текст, который нужен, но при запуске этого скрипта, текст в поля не вставляется, хотя в результате выполнения скрипта - пишется Passed.
С чем это может быть связано?
спасибо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В чем соль?

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

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

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

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

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

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

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

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>, ...)
...

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

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

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

Проблема: 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 } // Смещение кнопки относительно левого верхнего угла тулбара

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

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

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

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

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

Добрый день.
Панели инструментов постоянно распознаются как один объект, приложение сконструированно в 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-й пункт). Для всех поддерживаемых видов расширений способ автоматической активации идентичен

Добрый день
Ребята, помогите. :)

Возникла такая проблема - при команде "HtmlCheckBox.SetState(1)" Силк кликает не на сам чекбокс, а чуть левее и выше..в итоге клик не устанавливает состояние чекбокса.. попытки кликнуть через click() срабатывают так же...В чем может быть проблема?

Силк - 2008, приложение - веб... Силк переустанвливала, машину перегружала, у других в команде работает нормально - это глюк именно моего силка...

куда копать? существуют настройки такого смещения?

Как вариант, можно вместо SetState использовать клик по координатам. По умолчанию у метода click заданы координаты левого верхнего угла элемента. Соответственно, для нужд задачи можно "пристрелять" метод для клика по нужной области. Если данная задача специфична именно для данного элемента, то в объявлении окон всегда можно добавить свой метод, который сделает клик там, где надо

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

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

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

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

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

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

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

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

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

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

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

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

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