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

[OlgaV]

Добрый день
А для чего в Силке используется тип HTIMER?
Как с ним работать? можно делать замеры какие-то?
в хелпе как-то очень невнятно сказано - можно создавать ,можно на паузу ставить, а для чего...

[Genka]

вот пример замера времени работы тесткейса с помощью таймера

[-] testcase TimerDemo() appstate none
  [ ] HTIMER hTimer
  [ ] 
  [ ] hTimer = TimerCreate()
  [ ] TimerStart (hTimer)
  [ ] 
  [ ] // некие действия тесткейса
  [ ] 
  [ ] Print("Testcase working time: {TimerValue(hTimer)} seconds")

[KaNoN]

Эх, свинюка. А прибирать за тобой кто будет?

Создал таймер - убери его. Так что дописываем:

TimerStop( hTimer )
TimerDestroy( hTimer )

[Genka]

А прибирать за тобой кто будет?

Создал таймер - убери его

абсолютно согласен
но вообще...

When a script exits, SilkTest automatically destroys all timers that were not destroyed

так что в принципе СилкТест сам его приберет по завершении работы скрипта

конечно, в случае, когда запускается много тесткейсов подряд, надо прибирать =)

[KaNoN]

Да вообще прибирать надо, а то неизвестно, как эти скрипты будут использоваться и как они в дальнейшем корректироваться будут.

Но факт, что таймер в Силке - это просто счетчик, который можно запустить, остановить ( ну еще приостановить - TimerPause и возобновить - TimerResume ) и снять показания времени, которое натикало к определенному моменту времени.

[OlgaV]

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

[Genka]

не совсем понятно, что вы имеете ввиду
какие параметры снимать с контролов/окон?

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

[OlgaV]

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

[KaNoN]

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

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

[vass]

OlgaV, можно сделать обвязку каких-то действий, чтобы переписывать было меньше.
Например вот вам моя маленькая библиотечка для таймеров :

[+] winclass Timer
  [ ] HTIMER ht = NULL
  [ ] INTEGER i
  [ ] NUMBER sum
  [ ] String sName
  [+] New(STRING s optional)
  	[+] if IsNull(s)
    [ ] sName = ''
  	[+] else
    [ ] sName = s
  	[ ] ht = TimerCreate ()
  	[ ] i = 0
  	[ ] sum = 0.0
  [+] Del()
  	[+] if TimerState (ht) != TS_STOPPED
    [ ] F ()
  	[ ] Print ("[T]{sName}:{i}|SUM= {sum}|AVG= {(i==0)?0:sum/i}")
  	[ ] TimerDestroy(ht)
  [+] S ()
  	[+] if IsNull(ht)
    [ ] this.New()
  	[+] if TimerState (ht) == TS_STARTED
    [ ] TimerStop (ht)
    [ ] Print ("{sName}:{i} was started!")
  	[ ] TimerStart (ht)
  [+] F (STRING msg optional)
  	[+] if IsNull(msg)
    [ ] msg = ''
  	[+] if TimerState (ht) == TS_STOPPED
    [ ] Print ("{sName}:{i} was stopped!")
  	[+] else
    [ ] TimerStop (ht)
  	[ ] Print ("[T]{sName}:{++i}|{TimerValue(ht)}|{msg}")
  	[ ] sum += TimerValue(ht)
  [+] R (STRING msg optional)
  	[ ] this.F (msg)
  	[ ] this.S ()
  [ ] 
	[+] winclass Timers
  [ ] LIST OF WINDOW lw = {}
  [+] WINDOW New(STRING sName optional)
  	[ ] integer n = this.iNew(sName)
  	[ ] return lw[n]
  [+] INT iNew (STRING sName optional)
  	[ ] ListAppend(lw, Timer())
  	[+] if IsNull(sName)
    [ ] sName = "f{ListCount(lw)}"
  	[ ] lw[ListCount(lw)].New (sName)
  	[ ] return ListCount(lw)
  [+] Del()
  	[ ] WINDOW w
  	[+] for each w in lw
    [ ] w.Del()
	[ ] 
	[ ] window Timers _T

после этого можно написать
WINDOW T1 = _T.New('timer a')
WINDOW T2 = _T.New('timer b')
и где-то вызывать
T1.S() // начали отсчет времени а
...
T2.S() // начали отсчет времени б
...
T1.F() // закончили отсчет времени а
...
T1.F() // закончили отсчет времени б
и в конце скрипта поставьте
_T.Del()
для получения суммарных статистик по всем таймерам ;)

PS: 2 KaNoN сколько раз я проверял СилкТест - если есть вариант не удалять что-то руками а перекинуть это на его сборщик мусора, то лучше перекинуть. Так и быстрее и надежнее.

[OlgaV]

ага, ребята, спасибо большое. :)

[Genka]

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

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

лучше все-таки уничтожать их вручную

[vass]

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

не вопрос - силком этоможно сделать
только нужно сделать так чтобы проверка типа
1- силк сам ждет события (например SetActive или Exists )
2- самостоятельно в цикле проверять какое-то значение (например GetText или IsEnabled ).
в первом случае нужно вводить большую паузу для ожидания (типа Agent.SetOption (OPT_WINDOW_TIMEOUT, 500) ) события и быть готовым к эксепшенам;
во втором случае целесообразно ввести небольшую паузу типа Sleep(0.05) чтобы Силк не грузил и сделать выход из цикла либо по истечении времени либо по наступлению события.

[vass]

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

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

лучше все-таки уничтожать их вручную

остановленный таймер кушает только память под себя, так что даже 10000 таймеров сильно систему не нагрузят ;)
ну и для самых осторожных - у меня там в библиотечке все есть

[KaNoN]

PS: 2 KaNoN сколько раз я проверял СилкТест - если есть вариант не удалять что-то руками а перекинуть это на его сборщик мусора, то лучше перекинуть. Так и быстрее и надежнее.

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

Ну и насчет скорости не согласен. Это просто дело привычки. Примерно так же как и ставить префиксы в именах переменных, поначалу непривычно, а потом по-другому уже и не делаешь.

[KaNoN]

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

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

лучше все-таки уничтожать их вручную

остановленный таймер кушает только память под себя, так что даже 10000 таймеров сильно систему не нагрузят ;)
ну и для самых осторожных - у меня там в библиотечке все есть

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

[vass]

KaNoN - я проверял насчет скорости и надежности.
выделял куски памяти мегабайтами и либо освобождал их вручную либо оставлял сборщику.
Так вот в первом случае скрипт вис или Силк падал, а во втором случае - ни разу фигни не вылезло, плюс реально быстрее ;)
Конечно, если это не просто нечто в памяти, а какие-то работающие таймеры или SetTrap'ы - тогда да, оно тормозит скрипт.

... ну и если неуверен, что таймер незанят, то проверяешь на NULL а потом на TimerState () != TS_STOPPED, если это так то TimerStop ().
а потом тупо TimerCreate () при любом раскладе.
Не забыть только делать HTIMER hSomeTimer = NULL в самом начале и все.

[KaNoN]

KaNoN -  я проверял насчет скорости и надежности.
выделял куски памяти мегабайтами и либо освобождал их вручную либо оставлял сборщику.
Так вот в первом случае скрипт вис или Силк падал, а во втором случае - ни разу фигни не вылезло, плюс реально быстрее ;)
Конечно, если это не просто нечто в памяти, а какие-то работающие таймеры или SetTrap'ы - тогда да, оно тормозит скрипт.

Вот именно, что такое надо отследить, чтобы ничего левого не работало. А SetTrap'ы в особенности. И не только по причине освобождения памяти.

... ну и если неуверен, что таймер незанят, то проверяешь на NULL а потом на TimerState () != TS_STOPPED, если это так то TimerStop ().
а потом тупо TimerCreate () при любом раскладе.
Не забыть только делать HTIMER hSomeTimer = NULL в самом начале и все.

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

[vass]

.. эээ ... давайте не путать теплое с мягким
просто лишняя переменная в памяти - это наплевать и забыть, но лишняя "активность" в процессе работы - это, разумеется, стоит оптимизировывать.
Так что против TimerStop я ничего против не имею - даже обеими руками за.
Но TimerDestroy а тем более в конце модуля - это уже перебор.
Пускай сборщик мусора этим занимается. Тем более, что там уже скорее всего менеджер памяти тупо освобождает кучу без разбора на объекты (т.к. деструкторов в 4Test нету ) и всё (что вдвойне позитивно изза максимальной скорости).

[KaNoN]

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

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

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

Так что против TimerStop я ничего против не имею - даже обеими руками за.

А в изначальном посте ( из-за которого мы тут флейм раздули ) и остановки не было.

Но TimerDestroy а тем более в конце модуля - это уже перебор.

Под модулем я подразумевал некоторый выделенный блок кода, внутри которого используется таймер, а дальше его использование не нужно. То есть дальше вполне может присутствовать какой-то код. Например, do ... except ..

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