Model based testing

This paper was distributed at the Software Quality Week Conference in May, 1997.

Model Based Testing
Larry Apfelbaum General Manager 603-879-3555 larry@sst.teradyne.com John Doyle Support Manager 603-879-3499 jd@sst.teradyne.com

Teradyne Software & Systems Test 44 Simon Street Nashua, NH 03060 www.teradyne.com/sst

Abstract
The use of a model to describe the behavior of a system is aproven and major advantage to test development teams. Models can be utilized in many ways throughout the product life-cycle, including: improved quality of specifications, code generation, reliability analysis, and test generation. This paper will focus on the testing benefits and review some of the historical challenges that prevented model based testing and present the solutions that overcamethese challenges. In addition benefits of a model based approach are reviewed in the context of two real applications, a call processing feature and a UI of a workflow oriented database system.

Outline:
1. Rationale for modeling 2. Behavioral models as a specification of a product's use 3. Test design and generation using models 4. Case study: long distance call processing feature 5. Case study:workflow based user interface / database system 6. Conclusion

1. Rationale for modeling
Models are used to understand, specify and develop systems in many disciplines. From DNA and gene research to the development of the latest fighter aircraft, models are used to promote understanding and provide a reusable framework for product development. In the software engineering process, models are nowaccepted as part of a modern object oriented analysis and design approach by all of the major OO methodologies. Papers and books have been written about the application of models to test development and reliability analysis for over two decades; however, except for leading edge companies, test creation is still a manual process with few quantitative metrics and low reuse. The objective of this1

Model Based Testing paper is to present an approach for test creation based on a graphical model that describes the behavior of the system to be tested; and a set of heuristics that enable tests to be generated from that model. Modeling is a very economical means of capturing knowledge about a system and then reusing this knowledge as the system grows. For a testing team, this information isgold; what percentage of a test engineer's task is spent trying to understand what the System Under Test (SUT) should be doing? (Not just is doing.) Once this information is understood, how is it preserved for the next engineer, the next release, or change order? If you are lucky it is in the test plan, but more typically buried in a test script or just lost, waiting to be rediscovered. Byconstructing a model of a system that defines the systems desired behavior for specified inputs to it, a team now has a mechanism for a structured analysis of the system. Scenarios are described as a sequence of actions to the system [as it is defined in the model], with the correct responses of the system also being specified. Test coverage is understood and test plans are developed in the context ofthe SUT, the resources available and the coverage that can be delivered. The largest benefit is in reuse; all of this work is not lost. The next test cycle can start where this one left off. If the product has new features, they can be incrementally added to the model; if the quality must be improved, the model can be improved and the tests expanded; if there are new people on the team, they canquickly come up to speed by reviewing the model.

2. Specifications
This paper assumes that the software to be tested is at the integration or system test phase of the development process (see Figure 1). The implied test objective is to insure that the system meets its requirements from the external point of view. The focus will not be on the implementation, but on how its users will evaluate...