Running The Test Cases
At first the strategies were migrated and adapted from the CLI testing strategies. A popular method used in the CLI environment is capture/playback. Capture playback is a system where the system screen is “captured” as a bitmapped graphic at various times during system testing. This capturing allowed the tester to “play back” the testing process and compare the screens at the output phase of the test with expected screens. This validation could be automated since the screens would be identical if the case passed and different if the case failed.
Using capture/playback worked quite well in the CLI world but there are significant problems when one tries to implement it on a GUI-based system. The most obvious problem one finds is that the screen in a GUI system may look different while the state of the underlying system is the same, making automated validation extremely difficult. This is because a GUI allows graphical objects to vary in appearance and placement on the screen. Fonts may be different, window colors or sizes may vary but the system output is basically the same. This would be obvious to a user, but not obvious to an automated validation system.
To combat this and other problems, testers have gone ‘under the hood’ and collected GUI interaction data from the underlying windowing system. By capturing the window ‘events’ into logs the interactions with the system are now in a format that is decoupled from the appearance of the GUI. Now, only the event streams are captured. There is some filtering of the event streams necessary since the streams of events are usually very detailed and most events aren’t directly relevant to the problem. This approach can be made easier by using an MVC architecture for example and making the view (i. e. the GUI here) as simple as possible while the model and the controller hold all the logic. Another approach is to use the software's built-in assistive technology, to use an HTML interface or a three-tier architecture that makes it also possible to better separate the user interface from the rest of the application.
Another way to run tests on a GUI is to build a driver into the GUI so that commands or events can be sent to the software from another program. This method of directly sending events to and receiving events from a system is highly desirable when testing, since the input and output testing can be fully automated and user error is eliminated.
Read more about this topic: Graphical User Interface Testing
Famous quotes containing the words running the, running, test and/or cases:
“People run away from the name subsidy. It is a subsidy. I am not afraid to call it so. It is paid for the purpose of giving a merchant marine to the whole country so that the trade of the whole country will be benefitted thereby, and the men running the ships will of course make a reasonable profit.... Unless we have a merchant marine, our navy if called upon for offensive or defensive work is going to be most defective.”
—William Howard Taft (1857–1930)
“It is moot whether there be divinities
As I finish this play by Webster:
The street-cars are still running however
And the katharsis fades in the warm water of a yawn.”
—Allen Tate (1899–1979)
“A decent provision for the poor is the true test of civilization.”
—Samuel Johnson (1709–1784)
“We noticed several other sandy tracts in our voyage; and the course of the Merrimack can be traced from the nearest mountain by its yellow sand-banks, though the river itself is for the most part invisible. Lawsuits, as we hear, have in some cases grown out of these causes. Railroads have been made through certain irritable districts, breaking their sod, and so have set the sand to blowing, till it has converted fertile farms into deserts, and the company has had to pay the damages.”
—Henry David Thoreau (1817–1862)