Test Case Generation, UML, and Eclipse
Encouraging good practices to ensure software quality
Luis is an assistant professor of computer science at Universidad de Alcala. Pedro is director of the Computer Systems Department at the Universidad Europea de Madrid. They can be contacted at [email protected] and [email protected] , respectively.
Automatic test case generation has long been on developers' wishlists, and a promising approach to implementing it is the use of state diagrams to describe interactions. The idea is that diagrams can guide the generation of test cases based on the assumption that user activity with the program is modeled by the diagram.
The approach we propose in this article is to link requirements expressed in UML format with a test-generation method we call "AQUABUS" (esp.uem.es/aquabus/index.htm ). To do so, we use UML models stored in an Eclipse project to create a plug-in called "AGAPE" (also available at esp.uem.es/aquabus/index.htm ) that automatically generates test cases from software specifications based on use cases and activity diagrams.
Our approach with AQUABUS is to extend an activity diagram to include information about the use and severity of possible failures for each element as a starting point for the generation of test cases. AQUABUS creates a list of paths from the initial state to the ending one, then ranks them in order of priority using the information about probability of use and cost/severity of possible failures.
This approach is in sync with commonly used procedures for generating test cases based on the UI. However, this isn't practical if you can't support some type of tool or automated environment. So in this article, we present a solution that uses Eclipse to develop solutions that integrate UML modeling with test-generation aids.
AGAPE: A Test Case Generation Tool
AGAPE is a test generation plug-in for Eclipse. It is based on the EclipseUML (www.omondo.com ) UML modeling plug-in and the Eclipse Modeling Framework (www.eclipse.org/modeling/emf ) for diagramming. AGAPE uses the XMI definition of the activity diagrams associated with use cases as an input so you can complement the diagram with additional information about:
- Input data in specific states where users have to enter information in the system.
- Probability of "execution" for each transition (arrow) in the diagram.
- Severity (cost of experiencing an error) associated with the execution of an activity of the diagram.
AGAPE provides the following functions when using UML models to design tests:
- Modeling UML activity diagrams within the standard structure of an Eclipse project, allowing that analysts allocate probability and/or cost information to diagram elements to determine risk level associated to each path (scenario of the use case); that is, to each of the test cases that may be generated from the diagram using the AQUABUS algorithm.
- Graphical design and management of diagram elements, allowing the insertion of specific states (see Figure 1) like any other CASE tool. It lets you save diagrams in XMI format, as in Listing One.
- Management of data input activities both graphically (Figure 1) and via dialogs (Figure 2). The form is available for each specific activity related to data input to allow entering value ranges and equivalence classes both for valid and invalid data. Of course, there are also specific fields in the form for entering probability of use and cost of possible failures for each option.
- Test case generation—the essential objective of AGAPE. Once the activity diagram is specified and modeled, the tool generates paths from the beginning to the end of the use case. Each of these paths corresponds to a test case that can be stored as a text file (in XML format) and imported by existing automatic test execution tools. Listing Two shows the test cases generated from Figure 1 where there are only three paths because we have only established two data to be tested in the activity AD1. In general, data input activities should include several equivalent classes (valid and invalid values) that are represented as different paths in the diagram.
<?xml version='1.0' encoding='iso-8859-1'?>
<activityDiagram>
<start-point id="w11190188197910" itemName="start-point" x="387" y="14"/>
<activity id="w11190188197911" itemName="A1" x="361" y="50"/>
<decision id="w11190188197913" itemName="decision0" x="386" y="114"/>
<activityData id="w11190188197918" itemName="AD1" x="74" y="166" w="336" h="150">
<data id="w11190188197919" itemName="d1" x="0" y="0">
<value id="w111901881979110" itemName="d1@value0" x="123" y="258" value="0" type="Valid"/>
</data>
<data id="w111901881979114" itemName="d2" x="0" y="0">
<value id="w111901881979115" itemName="d2@value2" x="210" y="246" value="-1" type="Valid"/>
</data>
</activityData>
<activity id="w11190188197916" itemName="A2" x="528" y="208"/>
<end-point id="w111901881979121" itemName="end-point" x="384" y="375"/>
<connections>
<sourceConnection id="w11190188197914" source="w11190188197913" target="w11190188197916" p="0.5" c="3"/>
<sourceConnection id="w11190188197912" source="w11190188197911" target="w11190188197913" p="" c=""/>
<sourceConnection id="w111901881979119" source="w11190188197918" target="w111901881979121" p="" c=""/>
<sourceConnection id="w111901881979120" source="w11190188197918" target="w111901881979115" p="0.7" c="3"/>
<sourceConnection id="w111901881979117" source="w11190188197918" target="w111901881979110" p="0.5" c="4"/>
<sourceConnection id="w111901881979116" source="w111901881979115" target="w11190188197918" p="" c=""/>
<sourceConnection id="w11195300692600" source="w11190188197910" target="w11190188197911" p="" c=""/>
<sourceConnection id="w111901881979111" source="w111901881979110" target="w11190188197918" p="" c=""/>
<sourceConnection id="w11190188197917" source="w11190188197916" target="w111901881979121" p="" c=""/>
<sourceConnection id="w11190188197915" source="w11190188197913" target="w11190188197918" p="0.5" c="5"/>
</connections>
</activityDiagram>
Figure 3, an overview of the design, illustrates the classes that let AGAPE model the extended activity diagrams with the required characteristics to comply with the properties of the Eclipse Graphical Editing Framework (www.eclipse.org/gef ) GEF and Eclipse Modeling Framework. The basic element is ActivityDiagram broken down into elements Children that may be linked (Connections ) among them (each link with probability of use and severity of possible failures).
<?xml version='1.0' encoding='iso-8859-1'?>
<testCases>
<path id='0'>
<children itemName='start-point'/>
<children itemName='A1' p='' c=''/>
<children itemName='decision0' p='' c=''/>
<children itemName='A2' p='0.5' c='3'/>
<children itemName='end-point'/>
</path>
<path id='1'>
<children itemName='start-point'/>
<children itemName='A1' p='' c=''/>
<children itemName='decision0' p='' c=''/>
<children itemName='AD1' p='0.5' c='5'>
<value dataValue='d1=0' p='0.5' c='4'/>
</children>
<children itemName='end-point'/>
</path>
<path id='2'>
<children itemName='start-point'/>
<children itemName='A1' p='' c=''/>
<children itemName='decision0' p='' c=''/>
<children itemName='AD1' p='0.5' c='5'>
<value dataValue='d2=-1' p='0.3' c='3'/>
</children>
<children itemName='end-point'/>
</path>
</testCases>
Benefits
To determine the benefits of AQUABUS and AGAPE thanks to the support of two projects (TIN2007-67843-C06-01 and TIN2005-24792-E funded by the Spanish Ministry of Science), we collected performance data from more than 100 project leaders, analysts, programmers, testers, teachers, consultants, and the like, based on the following:
- We published on a web site a simple data management application for managing a DVD collection.
- Participants tested it, recording the test cases they did.
- Recorded test cases from the participants were compared with the set of test cases generated with AGAPE (AQUABUS).
- Participants had access to the results of their tests and the comparison with the AGAPE test cases. They were asked to give their opinion via a questionnaire designed to analyze their evaluation, both of the method and the plug-in. They were also asked to give a priority mark to each test case according to their idea of importance for the software application.
Given that the system recorded tests proposed and time devoted to the task (mean time of 21 minutes), poor-quality results (short time, few test cases) were discarded, leaving only 72 valid test sets. Although we collected lots of interesting information, for the purposes of this article we highlighted the following results:
- None of the participants included any test case or different scenario (path of activity diagram) that was not covered by the tests design generated by the algorithm.
- Only one participant reached more than 75 percent of the total existing paths; more than 50 percent did not reach the 50 percent of the paths/scenarios. Test cases designed by 50 (70 percent) of the participants hardly surpassed the threshold of 25 percent of total scenarios.
- Testers who used activity diagrams as reference designed 70 percent more test cases than those who did not.
- Among the 10 most tested paths by all participants, only one (in eighth place) appears in the 10 top priority paths for them. Within the list of the 10 least tested paths, three of the top priority paths are included. Even more, at least 50 percent of the testing effort was dedicated to test something previously tested.
- Regarding the usefulness of the method and plug-in, 77 percent of the testers said that AQUABUS would be really cost-effective for their organizations, although activity diagrams are needed as part of software specifications. Seventy percent of the participants believe the priority allocated to the different scenarios following the AQUABUS method would be cost-effective.
Conclusion
To encourage good practices for controlling software quality, developers clearly need integrated environments that take advantage of the cross relationships between analysis and modeling. Although existing tools support certain quality assurance activities, integration isn't always easy because of problems with communication between tools, or the lack of techniques to exploit models for quality control. However, standard notation like UML and open environments like Eclipse make possible useful tools that go one step further in making affordable and convincing implementations of software quality assurance techniques. The AGAPE plug-in lets you concentrate on requirements and models, and with a simple click lets you generate a whole set of test cases with a priority rank.
