Your SlideShare is downloading. ×
Automated GUI testing
Automated GUI testing
Automated GUI testing
Automated GUI testing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Automated GUI testing

585

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
585
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Some GUI facts Automated GUI testing Software testing accounts for 50-60% of total software development costs GUIs can constitute as much as 60% of the code of an application How to test an interactive GUI development frameworks such as application automatically? Swing make GUI development easier Unfortunately, they make GUI testing much harder 2 Why is GUI testing difficult? Challenges of GUI testing Event-driven architecture Test case generation: What combinations User actions create events of user actions to try? An automatic test suite has to simulate these Oracles: What is the expected GUI events somehow behaviour? Large space of possibilities Coverage: How much testing is enough? The user may click on any pixel on the screen Regression testing: Can test cases from an Even the simplest components have a large earlier version be re-used? number of attributes and methods JButton has more than 50 attributes and 200 methods Representation: How to represent the GUI The state of the GUI is a combination of the states to handle all the above? of all of its components 3 4 A GUI test case A GUI Test Case 1. Select text “Some” 2. Menu “Format” 4. Combobox “Size” 3. Option “Font” 5. Click on 26 6. Click OK 5 6 1
  • 2. A GUI Test Case GUI vs. business model testing GUI testing The look of the text in the editor window corresponds to the operations performed 7. Select “text” The U button is selected 8. Click U All appropriate actions are still enabled, i.e. we 9. Verify that the can italicize the underlined text output looks like this Business model testing Word’s internal model reflects the text formatting we performed 7 8 Two approaches to GUI testing Two approaches to GUI testing 1. Black box 2. Glass box Launch application Launch application in the testing code Simulate mouse and keyboard events Obtain references to the various components and send events to them Compare final look to an existing screen Assert the state of components directly dump Test cases harder to break Very brittle test cases Business model can be tested Cannot test business model Framework dependent Framework independent 9 10 A first approach RobotDemo The Java API provides a class called java.awt.Robot It can be used to generate native system input events Different than creating Event objects and adding them to the AWT event queue These events will indeed move the mouse, click, etc. 11 12 2
  • 3. Testing with Robot Problems with this approach User input can be simulated by the robot Low-level How to evaluate that the correct GUI Would rather say “Select "blue" from the behaviour has taken place? colour list” than Robot includes method Move to the colour list public BufferedImage co-ordinates createScreenCapture(Rectangle screenRect) Click Creates an image containing pixels read from the Press 5 times screen Click Brittle test cases (regression impossible) 13 14 A better approach Unfortunately… Every GUI component should provide a Most GUI development frameworks are public API which can be invoked in the not designed in this fashion same manner via a system user event or programmatically In Swing, event handling is mixed with complex component behaviour in the Component behaviour should be Look and Feel code separated from event handling code For example, class JButton contains the Few components offer methods such as doClick() method doClick() 15 16 Abbot – A Better ’Bot Goals of the Abbot framework A GUI testing framework for Swing Reliable reproduction of user input Works seamlessly with JUnit High-level semantic actions Can be used to create Scripted control of actions Unit tests for GUI components Loose component bindings Functional tests for existing GUI apps Extensible user action recording and Open source generation http://abbot.sourceforge.net/ 17 18 3
  • 4. Abbot overview A typical test case A better Robot class is provided JButton button = (JButton)getFinder().find( abbot.tester.Robot includes events to click, drag, new Matcher() { type on any component public boolean matches(Component c) { For each Swing widget a corresponding return c instanceof JButton && Tester class is provided ((JButton)c).getText().equals("OK"); E.g. JPopupMenuTester provides a method called }}); getMenuLabels() AbstractButtonTester tester = Components can be retrieved from the new AbstractButtonTester(); component hierarchy Tester.actionClick(button); assertEquals("Wrong button tooltip", No direct reference to any widget is necessary "Click to accept", button.getToolTipText()); 19 20 Unit Testing with Abbot demo Costello Demo 21 22 4

×