Using HISUtils.StopWatch in keyword tests
I want to open this out to others to see if there's anyone else who has a better way of doing this. Essentially, the goal is to minimize, as much as possible, the amount of script code that nee...
Forum Discussion
Hi
Mathijs,
> [...] so I will need to start exploring AQTime. Is there a demo version available so I can start to learn this?
Yes, as with all products by AutomatedQA - http://smartbear.com/products/development-tools/performance-profiling/sign-up/ (accessible from http://smartbear.com/products/development-tools/performance-profiling/).
> [...] the application I am testing on, is a webapplication [...]
I would recommend the http://smartbear.com/support/viewarticle/17953/ and related help articles.
Also: http://smartbear.com/support/screencasts/aqtime/profiling-scripts/ (from the http://smartbear.com/support/screencasts/aqtime/ page)
and http://smartbear.com/support/viewarticle/8748/
> [...] those numbers
include both the server processing time as well as the data transfer
time (time it takes to transfer the data (actually its pdf data) over
the network.
Yes. Actually LoadComplete measures several times (like Time To First Byte, Time To Last Byte, etc.) but obviously (as LoadComplete is running on the client but not on the server box) they all consist of the time for the request to get to the server, time spent by the server to process the request and time for the response to get back to the client. However, LoadComplete can connect to the Performance Counters on the server and I am sure (did not do this personally, but pretty much sure this is possible) that by selecting proper counter it should be possible to measure time it takes the server to process the request. Subtracting this time from the overall time for the request-response roundtrip you should be able to get separate figures for the server processing and network transfer times.
>
So, I guess, by using the Object Spy to "select" it, it should be in the
TestComplete namemapping model, right??
On the one hand I am far not sure that Object Spy and runtime share the same cache. On the other hand (according to the experience) - Object Spy has some influence on the objects 'seen' by the runtime (especially when debugging and for NameMapping/Aliases functionality).
However, it was decided to implement the approach I described because of several reasons: a) it is not that difficult to enclose some action in a loop and repeat it several times; b) The action repeated immediately changes application's state the least (note, that during this test you are not testing the functionality, but only performance. That means that it is OK for the test code not to check the functionality (e.g. whether correct record was displayed, etc.) and it is better to execute one simple action at a time, but not the sequences of actions as per business process.); c) Executing actions in a loop does not require you to manually navigate in Object Spy to all tested objects (with the risk that some of them may be removed from TC cache while navigating because of cache size, because the application object was dismissed, etc.).
Mathijs,
> [...] so I will need to start exploring AQTime. Is there a demo version available so I can start to learn this?
Yes, as with all products by AutomatedQA - http://smartbear.com/products/development-tools/performance-profiling/sign-up/ (accessible from http://smartbear.com/products/development-tools/performance-profiling/).
> [...] the application I am testing on, is a webapplication [...]
I would recommend the http://smartbear.com/support/viewarticle/17953/ and related help articles.
Also: http://smartbear.com/support/screencasts/aqtime/profiling-scripts/ (from the http://smartbear.com/support/screencasts/aqtime/ page)
and http://smartbear.com/support/viewarticle/8748/
> [...] those numbers
include both the server processing time as well as the data transfer
time (time it takes to transfer the data (actually its pdf data) over
the network.
Yes. Actually LoadComplete measures several times (like Time To First Byte, Time To Last Byte, etc.) but obviously (as LoadComplete is running on the client but not on the server box) they all consist of the time for the request to get to the server, time spent by the server to process the request and time for the response to get back to the client. However, LoadComplete can connect to the Performance Counters on the server and I am sure (did not do this personally, but pretty much sure this is possible) that by selecting proper counter it should be possible to measure time it takes the server to process the request. Subtracting this time from the overall time for the request-response roundtrip you should be able to get separate figures for the server processing and network transfer times.
>
So, I guess, by using the Object Spy to "select" it, it should be in the
TestComplete namemapping model, right??
On the one hand I am far not sure that Object Spy and runtime share the same cache. On the other hand (according to the experience) - Object Spy has some influence on the objects 'seen' by the runtime (especially when debugging and for NameMapping/Aliases functionality).
However, it was decided to implement the approach I described because of several reasons: a) it is not that difficult to enclose some action in a loop and repeat it several times; b) The action repeated immediately changes application's state the least (note, that during this test you are not testing the functionality, but only performance. That means that it is OK for the test code not to check the functionality (e.g. whether correct record was displayed, etc.) and it is better to execute one simple action at a time, but not the sequences of actions as per business process.); c) Executing actions in a loop does not require you to manually navigate in Object Spy to all tested objects (with the risk that some of them may be removed from TC cache while navigating because of cache size, because the application object was dismissed, etc.).
