An Automatic Test Suite Regeneration TechniqueEnsuring State Model Coverage Using UML

Diagrams and Source SyntaxAfrina Khatun∗ and Kazi Sakib†

Institute of Information Technology, University of Dhaka, Bangladesh∗bit0411@iit.du.ac.bd, †sakib@iit.du.ac.bd

Abstract—Automated test regeneration intends to ensure highcoverage of the system model from an existing test suite. Whileregenerating test suite, most of the existing techniques ignorecoverage achieved so far by existing test suite. An automatictest regeneration technique to achieve high coverage of statemodel is proposed in this paper which uses coverage result aswell as information from UML diagrams and source code. Thearchitecture of the technique is supported by three modules.The first module processes inputted UML diagrams, sourcecode and test suite as XML elements, source class and teststeps respectively. The second module measures model coverageresult achieved by existing test suite. The final module combinescoverage result, extracted UML and source syntax together toregenerate test cases. A case study has been conducted to assessthe technique effectiveness and has been successful to regenerateunit and integration test cases that achieve full coverage of thestate model.

Keywords—software testing, automatic test regeneration, modelcoverage analysis, unit and integration testing

I. INTRODUCTION

Test suite regeneration from existing test suite is done toensure high test coverage of a System Under Test (SUT). Testcoverage is a quality assurance metric which indicates howthoroughly a test suite exercises a given system [1]. A systemmodel describes the behavior and requirements of the system.If a test suite fails to achieve full coverage of the system model,it indicates the test cases have missed important requirementsof the SUT. In model based coverage analysis techniques,manual or auto generated test suite is executed against thesystem UML diagrams like - class, state, sequence diagramsand GUI screens. In this approach, coverage result is measuredby parsing the test cases and finding corresponding elementsin the UML diagrams. The coverage result is represented tothe tester in a graphical or documented form which can playa vital role in test suite regeneration.

Achieving full coverage of the model generally fails, astest automation tools lack predefined coverage checking whilegenerating test suites. Existing coverage analysis tools measurethe coverage of a model, based on some predefined coveragecriteria like - state coverage, transition coverage, all pathcoverage etc. These tools only identify the tested and untestedelements of the system model. Therefore, to ensure coverageeither existing test generation algorithms need to be changedor regeneration needs to be done. On the other hand, most ofthe automated model based test generation techniques generatetest cases from an abstract model of the SUT [2]. However,those fail to find out how much coverage is achieved throughthe generated test suites. As a result, many system require-ments may remain untested. Even if the number of uncovered

elements is small, this may lead to manual inspection of thewhole model again to find those elements.

A dependence graph-based test coverage analysis techniquefor object oriented programs has been proposed by Najumud-heen et al. [3]. In this paper source code was instrumentedand a call based system dependence graph was constructed byparsing source code to measure traditional coverage criterialike - statement, branch, method coverage etc. Therefore, theapproach does not generate test cases for the uncovered partof the system graph. A model based test coverage analysistechnique of UML state machines has been proposed byFerreira et al. [4]. The proposed tool received XML formattedstate model and auto generated test suite to identify coveredand uncovered elements by the test suite. Therefore, the testsuite still lacks test cases that are required to ensure the fullcoverage of the model. A technique to create test cases fromUML models is offered by Sarma et al. [5]. In this techniqueUML use case and sequence diagram have been considered forgenerating test sequences. A test case regeneration approachbased on sequential pattern mining has been proposed byWei He et al. in [6] to produce test cases from existing testrepositories. It uses a GA based approach to regenerate testcases from existing test repository. However, both of thesetechniques ignore coverage criteria of system model elements.

This paper incorporates coverage analysis result with testregeneration technique to produce unit and intra class integra-tion test cases which ensure high coverage of the system statediagram. The technique contains three modules to manage thewhole regeneration process. The Parser, Coverage Analysisand Test Regeneration - each module has some predefinedresponsibilities to support the technique implementation. TheParser is the input data provider of the proposed technique.It extracts test steps, source syntax and UML elements byparsing an existing test suite, source code and UML diagramsrespectively and processes these information in a structuredway to be used later. The Coverage Analysis module usesthe processed test suite, UML class and state elements toidentify the covered and uncovered elements of the statemodel by simulating the execution of test cases against themodel. The Test Regeneration first uses the coverage resultto generate all possible uncovered transition paths from thestate diagram of the system. It then regenerates unit andintra class integration test cases for the generated uncoveredtransition paths. While regenerating tests, event call signatureof transitions and method call syntax of source code are alsoconsidered to check consistency, that ensures regeneration ofexecutable test cases.

A case study on a sample java project illustrating an ATMsystem [7], has been conducted here for the initial assessment

978-1-5090-1269-5/16/$31.00 ©2016 IEEE

2016 5th International Conference on Informatics, Electronics and Vision (ICIEV) 88

of the proposed technique. The corresponding UMLs of thesample project were also built. Test suites of the sample projectwas generated using an existing automated test generationframework [8]. These source code, test suites and UMLswere extracted into source class, test steps and XML elementsrespectively by the Parser. The Coverage Analysis modulereceived the XML data and test cases and produced thecoverage result of the state model. These coverage result andsource classes were received by the Test Regeneration moduleand test scripts were produced which achieved full coverageof the model.

II. RELATED WORK

In the literature survey, several automated coverage analysisand test regeneration techniques have been proposed. Most ofthe techniques emphasize only one of the tasks of either testregeneration [6] or coverage measurement [4]. Some of thesignificant works related to this research topic are describedin the following part.

Najumudheen et al. proposed a dependence graph basedtest coverage analysis technique for object oriented projects[3]. In this approach the source program is converted intoa dependence graph based representation, named call basedobject oriented system dependence graph and instrumented atspecific points. During the test execution, a coverage analysis isdone based on some coverage criteria like - statement, branch,path, method coverage and the edges of the graph are markedas covered by a graph marker. However if test regenerationcould be done for the unmarked edges of the graph, highcoverage could have been achieved.

A state based coverage analysis and behavioral equivalencechecking for C++ programs has been proposed by Heckeleret al. [9]. The approach transforms the UML state model to atransition table to detect behavioral deviation from the C++ im-plementing finite state machine. After transformation, it linksthe source code with appropriate states and executes existingunit, system and integration tests to find out which states arecovered. However, the approach uses manual instrumentationand considers only state coverage. Considering transition se-quence coverage along with state coverage could ensure highintegration coverage of the integration tests. Again combiningtest regeneration technique with the coverage analysis processcould produce more accurate test suites.

Ferreira et al. has proposed a state model based testcoverage analysis tool [4]. The tool is developed as part ofa GUI testing environment. The tool receives a system modeland a test suite in XMI format as input. It then simulates theexecution of the test suite over the model to determine thecoverage achieved through the test suite. It represents the resultin a colored UML state machine model to the tester. Howeverthe tool ends its task by only concluding the incompletenessof the test suite. Regenerating test case for the uncoveredelements of the state model would make it more useful forthe tester.

An integration testing coverage tool for object orientedprogram has been proposed in [10]. The tool automaticallyinstruments the source code and collects coverage data whiletest execution. After execution, it identifies the uncoveredmethods from coverage result and creates a scenario graph

using sequence and use case diagrams. It then extracts interclass method call path from the scenario graph that containsthe uncovered method and generates test case for the path.However, the approach does not consider unit and intra classintegration tests and also generates inexecutable test cases.

Few test case regeneration techniques have been alsoproposed in the literature survey. A sequential pattern miningbased test regeneration technique for object oriented projectsis presented by Wei et al. [6]. The approach applies sequentialpattern mining strategy to obtain frequent subsequences ofmethod call from existing test suite. It uses a GA basedapproach to regenerate test cases by mining the frequentsubsequences but ignore coverage consideration. Alshahwanet al. proposed two test regeneration techniques for web appli-cations [11] using standard and value based Def-Use testingaccordingly. This approach combines HTTP requests from atest suite to form client side requests and combine fragmentof these requests to regenerate test cases to execute server siderequests. However, combining coverage criteria along with theregeneration process could produce more effective test cases.

Fraser et al. has proposed a tool called, EvoSuite forautomatic test generation of object oriented programs [12].However, it does not consider model requirements and cov-erage for test generation. An automatic test generation tech-nique to detect operational, use case dependency and scenariofaults has been proposed by Srama et al.[5]. The techniquegenerates test cases from use case and sequence diagrams.However, the test generation process totally ignores sourcesyntax information. Nahar et al. has proposed a framework forautomatic test generation using software semantics and sourcesyntax [8]. However it totally ignores coverage criteria whilegenerating test cases. Chen et al. has proposed a technique forautomatic test case generation for UML activity diagrams [13].This approach executes random generated test cases againstthe UML activity diagram and selects test cases that satisfypredefined coverage criteria. Instead of reducing the test suite,regenerating new test cases ensuring the predefined coveragecould make the test suite more accurate.

Most of the existing coverage analysis techniques in theliterature only focus in identifying tested and untested elementsand ignore test regeneration (e.g.[4]). Some test regenerationtechniques are also available in the literature (e.g. [6], [11]).However, they do not ensure full coverage of a system statemodel. So even if the number of untested elements is small,it leads to manual inspection of the whole model.

III. METHODOLOGY

In this section, a technique for automated test regenerationensuring state model coverage is proposed. As mentioned inthe previous section, the existing approaches either regeneratetest cases or measure coverage, but do not regenerate testcases from existing test suite, considering the state modelcoverage for intra class integration test. To meet up thelimitations of the above individual approaches, an automatedtest suite regeneration technique, considering the coverageanalysis result, and using UML diagrams and source syntaxis proposed. The overview and the internal architecture of theproposed technique are described in the following part.

89

A. Overview of the Proposed Test Regeneration Technique

The top level overview of the proposed technique artifactsis shown in Fig. 1. The artifacts perform core tasks for thefunctionality of the technique. The Source Code Parser, Test

Fig. 1: Top Level View of the Test Regeneration Technique

Suite Parser and UML Parser shown in Fig. 1 process theinputted data into a structured form. This modules extractinformation from the source code, test suite and UML class,state diagrams which are provided by the user. CoverageAnalyzer of Fig. 1 considers each test step (test statement) ofa test case which is a method call event along with parametervalues, and identifies the covered and uncovered elements ofthe state model by the existing test suite. Test Regeneratorillustrated in Fig. 1 performs the task of test regeneration. Ituses the coverage result, extracted UML elements and derivedmethod syntax by the Source Parser to regenerate unit andintegration test cases, for uncovered states, transitions and intraclass method call sequences that is transition sequences.

B. Internal Architecture of the Test Regeneration Technique

The internal architecture of test regeneration techniqueshown in Fig. 2 consists of several modules, as each moduleperforms different responsibilities. The architecture is dividedinto three major modules: (1) Parser Module, (2) CoverageAnalysis Module and (3) Test Regeneration Module. Eachmodule consists of several components which support itsfunctionality. The functionality of these modules is describedin the following part.

1) Parser Module: The Parser Module acts as input dataprovider for the proposed technique. It receives XML format-ted UML diagrams, source code and test suite files from a userdefined location. It contains three components as illustrated inFig. 2. The Source Syntax Identifier component extracts class,method syntax from the existing source code files, and passesthem to Test Regeneration module. On the other hand, TestSteps Identifier component shown in Fig. 2 extracts test stepsfrom the test cases of existing test suite files. It identifies eachtest step that is method call statement along with its parametervalues and passes those to the Coverage Analysis module.

UML Element Identifier receives XML formatted UMLdiagrams, and identifies class attributes, their initial values,methods, parameter list from class diagrams. As each statemachine is usually associated to a class, the class attributesrepresent state variables in the state machine, and the class

Fig. 2: Internal Modules of the Test Regeneration Technique

methods define the signature of call events in the state machine.The information of states, transitions, corresponding guardsand action events are also extracted from state diagrams. Thisinformation is used later by the Coverage Analysis and TestRegeneration module as showed in Fig. 2 to measure modelcoverage and regenerate unit and integration tests.

2) Coverage Analysis: Coverage Analysis module is re-sponsible for the computation of the coverage achieved byexisting test suite. Coverage criteria must be measurable and bean indicator of the test adequacy. One of the coverage criteriaapplicable to system state models is transition based coverage.All states and transitions coverage represent the full coverageof all available methods of the class that is unit test and allsimple path coverage represents the full coverage of intra classmethod call sequence as well as integration test. Therefore, theproposed technique supports state, transition and all possiblesimple path coverage criteria. A state is considered coveredif all possible outgoing transitions from the state is traversedat least once. A partially covered state represents a subsetof all possible transitions out of the state is exercised. Anuncovered state is a state which is never reached through thetest suite. This coverage criteria is used by Coverage Analyzercomponent later to identify covered and uncovered elements.

The Coverage Analyzer component of this module receivesstructured UML class, state diagram elements and test suitesfrom Parser module as shown in Fig. 2. It then executes the testsuite against the state models based on the algorithm shown inAlgorithm 1. The algorithm receives existing test suite of theproject as input. The test suite contains a number of test scripts.It is assumed that each test script is associated with a class.For each test script, the algorithm identifies the corresponding

90

Algorithm 1 Coverage Analysis Algorithm

Input: Existing TestSuiteOutput: Marked state diagram based on coverage

1: Begin2: for each TestScript ∈ TestSuite do3: get state diagram of TestScript corresponding

class4: for each TestCase ∈ TestScript do5: initialize an empty list V to store state variables

,class attributes and insert all variables into V6: currentState← GETSTATE(TestStep[0])7: for each TestStep ∈ TestCase do8: Initialize an empty list T of possible transitions9: Initialize boolean variables S,G

10: Transitions←GETOUTGOINGTRANSITIONS(currentState)

11: for each t ∈ Transitions do12: S ← MATCHSIGNATURE(t.event, TestStep)13: G← EXECUTEEXPRESSION(t.guard, V )14: if S AND G then15: insert t into T16: end if17: end for18: if T = 1 then19: EXECUTEEXPRESSION(t.action, V )

and mark currentState and t as covered20: currentState← t.destinationState21: else if T >1 then22: Continue with next test case23: end if24: end for25: end for26: end for27: End

state diagram as shown in line 3 of Algorithm 1. In thisstep, the algorithm gets the extracted UML class and stateelements from the Parser module. The extracted class diagraminformation of UML contains class name, attribute types,initial value, method name, method parameter name, type andreturn type. The extracted state diagram elements contains statename, transition, guard condition of each transition (if any)and corresponding action of each transition (if any). The guardcondition of a transition is a mathematical boolean expressionwhich decides whether a transition will be taken or not. Theaction of a transition is also a mathematical operation whichoccurs after a transition is taken. It is generally used to updatevalue of state variables of the state diagram. A state variableis one of the set of variables that are used to describe thestatus of the states and changes with the flow of transition.Foreach test case in the test suite, the state variables and theircorresponding initial values are also loaded by the programas in line 5. Once all state variables are loaded, the algorithmthen executes the test cases of the test suite.

A test step a is method call statement in the test cases.For the first test step of each test case the correspondingcurrent state is identified in line 6. Then the outgoing transitionfrom the current state is selected as shown in line 10 ofAlgorithm 1. For each outgoing transition t in list Transi-tions, function MatchSignature checks whether the test step

method call signature matches with the event call signatureof transition t and ExecuteExpression evaluates the booleanguard expression of tansition t based on variable list V asillustrated in line 12 and 13 respectively. A possible transitiont from the current state is selected and inserted into list T,if its event call signature matches with the test step and itscorresponding guard condition evaluates to be true as shownin line 14 of Algorithm 1. If a possible transition is found,the corresponding action of the transition is also executed bythe ExecuteExpression function as illustrated in line 19 andthe current state and transition are marked as covered. Boththe guard condition and the action expression are performedby the Expression Evaluator component of Figure 2. Line20 of the algorithm then updates the currentState with thecorresponding transition destination state for the next iteration.If more than one transition is found, it is discarded and theprocess continues with the next test case as shown in line 22.

3) Test Regeneration: Test Regeneration module performsthe major responsibility of regenerating test cases for theuncovered paths and transitions. There are three componentsthat support the whole test regeneration procedure illustratedin Fig. 2. As mentioned above transitions represent availablemethods of a class. Therefore, full state and transition coverageensure high coverage of integration and unit test cases.The Unit Test Regenerator component receives uncoveredtransitions as input from Coverage Analysis component asshown in Fig. 2. If the event call signature of uncoveredtransitions derived from state diagram, do not match withthe actual method syntax of source code, inconsistent andinexecutable test cases may be generated. Therefore, thiscomponent also receives the extracted method syntax fromSource Syntax Parser to ensure consistency. Combining theseinformation it regenerates unit test cases.The Integration Test Regenerator component regenerates inte-gration test cases similar to Unit Test Regenerator, it addition-ally requires the uncovered intra class method call sequences.The Sequence Identifier componet supports the IntegrationTest Regenerator by providing the uncovered method callsequences. The Sequence Identifier receives the coverage resultproduced by Coverage Analyzer as input. To generate integra-tion tests the uncovered path of the state diagram needs tobe extracted. Therefore, this component applies Depth FirstSearch algorithm on the state model to extract possible simplepaths. The Integration Test Regenerator then regenerates testcases for the extracted paths and these regenerated tests arestored in test scripts to run later.The Manual Assert Statement Insertion component requireshuman interaction to manually set the assert statements in thetest scripts. The Test Compiler and Test Runner of Fig. 2 isresponsible for setting up required libraries like JUnit for Javaprograms to run the test scripts. The regenerated test casescan be executed against the state model in the similar way tocheck the increased coverage. To find out the effectiveness ofthe proposed technique, an application of its methodology ona sample project is required.

IV. CASE STUDY

The proposed technique is applied on a sample project,named ATM System [7]. The ATM system has some useraccounts where the accounts are protected through accountnumber and pin number. If a user enters the right pin number,

91

the user is allowed to perform some transactions like checkingbalance, withdrawing and depositing money. A user is allowedto withdraw money if enough money is available in thecorresponding user account and in the system cash dispenser.After two failed attempts to insert a pin, the account is locked.

Fig. 3: Class Diagram of Sample Project

The example system contains four classes as shown in Fig.3, ATM which is responsible for running ATM and handlinguser interaction, Account class manages user transactions,CashDispenser class updates dispensers available cash andATMSystemMain runs the system. As stated before, eachstate diagram is associated with a class of the project. Theapplication of the proposed technique on Account class isdescribed below.

Fig. 4: UML State Diagam (Class: Account)

The state diagram of Account class is shown in Fig. 4.The transitions among the states represent the event call inthe class which are illustrated in Table I. The class andstate diagrams are then converted to XML using EnterpriseArchitect [14]. The UML Elements Identifier extracts classattributes and methods by analyzing <owedAttribute> and<owedOperation> tags of the converted class diagram XML.On the other hand, information of transitions, guards, actionsare also extracted from <transition>, <guard>, <effect> tagsof state XMLs respectively.

A snapshot of generated integration test suite of Accountclass by an existing automated test generation frameworknamed SSTF [8] is illustrated in Fig. 5. The test steps of this

Fig. 5: Existing Auto Generated Integration Test SuiteExample (Class: Account)

TABLE I: Transition Coverage Achieved Through Existingand Regenerated Test Suite ( Class: Account )

Transition Id : TransitionEvent [Guard]/Action

ExistingTest Suite[8]

Regener-ated TestSuite

t0 : setToIdleState Covered Coveredt1 : validatePin(pin) [pin==expectedPin] Covered Coveredt2 : validatePin(pin) [pin!=expectedPin ANDattemptCount+1>=maxAttempt] Uncovered Covered

t3 : withdraw(amount)[amount<presentBalance ANDpresentBalance-amount>=100 ANDavailableCash-amount>=100]/presentBalance=presentBalance-amount

Covered Covered

t4 : updateCashDispenser(amount) /availableCash=availableCash-amount Covered Covered

t5 : deposit(amount) /presentBalance=presentBalance+amount Uncovered Covered

t6 : checkBalance() Covered Coveredt7 : validatePin(pin) [pin!=expectedPin ANDattemptCount+1<maxAttempt]/attemptCount=attemptCount+1

Uncovered Covered

t8 : backToIdleStateAfterWithdraw Covered Coveredt9 : backToIdleStateAfterDeposit Uncovered Coveredt10 : backToIdleStateAfterCheckBalance Covered Covered

generated test suites are then processed by the Test Step Identi-fier component of the Parser module described in sub sectionIII-B. For example, Algorithm 1 identifies three test stepsvalidatePin(5), withdraw(200) and updateCashDispenser(200)from the first test case of Fig. 5. The algorithm executes thesetest steps against the state model of Fig. 4 and evaluates theguard and action conditions based on the method parameters.As a result, Algorithm 1 marks the transition sequence t0 –>t1–>t3 –>t4 –>t8 as covered. The same process continues forall the test cases and the coverage result is passed to TestRegeneration Module for further processing. The class andmethod syntax of corresponding source files are derived bythe Source Syntax Identifier of Fig. 2 and also sent to TestRegeneration module for consistency checking.

The transition and state coverage achieved from existingtest suite of Fig. 5, is represented in Table I and II accordingly.As all the transitions are not covered, therefore, the Accountclass contains untested methods and intra class method callsequences. These tables clearly show that the test suite failedto cover all the elements of the state model of Fig. 4.

92

The Sequence Identifier component then generates uncov-ered transition paths based on the coverage result. Thesegenerated paths, extracted transition signature and sourcemethod syntax are combined, to regenerate executable unit andintegration test cases by the Unit and Integration Test Regener-ator accordingly. The generated unit and integration test casesample snapshots are shown in Fig. 6 and 7 respectively. Theseregenerated test cases are then added to the correspondingexisting test suite files. To measure the increased coverage bythe regenerated test cases, the Coverage Analyzer module againexecutes the test suites against the state models and computesthe coverage result. Table I indicates that 40% transitions areuncovered by the existing test suite generator [8]. Table I andII show that the regenerated unit and integration test suite hassuccessfully covered all the elements of Fig 4.

TABLE II: State Coverage Achieved Through Existing andRegenerated Test Suite ( Class: Account )

State Name Existing Test Suite[8]

Regenerated TestSuite

Idle Partially Covered Fully CoveredPin Validated Partially Covered Fully CoveredWithdrawed Fully Covered Fully CoveredDispenser Updated Fully Covered Fully CoveredDeposited Uncovered Fully CoveredBalance Checked Fully Covered Fully CoveredLocked Uncovered Fully Covered

Fig. 6: Unit Test Example

Fig. 7: Integration Test Example

V. CONCLUSIONThis paper introduces a test suite regeneration technique

to ensure state model coverage, that analyzes the coverageachieved so far, and uses both the UML elements and sourcesyntax for the regeneration. The consideration of coverage

analysis result, UML elements and source syntax, while re-generating process achieve high coverage of the state modelas well as generate executable unit and integration test cases.

The Parser, Coverage Analysis and Test Regenerationmodule operate together to regenerate unit and integrationtest cases. While Parser module processes UML, source andtest suite information provided by the user, Coverage Analysismodule identifies the covered and uncovered elements of thestate model. Test Regeneration module considers the coverageresult and extracted information by the Parser and regeneratesunit and intra class integration test cases.

A case study on a sample project is shown to analyze theeffectiveness of the technique. The case study result shows thatthe existing test suites do not cover all the elements of the statemodel and full coverage is achieved through the regeneratedtest cases. The future scope lies in incorporating more coveragecriteria with the regeneration process.

REFERENCES

[1] M. Shahid and S. Ibrahim, “An evaluation of test coverage tools insoftware testing,” in Proc. of Computer Science and Information Tech-nology and International Conference on Telecommunication Technologyand Applications, vol. 5. IACSIT Press, 2011.

[2] M. Utting and B. Legeard, Practical Model-Based Testing: A ToolsApproach. Elsevier Inc., 2007.

[3] E. Najumudheen, R. Mall, and D. Samanta, “A dependence graph-basedtest coverage analysis technique for object-oriented programs,” in Proc.of the 6th International Conference on Information Technology. IEEE,Apr 2009, pp. 763–768.

[4] R. Ferreira, J. Faria, and A. Paiva, “Test coverage analysis of uml statemachines,” in Proc. of the 3rd International Conference on SoftwareTesting, Verification, and Validation Workshops. IEEE, Apr. 2010, pp.284–289.

[5] M. Sarma and R. Mall, “Automatic test case generation from umlmodels,” in Proc. of 10th International Conference on InformationTechnology. IEEE, Dec. 2007, pp. 196 – 201.

[6] W. He and R. Zhao, “Sequential pattern mining based test caseregeneration,” Journal of Software, vol. 8, no. 12, pp. 3105–3113, Dec2013.

[7] (2015, Aug.) Sample atmsystem project. [Online]. Available:https://github.com/Afrina/ATMSystem

[8] N. Nahar and K. Sakib, “Sstf: A novel automated test generationframework using software semantics and syntax,” in Proc. of 17thInternational Conference on Computer and Information Technology.IEEE, Dec. 2014, pp. 69–74.

[9] P. Heckeler, J. Behrend, T. Kropf, J. Ruf, and W. Rosenstiel, “State-based coverage analysis and uml-driven equivalence checking for c++state machines,” in Proc. of the 2nd International Workshop on FormalMethods and Agile Methods, Sep. 2010, pp. 49–62.

[10] P. Augsornsri and T. Suwannasart, “An integration testing coverage toolfor object-oriented software,” in Proc. of the International Conferenceon Information Science and Applications. IEEE, May 2014, pp. 1–5.

[11] N. Alshahwan and M. Harman, “State aware test case regeneration forimproving web application test suite coverage and fault detection,” inProc. of the International Symposium on Software Testing and Analysis.ACM, Jul 2012, pp. 45–55.

[12] G. Fraser and A. Arcuri, “Evosuite: automatic test suite generationfor object-oriented software,” in Proc. of 13th European conferenceon Foundations of software engineering. ACM SIGSOFT, 2011, pp.416–419.

[13] M. Chen, X. Qiu, and X. Li, “Automatic test case generation foruml activity diagrams,” in Proc. of the International Workshop onAutomation of Software Test. China: ACM, May 2006, pp. 2–8.

[14] (2015, Aug.) Enterprise architect - uml design tools anduml case tools for software development. [Online]. Available:http://www.sparxsystems.com/products/ea/

93