An Approach for Selective State Machine based Regression Testing

Qurat-ul-ann Farooq
Center for Software Dependability Mohammad Ali Jinnah University Islamabad, Pakistan

Muhammad Zohaib Z. Iqbal

Center for Software Dependability Mohammad Ali Jinnah University Islamabad, Pakistan

Zafar I Malik
Center for Software Dependability Mohammad Ali Jinnah University Islamabad, Pakistan

quratulann@jinnah.edu.pk Aamer Nadeem

Center for Software Dependability Mohammad Ali Jinnah University Islamabad, Pakistan

zouhaib@hotmail.com

zafar@jinnah.edu.pk

anadeem@jinnah.edu.pk ABSTRACT
Model-based regression testing is an important activity that ensures the reliability of evolving software. One of the major issues in this type of testing is the optimal selection of test-cases to test the affected portion of the software. In this paper, we present a UML based selective regression testing strategy that uses state machines and class diagrams for change identification. We identify the changes using the UML 2.1 semantics of state machines and class diagram. The changes are classified as Classdriven (obtained from class diagram) and State-driven (obtained from state machine). The Class-driven changes are important as these changes are not reflected on the state machines and they might be helpful in identifying some fault-revealing test cases. With the help of the identified changes, we classify the test cases of the test suite as Obsolete, Reusable, and Retestable. We apply the approach on a case study to demonstrate its validity.

1. INTRODUCTION
Software systems evolve with time. Regression testing is an important activity to ensure that this evolution will not harm the existing functionalities of the system. Once the software development process is completed, the system may change due to the maintenance activities. After such changes regression testing becomes essential to ascertain the correctness of the system [4, 10, 23]. Regression testing ensures that the system will not regress in effect of new or modified features and the earlier functionalities work accordingly [1]. Model-based regression testing of software has several advantages [2]. Model-based development aims to provide reusable and platform independent solutions [15]. The significance of use of models for application development has increased a lot with the advancement in Executable Modeling and Model Driven Architecture (MDA) [25, 26]. Due to the advances in model-driven development, model-based testing and maintenance has become crucial. The aim of our work is to present a model-based regression testing technique that exploits design information from UML state machines and class diagrams for regression test selection. State-dependent behavior of objects raises major issues in objectoriented software testing [1]. Kung et.al, [2] discuss an example of problems that can not be revealed using structural and functional testing techniques. UML state machines are a key artifact for modeling the state dependent behavior of objects. There are several testing techniques in literature that test statedependent behavior of objects using state machines [5, 24, 19]. A major problem occurs when the state machine is modified. In such a case, testing of modified parts becomes crucial. There are two possible options for testing; one is to retest all the earlier test cases. This option is not feasible in terms of cost since the number of available test cases may be very large [1]. The second option is to select a set of test cases that test the affected portions of the software. This option has obviously been widely advocated by practitioners and researchers [1, 7, 13, 14] and is generally known as selective regression testing. The core concern of our work is to provide a state based selective regression testing strategy. Our work provides change definitions for UML 2.1 state machines and class diagram and uses them to

Categories and Subject Descriptors

Models for component, integration, and system testing, Testing from Architectural Models, Processes, Methods, and ToolsTracing for requirement models to test models.

General Terms
Design, Reliability, Verification.

Keywords
UML, Regression Testing, Model Based Testing
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that Permission to make digital or hard copies of all or part of this work for copies bear notice and full citation on the page. that To copy personal orthis classroom usethe is granted without feefirst provided copies are otherwise, republish, to post servers or to redistribute to lists, not madeor or distributed for on profit or commercial advantage and that requires prior this specific permission a fee. on the first page. To copy copies bear notice and the and/or full citation AMOST'07, July 9-12, 2007, otherwise, or republish, to London, post on UK servers or to redistribute to lists, Copyright 2007 ACM 978-1-59593-850-3/07/0007...$5.00 requires prior specific permission and/or a fee. 3rd Workshop on Advances in Model Based Testing (A-MOST)07, July 2007, London, United Kingdom. Copyright 2007 ACM

44

classify the test cases and generate regression test suite. To verify the applicability of the proposed technique, we have applied it on a case study. The rest of the paper is structured as follows: Section 2 discusses the related work in the area of model-based regression testing. Section 3 discusses the proposed approach for selective regression testing, which is followed by case study section. Finally we conclude the paper in section 5.

2. Related Work
There are two distinct approaches for UML based regression testing, i.e., Regression testing of UML artifacts and Regression testing of code using UML artifacts. In the former approach, we test the UML design itself, whereas, in the later approach UML designs are used to generate test cases that are executed on the code. Pilskalns et.al worked on regression testing of UML designs. They have proposed an approach that is based on their previous work of test case generation for UML designs using the symbolic execution technique [17]. Regression testing of software has always been an important area in software testing. Briand et.al [9] presented a safe regression testing technique using use case diagrams, sequence diagrams, and class diagrams. The definitions of changes between baseline and delta version of these diagrams is presented. Changes are identified in these diagrams and their impact on baseline test suite is analyzed. The test cases are categorized based on White et al [6] classification. Chen et.al [8] presented a strategy for regression test selection using activity diagram. They have used activity diagram for describing the system requirements. Activity diagram is treated like a control flow graph (CFG) and baseline and delta version of CFG are compared to identify the changes. The test paths corresponding to the affected nodes are selected using traceability matrix for regression test suite. The technique presented by Traon et.al [14] is basically for integration testing using UML class diagrams. They have used a TDG (Test Dependency Graph) as their test model. For regression purpose, the authors have suggested to select the TDG subset that contains a modified component. The authors have proposed different criteria for regression testing. Wu and Offutt [27] have presented a UML based regression testing technique for component based software using collaboration diagram, class diagram and state machines. They have discussed the regression strategies for different maintenance activities. Their focus is on regression testing strategy and not on change impact analysis. A limited research is also available in literature in which state machine like models are used for regression testing. These techniques are not UML based but, since our work employs UML state machines which are extensions of state charts, therefore, we are also including them. The technique presented by Beydeda and Gruhhn [11] is for class level regression testing based on specification as well as implementation information. A class specification implementation graph (CSIG) is used as a model. Regression test cases are selected by comparing the base line and delta version of CSIG. Korel et.al [16] have used the EFSM (Extended Finite State

Machines) as the model and their test case reduction technique is based on dependence analysis of this model. They have identified the difference in the original and modified model based on the elementary modifications. They have defined two types of elementary model modifications, i.e., addition of a transition and deletion of a transition. The focus of their work is on regression test suite reduction by performing the dependence analysis of the EFSM. The authors have constructed a dependence graph considering the data and control dependencies of the transitions. The interaction pattern of each test case is calculated based on these modifications and test suite is reduced based on these interaction patterns. Briand et.al [17] presented the changes in class diagram using UML 2.1 semantics for traceability analysis of model refinements. Their change definitions are focusing model refinements and are not complete for our purpose. Briand et.al [18] have presented an approach for impact analysis of changes in UML artifacts. Change taxonomy for UML artifacts including class diagram, sequence diagram, and state machine is provided and impact analysis rules are specified for these UML models. The change definitions provided by Briand et.al are based on UML 1.4 and are mainly concerned with consistency checking. We have changed and extended their definitions according to UML 2.1 constructs to perform regression testing.

3. Proposed Approach
In UML based modeling, artifacts are interrelated. A change in one artifact may cause a change in another artifact without even being reflected on it. For example, a message in the sequence diagram may change due to a change in its respective operation in the class diagram. This change may not be reflected directly in the sequence diagram and consulting the class diagram becomes essential to obtain this change information. Due to this ripple effect phenomenon, changes in some other artifacts in UML may also affect the state machines. It is necessary to cater these changes when we use state machines for regression testing. The basic regression testing process involves following steps. Identification of changes in delta version of the system. Analysis of elements that are indirectly affected due to some dependencies. Inspection of the effect of both changed elements and indirectly affected elements on the base line test suite. Discarding the test cases that are no more valid and selecting a subset of baseline test suite that needs to be exercised for regression testing. According to UML 2.1 [21], there are two types of state machines, behavioral state machines and protocol state machines. We are considering behavioral state machine for our regression testing approach. Behavioral state machines are widely used and they employ actions that protocol state machines lack. The most important artifact that can affect the state machines behavior is the class diagram in which the context class of the state machine is defined. Besides, some other artifacts may also affect the state machine, e.g., sequence diagrams. Primarily we are focusing on the changes in class diagram in which the context class of the state machine is defined. Hsia et.al [3] classified the changes in OO programs as changes that affect the object behavior, data members, operations, operations behavior, relationships, and dependencies among

45

different classes. We are catering all these types of changes in our regression testing technique by considering the changes in object behavior by analyzing the state machine and the changes in data members, operations, relationships and dependencies by using the information from class diagram. Figure 1 represents the architecture of our proposed regression testing approach. The CDComparator takes the baseline and delta version of class diagram, class invariants, and operation contracts, and generates Class-driven Changes (CDC). The SMComparator takes CDC and baseline and delta state machines, contracts and state invariants as input and generates State-driven Changes (SDC). SDC, along with baseline test suite, are fed to Regression Test Selector. The regression test selector classifies the baseline test suite into obsolete, reusable, and retestable test cases.

prerequisite of our approach to ease the automation and traceability with test cases.

3.1 Class-driven Changes

We define Class-driven changes in this section. We refer to the baseline and delta version of the class as CD and CD respectively. A class diagram will be changed if any of its attributes, operation, or relationship is changed [9, 18, 17]. Following we define these changes for our state based regression testing approach. ModifiedExpression: According to UML 2.1, an expression is a structured tree of symbols representing a set of values when evaluated in a context [21]. We detect the ModifiedExpression in two steps. First step is comparing the two expressions as text strings. If the previous expression does not match the new one then the expression will be considered changed. If in this step no difference is found in the expression then the expression is analyzed to check the accessed attributes and links of the class. If the expression contains a modified attribute or link of the class, it will be considered modified. A constraint is a specialized kind of expression and a ModifiedConstraint will be evaluated similar to the ModifiedExpression. ChangedMultiplicity: The ChangedMultiplicity refers to the changed upper or lower bound. ModifiedProperty: In UML 2.1 [21], AssociationEnd and Attributes are instances of Property meta class. We have defined ModifiedAttributes and ModifiedAssociations in terms of ModifiedProperty to avoid the redundant definitions. The ModifiedProperty will be reused to analyze both associations and attributes. An instance of Property class will be modified if its visibility (public, private, protected, package) is changed or it has a ChangedMultiplictity. An instance of Property class will be modified if its default value is changed or any other properties associated with the Property instance are changed. These properties include some Boolean properties, i.e. isDerived, isReadonly, isComposite isOrdered, isUnique, isStatic, isLeaf, and isDerivedUnion. These properties will be changed if Boolean values of these properties are changed. The instance of Property class will also be changed if its aggregation kind (none, shared, composite) is changed. The Property instance will be changed if any constraint associated with the Property instance is changed or the list of Property instances that are its subset is changed. This list will be changed in case of addition or deletion of any Property instance. ModifiedAttribute: We define the set of attributes in a class CCD as AC and the attributes in the class D CD as AD. . The set ADM denotes the set of modified attributes in D. In UML 2.1 [21], attributes of a class are described as instances of the property class. We define ModifiedAttribute as a specialization of ModifiedProperty. An attribute a AD will be modified and placed in ADM if an attribute with the same name exists in AC but its type is changed or it is changed due to any of the changes defined in ModifiedProperty. All the modifications in the attributes are shown in the form of a change model in Figure 2. ModifiedOperationParameter: A parameter of an operation will be considered modified if its direction (in, inout, out, return) is

Figure 1: Abstract Model of State based regression testing approach We define two types of changes in our approach; Class-driven changes and State-driven changes. Class-driven changes are those changes which can be obtained by comparing baseline and delta version of the class diagram. These changes may or may not reflect on the state machine. State-driven changes are obtained by comparing the base line and delta version of the state machine and by using the Class-driven changes. We have defined both of these changes based on the UML 2.1 Meta model [21]. We have ignored the syntactic representation of the model elements and focus on the semantics described in UML 2.1 superstructure [21]. We have represented all the modifications in various change models. One of the models depicts the modifications in attributes and is shown in Figure 2. Due to space constraints we are not presenting all the change models. We are assuming that the input models for our approach are consistent and flattening is also a

46

changed. The parameter will be modified if its default value is changed or it has a ChangedMultiplicity. The operation parameter will be modified if the IsOrdered or isUnique property of the parameter is changed or it has an associated ModifiedConstraint ModifiedOperation: We define the set of operations in a class CCD as OPC and the operations in the class D CD as OPD. The set OPDM denotes the set of modified operations in D. An operation op OPD will be considered modified in the following cases: An operation will be modified if the operation has a changed visibility, or the list of exceptions associated with the operation is changed. The list of raised exceptions will be changed due to some added or deleted exception. The operation will be modified if it contains a ModifiedOperationParameter. We have already discussed the ModifiedOperationParameter. An operation will be modified if any of its properties are changed. The properties include isStatic, isLeaf, and isQuery properties. There are some other properties of the operation as well but these will apply on the return value of the parameter. These properties are isOrdered, isUnique and multiplicity of the return value. However, an operation will be changed on change of any of these properties. All these properties are of Boolean type except multiplicity of the return value. Hence, these properties will be considered changed if their Boolean value is changed. An operation will be changed if its return type multiplicity is ChangedMultiplicity. An operation will be modified if it contains a different operation constraint. Three types of constraints are defined for operations, i.e., pre, post, and body condition. Pre/post conditions are the notion of design by contract [20] methodology. Pre condition is a condition that must hold before invocation of the operation. Post condition is a condition that must hold after the execution on that operation and body condition is condition on the return value of the operation. Operations constraints are a kind of constraint and they will be treated as ModifiedConstraint. ModifiedAssociation: According to the UML specification [21], an association is defined as a set of tuples whose value refers to typed instances. We define the set of associations in a class CCD as ASC and the associations in the class D CD as ASD. The set ASDM denotes the set of modified associations in D. An association as ASD will be considered modified if its end type is changed. End type refers to the memberEnd, ownedEnd, and navigableOwnedEnd. An association will be modified if any of its AssociationEnds is changed. An association end will be changed if it has any of the changes defined in ModifiedProperty. An association is modified if IsAbstract attribute of the association is changed. An instance of an association is called a link. An association link will be changed if its respective association is changed Added/deleted Attribute: An attribute aAC will be considered deleted if no attribute with the same name exists in AD. An attribute aAD will be considered added if no attribute with the same name exists in AC. In case of addition and deletion of an attribute, this change will also be reflected on the state machine if the respective attribute is used in the state machine. The addition/deletion of an attribute can also affect some operations, e.g., operation contract may traverse that attribute. This change

will be handled through ModifiedOperation and affect the state machine indirectly. Added/deleted Operation: An operation opOPC will be considered deleted if no operation with the same name, return type, same number of parameters with same type exists in OPD. In case of deletion of an operation, this change will also be reflected on the state machine if the respective operation is used in the state machine as a CallEvent or a CallAction. An operation opOPD will be considered added if no operation with the same name, return type, same number of parameters with same type exists in OPC. The addition of the operation in the class will also be reflected on the state machine if the respective operation is used in the state machine as CallEvent or CallAction. Added/deleted Association: Addition and deletion of associations will also reflect on those transitions of the respective state machine that refer to the links of these associations in events, actions, or guards.

3.2 State-driven Changes

In UML 2.1, state machines are composed of regions and regions are composed of states, transitions and other vertices. We assume that the state machines are flattened and are within a single region. We will ignore the notion of composite and sub-machine states and assume that the state machine is flattened. Flattening will ease the automation process and traceability of states and transitions with the baseline test suite. We are focusing on changes associated with states and transitions and are ignoring other vertices of state machine at this time. We are assuming that attributes of the context class always appear on the state machine with the keyword self to distinguish them from local variables or parameters. We will denote the baseline state machine as SM and delta version of state machine as SM. The set of states in the baseline state machine SM is defined as S and set of transitions is defined as T. The set of states in delta version of the state machine SM are denoted as S and set of transitions in SM is represented as T. Added/Deleted State: Addition/deletion of states will always result in addition/deletion of some transitions [16], hence we are considering only addition and deletion of transitions which will also cater addition/deletion of states. ModifiedState: We denote the set of modified states in SM as SM. A state sS will be considered modified and placed in the SM, if it has a modified state invariant or its redefined behaviors or redefinition context is changed. A modified state invariant is same as ModifiedConstraint defined earlier. A state will also be considered modified if its visibility or isLeaf attribute is changed. The change in container of the state is not applicable in our context as we are assuming a flattened state machine with a single region. We are not considering a state as modified if its set of incoming or outgoing transitions is changed as it will be handled through addition and deletion of transition. We assume that after flattening, all entry, exit, and do actions also move to the transitions. Hence, modified entry, exit, and do actions will result in modified transitions and not in modified states. Briand et.al [22] have discussed example of such flattening of states.

47

ModifiedAttribute

changed. Changes in transition kind and container are not applicable because of flattened state machine.
ChangedVisibilityKind ChangedDefaultValue ChangedAttributeMultiplicity ChangedProperties ChangedssDerived ChangedisReadOnly ChangedAggregationKind ChangedisComposite ChangedisOrdered ChangedisUnique ChangedisStatic ChangedisLeaf ChangedisDerivedUnion ChangedSubsets ChangedPropertyConstraint Changed Type

ModifiedEvent: According to UML 2.1 specifications [21], there are three major kinds of events; MessageEvent, TimeEvent, and ChangeEvent. The MessageEvent has three specializations AnyReceiveEvent, SignalEvent, and CallEvent. Following paragraphs discuss changes in these events. The transition having AnyReceiveEvent will be executed on any message except those that are not referenced in any other transition from the same source state. In UML 2.1 [21], this event is denoted as all. There can be only addition and deletion of such event and they would not be considered for modification. CallEvents model the request to invoke a specific operation. They can be represented as operations of classes [19]. They can reference attributes and links of context classifier [22]. In our case, this classifier is the context class of state machine. These operations can correspond to the CallEvents and in our approach, we are assuming that every CallEvent in state machine corresponds to some operation in its context class. A CallEvent will be considered modified when the operation corresponding to the CallEvent in the context class is a ModifiedOpeartion. SignalEvents model the receipt of asynchronous signals. SignalEvents are depicted on the state machine similar to the CallEvent with a name and assignment specifications. However, there are different ways of implementing SignalEvents. We are assuming that there is an operation in the class with the same name as signal [22]. This is equivalent to a CallEvent and changes in SignalEvents will be handled similarly. ChangeEvents correspond to the system configuration that makes a condition true and they are denoted as Boolean expressions. A ChangeEvent is of the form when <expression>. A TimeEvent specifies a point in time at which an event occurs [21]. There are two types of TimeEvents in UML 2.1 [21]: Relative time events and Absolute timeEvents. Relative time events are denoted with after<<Expression>> and Absolute TimeEvents are denoted with at<<Expression>>. The ChangeEvents and TimeEvents will be modified if their expression part uses some ModifiedAttribute or links from the class diagram. If the expression is deleted we will treat this as DeletedEvent. In case expression is an operation call, the event will be changed if the operation belongs to the set of ModifiedOperation. ModifiedActions and ModifiedGuards: There are 44 actions defined in UML 2.1 action semantics. Defining all the possible changes in these actions is out of scope of this paper. We only consider CallActions and VariableActions. Changes in CallActions are handled similar to CallEvent. VariableActions and guards will be treated same as ModifiedExpression.

Figure 2: A change model for modifications in attributes Added/Deleted Transition: TA denotes the set of added transitions and TD defines the set of deleted transitions. A transition tT will belong to the TA if it does not exist in T, but exists in T. A transition tT will belong to TD if it exists in T, but it does not exist in T. The reason of the deletion may be some DeletedEvent, DeletedAction, or DeletedGuard. A transition may also be deleted if source or target state of the transition is deleted ModifiedTransition: The set of modified transitions in the SM is denoted as TM. A transition tT will belong to the TM if it contains some ModifiedEvent, ModifiedAction or ModifiedGuard. A transition will also be modified if its associated set of redefined transitions or its redefinition context is changed. A transition will be modified if its visibility or isLeaf attribute is

3.3 Test Suite Classification

We have discussed Class-driven and State-driven changes in section 3.1 and 3.2 respectively. We get the change sets for Classdriven and State-driven changes by using above definitions. The next step is the classification of baseline test suite using Statedriven changes. The maintenance of the test suite requires the identification of three types of test cases as classified by Leung and White [6], i.e., Obsolete, Reusable and Retestable as shown in Figure 3. This classification is adopted by several regression testing techniques in the literature [8, 9, 12]. Obsolete test cases are no more valid for the delta version. They usually correspond

48

to elements in the system that are deleted and are not accessible in the delta version. Retestable test cases need to be exercised for regression testing as they correspond to modified parts of the system. Reusable test cases correspond to unchanged parts of the system. They are valid but they are not required to be re-executed for regression testing. We define the baseline test suite as TS. Our base line test suite consists of the test paths extracted from the SM by applying any of the state based testing strategies [24,19 ].
TestSuiteClassification

application and state machine for Student class are shown in Figure 4 and Figure 5 respectively. The delta version contains following change information. The coursesTaken attribute in Registration class was of type String in the base line version, now it is of type int. A transition labeled as t12 was present in the baseline version but delta version does not contain this information. A new transition labeled as t16 is added in the delta version and it was not present in baseline version.

ObsoleteTestCases * * DeletedTransition

RetestableTestCases * * ChangedTransition

After the comparison of baseline and delta version of class diagram, the attribute coursesTaken is inserted in the set of modified attributes. This Class-driven change set is then used to identify changes in the state machine of the Student class. Baseline and delta versions of Student state machine are compared. The guard conditions of transitions t4 and t6 use the modified attribute coursesTaken; hence, guards of t4 and t6 are modified. The transition t4 and t6 are placed in the set of modified transitions due to modified guard condition. The transition t12 is placed in set of deleted transitions and t16 in the set of Added transitions. These State-driven changes along with base line test suite are used to classify the test cases into obsolete, reusable, and retestable. Table1 shows the baseline test suite of Student class which consist of 22 test paths. A unique id is assigned to each test path for reference. Test cases with ID 3, 8, 14, and 20 are classified as obsolete as they contain the deleted transition t12. Test cases with ID 1, 2, 4, 5, 11, 12, 13, 15, 16, and 17 are Retestable as they contain the modified transitions t4 and t6. All other test cases in the base line test suite are reusable as they do not correspond to any modification in the state machine and class diagram. If we do not consider the changes in the class diagram for test selection and only consider the state machine changes, then only the test cases with ID 3, 8, 14, and 20 will be selected and we will miss 10 potential fault revealing test cases.

ReusableTestCases

Figure 3: Test Suite Classification in state based regression testing approach Each test path tsTS in the test suite will represent a sequence of transitions tiT in the SM. The set of obsolete test cases is defined as TSO TS. The set of reusable test cases is defined as TSRE TS and TSRT TS is the set of retestable test cases. A test case tsTS will be added to TSO if some transition tits exists in TD. A test case tsTS will be added to TSRE if some transition tits exists in TM and ti TD. All the other test case in TS belong to TSRT and are not included in TSO TSRE.

4. Case Study
In order to validate the applicability of the proposed regression testing strategy, we have employed a case study of Student Enrollment System. The delta version class diagram for the

49

Regi strati on Student reg# : Stri ng isEligable() +theStudent 1

*
+currentReg

coursesT aken : String coursesLeft : Integer enrollInCourse() requestForWi thdraw() 1 1 Semester

Regi steredSemesterCours es

* *

SemesterCourses getSemesterCourses() addSemesterCourses() updateSemesterCourses() 1

+currentSem ester

*
1

getSemesterCourses() addSemesterCourses()

getCurrentWeek() isShowUpWeek() offerCourses() getSemesterBreak() isSemesterCl osed() isMidTermShowUp()

*
Courses courseCode : Integer courseOutli ne : String

Figure 4: Class diagram for Student Enrolment System

Figure 5: State Machine of Student Class

50

Table 1: Base line test suite for Student class ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Test Path to,t1,t3,t6,t7 to,t1,t3,t6,t8 to,t1,t3,t6,t9,t10,t12 to,t1,t3,t6,t9,t10,t11,t13 to,t1,t3,t6,t9,t10,t11,t14,t15 to,t1,t3,t5t7 to,t1,t3,t5,t8 to,t1,t3,t5,t9,t10,t12 to,t1,t3,t5,t9,t10,t11,t13 to,t1,t3,t5,t9,t10,t11,t14,t15 to,t1,t3,t4 to,t2,t6,t1 to,t2,t6,t8 to,t2,t6,t9,t10,t12 to,t2,t6,t9,t10,t11,t13 to,t2,t4 to,t2,t6,t9,t10,t11,t14,t15 t0,t2,t5,t1 t0,t2,t5,t8 t0,t2,t5,t9,t10,t12 t0,t2,t5,t9,t10,t11,t13 t0,t2,t5,t9,t10,t11,t14,t15

6. ACKNOWLEDGMENTS
Our thanks to Tabinda Waheed, Iram Rubab, Irum Rauf, Mohammad Usman and Atif A. Jilani for their support and cooperation throughout this work.

7. REFERENCES
[1] Binder, R.V., Tools and Techniques for testing object-oriented programs, Published by Addison-Wesley, ISBN 0201809389, March 2003. [2] Kung, D., Gao, J., Hsia, P., Toyoshima, Y ., Chen, C., Kim, Y.S., and Song, Y.K . Developing an object-oriented software testing and maintenance environment. Communications of the ACM, Volume 38, Issue 10, Special issue on object-oriented experiences and future trends, ACM Press, 1995 [3] Hsia, P., Li, X., Kung, DC. Hsu, C.T., Li, L., Toyoshima, Y., and Chen, C. A technique for the selective revalidation of OO software. Journal of Software Maintenance: Research and Practice Volume 9, Issue 4, Pages: 217 - 233, ISSN: 1040-550X, 1997. [4] Bellur, U. Vallieswaran, V. On OO Design Consistency in Iterative Development, Third International Conference on Information Technology. New Generations, on page(s): 46- 51, ISBN: 0-7695-2497-4, April 2006. [5] Kung, D. Suchak, N. Gao, J. Hsia, P. Toyoshima, Y. Chen, C., On object state testing, Computer Software and Applications Conference, 1994. COMPSAC 94. Proceedings., Eighteenth Annual International, On page(s): 222-227, ISBN: 08186-6705-2, Nov 1994. [6] Leung, H.K.N. White, L. , Insights into regression testing [software testing, Proceedings of Conference on Software Maintenance., , On page(s): 60-69, ISBN: 0-8186-1965-1, Oct 1989. [7] Rothermel, G., and Harrold, M.J. A safe, efficient regression test selection technique. ACM Transactions on Software Engineering and Methodology (TOSEM), Volume 6, Issue 2, ISSN: 1049-331X, April 1997. [8] Chen,Y., Probert, R.L., and Sims, D.P. Specification-based Regression Test Selection with Risk Analysis. IBM Centre for Advanced Studies Conference, Proceedings of the conference of the Centre for Advanced Studies on Collaborative research, 2002. [9] Briand, L.C., Labiche, Y, and Soccar, G. Automating Impact Analysis and Regression Test Selection Based on UML Designs. Proceedings of the International Conference on Software Maintenance (ICSM.02), IEEE 2002. [10] Mattsson, M.K., Forssander, S., and Olsson, U. Corrective maintenance maturity model (CM3): maintainer's education and training. Proceedings of the 23rd International Conference on Software Engineering, Pages: 610 619. [11] Beydeda, S., and Gruhn, V. Integrating White- and BlackBox Techniques for Class-Level Regression Testing. Proceedings of the 25th International Computer Software and Applications Conference on Invigorating Software Development, Pages: 357 362, ISBN:0-7695-1372-7, 2001.

5. Conclusions and Future Work

We have presented a methodology for regression test selection using UML state machines and class diagrams. Our approach focuses on finding the impact of changes in class diagram on state machines and finally on the test suite. We have defined changes in baseline and delta versions of the class diagram (Class-driven Changes) and state machine (State-driven Changes). The change definitions presented in the paper conform to UML version 2.1. We have classified the baseline test suite as Obsolete, Reusable, and Retestable. We have applied the proposed regression testing strategy on a case study of Student Enrolment System to prove the applicability of our proposed approach. Our future work aims to determine the effectiveness of the proposed regression testing strategy by applying it on an industrial scale case study. We also intend to evaluate the approach through mutation analysis. We are currently working on complete automation of the approach.

51

[12] Liang, H. Regression testing of classes based on TCOZ specification. Proceedings Of 10th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS), On page(s): 450- 457, ISBN: 0-7695-2284-X, June 2005. [13] Sajeev, A.S.M, and Wibowo, B, Regression test selection based on version changes of components. Tenth Asia-Pacific Software Engineering Conference, pp 78- 85, ISBN: 0-76952011-1, Dec 2003. [14] Traon, YL. Jeron, T. Jezequel, JM. Morel, P. Efficient object-oriented integration and regression testing. Reliability, IEEE Transactions, Volume: 49, Issue: 1, ISSN: 0018-9529, Mar 2000. [15] Deng, D., Sheu, P.C.Y, and Wang, T. Model-based testing and maintenance. Proceedings of IEEE Sixth International Symposium on Multimedia Software Engineering, pp 278- 285, ISBN: 0-7695-2217-3, Dec. 2004. [16] Korel, B., Tahat, L.H., and Vaysburg, B. Model Based Regression Test Reduction Using Dependence Analysis. Proceedings of the International Conference on Software Maintenance (ICSM.02), ISBN: 0-7695-1819-2, IEEE , 2002. [17] Briand,L.C, Labiche,Y, Yue, T, Automated Traceability Analysis for UML Model Refinements, Technical Report: TR SCE-06-06, Version 2, Carleton University, Department SCE Software Quality Engineering Laboratory 1125 Colonel By Drive, Ottawa, ON K1S5B6, Canada, http://sce.carleton.ca/squall, August 2006. [18] Briand, L.C., Labiche, Y, Sullivan, L.O, and Sowka, M. M. Automated impact analysis of UML models. Journal of Systems and Software, Volume 79, Issue 3, Pages: 339 - 352, ISSN: 0164-1212, March 2006. [19] Hong, H.S., Kwon, Y.R, and Cha, S.D. Testing of ObjectOriented Programs Based on Finite State Machines. p. 234,

Second Asia-Pacific (APSEC'95), 1995.

Software

Engineering

Conference

[20] Myers, B. Applying `design by contract'. IEEE Computer Society Press, Volume 25, Issue 10, Pages: 40 - 51, ISSN: 00189162, October 1992. [21] OMG, UML 2.1: Super structure Specifications, OMG, April 2006: Available: http://www.omg.org/cgi-bin/doc?formal/07-0203 [22] Briand,L.C., Labiche,Y., and Lin,Q. Improving state chart based coverage criteria using data flow information. Technical Report SCE-04-17, Carleton University, October 2004. [23] Winter. Managing object-oriented integration and regression testing. EuroSTAR98, Munch, 1998. [24] Ali, S., Briand, L.C., Rehman, M.J., Asghar, H., Iqbal, M.Z.Z., and Nadeem, A. A State-based Approach to Integration Testing based on UML Models. Carleton Technical Report SCE05-02, Version 3, October 2006 [25] Mellor, S. J. and Balcer, M. J. Executable UML; A Foundation for Model-Driven Architecture, Addison-Wesley, 2002, ISBN 0-201-74804-5. [26] Mellor, S. J. Introduction to Executable and Translatable UML, Application Development Toolkit, Whitepapers CNET Networks, 2005. [27] Wu, Y. and Offutt, J. Maintaining Evolving Component based software with UML, in Proceeding of 7th European on software maintenance and reengineering, IEEE,2003. [28] Pilskalns, O. and Andrews, A. Regression Testing UML Designs, in Proceedings of 22nd IEEE International Conference on Software Maintenance (ICSM06), IEEE 2006.

52