Stefan Schmerler - Softwaretest in der Praxis

Die Geschichte der Softwareentwicklung seit Anfang der 1970er Jahre ist so umfangreich wie die Geschichte ihrer katastrophalen Fehler – wobei letztere sich sogar noch besser in Erinnerung halten.

1.1 Fehlerbegriff

Zu Beginn ist es wichtig, die Definition einiger Begriffe festzulegen, die im weiteren Verlauf dieses Buchs Verwendung finden. Allem voran natürlich der Begriff des Fehlers selbst.

Ein Fehler ist die nachgewiesene Nichterfüllung einer bekannten Anforderung, d. h. die Abweichung des Istverhaltens vom Sollverhalten einer Software.

Testbasis

Diese Abweichung kann natürlich nur dann ermittelt werden, wenn vorab das richtige Verhalten korrekt spezifiziert wurde. Man spricht in diesem Zusammenhang von der Testbasis, gegen die getestet wird.

Ein Fehler äußert sich in der Regel im Verhalten der Software, dabei unterscheidet man zwischen Fehlerwirkung und Fehlerzustand.

Unter Fehlerwirkung (auch Failure, Fehlverhalten, Fehler) versteht man die äußeren Anzeichen eines Softwarefehlers, die Ursache hingegen als Fehlerzustand (auch Defect, Fault, Bug) bezeichnet (DIN 66271).

»Ein Unglück kommt selten allein«, wie ein Sprichwort sagt. In der Tat zeigen Analysen, dass Fehler häufig aggregiert auftreten, d. h., wo ein Fehler aufgetreten ist, kann man mit höherer Wahrscheinlichkeit davon ausgehen, noch weitere Fehler zu finden. Unter Umständen verursacht die Behebung eines Fehlers auch erst die Wirkung eines weiteren Fehlers, der vorher bereits im Code enthalten war, durch den ersten Fehler allerdings nicht zur Wirkung kam. Man spricht von Fehlermaskierung.

Fehlerzustände können sich gegenseitig kompensieren oder überdecken. Eine Fehlerwirkung tritt dann erst nach Behebung der maskierenden Fehlerzustände zutage.

Ergebnisse klassifizieren:

False positive, false negative,

true positive, true negative

Nicht bei jedem Auftreten eines unerwarteten Verhaltens kann jedoch von einem Fehler des Testobjekts ausgegangen werden. Ein Missverständnis in der Spezifikation oder Fehler in der Testumgebung können ebenfalls in einem vermeintlichen Fehler resultieren. In diesem Fall spricht man von einem falsch positiven (false positive) Resultat. Wird umgekehrt ein vorhandener Fehler nicht entdeckt, obwohl ein entsprechender Test dafür vorliegt, haben wir ein falsch negatives (false negative) Resultat. Von einem richtig positiven (true positive) Ergebnis spricht man, wenn die Fehlerwirkung durch den Test gefunden wird und umgekehrt bedeutet ein richtig negatives (true negative) Resultat, dass ein erwartetes Verhalten des Testobjekts mit dem Test nachgewiesen werden konnte.

Ursachen für die Ent-

stehung von Fehlern

So wichtig wie das Auffinden von Fehlerzuständen ist die Kenntnis der Ursachen ihrer Entstehung. Beim ersten jemals dokumentierten Bug handelte es sich tatsächlich um eine Motte, die am 9. Sept. 1947 in Relay #70 des Panels F eines Mark-II-Computers in Harvard von zwei Relaiskontakten erschlagen wurde. Der erste Bug Report der Computergeschichte wurde daraufhin noch am selben Tag durch die Universitätsmitarbeiterin Grace Hopper erstellt und enthielt unter einem Klebestreifen die Fehlerursache.

der erste Bug Report der Computergeschichte (9. Sept. 1947)

nebst angeklebter Fehlerursache. Bild: Gemeinfrei/CC0

Inzwischen sind Fehlerursachen nicht mehr so gegenständlich und leicht zu finden. Insbesondere in der industriellen Softwareentwicklung belegen die Erfahrungen mehrerer Dekaden die folgenden Hauptursachen:

Zeitdruck

Der Zeitdruck in Projekten führt zu Nachlässigkeiten in der Softwareentwicklung.

Missverständnisse

Die Projektpartner besitzen unterschiedliches Verständnis über Sachverhalte, Aufgabenstellungen oder Anforderungen. Diese Missverständnisse führen oft zu Fehlern.

Komplexität

Größere Softwareprojekte benötigen aktive Maßnahmen zur Sicherstellung von Softwarequalität, z. B. eine stringente Architekturprüfung oder Einhaltung von Codierrichtlinien. Andernfalls entsteht ein Monolith, den kein Entwickler mehr versteht und ohne fehlerträchtige Seiteneffekte ändern oder erweitern kann.

Integration

Bei größeren Projekten, die die Integration vieler Komponenten erfordern, besteht auch in diesem Schritt großes Potenzial für Missverständnisse, da wiederum verschiedene Parteien über viele Sachverhalte ein identisches Verständnis besitzen müssen.

neue Technologien

Immer dann, wenn Entwicklungsprojekte einen Technologieschub erfahren, ist dies eine potenzielle Fehlerquelle. Neue Technologien müssen vor der korrekten Anwendung erst gut verstanden werden.

1.2 Testen von Software

Auch im Bereich des Testens gilt es, zuallererst einige Begrifflichkeiten zu definieren.

1.2.1 Testbegriff

Testen ist nicht Debuggen!

Hier wäre z. B. der Begriff des Debuggens, der oft fälschlicherweise synonym zu Testen verwendet wird. An dieser Stelle sei gesagt: Testen ist nicht Debuggen! Während Debuggen das Ziel hat, Fehlerzustände zu lokalisieren und zu beheben d. h. Fehler zu beseitigen, ist es Aufgabe des Tests, Verhaltensweisen (Fehlerwirkungen) aufzudecken, die auf Fehlerzustände hindeuten, d. h. Fehler zu finden.

Regressionstest

Nach einer Fehlerbeseitigungsmaßnahme ist über einen nachgelagerten Test noch zu verifizieren, dass zum einen der Fehler tatsächlich nicht mehr auftritt und zum anderen keine neuen Fehler durch die Maßnahme in den Code eingebracht wurden. Derartige Tests werden als Regressionstests bezeichnet.

die wichtigsten Ziele beim

Testen von Software

Ein Softwaretest kann unterschiedliche Ziele verfolgen und aus verschiedenen Motivationen heraus erfolgen. Die wichtigsten Testziele in der Praxis werden im Folgenden kurz dargelegt:

▶die Überprüfung, dass alle im Lastenheft beschriebenen Anforderungen funktional korrekt umgesetzt wurden,

▶die qualitative Bewertung verschiedener testrelevanter Dokumente wie Lastenhefte oder Quellcode,

▶die Begrenzung des aus einem schlechten Reifegrad resultierenden wirtschaftlichen Risikos,

▶die Analyse des Quellcodes und der assoziierten Dokumente, um Fehlerzustände zu vermeiden und vorhandene Defects zu beseitigen,

▶der Nachweis der Konformität der Software zu gesetzlichen, juristischen oder vertraglichen Standards und Anforderungen,

▶Freigaberelevante Informationen erhalten, z. B. für die nächste Integrationsstufe, oder um den Code in eine konsolidierte Release einzuchecken.

Testbewertung, System under Test

und Auffälligkeit

Ein Test ist eine stichprobenhafte Prüfung. Man führt das Testobjekt aus und untersucht, ob es sich korrekt verhält, z. B. durch Vergleich mit einer Spezifikation, aus der das gewollte Verhalten hervorgeht. Entsprechend wird der Test mit Pass/Fail bewertet. Stellt man ein abweichendes Verhalten des Testobjekts fest (oft auch System under Test bzw. SUT genannt), ist sich aber noch nicht sicher, ob Fehlverhalten oder z. B. ein Spezifikationsfehler, eine Spezifikationslücke oder gar ein Fehler im Testsystem vorliegt (der Umgebung, die den Test durchführt), spricht man bis zur eindeutigen Klärung auch neutral von Auffälligkeit. Die Durchführung dieser Klärung wird in aller Regel von Spezialisten der Fehleranalyse durchgeführt – dies kann auch der Entwickler selbst sein. Es ist dazu in jedem Fall tiefe Expertise erforderlich.

Das Testendekriterium - wann

kann man aufhören zu testen?

Der stichprobenhafte Charakter des Tests hat eine Reihe von Konsequenzen, die im Folgenden erläutert werden. Es gibt kein klar erkennbares, allgemeingültiges Kriterium für das Testende. Man testet oftmals so lange, bis das Vertrauen in die Software groß genug ist, um sie zum kommerziellen Einsatz zu bringen. Dies ist bei der Steuerungssoftware einer Kaffeemaschine sicher anders als bei der Kühlelektronik eines Kernkraftwerks oder der Klappensteuerung eines Flugzeugs. Andererseits muss man sich immer im Klaren darüber sein, dass auch Kaffeemaschinen in hohen Stückzahlen produziert werden. Wird ein kapitaler Fehler erst beim Kunden entdeckt, entstehen bei einfachen, aber in hohen Stückzahlen gefertigten Systemen sehr schnell ganz erhebliche Garantiekosten. Der Aufwand, den man bei einer Softwareentwicklung in den Test investieren sollte, hängt also vom möglichen Fehlerschaden und dessen Eintrittswahrscheinlichkeit ab. Doch dazu später mehr.