The majority of present day software users interact with the software via a graphical user interface (GUI) that comprises around 45-60% of the total code. The correctness of the Graphical user interface is important to ensure the correctness of the overall software. Despite the fact that GUIs have become common, testing GUIs for functional correctness has always been an ignored research area. Present GUI testing approaches are quite resource intensive simply because GUIs have very large input spaces and evolve frequently. This project report overcomes the constraints of existing approaches by creating a method with supporting models, techniques, and tools for continuous integration testing of evolving GUI-based applications. The main concept of this process is to generate three concentric testing loops, each with specific GUI testing goals, resource usage, and targeted feedback. The innermost totally automatic loop called crash testing operates on each code change of the GUI software……
Contents
1 Introduction
1.1 What is a GUI?
1.2 GUI Testing Process
1.3 Challenges of GUI Testing
1.4 Existing Approaches and their Limitation
1.5 A New Continuous GUI Testing Process
1.6 Structure of the Dissertation
2 Background and Related Work
2.1 GUI Representation
2.1.1 GUI’s State
2.1.2 Event-flow Graphs
2.2 Test Case Generation
2.2.1 Manual Approaches
2.2.2 Model-based Approaches
2.3 Test Oracles
2.4 Test Coverage Criteria
2.5 Regression testing
2.6 Rapid Feedback-based QA mechanisms
2.7 Fault Seeding
2.8 Summary
3 A Continuous graphical user interface GUI Testing Process
3.1 Innermost Loop
3.2 Intermediate Loop
3.3 Outermost Loop
3.4 Instantiating the Loops
3.5 Summary
4 Crash Testing
4.1 Minimized Effective Event Context
4.2 Pilot Study – Understanding the MEEC
4.2.1 Study Procedure
4.2.2 Step 1: Study Subjects
4.2.3 Step 2: Fault Seeding
4.2.4 Step 3: Test-Case Generation
4.2.5 Step 5: Studying Predecessor Events
4.3 Dissecting the MEEC
4.4 Threats to Validity
4.5 Event-Interaction Graph
4.6 Crash Test Cases
4.7 Feasibility Studies – Evaluating Crash Test Cases
4.7.1 Feasibility Study – Crash Testing on TerpOffice Applications
4.7.2 Feasibility Study – Crash Testing for Open-Source Applications .
4.8 Conclusions
5 Smoke Testing
5.1 Designing Different Test Oracles
5.1.1 Oracle Information
5.1.2 Oracle Procedure
5.2 Evaluating the GUI Test Oracles
5.2.1 Research Questions
5.2.2 Modeling Cost and Fault Detection Effectiveness
5.2.3 Experimentation Procedure
5.2.4 Results
5.3 Conclusions
6 Comprehensive GUI Testing
6.1 Experiment – Studying the Characteristics of a “Good” Comprehensive
Test Suite
6.1.1 Experimentation Procedure
6.1.2 Test Pool
6.1.3 Part 1: Effect of Test Suite Size
6.1.4 Part 2: Effect of Test Case Length
6.1.5 Part 3: Effect of Event Composition…………..
Source: University of Maryland
Download URL 2: Visit Now