Test Case Generation, UML, and Eclipse

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.

[Click image to view at full size]

Figure 1: Activity diagram modeled with AGAPE.

[Click image to view at full size]

Figure 2: Form for data input activities.

<?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).

[Click image to view at full size]

Figure 3: Class diagram referred to the part of AGAPE in charge of modeling extended diagrams.

<?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>