Those of You who don’t have any test automation at all has probably faced the dilemma: do it ? is it possible ? is it working ?
I propose You to take a fast test automation kick-off and gain a value and improve quality. I will describe how to write and use test case for Windows windowed application using AutoIt scripts, which cover main functionality :) – open all windows. Often we have some bugs which really don’t need complicated user interaction – window is opening and we see message box saying “SQL syntax error” or “Cannot operate on closed dataset”. That kind of errors are very critical but very easy to find by test automation.
Possible story
- Run application
- Login
- Open all possible windows by mouse
- Open all possible windows by shortcuts
- Close application
Tool ? AutoIt (http://www.autoitscript.com/autoit3/) – free script language engine with many of great features – plugin support etc.
Workaround
- Write help library – it will shorten the code
- How to report job – do screen shots
- How to manage script versions – connect with software releases.
Write help library – “library.au3″
Place here your global AutoIT options and help functions, when using SVN or another source control software connect library as external source.
Header - set global options – look at AutoIt docs (http://www.autoitscript.com/autoit3/docs/)
[cc lang="vb"]
Opt(“WinWaitDelay”,200)
Opt(“WinTitleMatchMode”,2)
Opt(“WinDetectHiddenText”,1)
Opt(“MouseCoordMode”,0)
Opt(“TrayIconDebug”, 1)
Opt(“SendKeyDelay”, 200)
Opt(“MouseCoordMode”, 2)
Global $WinWaitTimeOut = 5
Global $DEBUG = TRUE
Global $CurrentLine = 0;
Global $ErrorMessage = “”
#include <ScreenCapture.au3>
#include <Date.au3>
[/cc]
Screen Shot function
[cc lang="vb"]
Func _ScreenShot($caption)
; Capture full screen
$hBmp = _ScreenCapture_Capture(“”)
$sDateTime = StringReplace(_NowCalc(), “/”, “”)
$sDateTime = StringReplace($sDateTime, “:”, “”)
$sDateTime = StringReplace($sDateTime, ” “, “_”)
$FileName = “C:OutputFolder” & $Caption & $sDateTime & “.jpg”
; Save bitmap to file
_ScreenCapture_SaveImage($FileName, $hBMP)
EndFunc
[/cc]
Window Active and Wait
First one tries to activate windows, next one waits for a window with provided title then activate it.
[cc lang="vb"]
Func _WindowActivate($title, $text = “”)
IF WinActive($title, $text) = 0 Then
$ErrorMessage = StringFormat(“Window not found %s”, $title)
Exit()
EndIf
EndFunc
Func _WindowWait ( $title, $text=”" )
IF WinWait ( $title, $text, $WinWaitTimeOut ) = 0 THEN
$ErrorMessage = StringFormat(“Window not found %s”, $title)
Exit()
EndIf
IF WinWaitActive($title, $text, 5) = 0 Then
$ErrorMessage = StringFormat(“Window not found %s”, $title)
Exit()
EndIf
EndFunc
[/cc]
Give feedback / report functions
[cc lang="vb"]
‘ fill it with start actions
Func OnAutoItStart ( )
EndFunc
‘ if global errormassage variable is not empty – take screen shot
Func OnAutoItExit ( )
If $ErrorMessage <> “” Then
_ScreenShot(“img”)
EndIf
ConsoleWrite($ErrorMessage)
EndFunc
[/cc]
Constants library – constants.au3
[cc lang="vb"]
Global $WINDOW_LOGIN = “Please login”
Global $WINDOW_MAINSCREEN = “My Application”
Global $WINDOW_PREFERENCES = “Application preferences”
[/cc]
Final code example
[cc lang="vb"]
#include <library.au3>
#include <constants.au3>
Run(“PathToYourApplication”, PathToFolder)
Sleep(10000)
_WindowActivate($WINDOW_LOGIN)
‘typicaly we have focus on password field
Send(“some password”)
Send(“{Enter}”)
_WindowWait($WINDOW_MAINSCREEN)
‘ alt + p – run preferences from shortcut
Send(“{!p}”)
_WindowWait($WINDOW_PREFERENCES)
‘ close window or use alt + f4
Send(“{Esc}”)
[/cc]
How to manage script versions
User SVN or other code repository. Place test scripts with Your application codes, is easy to manage it with connection to software versions. Group scripts into folders !
Run It !
Run that kind of script every gui test process – it helps, belive me :) AutoIT can compile script to exe application.
Marcin,
I have something to suggest; I’ve been using a similar approach, but with a commercial product, albeit a very inexpensive one at that…
Why Homebrew + Tool in development?
First, regarding the HomeBrew solution, well this article says it all. Much like your approach, where you aim to cover more in less time. HomeBrew
However, what if you would like to do the same for your company/testing but you’re not a programmer (like myself), or never, ever had anything to do with programming. Is this road totally off limits?! Well, not completely. I came across an automation tool, Macro Scheduler that works extremely well because it follows your idea and comes complete with the pre-built functions (like the ones you’ve created) and allows the tester create scripts that wait for windows, and log error messages easily.
I think that a powerful and quick scripting language is best, and it seems impossible to achieve that in short time. But a good High level language such as Perl, python, Smalltalk can be leveraged to achieve great results in the right hands. But what about making it work, Debugging, etc.?
These aren’t easy things for some people to learn. I was totally lost in college when it came to programming. C++ was an F-0 for me. So what does somebody like me do?
Go into film making?
Uh, maybe…
Then I came across Macro Scheduler. I love it because it allowed me to, as I mentioned already, create scripts to do the same while I’m just a mere mortal.
-I have to admit, that the code above is overwhelming for a guy like me, but I still want and need a better way to do my job. So what’s the advantage that you get with Macro Scheduler.
Well, its THE SUPPORT; the number one reason someone like me might need a commercial tool, and this justifies the cost. Actually, I think the tool is free for all intent and purposes, and the amount paid is for the support received. You get many examples and a great support community, along with a tremendous support effort from the company itself (very high quality indeed). All this make it possible for others (like myself) to, for very little money mind you, do the testing you’ve suggest quicker and easier.
[...] problem of a robot that performs a test for the man appears to be something simple: iTestBot , AutoIT and many others. Each of these applications will be able to log the duration of the operation, [...]
I just wanted to point out http://vbscript-macro-template.blogspot.com as another solution instead of autoit. It using vbscript which is already built in. All you have to do is use the prebuilt functions in the free vbscript template. That works easier for me because there are a lot of machines that I can not install autoit onto for one reason or another. If I had compiled the autoit scripts, then I can’t tweak the code without recompiling. With this macro template, I have the code right there. I like it. Thats all.
Thanks Joey for the link to another test tool.
This article is great, however, it’s rather simplistic on test automation. One of the big problems with test automation is detecting or validating the state of the GUI. It is much easier to just drive the GUI without checking its state.
Being a free tool, AutoIt is more limited in its ability to detect the state of GUI components. Commercial tools offer you additional ways to do the detection, and may be more robust in the detection process.
And last thing to mention, GUI component (IDs or names) can change in every build/release and thus can break automation because you’ll have to update the IDs/names of the controls in the automation code.
Thanks David for a comment, you have absolutly right. Application state is always a challange, we can try to construct some functions to detact it but it is hard to do.
Components ID’s is another, not very predictable thing it depends on technology. In Flex Automation we have special component property “automationName” which is stable because developers must set it every time.
Nice post.
If I coud say anything, AutoIT is very good for simulating user interaction – quite simple and rapid. This kind of tests are expensive to maintain though… There are lots of external issues that can result in an AutoIT test fails (e.g. another process or a pop-up that steals the focus, when the script is supposed to click something).
IMHO it’s better to write as much of simple unit tests as possible (test the code) and use AutoIT for cases when user interaction is the aspect to be tested.
But anyway, AutoIT has it – it’s very powerful. You can do a lot with it!
Jarek