I am using Macro Scheduler for 2 months now to do GUI testing of a Windows application. It works well and it is easy to use. the forum is of great help for new learners like me. Appreciate the super fast responses and suggestions.
The windows application I am testing has lots of shortcuts for navigation. The test script passes these shortcuts such as Alt +S, Ctrl +F etc. What I am worried about is this type of testing seems heavily dependent on GUI. I'll have to rewrite my scripts if the windows/forms within the application is changed.
Is there a way to automate things better? The language used is C# and I am wondering if I should be writing test scripts that interacts with the code.
Welcome any suggestions and questions.
Thanks much!
Need suggestions on more testing options
Moderators: Dorian (MJT support), JRL
-
Marcus Tettmar
- Site Admin
- Posts: 7395
- Joined: Thu Sep 19, 2002 3:00 pm
- Location: Dorset, UK
- Contact:
If you are doing UI testing - and you want to test the GUI - then of course if the GUI changes intentionally you will have to change your test. If the GUI changes unintentionally then your test will fail, which is what you want.
If you go for testing something beneath the GUI and not simulating what a user would do then in my view you are not testing the interface at all.
If you go for testing something beneath the GUI and not simulating what a user would do then in my view you are not testing the interface at all.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
-
Jerry Thomas
- Macro Veteran
- Posts: 267
- Joined: Mon Sep 27, 2010 8:57 pm
- Location: Seattle, WA
UI Testing has a high support cost.
Every time a developer changes a UI you are changing scripts.
If you isolate the action from the scripts, you will be making fewer changes. Ideally you want to update in just 1 place and all scripts still run, instead of having to change every script.
Example:
Your test scripts all print out the results.
Instead of having every script call "Alt+P" or File/Print/..., you would have them call "GoSub>PrintResults,ResultsData".
In that subroutine, you would define how to print.
The first line in my scripts is "Include>%Script_Dir%\BaseFunctions.scp".
This has all of the functionality to press any button or call any functionality.
My scripts use this approach:
GoSub>Action,Button,Data,XLoc,YLoc
Where action is Click or RightClick, Button is the button I want to use, data that might be applicable, and then the X and Y screen location to click
They look like this:
GoSub>RtClickItem,Select,,100,200
GoSub>RtClickItem,Text,text to enter,,
GoSub>ClickBtn,Zoom,,200,300
Every time a developer changes a UI you are changing scripts.
If you isolate the action from the scripts, you will be making fewer changes. Ideally you want to update in just 1 place and all scripts still run, instead of having to change every script.
Example:
Your test scripts all print out the results.
Instead of having every script call "Alt+P" or File/Print/..., you would have them call "GoSub>PrintResults,ResultsData".
In that subroutine, you would define how to print.
The first line in my scripts is "Include>%Script_Dir%\BaseFunctions.scp".
This has all of the functionality to press any button or call any functionality.
My scripts use this approach:
GoSub>Action,Button,Data,XLoc,YLoc
Where action is Click or RightClick, Button is the button I want to use, data that might be applicable, and then the X and Y screen location to click
They look like this:
GoSub>RtClickItem,Select,,100,200
GoSub>RtClickItem,Text,text to enter,,
GoSub>ClickBtn,Zoom,,200,300
