Aynur Abdurazik

Generating tests from UML specifications

Although most industry testing of complex software is conducted at the system level, most formal research has focused on the unit level. As a result, most system level testing techniques are only described informally. This paper presents a novel technique that adapts pre-defined state-based specification test data generation criteria to generate test cases from UML statecharts. UML statecharts provide a solid basis for test generation in a form that can be easily manipulated. This technique includes coverage criteria that enable highly effective tests to be developed. To demonstrate this technique, a tool has been developed that uses UML statecharts produced by Rational Software Corporations Rational Rose tool to generate test data. Experimental results from using this tool are presented.

Generating test data from state-based specifications

Although the majority of software testing in industry is conducted at the system level, most formal research has focused on the unit level. As a result, most system‐level testing techniques are only described informally. This paper presents formal testing criteria for system level testing that are based on formal specifications of the software. Software testing can only be formalized and quantified when a solid basis for test generation can be defined. Formal specifications represent a significant opportunity for testing because they precisely describe what functions the software is supposed to provide in a form that can be automatically manipulated.

Using UML collaboration diagrams for static checking and test generation

Software testing can only be formalized and quantified when a solid basis for test generation can be defined. Tests are commonly generated from program source code, graphical models of software (such as control flow graphs), and specifications/requirements. UML collaboration diagrams represent a significant opportunity for testing because they precisely describe how the functions the software provides are connected in a form that can be easily manipulated by automated means. This paper presents novel test criteria that are based on UML collaboration diagrams. The most novel aspect of this is that tests can be generated automatically from the software design, rather than the code or the specifications. Criteria are defined for both static and dynamic testing of specification-level and instance-level collaboration diagrams. These criteria allow a formal integration tests to be based on high level design notations, which can help lead to software that is significantly more reliable.

A Comparative Evaluation of Tests Generated from Different UML Diagrams

This paper presents a single project experiment on the fault revealing capabilities of model-based test sets. The tests are generated from UML statecharts and UML sequence diagrams. This experiment found that the statechart test sets did better at revealing unit level faults than the sequence diagram test sets, and the sequence diagram test sets did better at revealing integration level faults than the statechart test sets. The statecharts also resulted in more test cases than the sequence diagrams. The results show that model-based testing can be used to systematically generate test data and indicates that different UML models can play different roles in testing.

Evaluation of three specification-based testing criteria

This paper compares three specification-based testing criteria using Mathur and Wongs PROBSUBSUMES measure. The three criteria are specification-mutation coverage, full predicate coverage, and transition-pair coverage. A novel aspect of the work is that each criterion is encoded in a model checker, and the model checker is used first to generate test sets for each criterion and then to evaluate test sets against alternate criteria. Significantly, the use of the model checker for generation of test sets eliminates human bias from this phase of the experiment. The strengths and weaknesses of the criteria are discussed.

Using Coupling-Based Weights for the Class Integration and Test Order Problem

During component-based and object-oriented software development, software classes exhibit relationships that complicate integration, including method calls, inheritance and aggregation. Classes are integrated and tested in specific orders, where each class is added and tested one by one to see if it integrates successfully. A difficulty arises when cyclic dependencies exist—the functionality that is used by the first class to be tested must be mimicked by creating ‘stubs’ (sometimes called ‘mock objects’), an expensive and error-prone operation. This problem is generally called the class integration and test order (CITO) problem, and solutions must fully be automated for integration and testing to proceed smoothly and efficiently. This paper describes new techniques and algorithms to solve the CITO problem. New results include improved edge weights to more precisely model the cost of stubbing, and the use of node weights, which allows more information to be used. These weights are derived from quantitative measures of couplings between the integrated and the stubbed classes. Also, a new algorithm for computing the integration and test orders is presented. The technique is compared with an existing approach and found to be cheaper, get the same results when using edge weights exclusively, and yield better results when using node weights.

Quantitatively measuring object-oriented couplings

One key to several quality factors of software is the way components are connected. Software coupling can be used to estimate a number of quality factors, including maintainability, complexity, and reliability. Object-oriented languages are designed to reduce the number of dependencies among classes, which encourages separation of concerns and should reduce the amount of coupling. At the same time, the object-oriented language features change the way the connections are made, how they must be analyzed, and how they are measured. This paper discusses software couplings based on object-oriented relationships between classes, specifically focusing on types of couplings that are not available until after the implementation is completed, and presents a static analysis tool that measures couplings among classes in Java packages. Data from evaluating the tool on several open-source projects are provided. The coupling measurement is based on source code, which has the advantage of being quantitative and more precise than previous measures, but the disadvantage of not being available before implementation, and thus not useful for some predictive efforts.

An analysis tool for coupling-based integration testing

This research is part of a project to develop practical, effective, formalizable, automatable techniques for integration testing. Integration testing is an important part of the testing process, but few integration testing techniques have been systematically studied or defined. This paper discusses the design and implementation of an analysis tool for measuring the amount of coverage achieved by a set of test data according to a set of previously defined coupling criteria. This tool can be used to support integration testing of software components. The coupling-based testing technique, which has been described elsewhere, is summarized, and coverage algorithms are discussed. The focus of this paper is on the instrumentation techniques and an analysis tool built for Java programs. It was built in Java using the general Java parser JavaCC and the Java Tree Builder (JTB). We are currently using this tool to gather experimental data on the efficacy and the usefulness of the technique.