Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Test Case Generation, UML, and Eclipse


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.

[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>
Listing One

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>
Listing Two


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.