毕业论文设计外文翻译研究基于gui测试生成的测试用例.doc

International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.1, January 2012STUDY PAPER ON TEST CASE GENERATION FOR GUI BASED TESTINGIsabella1and Emi Retna21PG Research Scholar, Software Engineering Group, School of Computer Science and Technology, Karunya University, Coimbatore, Indiaaisabella202Head Computer Technology Centre, Karunya University, Coimbatore, IndiaemiretnaABSTRACTWith the advent of WWW and outburst in technology and software development, testing the softwarebecame a major concern. Due to the importance of the testing phase in a software development lifecycle,testing has been divided into graphical user interface (GUI) based testing, logical testing, integrationtesting, etc.GUI Testing has become very important as it provides more sophisticated way to interact withthe software. The complexity of testing GUI increased over time. The testing needs to be performed in away that it provides effectiveness, efficiency, increased fault detection rate and good path coverage. Tocover all use cases and to provide testing for all possible (success/failure) scenarios the length of the testsequence is considered important. Intent of this paper is to study some techniques used for test casegeneration and process for various GUI based software applications.KEYWORDSGUI Testing, Model-Based Testing, Test Case, Automated Testing, Event Testing.1. INTRODUCTIONGraphical User Interface (GUI) is a program interface that takes advantage of the computersgraphics capabilities to make the program easier to use. Graphical User Interface (GUI) providesuser an immense way to interact with the software 1. The most eminent and essential parts ofthe software that is being used today are Graphical User Interfaces (GUIs) 8, 9. Even thoughGUIs provides user an easy way to use the software, they make the development process of thesoftware tangled 2.Graphical user interface (GUI) testing is the process of testing softwares graphical user interfaceto safeguard it meets its written specifications and to detect if application is working functionallycorrect. GUI testing involves performing some tasks and comparing the result with the expectedoutput. This is performed using test cases. GUI Testing can be performed either manually byhumans or automatically by automated methods.Manual testing is done by humans such as testers or developers itself in some cases and it is oftenerror prone and there are chances of most of the test scenarios left out. It is very time consumingalso. Automated GUI Testing includes automating testing tasks that have been done manuallybefore, using automated techniques and tools. Automated GUI testing is more, efficient, precise,reliable and cost effective.A test case normally consists of an input, output, expected result and the actual result. More thanone test case is required to test the full functionality of the GUI application. A collection of testcases are called test suite. A test suite contains detailed guidelines or objectives for eachcollection of test cases.Model Based Testing (MBT) is a quick and organized method which automates the testingprocess through automated test suite generation and execution techniques and tools 11. Modelbased testing uses the directed graph model of the GUI called event-interaction graph (EIG) 4and event semantic interaction graph (ESIG). Event interaction graph is a refinement of eventflow graph (EFG) 1. EIG contains events that interact with the business logic of the GUIapplication. Event Semantic Interaction (ESI) is used to identify set of events that need to betested together in multi-way interactions 3 and it is more useful when partitioning the eventsaccording to its functionality.This paper is organized as follow: Section 2 provides some techniques, algorithms used togenerate test cases, a method to repair the infeasible test suites are described in section 3, GUItesting on various types of softwares or under different conditions are elaborated in section 4,section 5 describes about testing the GUI application by taking event context into considerationand last section concludes the paper.2. TEST CASE GENERATION2.1. Using GUI Run-Time State as FeedbackXun Yuan and Atif M Memon 3, used GUI run time state as feedback for test case generationand the feedback is obtained from the execution of a seed test suite on an Application Under Test(AUT).This feedback is used to generate additional test cases and test interactions between GUIevents in multiple ways. An Event Interaction Graph (EIG) is generated for the application to betested and seed test suites are generated for two-way interactions of GUI events. Then the testsuites are executed and the GUIs run time state is recorded. This recorded GUI run time state isused to obtain Event Semantic Interaction(ESI) relationship for the application and these ESI areused to obtain the Event Semantic Interaction Graph(ESIG).The test cases are generated andESIGs is capable of managing test cases for more than two-way interactions and hence forth 2-,3-,4-,5- way interactions are tested. The newly generated test cases are tested and additional faultsare detected. These steps are shown in Figure 1. The fault detection effectiveness is high than thetwo way interactions and it is because, test cases are generated and executed for combination ofevents in different execution orders.There also some disadvantages in this feedback mechanism. This method is designed focusing onGUI applications. It will be different for applications that have intricate underlying business logicand a simple GUI. As multi-way interactions test cases are generated, large number of test caseswill be generated. This feedback mechanism is not automated.Figure 1. Test Case Generation Using GUI Runtime as Feedback2.2. Using Covering Array TechniqueXun Yuan et al 4, proposed a new automated technique for test case generation using coveringarrays (CA) for GUI testing. Usually 2-way covering are used for testing. Because as number ofevents in a sequence increases, the size of test suite grows large, preventing from using sequenceslonger than 3 or 4. But certain defects are not detected using this coverage strength. Using thistechnique long test sequences are generated and it is systematically sampled at particularcoverage strength. By using covering arrays t-way coverage strength is being maintained, but anylength test sequences can be generated of at least t. A covering array, CA(N; t, k, v), is an N karray on v symbols with the property that every N t sub-array contains all ordered subsets ofsize t of the v symbols at least once.As shown in Figure 2, Initially EIG model is created which is then partitioned into groups ofinteracting events and then constraints are identified and used to generate abstract model fortesting. Long test cases are generated using covering array sampling. Event sequences aregenerated and executed. If any event interaction is missed, then regenerate test cases and repeatthe steps.The disadvantages are event partition and identifying constraints are done manually.Figure 2. Test Generation Using Covering Array2.3. Dynamic Adaptive Automated test GenerationXun Yuan et al 5, suggested an algorithm to generate test suites with fewer infeasible test casesand higher event interaction coverage. Due to dynamic state based nature of GUIs, it is necessaryand important to generate test cases based on the feedback from the execution of tests. Theproposed framework uses techniques from combinatorial interaction testing to generate tests andbasis for combinatorial interaction testing is a covering array. Initially smoke tests are generatedand this is used as a seed to generate Event Semantic Interaction (ESI) relationships. EventSemantic Interaction Graph is generated from ESI. Iterative refinement is done through geneticalgorithm. An initial model of the GUI event interactions and an initial set of test sequences basedon the model are generated. Then a batch of test cases are generated and executed. Code coverageis determined and unexecutable test cases are identified. Once the infeasible test cases areidentified, it is removed and the model is updated and new batch of test cases are generated andthe steps are followed till all the uncovered ESI relationships are covered. These automated testcase generation process is shown in Figure 3. This automated test generation also providesvalidation for GUIs.The disadvantages are event contexts are not incorporated and need coverage and test adequacycriteria to check how these impacts fault detection.Figure 3. Automated Test Case Generation3. REPAIRING TEST SUITESSi Huang et al 6, proposed a method to repair GUI test suites using Genetic algorithm. New testcases are generated that are feasible and Genetic algorithm is used to develop test cases thatprovide additional test suite coverage by removing infeasible test cases and inserting new feasibletest cases. A framework is used to automatically repair infeasible test cases. A graph model suchas EFG, EIG, ESIG and the ripped GUI structure are used as input. The main controller passesthese inputs to the test case assembler which then passes the ESIG model to the covering arraygenerator along with the strength of testing. This covering array generator generates an initial setof event sequences. The covering array information is send to test case assembler and it assemblesthis into concrete test cases. These are passed back to the controller and test suite repair phasebegins. Feasible test cases are returned by the framework once the repair phase is complete.Genetic algorithm is used as a repair algorithm. An initial set of test cases are executed and ifthere is no infeasible test cases, it exits and is done. If infeasible test cases are present, it thenbegins the repair phase. A certain number of iterations are set based on an estimate of how largethe repaired test suite will be allowed to grow and for each iteration the genetic algorithm isexecuted. The algorithm adds best test case to the final test suites. Stopping criterias are used tostop the iterations.The advantages are it generates smaller test suites with better coverage on the longer testsequences. It provides feasible test cases. But it is not scalable for larger applications as executiontime is high. As GUI ripping is used, the programs that contain event dependencies may not bediscovered.4. GUI TESTING ON VARIOUS APPLICATIONS4.1. Industrial Graphical User Interface SystemsPenelope Brooks et al 7, developed GUI testing methods that are relevant to industryapplications that improve the overall quality of GUI testing by characterizing GUI systems usingdata collected from defects detected to assist testers and researchers in developing more effectivetest strategies. In this method, defects are classified based on beizers defect taxonomy. Eightlevels of categories are present each describing specific defects such as functional defects,functionality as implemented, structural defects, data defects, implementation defects, integrationdefects, system defects and test defects. The categories can be modified and added according tothe need. If any failures occur, it is analyzed under which defect category it comes and thisclassification is used to design better test oracle to detect such failures, better test case algorithmmay be designed and better fault seeding models may be designed.Goal Question Metric (GQM) Paradigm is used. It is used to analyze the test cases, defects andsource metrics from the tester / researcher point of view in the context of industry-developed GUIsoftware. The limitations are, the GUI systems are characterized based on system events only.User Interactions are not included.4.2. Community-Driven Open Source GUI ApplicationsQing Xie and Atif M. Memon 8, presented a new approach for continuous integration testing ofweb-based community-driven GUI-based Open Source Software(OSS).As in OSS manydevelopers are involved and make changes to the code through WWW, it is prone to more defectsand the changes keep on occurring. Therefore three nested techniques or three concentric loopsare used to automate model-based testing of evolving GUI-based OSS. Crash testing is theinnermost technique operates on each code check-in of the GUI software and it is executedfrequently with an automated GUI testing intervention and performs quickly also. It reports thesoftware crashes back to the developer who checked in the code. Smoke testing is the secondtechnique operates on each days GUI build and performs functional reference testing of thenewly integrated version of the GUI, using the previously tested version as a baseline.Comprehensive Testing is the outermost third technique conducts detailed comprehensive GUIintegration testing of a major GUI release and it is executed after a major version of GUI isavailable. Problems are reported to all the developers who are part of the development of theparticular version.These concentric loops provide resource utilization, errors are caught earlier by inner loops. Theflaws that persist across multiple versions GUI-based OSS are detected by this approach fullyautomatically. It provides feedback. The limitation is that the interactions between the three loopsare not defined.4.3. Continuously Evolving GUI-Based Software ApplicationsQing Xie and Atif M. Memon 9, developed a quality assurance mechanism to manage thequality of continuously evolving software by Presenting a new type of GUI testing, called crashtesting to help rapidly test the GUI as it evolves. Two levels of crash testing is being described:immediate feedback-based crash testing in which a developer indicates that a GUI bug was fixedin response to a previously reported crash; only the select crash test cases are re run and thedeveloper is notified of the results in a matter of seconds. If any code changes occur, new crashtest cases are generated and executed on the GUI. Test cases are generated that can be generatedand executed quickly and cover all GUI functionalities. Once EIG is obtained, a boolean flag isassociated with each edge in the graph. During crash testing, once test cases that cover thatparticular edge are generated, then the flag is set. If any changes occur, boolean flag for each edgeis retained. Test cases are executed and crashes during test execution are used to identify seriousproblems in the software. The crash testing process is shown in Figure 4. The effectiveness ofcrash test is known by the total number o