外文翻譯--研究基于gui測(cè)試生成的測(cè)試用例

1、<p>　　International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.1, January 2012</p><p>　　STUDY PAPER ON TEST CASE GENERATION FOR</p><p>　　GUI BASED TESTING</p&g

2、t;<p>　　Isabella1and Emi Retna2</p><p><b>　　1</b></p><p>　　PG Research Scholar, Software Engineering Group, School of Computer Science and</p><p>　　Technology, Ka

3、runya University, Coimbatore, India</p><p>　　aisabella20@gmail.com</p><p><b>　　2</b></p><p>　　Head – Computer Technology Centre, Karunya University, Coimbatore, India<

4、;/p><p>　　emiretna@gmail.com</p><p><b>　　ABSTRACT</b></p><p>　　With the advent of WWW and outburst in technology and software development, testing the software</p>&

5、lt;p>　　became a major concern. Due to the importance of the testing phase in a software development lifecycle,</p><p>　　testing has been divided into graphical user interface (GUI) based testing, logical

6、testing, integration</p><p>　　testing, etc.GUI Testing has become very important as it provides more sophisticated way to interact with</p><p>　　the software. The complexity of testing GUI incre

7、ased over time. The testing needs to be performed in a</p><p>　　way that it provides effectiveness, efficiency, increased fault detection rate and good path coverage. To</p><p>　　cover all use c

8、ases and to provide testing for all possible (success/failure) scenarios the length of the test</p><p>　　sequence is considered important. Intent of this paper is to study some techniques used for test case&

9、lt;/p><p>　　generation and process for various GUI based software applications.</p><p><b>　　KEYWORDS</b></p><p>　　GUI Testing, Model-Based Testing, Test Case, Automated Tes

10、ting, Event Testing.</p><p>　　1. INTRODUCTION</p><p>　　Graphical User Interface (GUI) is a program interface that takes advantage of the computer's</p><p>　　graphics capabilitie

11、s to make the program easier to use. Graphical User Interface (GUI) provides</p><p>　　user an immense way to interact with the software [1]. The most eminent and essential parts of</p><p>　　the

12、software that is being used today are Graphical User Interfaces (GUIs) [8], [9]. Even though</p><p>　　GUIs provides user an easy way to use the software, they make the development process of the</p>&

13、lt;p>　　software tangled [2].</p><p>　　Graphical user interface (GUI) testing is the process of testing software's graphical user interface</p><p>　　to safeguard it meets its written speci

14、fications and to detect if application is working functionally</p><p>　　correct. GUI testing involves performing some tasks and comparing the result with the expected</p><p>　　output. This is pe

15、rformed using test cases. GUI Testing can be performed either manually by</p><p>　　humans or automatically by automated methods.</p><p>　　Manual testing is done by humans such as testers or deve

16、lopers itself in some cases and it is often</p><p>　　error prone and there are chances of most of the test scenarios left out. It is very time consuming</p><p>　　also. Automated GUI Testing incl

17、udes automating testing tasks that have been done manually</p><p>　　before, using automated techniques and tools. Automated GUI testing is more, efficient, precise,</p><p>　　reliable and cost ef

18、fective.</p><p>　　A test case normally consists of an input, output, expected result and the actual result. More than</p><p>　　one test case is required to test the full functionality of the GUI

19、 application. A collection of test</p><p>　　cases are called test suite. A test suite contains detailed guidelines or objectives for each</p><p>　　collection of test cases.</p><p>　

20、　Model Based Testing (MBT) is a quick and organized method which automates the testing</p><p>　　process through automated test suite generation and execution techniques and tools [11]. Model</p><p

21、>　　based testing uses the directed graph model of the GUI called event-interaction graph (EIG) [4]</p><p>　　and event semantic interaction graph (ESIG). Event interaction graph is a refinement of event<

22、;/p><p>　　flow graph (EFG) [1]. EIG contains events that interact with the business logic of the GUI</p><p>　　application. Event Semantic Interaction (ESI) is used to identify set of events that ne

23、ed to be</p><p>　　tested together in multi-way interactions [3] and it is more useful when partitioning the events</p><p>　　according to its functionality.</p><p>　　This paper is or

24、ganized as follow: Section 2 provides some techniques, algorithms used to</p><p>　　generate test cases, a method to repair the infeasible test suites are described in section 3, GUI</p><p>　　tes

25、ting on various types of softwares or under different conditions are elaborated in section 4,</p><p>　　section 5 describes about testing the GUI application by taking event context into consideration</p&g

26、t;<p>　　and last section concludes the paper.</p><p>　　2. TEST CASE GENERATION</p><p>　　2.1. Using GUI Run-Time State as Feedback</p><p>　　Xun Yuan and Atif M Memon [3], used

27、 GUI run time state as feedback for test case generation</p><p>　　and the feedback is obtained from the execution of a seed test suite on an Application Under Test</p><p>　　(AUT).This feedback i

28、s used to generate additional test cases and test interactions between GUI</p><p>　　events in multiple ways. An Event Interaction Graph (EIG) is generated for the application to be</p><p>　　test

29、ed and seed test suites are generated for two-way interactions of GUI events. Then the test</p><p>　　suites are executed and the GUI’s run time state is recorded. This recorded GUI run time state is</p>

30、;<p>　　used to obtain Event Semantic Interaction(ESI) relationship for the application and these ESI are</p><p>　　used to obtain the Event Semantic Interaction Graph(ESIG).The test cases are generated

31、 and</p><p>　　ESIGs is capable of managing test cases for more than two-way interactions and hence forth 2-,</p><p>　　3-,4-,5- way interactions are tested. The newly generated test cases are tes

32、ted and additional faults</p><p>　　are detected. These steps are shown in Figure 1. The fault detection effectiveness is high than the</p><p>　　two way interactions and it is because, test cases

33、 are generated and executed for combination of</p><p>　　events in different execution orders.</p><p>　　There also some disadvantages in this feedback mechanism. This method is designed focusing

34、on</p><p>　　GUI applications. It will be different for applications that have intricate underlying business logic</p><p>　　and a simple GUI. As multi-way interactions test cases are generated, l

35、arge number of test cases</p><p>　　will be generated. This feedback mechanism is not automated.</p><p>　　Figure 1. Test Case Generation Using GUI Runtime as Feedback</p><p>　　2.2. U

36、sing Covering Array Technique</p><p>　　Xun Yuan et al [4], proposed a new automated technique for test case generation using covering</p><p>　　arrays (CA) for GUI testing. Usually 2-way covering

37、 are used for testing. Because as number of</p><p>　　events in a sequence increases, the size of test suite grows large, preventing from using sequences</p><p>　　longer than 3 or 4. But certain

38、defects are not detected using this coverage strength. Using this</p><p>　　technique long test sequences are generated and it is systematically sampled at particular</p><p>　　coverage strength.

39、By using covering arrays t-way coverage strength is being maintained, but any</p><p>　　length test sequences can be generated of at least t. A covering array, CA(N; t, k, v), is an N × k</p><

40、p>　　array on v symbols with the property that every N × t sub-array contains all ordered subsets of</p><p>　　size t of the v symbols at least once.</p><p>　　As shown in Figure 2, Initial

41、ly EIG model is created which is then partitioned into groups of</p><p>　　interacting events and then constraints are identified and used to generate abstract model for</p><p>　　testing. Long te

42、st cases are generated using covering array sampling. Event sequences are</p><p>　　generated and executed. If any event interaction is missed, then regenerate test cases and repeat</p><p>　　the

43、steps.</p><p>　　The disadvantages are event partition and identifying constraints are done manually.</p><p>　　Figure 2. Test Generation Using Covering Array</p><p>　　2.3. Dynamic Ad

44、aptive Automated test Generation</p><p>　　Xun Yuan et al [5], suggested an algorithm to generate test suites with fewer infeasible test cases</p><p>　　and higher event interaction coverage. Due

45、to dynamic state based nature of GUIs, it is necessary</p><p>　　and important to generate test cases based on the feedback from the execution of tests. The</p><p>　　proposed framework uses techn

46、iques from combinatorial interaction testing to generate tests and</p><p>　　basis for combinatorial interaction testing is a covering array. Initially smoke tests are generated</p><p>　　and this

47、 is used as a seed to generate Event Semantic Interaction (ESI) relationships. Event</p><p>　　Semantic Interaction Graph is generated from ESI. Iterative refinement is done through genetic</p><p&g

48、t;　　algorithm. An initial model of the GUI event interactions and an initial set of test sequences based</p><p>　　on the model are generated. Then a batch of test cases are generated and executed. Code cover

49、age</p><p>　　is determined and unexecutable test cases are identified. Once the infeasible test cases are</p><p>　　identified, it is removed and the model is updated and new batch of test cases

50、are generated and</p><p>　　the steps are followed till all the uncovered ESI relationships are covered. These automated test</p><p>　　case generation process is shown in Figure 3. This automated

51、 test generation also provides</p><p>　　validation for GUIs.</p><p>　　The disadvantages are event contexts are not incorporated and need coverage and test adequacy</p><p>　　criteria

52、 to check how these impacts fault detection.</p><p>　　Figure 3. Automated Test Case Generation</p><p>　　3. REPAIRING TEST SUITES</p><p>　　Si Huang et al [6], proposed a method to re

53、pair GUI test suites using Genetic algorithm. New test</p><p>　　cases are generated that are feasible and Genetic algorithm is used to develop test cases that</p><p>　　provide additional test su

54、ite coverage by removing infeasible test cases and inserting new feasible</p><p>　　test cases. A framework is used to automatically repair infeasible test cases. A graph model such</p><p>　　as E

55、FG, EIG, ESIG and the ripped GUI structure are used as input. The main controller passes</p><p>　　these inputs to the test case assembler which then passes the ESIG model to the covering array</p><

56、;p>　　generator along with the strength of testing. This covering array generator generates an initial set</p><p>　　of event sequences. The covering array information is send to test case assembler and it

57、assembles</p><p>　　this into concrete test cases. These are passed back to the controller and test suite repair phase</p><p>　　begins. Feasible test cases are returned by the framework once the

58、repair phase is complete.</p><p>　　Genetic algorithm is used as a repair algorithm. An initial set of test cases are executed and if</p><p>　　there is no infeasible test cases, it exits and is d

59、one. If infeasible test cases are present, it then</p><p>　　begins the repair phase. A certain number of iterations are set based on an estimate of how large</p><p>　　the repaired test suite wil

60、l be allowed to grow and for each iteration the genetic algorithm is</p><p>　　executed. The algorithm adds best test case to the final test suites. Stopping criteria’s are used to</p><p>　　stop

61、the iterations.</p><p>　　The advantages are it generates smaller test suites with better coverage on the longer test</p><p>　　sequences. It provides feasible test cases. But it is not scalable f

62、or larger applications as execution</p><p>　　time is high. As GUI ripping is used, the programs that contain event dependencies may not be</p><p>　　discovered.</p><p>　　4. GUI TESTI

63、NG ON VARIOUS APPLICATIONS</p><p>　　4.1. Industrial Graphical User Interface Systems</p><p>　　Penelope Brooks et al [7], developed GUI testing methods that are relevant to industry</p>&l

64、t;p>　　applications that improve the overall quality of GUI testing by characterizing GUI systems using</p><p>　　data collected from defects detected to assist testers and researchers in developing more ef

65、fective</p><p>　　test strategies. In this method, defects are classified based on beizer’s defect taxonomy. Eight</p><p>　　levels of categories are present each describing specific defects such

66、as functional defects,</p><p>　　functionality as implemented, structural defects, data defects, implementation defects, integration</p><p>　　defects, system defects and test defects. The categor

67、ies can be modified and added according to</p><p>　　the need. If any failures occur, it is analyzed under which defect category it comes and this</p><p>　　classification is used to design better

68、 test oracle to detect such failures, better test case algorithm</p><p>　　may be designed and better fault seeding models may be designed.</p><p>　　Goal Question Metric (GQM) Paradigm is used. I

69、t is used to analyze the test cases, defects and</p><p>　　source metrics from the tester / researcher point of view in the context of industry-developed GUI</p><p>　　software. The limitations ar

70、e, the GUI systems are characterized based on system events only.</p><p>　　User Interactions are not included.</p><p>　　4.2. Community-Driven Open Source GUI Applications</p><p>　　Q

71、ing Xie and Atif M. Memon [8], presented a new approach for continuous integration testing of</p><p>　　web-based community-driven GUI-based Open Source Software(OSS).As in OSS many</p><p>　　deve

72、lopers are involved and make changes to the code through WWW, it is prone to more defects</p><p>　　and the changes keep on occurring. Therefore three nested techniques or three concentric loops</p>&l

73、t;p>　　are used to automate model-based testing of evolving GUI-based OSS. Crash testing is the</p><p>　　innermost technique operates on each code check-in of the GUI software and it is executed</p>

74、<p>　　frequently with an automated GUI testing intervention and performs quickly also. It reports the</p><p>　　software crashes back to the developer who checked in the code. Smoke testing is the secon

75、d</p><p>　　technique operates on each day's GUI build and performs functional reference testing of the</p><p>　　newly integrated version of the GUI, using the previously tested version as a

76、baseline.</p><p>　　Comprehensive Testing is the outermost third technique conducts detailed comprehensive GUI</p><p>　　integration testing of a major GUI release and it is executed after a major

77、 version of GUI is</p><p>　　available. Problems are reported to all the developers who are part of the development of the</p><p>　　particular version.</p><p>　　These concentric loop

78、s provide resource utilization, errors are caught earlier by inner loops. The</p><p>　　flaws that persist across multiple versions GUI-based OSS are detected by this approach fully</p><p>　　auto

79、matically. It provides feedback. The limitation is that the interactions between the three loops</p><p>　　are not defined.</p><p>　　4.3. Continuously Evolving GUI-Based Software Applications<

80、/p><p>　　Qing Xie and Atif M. Memon [9], developed a quality assurance mechanism to manage the</p><p>　　quality of continuously evolving software by Presenting a new type of GUI testing, called cra

81、sh</p><p>　　testing to help rapidly test the GUI as it evolves. Two levels of crash testing is being described:</p><p>　　immediate feedback-based crash testing in which a developer indicates tha

82、t a GUI bug was fixed</p><p>　　in response to a previously reported crash; only the select crash test cases are re run and the</p><p>　　developer is notified of the results in a matter of second

83、s. If any code changes occur, new crash</p><p>　　test cases are generated and executed on the GUI. Test cases are generated that can be generated</p><p>　　and executed quickly and cover all GUI

84、functionalities. Once EIG is obtained, a boolean flag is</p><p>　　associated with each edge in the graph. During crash testing, once test cases that cover that</p><p>　　particular edge are gener

85、ated, then the flag is set. If any changes occur, boolean flag for each edge</p><p>　　is retained. Test cases are executed and crashes during test execution are used to identify serious</p><p>　

86、　problems in the software. The crash testing process is shown in Figure 4. The effectiveness of</p><p>　　crash test is known by the total number of test cases used to detect maximum faults. Significantly,<

87、;/p><p>　　test suite size has no impact on number of bugs revealed.</p><p>　　This crash testing technique is used to maintain the quality of the GUI application and it also</p><p>　　he

88、lps in rapidly testing the application. The drawbacks are, this technique is used for only testing</p><p>　　GUI application and cannot used in web applications, Fault injection or seeding technique, which<

89、;/p><p>　　is used to evaluate the efficiency of the method used is not applied here.</p><p>　　Figure 4. Crash Testing Process</p><p>　　4.4. Rapidly Evolving Software</p><p&g

90、t;　　Atif M. Memon et al [10], made several contributions in the area of GUI smoke testing in terms</p><p>　　of GUI smoke test suites, their size, fault detection ability and test oracle. Daily Automated</

91、p><p>　　Regression Tester (DART) framework is used to automate GUI smoke testing. Developers work</p><p>　　on the code during day time and DART automatically launches the Application Under Test<

92、/p><p>　　(AUT) during night time, builds it and runs GUI smoke tests. Coverage and error report are</p><p>　　mailed to developer. In DART all the process such as Analyzing the AUT’s GUI structure u

93、sing</p><p>　　GUI ripper, Test case generation, Test oracle generation, Test case executor, Examining the</p><p>　　reports and unsuccessful test cases, Submitting bug reports are automated. GUI

94、smoke test cases</p><p>　　and test oracles are generated. Fault seeding is used to evaluate fault detection techniques used.</p><p>　　An adequate number of faults of each fault type are seeded f

95、airly.</p><p>　　The disadvantages are Some part of code are missed by smoke tests, Some of the bugs reported</p><p>　　by DART are false positive, Overall effectiveness of DART depends on GUI rip

96、per capabilities,</p><p>　　Not available for industry based application testing, Faults that are not manifested on the GUI</p><p>　　will go undetected</p><p>　　5. INCORPORATING EVEN

97、T CONTEXT</p><p>　　Xun Yuan et al [1], developed a new criterion for GUI testing. They used a combinatorial</p><p>　　interaction testing technique. The main motivation of using combinatorial int

98、eraction is to</p><p>　　incorporate context and it also considers event combinations, sequence length and include all</p><p>　　possible event. Graph models are used and covering array is used to

99、 generate test cases which are</p><p>　　the basis for combinatorial interaction testing.</p><p>　　A tool called GUITAR (GUI Testing Framework) is used for testing and this provides</p>&l

100、t;p>　　functionalities like generate test cases, execute test cases, verify correctness and obtain coverage</p><p>　　reports. Initially using GUI ripper, a GUI application is converted into event graph and

101、 then the</p><p>　　events are grouped depending on functionality and constraints are identified. Covering array is</p><p>　　generated and test sequences are produced. Test cases are generated an

102、d executed. Finally</p><p>　　coverage is computed and a test adequacy criterion is analyzed.</p><p>　　The advantages are: contexts are incorporated, detects more faults when compared to the prev

103、ious</p><p>　　techniques used. The disadvantages are infeasible test cases make some test cases unexecutable,</p><p>　　grouping events and identifying constraints are not automated.</p>&

104、lt;p>　　Figure 5. Testing Process</p><p>　　6. CONCLUSIONS</p><p>　　In this paper, some of the various test case generation methods and various types of GUI testing</p><p>　　adapte

105、d for different GUI applications and techniques are studied. Different approaches are being</p><p>　　used under various testing environment. This study helps to choose the test case generation</p><

106、;p>　　technique based on the requirements of the testing and it also helps to choose the type of GUI test</p><p>　　to perform based on the application type such as open source software, industrial software