UML Testing Framework

Keywords: UML Testing Framework, Testing UML Diagrams


Introduction

Since the evolution of Computers, there have been many approaches, standards and strategies for designing and developing software applications. The last two decades has witnessed a major revolution in software. There was something missing which is being unnoticed.

Since then researchers have been researching in developing a model which can handle the complete System Development Life Cycle (SDLC). Finally we could see the fruits of success, The Unified Modeling Language, in short The UML. The industry thanked the eminent scientists who made this possible – Grady Booch, James Rambaugh and Ivar Jacobson.

Building software is not a simple task. We need to admit that software’s become outdated in no time, but while building software we need to understand and be clear that it has to live a lifetime. These days, building secure web application, financial transaction systems, and mission critical systems is not a simple task. How much ever secure and stable is the application hackers find a way in. If we can take measures towards the beginning of building software, we can definitely get the results in the long run.

Target Audience
The objective of this paper is to have an overview of UML and design a framework for testing projects/applications following this standard. This paper is aimed for Testing Professionals who want to learn about UML and also White Box testing to a certain extent. I am currently working more in the area of Object Oriented Testing and want to bring out effective and efficient methods for testing Object Oriented Systems.

Testing UML Projects demands understanding of Object Oriented Systems. For those of you who are interested in learning more, I would sincerely suggest you to read Testing Object Oriented Systems: Models, Patterns and Tools by Robert V Binder. It’s indispensable.

A Note to the Reader
All the definitions and explanations pertaining to the technicalities of UML are addressed as per definitions. The framework is only my idea and it might look immature for testers who are working with Object Oriented Testing. As I am continuously working on the same, I would be updating the document whenever I get to solve new problems with respect to testing UML Diagrams. If you have any comments or suggestions, please don’t hesitate to write back to me at hari.nath@sqae.com. Alternatively you can visit http://www.sqae.com for updates on my works.



The Unified Modeling Language Testing Framework


Diagrams in UML

A Diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships).
There are nine diagrams included in UML:

Class Diagram
Object Diagram
Use Case Diagram
Sequence Diagram
Collaboration Diagram
Statechart Diagram
Activity Diagram
Component Diagram
Deployment Diagram



Model View of UML












Use Case Diagrams
Implementation View
Component Diagrams
Environmental View
Deployment Diagrams
Sequence / Collaboration / Statechart / Activity Diagrams
Structural View
Class / Object Diagrams
Behavioral View












How this framework is structured?
This framework will address testing of the Views. The above diagram depicts the Model View of UML. As you go along the framework you would see that we will be testing the five views individually and finally we shall integrate all of them.

The five Views are:
1. Use Case View.
2. Structural View.
3. Behavioral View.
4. Implementation View.
5. Environmental View.

The Use Case View of a system encompasses the use cases that describe the behavior of the system as seen by its end users, analysts and testers. With the UML, the static aspects of this view are captured in use case diagrams.

The Structural View of the system encompasses Class and Object Diagrams. These diagrams depict all the classes and objects that will be used in the development of the application.

The Behavioral View of the system encompasses the dynamism of the Classes and Objects. The dynamism of classes and objects are captured in Sequence, Collaboration, Statechart and Activity Diagrams.

The Implementation View of a system encompasses the components and files that are used to assemble and release the physical system. This view primarily addresses the configuration management of the system’s releases, made up of somewhat independent components and files that can be assembled in various ways to produce a running system.

The Environmental View of a system encompasses the nodes that form the system’s hardware topology on which the system executes. This view primarily addresses the distribution, delivery and installation of the parts that make up the physical system.


Statechart Diagrams
Collaborative Diagrams
Object Diagrams
Use Case DiagramsTester’s View of UML



The Use Case Diagrams are derived on the basis of Requirement Specification. These Diagrams can be used for Functionality Testing.
Class Diagrams
The Class, Object, Sequence, Collaborative, Statechart and the Activity Diagrams are used by the designers, developers and white box testers. These diagrams depict various states of Classes are used for Coding purpose, which can be utilized during reviews and White Box Testing.
Sequence Diagrams
Activity Diagrams























The Component Diagrams are used for identifying the individual components of the system and can be used for System Integration. The Deployment Diagrams are used as the basis for the Deployment of the software.
Component Diagrams
Deployment Diagrams









The above diagram illustrates the role of the UML Diagrams from a Tester’s perspective.



Testing Object Oriented Software – A brief Overview

We need to understand testing Object Oriented Software at this point, as the concept of UML is completely based on Object Oriented Methodology.
The strategies and techniques for testing Object Oriented software’s differ from the traditional function-based testing. The Object Oriented software testing follows a specific pattern as the software is structured.
We should be covering the following four types of testing while testing object oriented software:

1. Method Testing.
2. Class Testing.
3. Subsystem Testing and
4. System Testing.

Method Testing

· A method in a class should be tested using a black-box approach.
· The testing should begin from the Specification.
· Consider each parameter in the methods and identify its equivalence class.
· Build a test case specification for each interesting combination of equivalence class.

Class Testing

· A class contains a set of methods.
· Identify all the classes, which has interaction with the class you are testing.
· Identify the other classes for which you need the instances for testing a class.


Subsystem Testing

· Choose a set of Use Cases relevant to the subsystem.
· Identify the classes used in the Use Case.
· Derive the flow of communication and design the Test Case.

System Testing

· Start with the lowest level Use Case.
· Test each system increment by testing the new Use Cases produced in that increment.
· Keep re-testing the use cases which are at the low level periodically, especially when there is a change in the functionality.
· Writing detailed Test Plan for each Use Case helps find errors in the analysis model.
· Change in the requirements can be matched by changes to Use Case Test Plans.

Testing Use Case View

Use Case diagrams describe the functionality of the system.

A Use Case is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor. A use case is used to structure the behavioral things in a model.

Use Case Diagrams
Use Case Diagrams describe the functionality of a system and users of the system. These diagrams contain the following elements:

· Actors, which represent users of a system, including human users and other systems.
· Use Cases, which represent functionality or services provided by a system to users.

A typical use case contains the following information:

Use Case Section
Description
Name
An appropriate name for the Use Case.
Brief Description
A brief description of the use case’s role and purpose.
Flow of Events
A textual representation of what the system does with regard to the use case. Usual notation for the flow of events are:
Main Flow
Alternative Flow
Exceptional Flow
Special Requirements
A textual description that collects all requirements, such as non-functional requirements, on the use case, that are not considered in the use-case model, but that need to be taken care of during design or implementation.
Pre-Conditions
A textual description that defines any constraints on the system at the time the use case may start.
Post-Conditions
A textual description that defines any constraints on the system at the time the use case will terminate.


“Uses” Relationship

The “Uses” Relationship defines the relation between Use Cases. If the use case is related to or using the functionality of another use case, it is mentioned here.

“Extends” Relationship

The “Extends” Relationship defines the relation between Use Cases. If the one use case functionality is being extended to another, that functionality is mentioned here.

TestMap

A TestMap is a collection of Test Cases related by most common test target, shared test steps and the sequence of execution and also a TestMap is a program that defines multiple test cases by its execution paths.

Implementing Use Cases

For implementing the Use Cases the following makes a checklist.

1. Form function name from Use Case Name.
2. Identify actors.
3. Check pre-conditions.
4. Invoke “actor action” functions.
5. Verify meaningful results.
6. Very post-conditions.

Implementing Actor Actions

For implementing Actor Actions the following makes a checklist.

1. From function name from action description.
2. Define parameters.
- Object class record types.
- Optional override for actor action mode.
3. As interface definition evolves,
- Add window declaration include files.
- Add window method calls to the function to perform input, verify output, collect response time.

Testing the Use Case View

· For each actor involved in the use case, identify the possible sequence of interactions between the system and the actor, and select those that are likely to produce different system behaviors.
· For each input data coming from an actor to the use case, or output generated from the use case to an actor, identify the equivalence classes – sets of values which are likely to produce equivalent behavior.
· Identify Test Cases based on Range Value Analysis and Error Guessing.
· Each test case represents one combination of values from each of the below: objects, actor interactions, input / output data.
· Based on the above analysis, produce a use case test table (scenario) for each use case.
· Select suitable combinations of the table entries to generate test case specifications.
· For each test table, identify the test cases (success or extension) tested.
· Ensure all extensions are tested at least once.
· Maintain a Use Case Prioritization Table for the use cases for better coverage as follows:


Use Case No
Use Case
Risk
Frequency
Criticality
Priority







The Risk column in the table describes the risk involved in the Use Case.
The Frequency column in the table describes how frequently the Use Case occurs in the system.
The Criticality column in the table describes the importance of the Use Case in the system.
The Priority column in the table describes the priority for testing by taking the priority of the use case from the developer.

· Some use cases might have to be tested more thoroughly based on the frequency of use, criticality and the risk factors.
· Test the most used parts of the program over a wider range of inputs than lesser user portions to ensure better coverage.
· Test more heavily those parts of the system that pose the highest risk to the project to ensure that the most harmful faults are identified as soon as possible.
· The most risk factors such as change in functionality, performance shortfall or change in technology should be bared in mind.
· Test the use cases more thoroughly, which have impact on the operation of the system.
· The pre-conditions have to be taken into consideration before assuming the testing of the use case. Make test cases for the failure of the pre-conditions and test for the functionality of the use case.
· The post-conditions speak about the reference to other use cases from the use case you are testing. Make test cases for checking if the functionality from the current use case to the use case to which the functionality should be flowing is working properly.
· The business rules should incorporated and tested at the place where appropriately where they would be acting in the use case.
· Maintain a Test Coverage Matrix for each use case. The following format can be used:

UC No.
UC Name
Flow
TC No’s
No. of TC’s
Tested
Status























In the above table:

· The UC No. column describes the Use Case Number.
· The UC Name column describes the Use Case Name.
· The Flow column describes the flow applicable: Typical Flow, Alternate Flow 1, Alternate Flow 2, etc.
· The TC No’s column describes the start and end test case numbers for the flow.
· The No. of TC’s column describes the total number of test cases written.
· The Tested column describes if the flow is tested or not.
· The Status column describes the status of the set of test cases, if they have passed or failed.

Strategy for designing the Test Case’s and Test Scenario’s

The following steps typically speak of a strategy for designing the Test Case(s) and Test Scenario(s) from the Use Case document.

Step 1: Identify the module / class / function for which the Use Case belongs.

Step 2: Identify the functionality of the Use Case with respect to the overall functionality of the system.

Step 4: Identify the Functional Points in the Use Case and make a Functional Point Document.

Step 3: Identify the Actors involved in the Use Case.

Step 4: Identify if the Use Case “Extends” or “Uses” any other Use Case.

Step 5: Identify the pre-conditions.

Step 6: Understand the Typical Flow of the Use Case.

Step 7: Understand the Alternate Flow of the Use Case.

Step 8: Identify the Business Rule’s.

Step 9: Check for any post-conditions and special requirements.

Step 10: Document Test Cases for the Typical Flow (include any actions made in the alternate flow if applicable).

Step 11: Document the Test Cases for Business Rules.

Step 12: Document Test Cases for Alternate Flow.

Step 13: Finally, identify the main functionality of the Use Case and document a complete positive end-to-end scenario.

Make a Cross Reference Matrix with respect to each:
1. Use Case Document and Functional Point Document.
2. Functional Point Document and Test Case Document.
3. Test Case Document and Defect Report.

These Cross-Reference Matrix Documents would be helpful for easily identifying and tracking out the defects and the functionality.

Version Control
For every Test Case Document maintain Version Control Document for tracking out the changes in the Test Case Document. The template can be made in the following way:
Version Number
Date
Comments




Testing the Structural View

The Structural View depicts Class and Object diagrams.

A Class is a description of a set of objects that share the same attributes, operations, relationships and semantics.

Class Diagrams
Class Diagrams describe the static structure of a system, or how it is structured rather than how it behaves. These diagrams contain the following elements.

· Classes, which represent entities with common characteristics or features. These features include attributes, operations and associations.
· Associations, which represent relationships which relate two or more other classes where the relationships have common characteristics or features. These attributes and operations.

Writing Healthy Classes
Here is a sample checklist, which I made for checking the health of a class:
1. Does the class have an appropriate class name?
2. When defining member functions outside the class, is the scope of the function restricted to the class name specified?
3. Can your member function defined outside the class, access all the private data of the class to which it belongs?
4. Is the constructor for the class in the public section?

Object Diagrams
Object Diagrams describe the static structure of a system at a particular time. Whereas a class model describes all possible situations, an object model describes a particular situation. Object diagrams contain the following elements:

· Objects, which represent particular entities. These are instances of classes.
· Links, which represent particular relationships between objects. These are instances of associations.

Testing the Structural View
Testing Classes
A ‘Class’ basically is a collection of methods. The following can help gather the required information for testing class.
1. Identify all the classes.
2. Identify the communication between each class.
3. Identify the dependency of various classes.
4. Identify Associations. This helps in grouping of classes, which have common characteristics.
5. Make a list of all classes along with what the class is intended to do and with which other classes it communicates. This helps in easier investigation when a particular functionality fails.
The template for the above mentioned recordings can be as follows:

Class Name
Associated Class Name
Description





Testing Objects
When testing OO Systems, you can combine the testing of Classes and Objects. Objects are instances of Classes and hence you can reuse the test cases used for testing classes for testing objects of the same class.


Testing the Behavioral View

The Behavioral View comprises of the following:
1. Sequence Diagrams.
2. Collaboration Diagrams.
3. Statechart Diagrams.
4. Activity Diagrams.

Sequence Diagrams
Sequence Diagrams describe interactions among classes. These interactions are modeled as exchange of messages. These diagrams focus on classes and the messages they exchange to accomplish some desired behavior. Sequence diagrams are a type of interaction diagrams. Sequence diagrams contain the following elements:

· Class roles, which represent roles that objects may play within the interaction.
· Lifelines, which represent the existence of an object over a period of time.
· Activations, which represent the time during which an object is performing an operation.
· Messages, which represent communication between objects.

Collaboration Diagrams
Collaboration Diagrams describe interactions among classes and associations. These interactions are modeled as exchanges of messages between classes through their associations. Collaboration diagrams are a type of interaction diagram. Collaboration diagrams contain the following elements.
· Class roles, which represent roles that objects may play within the interaction.
· Association roles, which represent roles that links may play within the interaction.
· Message flows, which represent messages sent between objects via links. Links transport or implement the delivery of the message.

Statechart Diagrams
Statechart (or state) diagrams describe the states and responses of a class. Statechart diagrams describe the behavior of a class in response to external stimuli. These diagrams contain the following elements:

· States, which represent the situations during the life of an object in which it satisfies some condition, performs some activity, or waits for some occurrence.
· Transitions, which represent relationships between the different states of an object.

Activity Diagrams
Activity diagrams describe the activities of a class. These diagrams are similar to Statechart diagrams and use similar conventions, but activity diagrams describe the behavior of a class in response to internal processing rather than external events as in Statechart diagram.

· Swimlanes, which represent responsibilities of one or more objects for actions within an overall activity; that is, they divide the activity states into groups and assign these groups to objects that must perform the activities.
· Action States, which represent atomic, or non-interruptible, actions of entities or steps in the execution of an algorithm.
· Action flows, which represent relationships between the different action states of an entity.
· Object flows, which represent the utilization of objects by action states and the influence of action states on objects.

Testing the Behavioral View
In the Structural View of the UML, we have looked at Class and Object Diagrams and how do we test. In the Behavioral View, we will look more deep into the technicalities of the classes and objects. The Behavioral View completely concentrates on the following aspects of classes and objects:
· Interactions among classes.
· Various states and responses of a Class.
· Activities of a Class.

One Test Suit can be developed for testing Behavioral view. This view basically encompasses the behavior of the classes and objects.

Testing Frame work
1. Identify the set of message exchange sequences among a set of classes (interactions among class roles).
2. Identify the types of interaction diagrams that focus on one message exchange sequence or a set of such sequences involved in specifying the behavior.
3. Identify the sequence of messages exchanged by class roles within a time sequence.
4. Identify the dimension representing the time over which an interaction occurs.
5. Identify the dimension specifying the different class roles participating in an interaction.
6. Identify expressions (Activation’s, messages, guard conditions, iterations, and message signatures), that may be used for expressing using pseudo-code or another language.
7. Identify the lifelines, which represent the life of the object.
8. Identify the functions, which are denoted in Activation’s for the job the object is performing during its operation.
9. Identify the communication of the objects through messages.

In the Class Roles,
1. Identify the types of objects that may participate within interactions and collaborations.
2. Identify what is required of a class for its participation in the interaction or collaboration.
3. Identify the roles that bind to actual objects when interactions or collaborations are used.
Identify the other properties (business rules, responsibilities, variations, events, exceptions etc).

Testing the Implementation View

Component Diagrams
Component diagrams describe the organization of and dependencies among software implementation components. These diagrams contain components, which represent distributable physical units; including source code, object code, and executable code.

The Component diagrams lie within the Implementation View of a system and render the specification of behavior. Component diagrams describe the organization of and dependencies among software implementation components. These diagrams contain components, which represent distributable physical units, including source code, object code, and executable code. The Component Diagrams can be mainly used while doing the Integration Testing.
Testing Framework
Component diagrams depict the physical view of the code. The most aggressive testing of code will be performed while testing the Structural and Behavioral views. Component diagrams are useful for understanding how the software is built.

I suggest you to do the following with Component Diagrams:

1. Identify the components of the system.
2. Make a Cross Reference Matrix for the components and the class / object in which it is present. This helps in tracing back to the buggy components faster and also understand the structure of the software.


Component
Class Name
Functionality





Testing the Environmental View

Deployment Diagrams
Deployment diagrams describe the configuration of processing resource elements and the mapping of software implementation components onto them. These diagrams contain components and nodes, which represent processing or computational resources, including computers, printers, etc.

The Deployment diagrams lie within the Environmental View of a system and render the specification of behavior. Deployment diagrams describe the configuration of processing resource elements and the mapping of software implementation components onto them. These diagrams contain components and nodes, which represent processing or computational resources, including computers, printers, etc. The Deployment Diagrams can be mainly used while going about the Installation Testing

Testing Framework
Testing the Deployment diagram is to do an installation testing. The following list of activities will help build up the system while testing (Integrating various components of the software).

1. Identify all the components of the System.
2. Make a Reference Matrix for the Components of the system.
3. Identify the relationship existing between the components.

Class Name
Component
Relation to other Components





A Complete Framework for Testing UML Based Applications

UML, The Unified Modeling Language designed and developed by the Object Management Group (OMG) is based on the Object Orient Software Development Methodology. But considering the importance of UML, the standards have been followed in all the software development life cycles.
During the above discussion we have looked into the UML in overall and the stages of software development lifecycle where we use different diagrams and components of UML, and also a simple testing framework for each diagram in brief. Now lets us take an overall picture of the Testing activities to be performed while testing the application being developed using the UML standard.
Refer the Role of UML and Behavioral View charts.

Step 1: Study the System Requirement Document to understand the functionality of the system.

Step 2: Study the Use Case Documents, which have been derived from the SRS.

Step 3: Execute Framework for Testing Use Case’s.

Step 4: Make a Cross Reference Matrix for the System Requirement Document and the Use Case Document’s.

Step 5: Study the Sequence Diagram’s for understanding the sequence of information flow and the structure of Classes.

Step 6: Make a document between the Use Cases and the different classes in each Use Case to test if all the classes mentioned in the Sequence diagram are present in the respective module / Use Case.

Use Case Name
Classes / Objects Present




Step 7: Execute Framework for Testing Component Diagrams.

Step 8: Execute Framework for Testing Deployment Diagrams.


Bibliography

Object Oriented Software Engineering – Stephen R. Schach
UML Distilled – Martin Fowler.
UML Reference Manual – Grady Booch, James Rambaugh, Ivar Jacobson.
Object Oriented Testing – A presentation by F.Civello