Test Sequence Generation For Integration Testing Of Component Software

Abstract

Ensuring high object interoperability is a goal of integration testing for object-oriented (OO) software. When messages are sent, objects that receive them should respond as intended. Ensuring this is especially difficult when software uses components that are developed by different vendors, in different languages, and the implementation sources are not all available. A finite state machines model of inter-operating OO classes was presented in a previous paper. The previous paper presented details of the method and empirical results from an automatic tool. This paper presents additional details about the tool itself, including how test sequences are generated, how several difficult problems were solved and the introduction of new capabilities to help automate the transformation of test specifications into executable test cases. Although the test method is not 100% automated, it represents a fresh approach to automated testing. It follows accepted theoretical procedures while operating directly on OO software specifications. This yields a data flow graph and executable test cases that adequately cover the graph according to classical graph coverage criteria. The tool supports specification-based testing and helps to bridge the gap between theory and practice.

GUI Interaction Testing: Incorporating Event Context

“…For example, Inkumsah et al [22] use branch coverage to evaluate test cases, which are method sequences for object-oriented programs. Similarly, Gallagher and Offutt [23] use classical graph coverage criteria on data flow graphs for integration testing of object-oriented software that uses components that are developed by different vendors, in different languages, where the implementation sources are not all available. Gargantini et al [24] use similar graph criteria on abstract-state machines to evaluate the adequacy of test cases generated from a model checker.…”

Robustness testing for software components

“…They set up a set of test targets, and rely on a theorem prover to find execution paths for each target. Gallagher et al [13] use interacting state machines with class variables to generate the combined class states and component flow graph, so as to get test cases upon them. Ali et al [1] combine collaboration diagrams and state machines, and produce a State Collaboration Test Model for testing.…”

“…The Proof-Carrying Code [27] approach also addresses this issue, but is hard to apply to large systems. Therefore, it seems that testing [1,11,13,18] is the choice left for effectively determining the correctness of a component, as it only needs the contract and executable code to verify a component. More examples of correctness testing for components are given in Section 6.…”

Robustness Testing for Components Based on State Machine Model

“…构件软件测试的主要困难来源于构件所提供信息非常有限--它们通常不提供源代码,实现平台也可能 与调用方的平台异构.传统的黑盒测试可以对构件进行功能性测试.对于构件间交互,测试可以基于 UML 顺序 图或交互图 [23] 或者构件交互图 [24] .Gallagher 等人 [8] 用带有类变量的交互状态机生成组合状态以及构件控制流 图,并基于此生成集成测试用例.Ali 等人 [6] 将交互图和状态机相结合,提出状态交互测试模型(state collaboration test model)用于测试.这些方法扩展 UML 进行集成测试,但都假定构件本身是正确的.而本文则专注于测试单个 构件的健壮性.…”