Object-oriented integration testing

Jorgensen, Paul C.; Erickson, Carl

doi:10.1145/182987.182989

Cited by 120 publications

(45 citation statements)

References 1 publication

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…For example, the path (1,2,9,11,13,15,16) in the program getlist is infeasible. An association can be covered by a set of distinct paths of the program.…”

Section: Concepts and Terminologymentioning

confidence: 99%

“…Additionally, all of them address only unit testing and nowadays, data flow based testing criteria and tools are being applied within a broader context. For example, data-flow based criteria have been extended to integration testing [2,8,10,20], specification testing [3,7], object-oriented software [9,16,25], concurrent and parallel programs [39,33] and, most recently, to web applications [21,29]. In all these new contexts the problem of infeasible paths remains.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Infeasible paths in the context of data flow based testing criteria: identification, classification and prediction

Vergílio¹,

Maldonado²,

Jino³

2006

J. Braz. Comp. Soc.

View full text Add to dashboard Cite

show abstract

“…For example, the path (1,2,9,11,13,15,16) in the program getlist is infeasible. An association can be covered by a set of distinct paths of the program.…”

Section: Concepts and Terminologymentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Infeasible paths in the context of data flow based testing criteria: identification, classification and prediction

Vergílio¹,

Maldonado²,

Jino³

2006

J. Braz. Comp. Soc.

View full text Add to dashboard Cite

show abstract

“…Jorgensen and Erickson [15] consider testing that exercises method-message paths and atomic system functions. A method-message path is a sequence of events of the form "method m 1 invokes method m 2 ; during this invocation, m 2 invokes m 3 ; during this invocation, m 3 invokes method m 4 .…”

Section: Testing and Sequence Diagramsmentioning

confidence: 99%

“…In the subsequent discussion, we will use the more common term call chain to refer to such a sequence. An atomic system function, as defined in [15], is equivalent to the set of all start-to-end message sequences in a sequence diagram.…”

Section: Testing and Sequence Diagramsmentioning

confidence: 99%

Coverage Criteria for Testing of Object Interactions in Sequence Diagrams

Rountev

Kagan

Sawin

2005

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

Abstract. This work defines several control-flow coverage criteria for testing the interactions among a set of collaborating objects. The criteria are based on UML sequence diagrams that are reverse-engineered from the code under test. The sequences of messages in the diagrams are used to define the coverage goals for the family of criteria, in a manner that generalizes traditional testing techniques such as branch coverage and path coverage. We also describe a run-time analysis that gathers coverage measurements for each criterion. To compare the criteria, we propose an approach that estimates the testing effort required to satisfy each criterion, using analysis of the complexity of the underlying sequence diagrams. The criteria were investigated experimentally on a set of realistic Java components. The results of this study compare different approaches for testing of object interactions and provide insights for testers and for builders of test coverage tools.

show abstract

“…see [14]). In general, a test model can specify the behavior of the complete system or of the sub-system that should be integration tested.…”

Section: Test Modelsmentioning

confidence: 96%

Integration Testing in Software Product Line Engineering: A Model-Based Technique

Reis

Metzger

Pohl

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. The development process in software product line engineering is divided into domain engineering and application engineering. As a consequence of this division, tests should be performed in both processes. However, existing testing techniques for single systems cannot be applied during domain engineering, because of the variability in the domain artifacts. Existing software product line test techniques only cover unit and system tests. Our contribution is a model-based, automated integration test technique that can be applied during domain engineering. For generating integration test case scenarios, the technique abstracts from variability and assumes that placeholders are created for variability. The generated scenarios cover all interactions between the integrated components, which are specified in a test model. Additionally, the technique reduces the effort for creating placeholders by minimizing the number of placeholders needed to execute the integration test case scenarios. We have experimentally measured the performance of the technique and the potential reduction of placeholders. MotivationSoftware product line engineering (SPLE) is a proven approach for deriving a set of similar applications at low costs and at short time to market [8] [21]. SPLE is based on the planned, systematic, and pro-active reuse of development artifacts (including requirements, components, and test cases). There are two key differences between SPLE and the development of single systems [21]:1. The development process of a software product line (SPL) is divided into two sub processes: domain engineering and application engineering. In domain engineering, the commonalities and the variability of the SPL are defined and reusable artifacts, which comprise the SPL platform, are created. In application engineering, customer-specific applications are realized by binding the variability and reusing the domain artifacts. Because of the division of the development process into domain and application engineering, there are two major kinds of development artifacts that have to be tested. In domain engineering, the SPL platform has to be tested, in application engineering the derived applications have to be tested.The SPL platform contains variability. This variability prevents the use of existing testing techniques for single systems, because the domain artifacts do not define a single application but a set of applications. With existing techniques from single system testing, each of these applications would have to be individually tested in domain engineering, resulting in an enormous test effort.In the literature, several approaches for SPL testing have been proposed (e.g.,). However, these approaches cover unit and system testing only.This paper presents a model-based, automated technique for integration testing in domain engineering. Our technique generates integration test case scenarios (ITCSs), which support the test of the interactions between the components of an integrated sub-system. An ITCS describes the order and the t...

show abstract

Object-oriented integration testing

Cited by 120 publications

References 1 publication

Infeasible paths in the context of data flow based testing criteria: identification, classification and prediction

Infeasible paths in the context of data flow based testing criteria: identification, classification and prediction

Coverage Criteria for Testing of Object Interactions in Sequence Diagrams

Integration Testing in Software Product Line Engineering: A Model-Based Technique

Contact Info

Product

Resources

About