State of the art in testing components

Beydeda, Sami; Gruhn, Volker

doi:10.1109/qsic.2003.1319097

Cited by 34 publications

(23 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…[10]). Der Entwickler einer Komponente kann sich zwar an den Anforderungen eines einzelnen Kunden oder an den durch die Marketingabteilung ermittelten Anforderungen orientieren; es ist ihm aber nicht möglich sämtliche Einsatzmöglichkei-ten der Komponente vorauszusehen.…”

Section: Motivation Und Zielsetzungunclassified

See 1 more Smart Citation

STECC: Selbsttestende Software-Komponenten

Beydeda

2006

Informatik Forsch. Entw.

View full text Add to dashboard Cite

ZusammenfassungKomponentenbasierte Softwareentwicklung kann verschiedene Vorteile in der Entwicklung von größeren Softwaresystemen haben. Diesen Vorteilen stehen aber häufig Nachteile gegenüber, wie beispielsweise die erschwerte Testbarkeit einer Komponente durch ihren Nutzer, der die Komponenten als Teil in ein größeres System integrieren möchte. Die erschwerte Testbarkeit resultiert insbesondere aus der Tatsache, dass der Quelltext vor allem bei kommerziellen Komponenten im Allgemeinen nicht offen gelegt wird und somit keine programmbasierten Tests mög-lich sind. Dieser Beitrag stellt die Self-Testing COTS Components (STECC) Method vor, die genau an dieser Stelle ansetzt. Die zugrunde liegende Strategie der STECC-Methode ist die Erweiterung einer Komponente mit Funktionalität von Testwerkzeugen, so dass die Komponente selbsttestend wird. Der Quelltext und andere kritische Informationen können innerhalb der Komponente in einer eingekapselten Art und Weise für Testzwecke genutzt werden, ohne dass diese Informationen nach außen, also zum Komponentennutzer, sichtbar werden. Die STECC-Methode stellt technisch einen Rahmen zur Verfügung, in den bestehende Verfahren, insbesondere solche für das pfadorientierte Testen, eingebettet werden können.Schlüsselwörter Komponentenbasierte Softwareentwicklung · Selbsttestbarkeit · Kontrollflussgraphgenerierung · Pfadorientiertes Testen Abstract Component-based development can have various benefits in the development of large software systems. However, component-based development can also introduce problems, such as obstacles in testing of a component by its user who intends to integrate the component into a larger system. Such an obstacle is, for instance, a lack of source code in the case of commercial components, which hinders program-based tests as one implication in particular. This article introduces the Self-Testing COTS Components (STECC) Method for such circumstances. The underlying strategy of the STECC method is to augment the functionality of a component by functionality specific to testing tools, so that the component is capable of testing itself. Source code and other detailed technical information can be processed within the component in an encapsulated form, without being disclosed to the component user for testing purposes. The STECC method provides a framework in which techniques of, in particular, path-oriented testing can be embedded.

show abstract

Section: Motivation Und Zielsetzungunclassified

“…Diese sollen hier kurz erläutert und mit der STECC-Methode verglichen werden. Eine ausführlichere Untersuchung dieser Ansätze findet sich in [10]. Dabei finden Methoden, die ausschließlich für den Entwickler der Komponente und nicht für deren Nutzer gedacht sind, keine Berücksichtigung.…”

Section: Vergleich Mit Anderen Ansätzen Für Das Testen Von Komponentenunclassified

STECC: Selbsttestende Software-Komponenten

Beydeda

2006

Informatik Forsch. Entw.

View full text Add to dashboard Cite

show abstract

“…CBT is an important activity in CSD for developing reliable CB software. A major problem in CBT is the lack of adequate information about the component, which makes it a challenging task (Section 1.2) [44]. Different techniques that have been proposed for addressing these problems are discussed below.…”

Section: Related Workmentioning

confidence: 99%

“…Built-in testing (BIT) is a technique in which built-in tests are added in the component's code, to add support for testing the component [44]. BIT refers to all mechanisms that add information to a component's code for facilitating testing or checking assertions at runtime [17].…”

Section: Built-in Testingmentioning

confidence: 99%

See 1 more Smart Citation

A Model-Driven Framework for Context-Dependent Component Testing

Javed¹

View full text Add to dashboard Cite

A model-driven framework for context-dependent testing of components (MD-CDCT) is the outcome of this research. Component-based Software Development (CSD) is a process in which software applications are developed by reusing existing components. Primarily, this research devises a technique for evaluating and extending the test adequacy of a component for its reuse in a new context (system). Secondly, it uses the Model-Driven Architecture (MDA) in the context of component testing and CSD. MDA is an emerging approach for developing software applications from high-level models. In MDA, models at various levels of abstraction are used to automate software development and testing activities.When a general-purpose component is used in a new context, it needs to be thoroughly tested for that context. MD-CDCT models the usage of a component, in a context of interest, using usage scenarios and interaction diagrams. From these scenarios, test cases for performing CDCT are automatically generated using a model-driven tool. We then evaluate and extend the adequacy of the generated test cases by comparing them with the test cases that were executed during This approach is novel in that it applies the emerging MDA technology to contextdependent testing of components. The proposed framework benefits from the advantages of an MDA-based approach, such as portability, interoperability and maintainability. Another novelty is the use of test cases, which are executed during component testing, to evaluate and extend the adequacy of component testing. We have developed two prototype tools (a tool for test case execution, and a tool for test suite comparison) to provide tool support for this approach.Five case studies are used to illustrate and evaluate the MD-CDCT. The first is a simulation of a Vending Machine system. This case study illustrates the application of MD-CDCT. The second is a simulation of an ATM system. This case study shows how to generate test cases from software models by making use of the model transformation technology. The third and fourth case studies show how the comparison of test suites can be used to evaluate and extend their test adequacy. The final case study evaluates the framework and the prototype tool support on a non-trivial system, which is Lucene (a search engine).iii

show abstract

Software Testing: Testing New Software Paradigms and New Artifacts

Muccini

2008

Wiley Encyclopedia of Computer Science and Engineering

View full text Add to dashboard Cite

Software testing research is continuously moving toward different challenges and obstacles driven by different forces. What we believe are two main forces that drive software testing evolution are the progress in software development paradigms and languages, and the artefacts along the software development process to be used for testing purposes. Based on this specific perspective, this work provides an ample presentation of issues and assessments related to testing software. Ongoing and (expected) future research directions on software testing are also outlined.

show abstract

State of the art in testing components

Cited by 34 publications

References 17 publications

STECC: Selbsttestende Software-Komponenten

STECC: Selbsttestende Software-Komponenten

A Model-Driven Framework for Context-Dependent Component Testing

Software Testing: Testing New Software Paradigms and New Artifacts

Contact Info

Product

Resources

About