Anti sleep function (QTP, VBScript, MercuryTimer, DeviceReplay)
Sometimes a PC goes to sleep, launches screensaver or locks the desktop during a long synchronization periods or other GUI inactivity periods. Adding the function below makes the script periodically moving mouse to avoid breaking of the execution. Place the call to the function within your time-consuming loops and custom synchronization functions.
To improve performance you may want to move Set objDeviceReplay = CreateObject(“Mercury.DeviceReplay”) statement to a global initialization function and do not create/release the object constantly.
Private Const SleepTime_Max = 300 ' 5 minutes
'
Public Function AntiSleep()
Dim iter
Dim objTimer
Dim objDeviceReplay
Dim intTimeElapsed
Set objTimer = MercuryTimers("AntiSleep")
intTimeElapsed = CInt(objTimer.ElapsedTime/1000)
If intTimeElapsed = 0 Then
MercuryTimers("AntiSleep").Start
Exit Function
End If
If intTimeElapsed < SleepTime_Max Then
Exit Function
End If
Set objDeviceReplay = CreateObject("Mercury.DeviceReplay")
For iter = 100 To 110
objDeviceReplay.MouseMove iter,300
Next
MercuryTimers("AntiSleep").Start
Set objDeviceReplay = Nothing
End Function
6 responses to "Anti sleep function (QTP, VBScript, MercuryTimer, DeviceReplay)"
I always turn off screensavers from machines where I’m performing automated testing. That way this problem never occurs.
In some scripting languages, you can turn it off programmatically, test, then turn it back on.
(I’m not sure moving the mouse to keep the system from sleeping is always wise. What if the pointer location is significant to your system-under-test?)
Hi Joe,
Don’t be surprised, in many large organizations security policies are very strict! You won’t even have the access to screensaver settings.
Going further, having screensaver turned off you won’t prevent a machine from going to stand-by mode – it will go to sleep and script waiting for a long generating report will get stopped/failed.
Regarding _my_ test automation, I have end-users executing scripts on different machines, and the main requirement is to be able to use the script “right now” and “as is”. The more _unnecessary_ manual configuration is required the less user-friendly solution is.
The workarounds you suggested may still work under some circumstances… I just think it’s much simpler not having the problem at all.
(As for the last note, I believe you didn’t really think it through. I’m afraid to imagine a program-under-test that prohibits a user from moving mouse anytime he wants.)
Thanks.
“(As for the last note, I believe you didn’t really think it through. I’m afraid to imagine a program-under-test that prohibits a user from moving mouse anytime he wants.)”
I didn’t say “prohibits”.
I know sites that have different behavior, depending on where the mouse pointer is placed. So do you, I’m sure.
Take, for example *this* site. With all the SnapShot popups, if you move the mouse into the wrong spot, something (perhaps unaccounted for) happens.
Anyway, glad this method works for you.
-joe
I finally think I should provide some more details.
The most common example.
“Generate report” button has been pressed.
Depending on the query (e.g. range of accounts and date range) AND Test Environment performance, generation of report takes from 1 minute to 20 minutes while a typical screensaver setting is 10 minutes, and stand-by setting is 20 minutes.
While report is being generated by the server on the back-end the Application-Under-Test is busy and not interacting with the user. It is not supposed to behave anyhow at the front-end until the report is generated.
So the script is simply waiting in the synchronization loop. Moving mouse won’t trigger anything.
Properly created scripts are successfully used through the all testing phases, and executed on different computers by different users without programming skills. All they want is to get test results with minimal manual efforts spent and definitely not changing computer configuration, especially on UAT which usually mimics all the settings from production.
So instead of excusing the script for failing test cases is better to use proper synchronization function.
And, by the way, the moving trajectory is all under control: DeviceReplay.MouseMove X,Y. So you can move the cursor over taskbar or title bar to be in complete safety.
Thanks.
Thanks, It helped me to resolve the issue.
Thank-you for the help. Will check this out!