Integrations- und Funktionstests im Rahmen des V-Modelles Aufgaben Teile von Software werden integriert und anschließend getestet Ziele Auffinden von Fehlern durch Integration tut das Programm was es soll tut das Programm nicht was es nicht soll Überprüfen des Verhaltens unter geänderten (extremen) Bedingungen Überprüfung der Effizienz durch benchmarking Vergleich der Ergebnisse mit erwartetem Verhalten (Realität) Test im Rahmen des V-Modells Anforderungs- definition Anwendungsszenarien Abnahmetest Testfälle Grobentwurf System / Funktionstest Feinentwurf Testfälle Annäherung an Objekte von a. Erfahrung aus Technik b. Ansätze aus SE c. Ansätze aus Common Sense oder Philosophie Daraus ableiten: Basiseigenschaften von Objekten und Beschreibung durch UML Integrations- test Testfälle Modulimple- mentation Modul/ Einzeltest

Verfolgung von Anforderungen In objektorientierten Softwareentwicklungen kann Durchgängigkeit und Transparenz zwischen den Phasen Analyse, Entwurf und Implementierung erreicht werden. An den Phasenübergängen werden Verfeinerungen, Ergänzungen und Präzisierungen des Systems vorgenommen. Diese Durchgängigkeit bezieht aber leider nicht die Anforderungsdokumente mit ein. Schon nach der Umsetzung der Anforderungen in Use-Cases ist eine Verfolgbarkeit innerhalb der UML nicht mehr gewährleistet, da in den anderen UML Diagrammen keine Bezüge zu den eigentlichen Anforderungen möglich sind. Aus diesem Grund ist es in der Regel nicht möglich, einen Zusammenhang zwischen objektorientierten Strukturblöcken (z. B. Klassen und Operationen) und den Anforderungen, denen sie dienen, herzustellen. Man kann hier vom Use-Case-Bruch sprechen. Es ist daher sinnvoll schon zusammen mit den Use-Cases festzulegen, welches die Kriterien für ihre Erfüllung sind, wie dies nachgewiesen wird und was passiert, wenn Änderungen in den Anforderungen nötig sind.

Integrations Tests Überprüfung des fehlerfreien Zusammenwirkens von Softwarebausteinen Vorraussetzung: Jeder Baustein wurde in Unit Test überprüft, so dass die Integrationstests der Überprüfung der Schnittstellen und des Zusammenwirkens über Schnittstellen dienen können White Box Test Integration der Softwarebausteine inkrementel: incremental Testing Test vereinfacht sich, wenn Teile einen möglichst grossen inneren Zusammenhang haben (cohesion) Zahl der Aufrufe und der auszutauschenden Parameter möglichst klein ist (low coupling)

Integrationsteststrategien „Big Bang“-Strategie: Alle Teile sofort integrieren und nur als Gesamtheit testen Lokalisierung von Fehlern schwierig Arbeitsteilung kaum möglich Testen beginnt zu spät „Top-down“-Testverfahren: Zuerst A mit Dummies für B, C und D; dann B mit Dummies für E und F, ... Erstellung „vernünftiger“ Dummies schwierig Test der Basisschicht sehr spät „Bottom-Up“-Testverfahren: Zuerst E, F, G und H mit Testtreibern, die Einbindung in B, C und D simulieren; dann B, C und D mit Testtreiber ... Test des Gesamtverhaltens des Systems gegen Lastenheft erst am Ende Designfehler und Effiziensprobleme werden oft erst spät entdeckt

Testabdeckung

Funktionstests Ziel des Funktionstests ist es, festzustellen, ob das Software-Produkt alle in der Produkt-Definition festgelegten funktionalen Anforderungen erfüllt. Die dazu notwendigen Testsequenzen werden gewöhnlich aus dem Pflichtenheft übernommen oder aus dem System-Modell abgeleitet. Soll die Funktion von Simulationsprogrammen getestet werden, so gilt es einen Raum von Eingabewerten auf einen Raum von Ausgabegrössen abzubilden. Beide Räume sind oft hochdimensional und die darin enthaltenen Grössen repräsentieren kontinuierliche Verläufe. Häufig ist die Abbildung so komplex, dass ihr Ergebnis nicht einfach vorhergesagt werden kann. Neben dem Test auf Softwarefehler ist daher auch ein Test auf Modellierungsfehler nötig. Da Modellierungsfehler aber typischerweise in der Anforderungsphase entstehen, ist ihre Behebung in der Integrationsphase sehr aufwendig.