Automatically testing interacting software components

Abstract

One goal of integration testing for object-oriented software is to ensure high object interoperability. Sent messages should have the intended effects on the states and subsequent actions of the receiving objects. This is especially difficult when software is comprised of components developed by different vendors, with different languages, and the implementation sources are not all available. A previous paper presented a model of inter-operating OO classes based on finite state machines. It addresses methods for identifying the relevant actions of a test component to be integrated into the system, transforms the finite state specification into a control and data flow graph, labels the graph with all def s and uses of class variables, and presents an algorithm to generate test specifications as specific paths through the directed graph. It also presents empirical results from an automatic tool that was built to support this test method. This paper presents additional details about the tool itself, including how several difficult problems were solved, and adds new capabilities to help automate the transformation of test specifications into executable test cases. The result is a fresh approach to automated testing. It follows accepted theoretical procedures while operating directly on an objectoriented software specification. 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.

A Proposal for New Software Testing Technique for Component Based Software System

“…and Edwards [49], [68] helped automate test case and test script generation by using their frameworks. -Gallagher and Offutt [69] proposed the use of a finite state machine model to describe component interaction and provide a test method to automate test sequence generation. -Some approaches [50]- [55] embedded a component with a suitable executable test case, also known as built-in testing or BIT [70].…”

“…Inheritance critical components also have a tendency to introduce error [31], [101]. Link critical components have more interactions with other components, therefore more testing is needed [38], [69]. Bridge critical components may cause the failure of the entire system if the faults are not found [102].…”

Software paradigms, assessment types and non-functional requirements in model-based integration testing

“…Summing up we can say that [2,3,8,11,33,35,36,50,56,62,68,77,78,88,93,95,97] use coverage criteria for the appropriate domain, [38,39,43] use metrics, [34,53] do monitoring of the testing progress, [57,63,74,81] combine different models or other data like usage profiles for doing the assessment of the test process, and [24,73] provide useful information, i.e. suggestions for the best integration order strategy for the tester.…”

Testing a Component-Based Application for Road Traffic Crossroad Control Using the SimCo Simulation Framework

“…Although component-based simulations, which do not simulate software components [11], [12], [13], and monolithic (i.e. not component-based) simulations of software components [17], [18], [19] exist, there are virtually no examples of combination of both approaches.…”