silktest для новичков

Программа как раз есть. В тех главах, что я предоставил, отражена работа с TestApp - тестовым приложением, которое идет в поставке с СилкТестом. И весь фрейм, весь код описывается на реальном приложении без всяких вариаций. И там поведение вполне детерминировано. Кстати, в рассматриваемом мною примере appstate описывается так

[+] appstate apsTestApp () basedon none
	[ ] TESTCASESTATE tcState
	[ ] 
	[ ] tcState = GetTestcaseState ()
	[+] if (tcState == TCS_ENTERING && !wTestApp.Exists (0))
  [ ] Print ("Application not opened. Starting...")
  [ ] wTestApp.Start (wTestApp.sCmdLine, wTestApp.sDir)
	[+] else
  [ ] wTestApp.CloseAll ()
  [+] if (tcState == TCS_EXITING)
 	 [ ] Print ("* * * Clearing menu")
 	 [ ] wTestApp.Menu.ClearMenus.Pick ()

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

А теперь покритикуем код. Вот этот участок

[-] if( !wTestApp.ChildWin("MDI Child Window #1").Exists() )
  [ ] Print("  MDI Child Window #1 appears")
  [ ] wTestApp.File.New.Pick()
	[-] else
  [ ] Print("  No MDI Child Window #1 appears")

Реализован некорректно. Получается, что мы говорим о том, что нужное окно появилось, когда его нет и наоборот, сообщаем, что окна нет, когда оно реально имеется в наличии. Более того, обычно скрипты строятся по приципу "действие-проверка результата". После выбора меню File > New как раз и имеет смысл проверять, появилось ли окно. А этой проверки нет. Соответственно, скрипт пойдет дальше криво, если нужное окно не появилось. Схожая ситуация для 2-го шага.

Так, третий шаг:

[ ] Print("Step 3: From Main menu select File > Close")
	[ ] wTestApp.SetActive()
	[ ] 
	[-] if( !wTestApp.ChildWin("MDI Child Window #1").Exists() )
  [ ] Print("  MDI Child Window #2 don't close, because MDI Child Window #2 don't exist!")
	[-] else
  [ ] Print("  MDI Child Window #2 was closed")
  [ ] wTestApp.File.Close.Pick()

Во-первых, лучше проверять, на наличие окно wTestApp.ChildWin("MDI Child Window #2") и если его нет, то тогда уже ругаться. Ну и естественно, проверять, что окно закрылось, нужно только после того как мы сделали соответствующее действие. А проверки такой нет.

Вот это вообще криво:

               [ ] wTestApp.SetActive()
	[ ] 
	[-] if( !wTestApp.Exists() )
  [ ] Print("  TestApp don't close, because TestApp don't exist!")
	[-] else
  [ ] Print("  TestApp was closed")
  [ ] wTestApp.File.Exit.Pick()

Вы активируете окно wTestApp, после чего проверяете его же на существование. Это не очень хорошо. Если вдруг главного окна нет, то скрипт загнется чуть ли не в самом начале или как минимум на SetActive(), то есть выражение в if-е не выполняется практически никогда (разве что вы будете во время выполнения скриптов мышкой по окнам кликать). Ну и здесь традиционная для данного скрипта ошибка. Вначале закройте окно, потом проверьте, что его нет и только после этого говорите, что окно закрыто.

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

Спасибо за конструктивную критику! Получается, что между программированием и написанием тестов есть большая разница в самом подходе, понимании. Программист и тестировщик решают различные задачи (хотя в общем случае задача одна - хорошая программа). Буду стараться исправляться.

У меня небольшая просьба. Нельзя ли выложить полный текст фрейма и тесткейса для примера к Google. Это было бы полезно большинству читателей этой темы и мне тоже. Хотелось бы лучше разобраться с веб-приложениями, но для новичка одного файла 04 все же недостаточно, хотя безусловно его необходимо использовать. К тому же не должно возникнуть недопониманий и других трактовок. В любом случае спасибо за внимание!

Пока прикрепил фрейм. Там еще требуется дополнительно файл common.inc.
При себе его нету
Код скрипта можно выдрать прямо из документа.
Следует только отметить, что фрейм этот описывался фактически для сайта www.google.com.ua . И еще возможно это не самая свежая версия данного файла. Книжка еще не готова и окончательная обработка примеров запланирована на завершающем этапе.

Народ, а может все таки есть какая нить инфа на русском желательно, чтобы въехать в Silk TEst с нуля. ?

Я тут нашел один линк,
http://forums.softwa...ype=post&id=242

но думаю есть продолжение?

Народ, а может все таки есть какая нить инфа на русском желательно, чтобы въехать в Silk TEst с нуля. ?

Я тут нашел один линк,
http://forums.softwa...ype=post&id=242

но думаю есть продолжение?

Это как раз первая глава книжки. Рядом выложена 2-я. Там про написание тесткейсов, рассматривается на примере конкретного сценария (работа с ГУИ-приложением). В этом же форуме есть материал по тестированию веб-приложений (но вам эта глава ни к чему, если вы не тестите веб-приложения).

Вообще, мы с Генкой работаем над книжкой. Процентов 80 уже есть. Скоро выложим на этом форуме

У меня с Infragistics проблемы :) Нифига не понимаю ... пишите скорее ибо нету инфы :) Пасибо

Пока прикрепил фрейм.  Там еще требуется дополнительно файл common.inc.
При себе его нету
Код скрипта можно выдрать прямо из документа.
Следует только отметить, что фрейм этот описывался фактически для сайта www.google.com.ua . И еще возможно это не самая свежая версия данного файла. Книжка еще не готова и окончательная обработка примеров запланирована на завершающем этапе.

а кто писал ф-цию OneOfTheTags ?
я так смотрю, что у меня точно такая же но все таки есть ряд отличий.
1- 1ый параметр- просто this. WindowParent спрятан внутри, чтобы не писать его каждый раз.
2- второй парметр не LIST OF STRING а warargs, потому что это позитивнее - позволяет включать вызов функции внутрь строки.
3- а в OneOfTheTags есть кеширование предыдущего успешного тега?

[-] winclass GoogleResultsBase : BrowserChild
[ ] STRING sKeyWords
[ ] tag "{sKeyWords}*"

* в конце - это риск :)

  [+] except
  [ ] ExceptPrint()

этого мало. Опыт показал, что нужно еще и Print (ExceptNum()) как минимум
... потом подробнее посмотрю код еще раз :))

ЗЫ: а кстати, а почему

BOOLEAN bNewWindow NULL optional

там NULL ? я вот своих отучаю так писать, чтобы просто optional было. а у вас ?

Вася, а ты шутник, однако.

а кто писал ф-цию OneOfTheTags ?
я так смотрю, что у меня точно такая же но все таки есть ряд отличий.

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

1- 1ый параметр- просто this. WindowParent спрятан внутри, чтобы не писать его каждый раз.

2- второй парметр не LIST OF STRING а warargs, потому что это позитивнее - позволяет включать вызов функции внутрь строки.

См. примеры.

[+] window BrowserChild wGoogleResults
	.......................................................................................................................................
	[+] HtmlLink lnkSearchInFound
  [ ] tag OneOfTheTags(WindowParent(this),{"[HtmlTable]#{iBaseIndex+3}/[HtmlColumn]#1/[HtmlLink]Iiene a iaeaaiiii","[HtmlTable]#{iBaseIndex+2}/[HtmlColumn]#1/[HtmlLink]Iiene a iaeaaiiii"})

iBaseIndex - это property. Аналогично можно вызвать функцию.

3- а в OneOfTheTags есть кеширование предыдущего успешного тега?

Посмотри рассматриваемые примеры и подумай, какой смысл кешировать и поможет ли это в рассматриваемых примерах.


Тем более, если хочешь, то можешь выложить свой вариант . Саше будет интересно посмотреть, как ты разбазариваешь интелектуальную собственность компании

[-] winclass GoogleResultsBase : BrowserChild
[ ] STRING sKeyWords
[ ] tag "{sKeyWords}*"
* в конце - это риск :)

Это не риск - это asterisk
Можно сделать так: tag "{sKeyWords}*[1]" . При определенных установках ничего плохого не произойдет.

  [+] except
  [ ] ExceptPrint() этого мало. Опыт показал, что нужно еще и Print (ExceptNum()) как минимум
... потом подробнее посмотрю код еще раз :))

А смысл? Опыт показывает, что числа вроде -62347256 мало о чен скажут тем, кто запускает скрипты и/или анализирует проблему. А ExceptPrint() выдает достаточно информации для быстрого перехода на строчку, в которой произошла ошибка. Тесткейс сдох и сказал, кто его убил - больше следователю и не надо.

ЗЫ: а кстати, а почему BOOLEAN bNewWindow NULL optional там NULL ? я вот своих отучаю так писать, чтобы просто optional было. а у вас ?

А вот как начитаемся такого:

null Optional. Indicates that the argument can contain a NULL value. If omitted, the default is that the argument cannot be NULL. If an argument is NULL and you have not explicitly allowed it to be NULL, SilkTest raises an exception.

и получается, что лучше явно указать, что все-таки значение NULL можно передавать, а иначе неизвестно как Силк будет себя вести.

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

БУГАГАШЕНЬКИ

Привет, Вася!

а кто писал ф-цию OneOfTheTags ?
я так смотрю, что у меня точно такая же но все таки есть ряд отличий.

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

ну! мало ли как бывает ... а вдруг не ты и я зря спрашивал ?

2- второй парметр не LIST OF STRING а warargs, потому что это позитивнее - позволяет включать вызов функции внутрь строки.

См. примеры.

[+] window BrowserChild wGoogleResults
	.......................................................................................................................................
	[+] HtmlLink lnkSearchInFound
  [ ] tag OneOfTheTags(WindowParent(this),
            {"[HtmlTable]#{iBaseIndex+3}/[HtmlColumn]#1/[HtmlLink]Iiene a iaeaaiiii",
             "[HtmlTable]#{iBaseIndex+2}/[HtmlColumn]#1/[HtmlLink]Iiene a iaeaaiiii"})

iBaseIndex - это property. Аналогично можно вызвать функцию.

да нет! я про то, что нельзя будет написать

tag "prefix{OneOfTheTags(...)}suffix"

3- а в OneOfTheTags есть кеширование предыдущего успешного тега?

Посмотри рассматриваемые примеры и подумай, какой смысл кешировать и поможет ли это в рассматриваемых примерах.

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

Тем более, если хочешь, то можешь выложить свой вариант . Саше будет интересно посмотреть, как ты разбазариваешь интелектуальную собственность компании  

ну, во первых, полный вариант я вряд ли выложу (например кеширование там очень хитро сделано)
а во-вторых иногда мне кажется, что компания ценит не самУ "интеллектуальную собственность", а то что она может ее никому не дать, хотя и не использует сама (блин! столько труда иногда нужно, чтобы твой код приняли и стали использовать вместо своего копи-пейста, что иногда хочется сесть, запаковать его и выложить где-нить на фришном сайте )

[-] winclass GoogleResultsBase : BrowserChild
[ ] STRING sKeyWords
[ ] tag "{sKeyWords}*"
* в конце - это риск :)

Это не риск - это asterisk
Можно сделать так: tag "{sKeyWords}*[1]" . При определенных установках ничего плохого не произойдет.

нуну!
вспомнишь, когда будет два контрола типа "слово1" и "слово1слово2" и надо будет обратиться к первому ;)

  [+] except
  [ ] ExceptPrint() этого мало. Опыт показал, что нужно еще и Print (ExceptNum()) как минимум
... потом подробнее посмотрю код еще раз :))

А смысл? Опыт показывает, что числа вроде -62347256 мало о чен скажут тем, кто запускает скрипты и/или анализирует проблему. А ExceptPrint() выдает достаточно информации для быстрого перехода на строчку, в которой произошла ошибка. Тесткейс сдох и сказал, кто его убил - больше следователю и не надо.

ххе, простейший return liIndexes[i] может выдать E_BAD_INDEX и E_VAR_NOT_SET, что может свидетельствовать о разных типах ошибок.
А что уж говорить о том, что сдохло в сравнительно простом случае
someCtrl.CaptureBitmap (GetSomeFileNames(iFileIndex))
??? (ибо там >10 различных причин - от нет места на диске, до <unset>-а iFileIndex)

ЗЫ: а кстати, а почему BOOLEAN bNewWindow NULL optional там NULL ? я вот своих отучаю так писать, чтобы просто optional было. а у вас ?

А вот как начитаемся такого:

null Optional. Indicates that the argument can contain a NULL value. If omitted, the default is that the argument cannot be NULL. If an argument is NULL and you have not explicitly allowed it to be NULL, SilkTest raises an exception.

и получается, что лучше явно указать, что все-таки значение NULL можно передавать, а иначе неизвестно как Силк будет себя вести.

хехе, читаем дальше :

optional Optional. Indicates that the argument is optional. If an optional argument has not been passed in, its value will be null on entry to the function. If you omit an optional argument, you may also omit any arguments that follow the optional argument.

и в следующей статье :

The AddDateTime function, can accept six arguments:

newDT = AddDateTime (Datetime [, iDays, iHours, iMins, iSecs, iMsecs])

The first argument, Datetime, is required; the five arguments shown inside of brackets are optional. However, if you specify one, you must also specify any of the optional arguments that precede that one.
Use NULL for arguments that need no value specified. For example, the following code adds one hour to the DATETIME value in newDateTime.

newDateTime = AddDateTime (datetime, NULL, 1)

да нет! я про то, что нельзя будет написать

tag "prefix{OneOfTheTags(...)}suffix"

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

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

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

ну, во первых, полный вариант я вряд ли выложу (например кеширование там очень хитро сделано)
а во-вторых иногда мне кажется, что компания ценит не самУ "интеллектуальную собственность", а то что она может ее никому не дать, хотя и не использует сама (блин! столько труда иногда нужно, чтобы твой код приняли и стали использовать вместо своего копи-пейста, что иногда хочется сесть, запаковать его и выложить где-нить на фришном сайте  )

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

нуну!
вспомнишь, когда будет два контрола типа "слово1" и "слово1слово2" и надо будет обратиться к первому ;)

Это BrowserChild, который один. А я поставлю опцию Verify that window uniquely identifies windows и порядок. К первому и обратится. А больше не к кому.

ххе, простейший return liIndexes[i] может выдать E_BAD_INDEX и E_VAR_NOT_SET, что может свидетельствовать о разных типах ошибок.
А что уж говорить о том, что сдохло в сравнительно простом случае
someCtrl.CaptureBitmap (GetSomeFileNames(iFileIndex))
??? (ибо там >10 различных причин - от нет места на диске, до <unset>-а iFileIndex)

Большинство людей понимают слова куда лучше, чем имена констант или вообще цифры. Пример

[ ] LIST OF INTEGER liIndex = {1}
	[+] do
  [ ] liIndex[2] = 1
	[+] except
                                [ ] Print( ExceptNum() )
  [ ] ExceptPrint()

Результат

[ ] -10800
[ ] *** Error: Index value of 2 exceeds list size of 1
[ ] Occurred in main at Test.t(798)

Как ты думаешь, что более информативно -10800 или
Index value of 2 exceeds list size of 1 ?

Я живу не в Матрице и предпочитаю получать словесную информацию об ошибке, а не коды.

ну, во первых, полный вариант я вряд ли выложу (например кеширование там очень хитро сделано)
а во-вторых иногда мне кажется, что компания ценит не самУ "интеллектуальную собственность", а то что она может ее никому не дать, хотя и не использует сама (блин! столько труда иногда нужно, чтобы твой код приняли и стали использовать вместо своего копи-пейста, что иногда хочется сесть, запаковать его и выложить где-нить на фришном сайте  )

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

1) До сих пор, все кому они реально были нужны, они не казались сложными ... ну может в первый раз, а потом - все нормально было.
2) в тесткейсах *настолько* общий код ИМХО не нужен. Только для реализации коммон кода на этапе фреймов и наборов данных. Типа "проверить, что все поля на форме задизейблены" или "в списке отчета есть подсписок образцов". А в коде типа "введите имя, нажмите кнопку" - оно, разумеется до лампочки ... И это еще полбеды. Ведь в своем отделе я могу показать/попросить/потребовать, а ведь есть еще и не только наш отдел. Как там их заставить не копи/пейстить грабли???

нуну!
вспомнишь, когда будет два контрола типа "слово1" и "слово1слово2" и надо будет обратиться к первому ;)

Это BrowserChild, который один. А я поставлю опцию Verify that window uniquely identifies windows и порядок. К первому и обратится. А больше не к кому.

простейший пример :

[+] window MainWin wTestA
	[ ] tag "testA*[1]"
	[-] TextField edtText
  [ ] tag "#1"
[+] window MainWin wTestAB
	[ ] tag "testAB*[1]"
	[-] TextField edtText
  [ ] tag "#1"
[ ] 
[-] main()
	[ ] 
	[ ] Agent.SetOption (OPT_VERIFY_UNIQUE, TRUE)
	[ ] Print (wTestA.edtText.sValue)
	[ ] Print (wTestAB.edtText.sValue)

окна блокнота в одном "testA.txt" во втором "testAB.txt" с соответсвующим текстом.
если "A" вверху, то выведет
A
B
если "AB" вверху, то выведет
AB
AB
OPT_VERIFY_UNIQUE - не поможет

ххе, простейший return liIndexes[i] может выдать E_BAD_INDEX и E_VAR_NOT_SET, что может свидетельствовать о разных типах ошибок.
А что уж говорить о том, что сдохло в сравнительно простом случае
someCtrl.CaptureBitmap (GetSomeFileNames(iFileIndex))
??? (ибо там >10 различных причин - от нет места на диске, до <unset>-а iFileIndex)

Большинство людей понимают слова куда лучше, чем имена констант или вообще цифры. Пример

[ ] LIST OF INTEGER liIndex = {1}
	[+] do
  [ ] liIndex[2] = 1
	[+] except
                                [ ] Print( ExceptNum() )
  [ ] ExceptPrint()

Результат

[ ] -10800
[ ] *** Error: Index value of 2 exceeds list size of 1
[ ] Occurred in main at Test.t(798)

Как ты думаешь, что более информативно -10800 или
Index value of 2 exceeds list size of 1 ?

Я живу не в Матрице и предпочитаю получать словесную информацию об ошибке, а не коды.

дело в том что только стандартный эксепшн выдаст информацию с описанием :

[-] main()
	[-] do
  [ ] raise E_VAR_NOT_SET
	[-] except
  [ ] ExceptPrint ()
	[ ] 
	[-] do
  [ ] raise E_VAR_NOT_SET, "some text"
	[-] except
  [ ] ExceptPrint ()
	[ ] 
	[ ] 
	[-] do
  [ ] Print({1}[3])
	[-] except
  [ ] ExceptPrint ()

результат :

[ ]       Exception -13600
[ ]       Occurred in main at test.t(3)
[ ]       some text
[ ]       Occurred in main at test.t(8)
[ ]       *** Error: Index value of 3 exceeds list size of 1
[ ]       Occurred in main at test.t(14)

поэтому иногда лучше немного подстраховаться ;)

1) До сих пор, все кому они реально были нужны, они не казались сложными ... ну может в первый раз, а потом - все нормально было.

И насколько интенсивно применяются большинство функций? Раз-два и все. Разве что кто-то на ревью посоветует, а так зачастую проще написать 3-4 строчки кода, но сразу, вместо одной, но предварительно перерыв кучу файлов.

2) в тесткейсах *настолько* общий код ИМХО не нужен. Только для
реализации коммон кода на этапе фреймов и наборов данных.

Коммон код ради коммон кода получается.

Типа "проверить, что все поля на форме задизейблены" или "в списке отчета есть подсписок образцов".

Так не имеет ли смысл на этом ограничиваться? В конце концов ценность представляют сами скрипты, а не функциональность, которая в неограниченном её применении делает код трудноподдерживаемым?

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

Это не полбеды. Это и есть беда. Ведь это у нас, допустим, отдел достаточно большой. А в других конторах может быть 2-3 человека, а то и один, которым дали задание автоматизировать такой-то объем тесткейсов и им абсолютно до лампочки, что те 3-4 строчки можно реализовать одной-двумя. Им важно, чтоб к определенному периоду времени было определенное количество рабочих скриптов. А качество их не столь существенно. Главное, чтоб все проверки нужные делались. Потому что автотестинг внедряется не только в уже оформившихся продуктах, но и по ходу разработки, поэтому достаточно обеспечить некоторый минимум.

окна блокнота в одном "testA.txt" во втором "testAB.txt" с соответсвующим текстом.
если "A" вверху, то выведет
A
B
если "AB" вверху, то выведет
AB
AB
OPT_VERIFY_UNIQUE - не поможет 

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

дело в том что только стандартный эксепшн выдаст информацию с описанием :
CODE[-] main()
[-] do
[ ] raise E_VAR_NOT_SET
[-] except
[ ] ExceptPrint ()
[ ]
[-] do
[ ] raise E_VAR_NOT_SET, "some text"
[-] except
[ ] ExceptPrint ()
[ ]
[ ]
[-] do
[ ] Print({1}[3])
[-] except
[ ] ExceptPrint ()
результат :
CODE[ ]      Exception -13600
[ ]      Occurred in main at test.t(3)
[ ]      some text
[ ]      Occurred in main at test.t(8)
[ ]      *** Error: Index value of 3 exceeds list size of 1
[ ]      Occurred in main at test.t(14)
поэтому иногда лучше немного подстраховаться ;)

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

1) До сих пор, все кому они реально были нужны, они не казались сложными ... ну может в первый раз, а потом - все нормально было.

И насколько интенсивно применяются большинство функций? Раз-два и все. Разве что кто-то на ревью посоветует, а так зачастую проще написать 3-4 строчки кода, но сразу, вместо одной, но предварительно перерыв кучу файлов.

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

2) в тесткейсах *настолько* общий код ИМХО не нужен. Только для
реализации коммон кода на этапе фреймов и наборов данных.

Коммон код ради коммон кода получается.

Разумеется. Если код повторяется несколько раз в общем коде, то его собирают в еще более общий код. что тут такого?

Типа "проверить, что все поля на форме задизейблены" или "в списке отчета есть подсписок образцов".

Так не имеет ли смысл на этом ограничиваться? В конце концов ценность представляют сами скрипты, а не функциональность, которая в неограниченном её применении делает код трудноподдерживаемым?

так ведь даже в этих случаях не применяют :(

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

Это не полбеды. Это и есть беда. Ведь это у нас, допустим, отдел достаточно большой. А в других конторах может быть 2-3 человека, а то и один, которым дали задание автоматизировать такой-то объем тесткейсов и им абсолютно до лампочки, что те 3-4 строчки можно реализовать одной-двумя. Им важно, чтоб к определенному периоду времени было определенное количество рабочих скриптов. А качество их не столь существенно. Главное, чтоб все проверки нужные делались. Потому что автотестинг внедряется не только в уже оформившихся продуктах, но и по ходу разработки, поэтому достаточно обеспечить некоторый минимум.

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

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

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

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

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

Разумеется. Если код повторяется несколько раз в общем коде, то его собирают в еще более общий код. что тут такого?

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

так ведь даже в этих случаях не применяют :(

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

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

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

во-вторых вылавливать все места копи/пейста и менять их если нашлась ошибка или изменилась архитектура ...

Интенсивно повторяющиеся действия как минимум претендуют на отражение в локальной функциональности. Это уже потом переносятся во фрейм или выше.

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

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

Всем привет! Я токже недавно начала изучать Silk Test. Сейчас меня интересует вопрос как опровить контекстное меню дочернего окна?. Есть массив в котором содержятся наименования пунктов меню.
1 - Мне нужно проверить совпадают ли наименования пунктов контекстного меню (к.м.) с теми что в массиве.
2 - Нужно вызывать пункты к.м. по названиям из массива (т.е. если наименования совпадают то выполнять задачу)
Помогите плиз....уже замучалась перебирать варианты