Model-Based Software Testing for Object-Oriented ... - SAGE Journals

E–Learning Volume 5 Number 4 2008 www.wwwords.co.uk/ELEA

Model-Based Software Testing for Object-oriented Software SOLY MATHEW BIJU University of Wollongong, Dubai, United Arab Emirates

ABSTRACT Model-based testing is one of the best solutions for testing object-oriented software. It has a better test coverage than other testing styles. Model-based testing takes into consideration behavioural aspects of a class, which are usually unchecked in other testing methods. An increase in the complexity of software has forced the software industry to look into other reliable models of software testing like model-based testing. This article provides an introduction to various existing methods of testing and compares them with model-based testing.

Introduction There are numerous testing styles in the field of software engineering today. Traditional software testing includes white box and black box testing. White box testing tests the complexity and efficiency of the code developed, whereas black box testing tests the software against the requirement specifications provided by the client. These methods of testing may not be able to detect and eliminate the bugs that occur in object-oriented software. A better approach would be to use model-based testing (MBT). ‘MBT has as its roots applications in hardware testing, most notably telephone switches, and recently has spread to wide variety of software domains’ (El-Far & Whittaker, 2001, p. 1). Model-based testing is software testing in which test cases are derived completely or partially from a model that describes some (usually functional) aspects of the System Under Test (SUT). SUT is the software which is being tested for errors. MBT may be called ‘gray box testing’. Models Used in Software Testing Introduction As a software program becomes increasingly complicated, it becomes vital that the analyst and programmer, along with all others involved in the software design and development, communicate with each other very closely. Uniform Modeling Language (UML) gives them a common blueprint of the software to be designed. UML is based on object-oriented problem solving. Object-oriented programming consists of classes – their attributes, objects, the messages communicated between these objects, etc. A model needs to be designed which makes use of all the classes’ objects, the states of the objects, etc., to give an abstraction of the underlying problem. As stated by Blaha & Rumbaugh (2004, p. 56), UML has turned out to be immensely popular in both industry and academia, and has been very widely investigated for model-based testing. The latest version, UML 2.0, allows a designer to model a system using a set of 15 diagrams to capture five views of the system. The use case model is a model design based on the user’s understanding/view of the system. The following are the nine modelling diagrams used in UML: • use case diagrams; 485

http://dx.doi.org/10.2304/elea.2008.5.4.485

Soly Mathew Biju • class diagrams; • object diagrams; • sequence diagrams; • collaboration diagrams; • statechart diagrams; • activity diagrams; • component diagrams; • deployment diagrams. A use case diagram describes what the system does and its interaction with external entities. For example, if we consider the security login system, when a user types in his or her name and password, the system will verify the user name with the corresponding password. Only if the combination of the user name and password matches with that in the database will the user be able to access the system. Figure 1 shows the association of the user with the security login system.

Figure 1. A use case diagram.

A class diagram provides information about the structure of a class. The structure of a class consists of attributes and functions provided by the class, their level of access (public, private, protected, etc.) and the signature of the member functions of the class. In a statechart diagram, the focus is on the different states an object can be in, and the possible transitions between those states. In object diagrams instances of the classes are used instead of classes. They are useful for explaining complex relationships among small pieces, especially recursive relationships. A sequence diagram is an interaction diagram that details how operations are carried out – what messages are sent and when. Sequence diagrams are organized according to time. The objects involved in the operation are listed from left to right according to when they take part in the message sequence. Miller (2003) explains the relationship between activity diagram and statechart diagram as follows: Collaboration diagram focuses on object roles. Activity diagrams and statechart diagrams are related. While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process.

486

Model-Based Software Testing The Object Constraint Language makes it possible to have precise models. Most of the research work carried out in MBT (Naslavsky et al, 2007) focuses either on class or statechart diagrams. Most of the bugs become exposed during specific behaviour of the software (while the software is run under different conditions). Some of the recent work carried out in the testing field (Farooq et al, 2007) also uses sequence diagrams, collaboration diagrams and activity diagrams. A component is a physical building block of the system. It is pictorially represented as a rectangle with tabs. Component-based development (CBD) and object-oriented development go hand in hand, and it is generally recognized that object technology is the preferred foundation from which to build components. A component diagram represents a software entity in a system, for example file, resources, etc. A deployment diagram models the run-time architecture of a system. It is used to display the configuration of hardware elements (represented as nodes) and shows how software elements are mapped onto those nodes. A node refers to either a hardware or software element. It is shown as a three-dimensional box shape. An Example of a Test Model The following example shows the different states to be considered while testing a system. Let the system be a simple stack with a limited capacity of holding only five elements. A simple model will have the following three states: • Stack full, when there are five elements in the stack.

• |Stack empty, when there are no elements in the stack.

• Stack in use, when the stack has some elements but is not full. Let us assume that there are three elements in the stack in this case.

The three possible operations that can be performed on this stack are as follows: • push() – will add an element to the stack. 487

Soly Mathew Biju • pop() – will remove an element from the stack. • clear() – will empty the stack by removing all the elements from the stack. These operations can be used to change the state of the stack. The following six transitions are possible with the three states and three operations mentioned above: 1. Stack full to stack empty: a call to clear().

2. Stack in use to stack full: two calls to push().

3. Stack empty to stack full: five calls to push().

4. Stack empty to stack in use: three calls to push().

5. Stack in use to stack empty: three calls to pop().

488

Model-Based Software Testing

6. Stack full to stack in use: two calls to pop().

Model-based Testing Process Software Model

Figure 2. Model-based testing process.

Figure 2 describes the life cycle of a model-based testing process. The software model to be used should be decided during the testing phase of the software development life cycle. This model could be based on more than one of the models discussed previously. The next step is to write abstract tests for this model. These tests should then be converted into executable tasks. Executable tasks are further converted into test scripts. The test scripts will generate test reports indicating the result of the tests. The abstract tests developed based on the model cannot be directly implemented. The test cases generated from these are in the form of sequences of test scenarios. A test scenario usually specifies high-level test cases rather than exact test data given as input to the system. For example, in the case of finite state machines, it can be the sequence in which specific states and transitions must be undertaken to test the system. It is also called the transition path. In the case of a sequence diagram, a message path can be generated. A message path shows the exact sequence in which the classes must interact for testing the software. 489

Soly Mathew Biju Automating Tests Some tests can be manually performed on the system, but in most cases the test suites generated are huge. Hence, it is preferable to automate these test suites. Moreover, MBT focuses on running the same tests again whenever a change is made to the code. The test suites can be converted into executable test scripts using the available software. In some cases, the software tester will be required to write the test scripts manually. The automatic test case execution also includes test coverage analysis. Test Coverage Analysis Usually, test cases are generated to test a particular feature of the system. ‘The extent to which the targeted features are tested can be determined [by] using test coverage analysis’ (Heimdahl & George, cited in Mall et al, 2008, p. 17). Code coverage analysis is the process of finding portions of a program that are not tested by a set of test cases. It also includes designing additional test cases to maximize coverage. It is also a method of testing the quality of the tests generated. A code coverage analyzer may be used to automate this process. Test coverage (code coverage) based on a model can be as follows: test if all the test scenarios are covered or tested. ‘Important test coverage based on UML models consists of message path coverage, transition path coverage, inheritance and polymorphic coverage’ (Mall et al, 2008, p. 17). Benefits of Using MBT MBT gives a better test coverage as it looks into the behavioural aspects of the system that are not taken into consideration in pure code-based testing. Code-based testing involves writing test cases based on the code written by the programmer, while model-based testing is writing test cases based on the model developed. It is irrespective of the code written to implement the system. Another major advantage of model-based testing is that the test cases need not be rewritten or changed, even if there are changes made to the code. In the case of code-based testing, the tester will have to manually look up the test cases that have to be changed in order to test the system after a change is made to the code. Limitations of MBT MBT should not be the only method used to test a piece of software. Other testing methods should be used along with MBT to ensure efficient software testing. Model-based testing requires a model of the System Under Test to be developed. In the initial phase of software development, this model is developed based on requirement specifications. A model developed based on these specifications will be a weaker model for testing. Hence, MBT is not advisable at this stage. Another limitation is that model-based testing cannot be used on legacy systems, as legacy systems usually have inconsistent models. Conclusion MBT is a very popular testing method, currently preferred in the industry, especially for objectoriented systems. It gives higher test coverage by comparison with other testing methods. It covers the behavioural aspects and possible states of a system, not tested by other software testing methods. One of the disadvantages is that MBT has to be used with other testing methods. In future, there may emerge a testing method which will integrate the strength of MBT and codebased testing that can be a complete solution for almost perfect testing. References Blaha, M. & Rumbaugh, J. (2004) Object Modelling and Design Using UML 2.0. New Jersey: Prentice Hall.

490

Model-Based Software Testing El-Far, I. & Whittaker, J.A. (2001) Model-based Software Testing, in J.J. Marciniak (Ed.) Encyclopedia on Software Engineering. New York: Wiley. http://www.geocities.com/model_based_testing/online_papers.htm Farooq, Q., Iqbal, M.Z., Malik, Z, Nadeem, A.(2007) An Approach for Selective State Machine Based Regression Testing, in Proceedings of the 3rd International Workshop on Advances in Model-based Testing, ACM, London, pp. 44-52. Mall, R., Bhabesh, R. & Lalchandani, J. (2008) Model-based Testing of Object-oriented Software, CSI Communications, 31, 16-18. Miller, R. (2003) Practical UML™: a hands-on introduction for developers. http://dn.codegear.com/print/31863 Naslavsky, L., Ziv, H., Richardson, D.J. (2007) Towards Traceability of Model-based Testing Artefacts, in Proceedings of the 3rd International Workshop on Advances in Model-based Testing, ACM, London, pp. 105-114.

SOLY MATHEW BIJU is a Lecturer in the College of Informatics and Computer Science at the Dubai campus of the University of Wollongong, where she teaches various programming languages, discrete mathematics and algorithms, and problem solving. She has taught various software engineering and information technology subjects at different colleges. She is an ISTQB (foundation) certified software testing professional. She has taught numerous online courses in different colleges in Europe. She has worked in the information technology industry as well as working as a Systems Administrator leading Windows NT and Lotus Notes teams for British Airways at Heathrow Airport, United Kingdom and in Pune, India. Correspondence: Dr Soly Mathew Biju, PO Box 20183, Dubai, United Arab Emerates ([email protected]).

491