Im Integrationstest werden die Abhangigkeiten zwischen den Bausteinen eines Softwaresystems getestet. Die grose Anzahl Abhangigkeiten heutiger Systeme stellt fur die beteiligten Rollen des Integrationstests eine grose Herausforderung dar. Die vorliegende Promotionsarbeit stellt neue und innovative Ansatze vor, um diese Rollen zu unterstutzen. Im ersten Teil der Arbeit wird ein Testprozess definiert, der die spezifischen Eigenheiten des Integrationstests berucksichtigt. Der definierte Integrationstestprozess setzt dabei seinen Schwerpunkt auf die im Prozess zu treffenden Entscheidungen. Er beschreibt, welche Entscheidungen in welcher Reihenfolge von welcher Rolle getroffen werden und welchen Einfluss diese Entscheidungen auf weitere Entscheidungen besitzen. Im weiteren Verlauf der Arbeit werden neue Ansatze vorgestellt, die das Treffen von zwei Entscheidungen im Integrationstestprozess unterstutzen: die Testfokusauswahl und die Integrationsreihenfolge. Das Testen aller Abhangigkeiten ist aufgrund der Ressourcenbeschrankungen in realen Softwareprodukten nicht moglich. Die wenigen verfugbaren Ressourcen mussen daher fur das Testen der fehleranfalligen Abhangigkeiten eingesetzt werden. Fur das Identifizieren der fehleranfalligen Abhangigkeiten, und somit fur die Testfokusauswahl, stellt die Promotionsarbeit einen neuen Ansatz vor. Der Ansatz verwendet Informationen uber die Fehleranzahl von Bausteinen und die Eigenschaften von Abhangigkeiten aus fruheren Versionen der zu integrierenden Software, um statistisch signifikante Zusammenhange zwischen den Eigenschaften und der Fehleranzahl aufzudecken. Diese Zusammenhange werden in der aktuellen Version ausgenutzt, um den Testfokus, d.h. die zu testenden Abhangigkeiten, auszuwahlen. Im Integrationstest werden Bausteine schrittweise zu einem Gesamtsystem zusammengesetzt, um die Lokalisation der Fehlerursache beim Auftreten eines Fehlers zu erleichtern. Der Nachteil dieses schrittweisen Vorgehens ist, dass Bausteine, die noch nicht integriert, aber fur das Ausfuhren der Tests notwendig sind, simuliert werden mussen. Das Ziel ist es daher, eine Integrationsreihenfolge zu ermitteln, die einen minimalen Simulationsaufwand bedeutet. Zusatzlich sollten Abhangigkeiten, die als Testfokus ausgewahlt wurden, fruhzeitig integriert werden, um eventuelle Fehler fruhzeitig aufzudecken. In dieser Promotionsarbeit wurde der erste Ansatz entwickelt, eine Integrationsreihenfolge zu ermitteln, die sowohl den Testfokus als auch den Simulationsaufwand berucksichtigt. Die in der Arbeit entwickelten Ansatze wurden in Fallstudien mit mehreren realistisch grosen Softwaresystemen evaluiert.

The integration testing process aims at uncovering faults within dependencies between the components of a software system. Due to the lack of resources, it is usually not possible to test all dependencies. Fault prone dependencies have to be selected as test focus. This test focus has to be considered during the stepwise integration of the whole software system. An integration test order strategy has to devise an integration order that integrates dependencies selected as test focus in early integration steps. Furthermore the strategy has to minimize the effort to simulate not yet integrated components of the software system. Current approaches only focus on the reduction of the simulation effort, but do not take into account the test focus. This paper introduces an approach to determine an optimal integration testing order that considers both, the test focus and the simulation effort. The approach is applied to nine real software systems and the results are compared to six approaches.

Considering that testing a software system completely is not possible, the main task of a test team is to decide which parts of a system should be tested in which way. The numerous decisions are usually made implicitly during the testing process. However, awareness of these decisions increases their quality, by forcing the decision-makers to search for alternatives and to trade off between them. In this technical report we propose a decision hierarchy for the testing process. This hierarchy comprises the decisions made during testing and reflects dependencies among them. These decisions can be assigned to several decision levels as well as to different roles involved in the testing process, resulting in a decision hierarchy. The decision hierarchy and the identified decisions can be applyied in different contexts. In this report, we additionally present the results of four case studies to which we applied this decision hierarchy.

Existing software systems consist of thousands of software components realizing countless requirements. To fulfill these requirements, components have to interact with or depend on each other. The goal of the integration testing process is to test that the interactions between these components are correctly realized. However, it is impossible to test all dependencies because of time and budget constraints. Therefore, error-prone dependencies have to be selected as tests. This paper presents an approach to select the test focus in the integration test process. It uses dependency and error information of previous versions of the system under test. Error-prone dependency properties are identified by statistical approaches and used to select dependencies in the current version of the system. The results of two case studies with real software systems are presented.

Im Integrationstestprozess werden Bausteine eines Softwaresystems schrittweise zusammengesetzt und deren Abhangigkeiten untereinander getestet. Die grose Anzahl Abhangigkeiten heutiger Systeme macht es unmoglich, alle Abhangigkeiten zu testen. Tester mussen sich daher auf die fehlerhaften Abhangigkeiten fokussieren. In diesem Beitrag stellen wir einen Ansatz vor, der Informationen uber Abhangigkeitseigenschaften nutzt, um den Testfokus fur den Integrationstest festzulegen. Der Ansatz umfasst eine Liste von Eigenschaften, um Abhangigkeiten zu klassifizieren. Daruber hinaus gibt er eine Methode vor, um mit Hilfe von Fehlerdaten fruherer Versionen eines Softwaresystems sowie deren Eigenschaften fehlerhafte Abhangigkeiten zu identifizieren. Evaluiert wurde der Ansatz mit Hilfe der Entwicklungsumgebung Eclipse.

Software processes often focus on artifacts, activities and roles, treating decisions to be made during the software development process only implicitly. However, awareness of these decisions increases their quality by forcing the decision-makers to search for alternatives and to trade off between them. In this paper, we propose a decision hierarchy for the testing process. This hierarchy comprises all decisions made during testing and reflects dependencies between them. Additionally, we present the results of four case studies to which we applied this decision hierarchy.

Zahlreiche wissenschaftliche Arbeiten thematisieren die Ableitung von Testfallen aus Anforderungen, insbesondere aus Use Cases. Die entwickelten Methoden werden jedoch nur selten in Anforderungsmanagementoder Testwerkzeugen integriert. In dieser Arbeit stellen wir einen leichtgewichtigen semi-formalen Ansatz vor, der die automatische Ableitung von Testfallen aus Use Cases ermoglicht und leicht in bestehende Anforderungsmanagementwerkzeuge integriert werden kann. Hierbei werden logische Testfalle aus Use Cases unter Berucksichtigung des Kontrollflusses und der vom Use Case verarbeiteten Daten und ihrer Bedingungen abgeleitet.

Softwareprozessbeschreibungen konzentrieren sich auf Artefakte, Aktivitaten und Rollen, lassen aber die im Prozess zu treffenden Entscheidungen meist implizit. Dies beeintrachtigt die Qualitat dieser Entscheidungen erheblich. In dieser Arbeit stellen wir eine Entscheidungshierarchie fur den Testprozess vor. Sie umfasst die Entscheidungen des Testprozesses und spiegelt Abhangigkeiten zwischen diesen wieder. 1 Einleitung Um festzustellen, in welchem Mase ein entwickeltes System die gestellten Anforderungen erfullt, sind Testaktivitaten unverzichtbar. Da vollstandiges Testen nicht moglich ist [Me79], mussen Entscheidungen daruber getroffen werden welche Teile des Systems wie zu testen sind. In den Testaktivitatsbeschreibungen, z.B. in [SLS06], werden Testentscheidungen allerdings nicht explizit fokussiert. Das Bewusstsein uber die zu treffenden Entscheidungen kann die Qualitat der Testprozessdurchfuhrung erheblich erhohen, da getroffene Entscheidungen die nachfolgenden Aktivitaten beeinflussen. Dieses Treffen von Entscheidungen setzt weiterhin (Test-)Aktivitaten und deren Artefakte voraus. In dieser Arbeit werden Entscheidungen identifiziert, die im Rahmen des Testprozesses getroffen werden. Dabei konzentrieren wir uns auf die Entscheidungen, die den dynamischen Test betreffen. Jede dieser Entscheidungen kann einer Entscheidungsebene zugeordnet werden, wodurch eine Entscheidungshierarchie entsteht. 2 Entscheidungshierarchie Die Entscheidungshierarchie basiert auf Prozessbeschreibungen in [SLS06], [BSC00], [IEEE98], [MP02] und lasst sich in drei grose Bereiche unterteilen. Auf den oberen Ebenen (Spezifikationsebene, Testzielebene) entscheiden Testdesigner und Testmanager, welche Teile des Softwaresystems getestet werden (was). Auf den drei nachfolgenden Ebenen wird vom Testdesigner, Tester und Testmanager festgelegt, wie diese Teile zu testen sind. Auf den abschliesenden zwei Ebenen (Testlaufebene, Testauswertungsebene) wird entschieden, welche Qualitat die zu prufende Software hat.

Students learning software systems development at the University of Heidelberg follow the TRAIN process. This tool supported process emphasizes the early phases of software development by combining different activities and artefacts such as requirements engineering, quality assurance as well as graphical user interface and system design. By the use of TRAIN students are being enabled to finish large software projects. TRAIN focuses especially on various decisions (rationales) in the development process and on several quality assurance activities like testing or inspection. This paper gives a short overview of the TRAIN–process, how it is taught in software engineering courses and how it is supported by a tool called Sysiphus.

Runtime testing is important for improving the quality of software systems. This fact holds true especially for systems which cannot be completely assembled at development time, such as mobile or ad-hoc systems. The concepts of built-in-test (BIT) can be used to cope with runtime testing, but to our knowledge there does not exist an implemented infrastructure for BIT. The MORABIT project realizes such an infrastructure and extends the BIT concepts to allow for a smooth integration of the testing process and the original business functionality execution. In this paper the requirements on the infrastructure and our solution are presented

Fur einen effizienten Einsatz von Qualitatssicherungsmasnahmen ist die Kenntnis uber die haufigsten Fehlerursachen entscheidend. Dieser Artikel beschreibt die Ergebnisse einer Online-Umfrage zu Fehlerhaufigkeiten in objektorientierten Systemen. Die Umfrage wurde vom GI-Arbeitskreis „Testen objektorientierter Programme“ im Zeitraum vom 19. August bis 31. Oktober 2005 durchgefuhrt. Die Fragebogen wurden von 1219 Teilnehmern ausgefullt.

Software engineering courses often use industrial modeling tools for their infrastructure, as it exposes students to the state-of-the practice and increases their awareness about the complexity of their craft. However, this approach has the risk of expending a disproportionate amount of effort on tools as opposed to teaching concepts. Moreover, industrial tools often do not include didactic concepts needed for education. In this paper, we discuss our experience with an integrated, rationale-based modeling tool in a variety of software engineering courses. By providing an integrated modeling environment, students use a single tool for requirements, system design, test planning, and collaboration. By attaching rationale to the models, students are encouraged to reflect on their work while instructors can monitor them and provide more insightful feedback

Using components in building software systems is a popular approach in software engineering. Testing component based systems (CBS), however is still a challenging task. Additional problems arise, if the tested CBS is a mobile system. Mobile systems offer more challenges, because their structure is dynamic: Components may be added or removed at any time. Thus, testing is required at run time. In this paper we present criteria that a testing approach of mobile CBS has to satisfy. We investigate to what extent common CBS testing approaches fulfill these criteria: For each approach we explore how the particular test steps (test cases, test inputs and test oracles) are created or generated. Although many approaches introduced in the literature assume that testing is needed only at deployment time, we found many interesting features that can be applied in testing mobile CBS, but no existing approach can be