Was Sie schon immer über das Testen wissen wollten

21.08.2006 | Autor / Redakteur: (mh) / Martina Hafner

Bild 1: Die Parameter und Abläufe der Testfälle werden aus der Anforderungsspezifikation abgeleitet.
Bild 1: Die Parameter und Abläufe der Testfälle werden aus der Anforderungsspezifikation abgeleitet.

Haben Sie Ihre Produkte ausreichend getestet? Sind Sie sicher, dass Sie im Fall der Fälle nachweisen können, dass Sie alle notwendigen Maßnahmen ergriffen haben, um einen Schaden zu verhindern? Wenn Sie jetzt ins Grübeln kommen, lohnt es sich, weiter zu lesen.

Es gibt kaum ein Thema, bei dem schneller ein Gefühl der Unbehaglichkeit in Unternehmen entsteht, als beim Thema Testen. Doch das muss nicht sein. Durch kompetente Information, Beratung und Ausbildung oder durch Kooperation mit Spezialisten werden die Risiken schnell greifbar und damit auch beherrschbar. Einen Beitrag liefert diese dreiteilige Serie, die einige wichtige Themen aus einem Training der Firma MicroConsult zum Thema Test zusammenfaßt. Teil 1: Testen beginnt beim Projektstart.

Bereits in dem frühen Projektstadium der Anforderungsanalyse entscheidet sich, ob ein Produkt durch Tests schnell zur Marktreife gelangen kann. Je genauer dort formuliert ist, was ein System können soll und was nicht, desto klarer umrissen sind damit bereits die späteren Aufgaben der Tester. Die Anforderungsanalyse beschreibt ein System mit Ein- und Ausgaben, außerdem seine Umgebung und die Randbedingungen, unter denen es betrieben wird. Aus dieser Analyse resultiert die Anforderungsspezifikation, die den Kontext des Systems darlegt, also was es zu tun hat (funktional) und welche Qualitäten es dabei erfüllen muss (nichtfunktional).

Mehr Durchblick mit grafischen Modellen

Meist werden heute Anforderungen tabellarisch und textuell erfaßt. Grafische Modelle helfen dabei komplexe Zusammenhänge besser zu verstehen, gerade wenn räumliche Strukturen und zeitliche Zusammenhänge beschrieben werden. Die Spezifikation lässt sich z.B. gut mit der UML erweitern, um primär abzusichern, ob eine Anforderungen plausibel ist. Die UML-Diagramme dienen dazu, Spezifikation zu verfeinern und helfen dem Ersteller, tiefer in das System einzudringen. Ein Beispiel dafür ist das Sequenzdiagramm, das dafür prädestiniert ist, Abläufe zwischen dem System und seiner Außenwelt darzustellen. Schon wenn die Anforderungsspezifikation formuliert werden sollte der Tester sein leider häufig unterschätztes Lösungswissen einbringen können, unter anderem, damit das spätere System auch praktisch testbar ist.

Dem Fehler auf der Spur

Nachdem die Anforderungen an die Funktionen spezifiziert wurden folgt die Fehleranalyse, die sich mit möglichen Problemen beschäftigt, wie sie Akteure im System verursachen könnten. Daraus werden später Tests oder Testsequenzen abgeleitet, die überprüfen, wie robust ein System gegenüber äußeren Einflüssen ist. Beispielsweise kann die Fehleranalyse zu dem Ergebnis führen, dass Ein- und Ausgaben redundant ausgelegt sein müssen, weil das System sicherheitskritisch ist. Damit soll gewährleistet werden, dass es im Fehlerfall minimal eingeschränkt oder ohne Funktionseinbußen weiterarbeitet.

Aus der fertigen Anforderungsspezifikation lassen sich im nächsten Schritt bereits konkret Tests und Prüfungen ableiten. Der Tester sucht dabei nach Testfällen, mit denen er das Verhalten seines Prüflings in bestimmten Situationen untersucht: Verhält er sich gemäß den spezifizierten Vorgaben und Sollwerten?

Testfälle setzen sich aus Parametern und Abläufen zusammen. Parameter können gültig oder ungültig gesetzt sein, so dass sich durch geschickte Parametrisierung mehrere Testfälle generieren lassen. Der Prüfer betrachtet dafür die Grenzen des Systems, also welche Ein- und Ausgangssignale die Aktoren und Sensoren liefern. Außerdem bezieht er Schnittstellen und Protokolle mit in die Überlegung ein. Für die Testabläufe betrachtet er Anwendungsfälle, Abläufe, Zustandsautomaten und ebenfalls wieder die Protokolle.

Externe und interne Qualitätsmerkmale

Die Parameter und Abläufe der Testfälle leiten sich aus der Anforderungsspezifikation ab. Dabei muss im Hinblick auf die nichtfunktionalen Anforderungen unterschieden werden: Externe Qualitätsmerkmale wie Zuverlässigkeit lassen sich beispielsweise durch Dauertests untersuchen, bei denen der Prüfling die geforderte Ausfallrate erfüllen muss. Für die Zeitanforderungen muss er eine bestimmte Aufgabe in einer bestimmten Zeit abarbeiten, die der Tester den Sequenzdiagrammen der Anforderungsanalyse als Sollwert entnimmt.

Problematisch gestaltet sich dagegen der Test interner Qualitätsmerkmale wie der Übertragbarkeit. Hier müsste der Tester das System auf unterschiedliche Hardware-Plattformen portieren, was aus Zeit- und Kostengründen praktisch nicht zu realisieren ist. Deshalb beschränkt er sich auf Prüfungen, betrachtet beispielsweise, was an der Systemarchitektur geändert werden muss, damit sich ein System von Prozessor A nach Prozessor B portieren lässt. Prüfungen sind immer dann die erste Wahl, wenn ein System nicht im realen Betrieb getestet werden kann.

Als Prüfmethoden gelten typischerweise Reviews und statische Analysen, wie beispielsweise mit Compiler oder LINT. Prüfungen sind eher allgemein und übergreifend ausgelegt, während Tests exakt ablaufen und konkretere Ergebnisse liefern.

Gute Planung ist die halbe Miete

Die übergreifende Sicht des Managements spiegelt der Testplan wider, weil er sich als Grobgerüst auf eine Beschreibung der Funktionalitäten und den Testzeitraum beschränkt. Auf seiner Basis kann die spätere Testspezifikation Details festlegen, beispielsweise welches Feature mit welchem Testfall auf den Prüfstand gestellt wird.

Der Testplan betrachtet das System als Gesamtheit und legt fest, wann es seine Marktreife in Bezug auf Funktionalität und Robustheit erreicht hat. Um verbindlich zu sein muss er von allen internen Verantwortlichen unterzeichnet werden. Eine praktikable Gliederung für den Plan liefert die Norm IEEE829, die beispielsweise den Sinn des Tests, den Prüfling samt Komponenten und Funktionalitäten, aber auch nicht zu testende Funktionen berücksichtigt, die Aufwand und Kosten unnötig in die Höhe schrauben würden.

Der Testplaner entwickelt die Strategie vorwiegend auf Basis von Qualitätsmerkmalen, Komponenten, Produktrisiken und zu erreichenden Meilensteinen. Dabei sollte er den Teststart so früh wie möglich im Entwicklungsprozess ansetzen, da die Problembeseitigung mit fortschreitendem Projektverlauf immer teurer und zeitintensiver wird. Außerdem benötigen Tester ausreichend Vorlaufzeit für die Vorbereitung der Testfälle.

Auch die Testausführungen sind im Plan zu nennen. Die Praxis zeigt, dass Entwickler und Tester häufig ein- und dieselbe Person sind, was die Gefahr birgt, dass diese „betriebsblind“ und emotional an das Produkt gebunden ist. Aussagekräftiger sind deshalb meist Peer-to-Peer-Tests oder -Reviews, bei denen die Entwickler ihre Module gegenseitig testen. Im Idealfall können Unternehmen auf eine eigene Testabteilung oder spezialisierte Dienstleister wie MicroConsult zurückgreifen, die produktiver, weil fokussierter und objektiver arbeiten.

V-Modell als Referenz

Als Referenz für die Testplanung gilt heute z.B. das V-Modell. Das nacheinander abzuarbeitende V-Modell zeigt auf seinem absteigenden Ast die Workflows Anforderungsanalyse, Analyse, Design und Implementierung. Der aufsteigende Ast widmet sich ausschließlich den Bereichen Testen und Prüfen. Seine vier Workflows korrelieren dabei mit den gegenüberliegenden im absteigenden Ast, also beispielsweise der Abnahmetest mit der Anforderungsanalyse.

Das V-Modell bildet eine wichtige Grundlage für die Testplanung, berücksichtigt aber nicht die iterative Vorgehensweise.

Der Unit- bzw. Funktionstest beschäftigt sich mit einem Modul innerhalb beispielsweise eines C-Programms und prüft dessen Funktionsweise. Der Komponenten- bzw. Integrationstest fokussiert sich dagegen auf das Zusammenspiel der Module und Fehler in Schnittstellen, während der Systemtest das gesamte Produkt verifiziert und es gegen die Spezifikation prüft. Dem Kunden oder einem von ihm beauftragten Dritten obliegt schließlich der Abnahmetest. Hier steht normalerweise das Validieren im Vordergrund, wobei der Auftraggeber womöglich auch sicherstellen will dass, die Spezifikation eingehalten werden, und deshalb verifizieren möchte.

Den Schlusspunkt setzen

Wann ein Prüfling martkreif ist, definiert das Test-Endekriterium. Dies stellt den Planer nicht selten vor Probleme, da der Zeitdruck meist gegen Projektende immens wächst. Ein Endekriterium könnte sein, dass das System zehn Tage fehlerfrei unter 110% Last gefahren wurde. Jedem Testplaner ist bewusst, dass nie alles hundertprozentig prüfbar sein wird. Deshalb sollte er nach dem risikobasierten Ansatz vorgehen, sprich: Komponenten mit höherer Priorität werden bevorzugt auf den Prüfstand gestellt.

MicroConsult

Tel. +49(0) 89 45061771Teil 2: Testen im Detail

*Peter Siwon ist Geschäftsführer bei MicroConsult in München

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 181158 / Software-Test & -Betrieb)