SW-Test

1. Einführung Testen von Software

Ob HW, SW, Server-Installationen oder gar Haus- oder Brückenbau: Das Testen der Lieferung ist eine Arbeit, die ein hohes Mass an Konzentration, Aufmerksamkeit und Zuverlässigkeit verlangt.
Die Testfälle müssen vollständig, eindeutig und für einen Dritten zu 100% nachvollziehbar sein.

• Etwas das gut bis sehr gut ist und/oder lange hält
• Gute Preis/Leistung
• Funktionsvielfalt, Verarbeitung
• Markenname der für gute Qualität bürgt
• Garantiedauer
• Verständliche und vollständige Bedienungsanleitung
• Nachhaltigkeit, Ökologische Herstellung und Entsorgung
• Haltbarkeit
• Sicherheit
• Design
• weiteres...

In verschiedenen Normen wird die Qualität beschrieben oder definiert. Als Beispiel die Begriffsdefinition aus DIN 55 350:
Qualität = Die Gesamtheit von Eigenschaften eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse beziehen.

Qualität von Software

Die wichtigsten Qualitätsmerkmale sind in Normen wie der DIN/ISO 9126 geregelt. Gelten bei einem Softwareauftrag/Produkt für ein Grossprojekt andere Qualitätsmassstäbe? Dazu ein Fallbeispiel:

Was kann der Kunde erwarten, wenn er ein Softwareprodukt wie z.B. eine Textverarbeitung kauft?

• Zuverlässigkeit (Reliability): Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren.
  Office bearbeitet beliebig komplexe Dokumente gleich.
  Ohne Absturz. (mit/ohne Fehlmanipulation)
• Funktionalität (Functionality): Vorhandensein von Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen.
  Office besitzt alle in der Dokumentation angegebenen (nützlichen) Funktionen.
• Benutzbarkeit (Usability): Aufwand, der zur Benutzung erforderlich ist, und individuelle Beurteilung der Benutzung durch eine festgelegte oder vorausgesetzte Benutzergruppe.
  Office lässt sich intuitiv erlernen und benutzen. (Benutzerführung, klare Fehlermeldung)
• Effizienz (Efficiency): Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen.
  Office erledigt alle Funktionen in angemessener Zeitspanne. (Reaktionszeit)
  Flüssiges Arbeiten möglich, Applikation ist möglichst resourcenschonend.
• Änderbarkeit (Maintainability): Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist. Änderungen können Korrekturen, Verbesserungen oder Anpassungen an Änderungen der Umgebung, der Anforderungen und der funktionalen Spezifikationen einschliessen.
  Office lässt sich einfach konfigurieren oder erweitern. (Plug ins) 
  Für die Programmierer gilt: Klare Strukturierung, bessere Wartbarkeit.
• Übertragbarkeit (Portability): Eignung der Software, von einer Umgebung in eine andere übertragen zu werden. Umgebung kann organisatorische Umgebung, Hardware- oder Software-Umgebung einschliessen.
  Office lässt sich auf Windows, Mac, Smartdevices etc. installieren oder aber auch cloud-basiert ausführen.

Auswirkungen von Fehlern

In der Praxis können sehr kleine Fehler sehr grosse Konsequenzen haben:

• Systemabstürze. Kann auch andere Programme betreffen und kommt für den SW-Lieferanten dem GAU sehr nahe. Bei Powershell: Rote Fehlermeldungen
• Programmabbrüche
• Datenverfälschung - Anomalien (siehe auch M104)
• Falsches Systemverhalten
• Prestigeverlust des SW-Firma
• Frustrierte Benutzer/Kunden
• usw.

Ob ein vorhandener Fehler die Verbreitung einer neuen Version, die Verteilung eines Patches oder eventuell auch keine Massnahme erfordert, ist von einer Vielzahl von Kriterien anhängig. Die Folgen und Kosten von Fehlern hängen stark von der Art des Einsatzes eines Produktes ab:

• Massenprodukt (grosse Anzahl Anwender, die dem Hersteller nicht direkt bekannt sind)
• Individuelle Software (kleiner Anwenderkreis mit Integration in den Entwicklungsprozess)
• Einsatz in einem sicherheitsrelevanten Bereich mit potentiellem Personenschaden, Materialschaden oder finanziellem Verlust. (Spital, technische Anlagen, Finanzsysteme usw.)

Fehlerarten

Es ist also wichtig zu ermitteln, wo welche Fehler entstehen können. Abgesehen von Syntaxfehlern, die bei der Übersetzung eines Programms automatisch erkannt werden und von Laufzeitfehlern, die unmittelbar zum Absturz führen, gibt es weitere Fehlerarten, die meist schwieriger aufzufinden sind:

• Codierfehler (z.B. bei Zeichencodierung)
• Logikfehler (z.B. bei Entscheidungen if-else, switch etc.)
• Strukturfehler (z.B. bei Iterationen, while, do-while, for)
• Entwurfsfehler (z.B. Realität in SW falsch abgebildet)
• Datenfehler (z. B. char/integer; Array falsch definiert; int32 anstatt int64; Jahr 2000 Problematik)
• Umsetzungsfehler (von der Spezifikation/Pflichtenheft ins Programm)
• Fehler in der Benutzeroberfläche (bei GUI oder sonstiger Benutzerinteraktion)

1.1 Analytische Qualitätssicherung zur Vermeidung von Fehlern

Testgrundlagen

Unter Qualitätssicherung versteht man die Summe aller Massnahmen, die die Qualität des entstehenden Produktes gewährleisten sollen. Im Softwarebereich wird unter der analytischen Qualitätssicherung der Test von Software und Dokumentation verstanden. Durch den Test wird das Ziel verfolgt, Fehler aufzudecken. Jeder gefundene und beseitigte Fehler führt zu einer Produktverbesserung.

Testaktivitäten und Testplanung

Die Testaktivitäten können nicht erst kurz vor Schluss in Angriff genommen werden. Das Testen von Software muss geplant sein, nimmt es doch bei grossen Projekten ca. 10% bis 15% der gesamten Projektzeit in Anspruch.

Es gibt für das Durchführen von Testaktivitäten einige Prinzipien, die sich in der Praxis bewährt haben:

• Fehler möglichst frühzeitig aufdecken: Das heisst, ein Test sollte frühzeitig und entwicklungsbegleitend erfolgen, um Fehlerauswirkungen und Folgefehler zu minimieren.
• Aus Fehlern lernen und sie zukünftig vermeiden: Das heisst, Fehlerursachen sind zu analysieren, um Hinweise für eine zukünftige Fehlervermeidung zu erhalten.
• Bei komplexen Testobjekten unabhängige Tests durchführen: Das heisst, um der Zielsetzung des Testens (Fehleraufdeckung) gerecht zu werden, sollen vor allem bei komplexen und wichtigen Produkten unabhängige Tester eingesetzt werden.
• Testziele erreichbar und messbar formulieren: Das heisst, dass überprüfbare Ziele (z.B. Forderungen über auszuführende Testfälle) für den Test formuliert werden sollten. Das Testende ist erreicht, wenn die zuvor aufgestellten Testziele erreicht werden.
• Testfälle professionell handhaben: Das heisst, die Testfälle sind zu speichern und für spätere Testwiederholungen (Regressionstests) verfügbar zu machen.
• Testaktivitäten planen: Das heisst, ohne Planung werden Testaktivitäten unsystematisch und im Wortsinne "ungeplant" durchgeführt. Die Testplanung ist in die Projektplanung zu integrieren.
• Testaktivitäten dokumentieren: Das heisst, nur durch Dokumentation ist Transparenz und Revisionssicherheit der Tests gewährleistet. Zur Testdokumentation gehören Testpläne, Testspezifikationen, Testfallbeschreibungen, sowie Test- und Fehlerprotokolle.

Testarten und Zeitpunkte

In der SW-Entwicklung werden während den verschiedenen Entwurfsphasen Vorgaben für die Tests der entsprechenden Ebenen spezifiziert. Bei der Umsetzung werden die Tests dann durchgeführt und entscheiden über den Fortgang der weiteren Entwicklung:

Systematische Tests

Zur Durchführung systematischer Tests wird in der Regel ein Testplan (Protokoll) erstellt. Dies kann bereits in der Design-Phase (Planung) geschehen. Dabei erfolgt die Aufteilung nach Fehlerkategorien. Die Durchführung dieser Tests kann je nach Entwicklungsumgebung von Debuggingtools oder speziellen Testsuiten unterstützt werden.

Datenfehler erkennen:

• Eingabenprüfung (Richtige und falsche Werte und Typen)
• Extremwerte prüfen (z.B. negative Zahlen, sehr grosse und sehr kleine Zahlen)
• Ausgabenprüfung (Verwendung von Testdaten)
• Erzeugt durch Testdaten-Generator (speziell entwickeltes Programm)
• Daten aus der Vergangenheit/aus dem existierenden Umfeld (evtl. mit bekannten Ergebnissen)

Strukturfehler erkennen:

• Pfadanalyse allgemein (Traces)
• Definieren kritischer Pfade

Statische Methoden: (Bei den statischen Methoden wird der Programmcode nicht ausgeführt. Das heisst, die Programmzeilen werden visuell nach bestimmten Kriterien untersucht.)

• Audit
• Inspektion
• Code-Review
• Walkthrough

Dynamische Methoden: (Bei den dynamischen Testmethoden wird die Software gestartet und nach bestimmten Testkriterien durchlaufen.)
Es gibt einige Grundsätze für die Testfallermittlung:

• Die Testfälle sollen minimalistisch sein. D.h dass zur Aufdeckung eines bestimmten Fehlers möglichst nur ein Testfall gebraucht wird.
• Die Testfälle sollen so zusammengestellt werden, dass das gesamte Testobjekt abgedeckt wird.
• Die Testfälle sollen nicht nur den Normalfall abdecken, sondern insbesondere auch Grenzfälle und Ausnahmesituationen testen.

White-Box Testmethode
Bei der White-Box-Methode werden die Testfälle mit Kenntnis der internen Strukturen des Testobjekts (Source-Code) entwickelt, d.h. diese Methode kann nur von Entwicklern eingesetzt werden. Der laufende Test beim Programmieren ist ebenfalls ein White-Box- Test. Die meisten Entwicklungsumgebungen stellen dazu umfangreiche Tools zur Verfügung (DEBUG), es sind aber auch eigenständige Applikationen für White-Box- Tests auf dem Markt erhältlich.

Black-Box Testmethode
Bei dieser Methode werden die Testfälle aus der vorliegenden Spezifikation (z.B. Pflichtenheft) oder aber aus der Oberflächenstruktur (z.B. Erfassungsmasken, GUI) hergeleitet. Die innere Struktur des Objektes wird nicht berücksichtigt und kann unbekannt sein. Diese Testmethode kann also auch vom Anwender durchgeführt werden.

2. Informelles Testen mit einem Debugger

Unter Debuggen versteht man das informelle Testen eines Quellcodes durch den SW-Entwickler. Das geschieht laufend während dem SW-Entwicklungsprozess. Da Programmierer und Tester dieselbe Person sind, ist eine Unabhängigkeit nicht gegeben. Es fehlt also der neutrale, unvoreingenommene Blick auf das Testobjekt. Es besteht dabei die Gefahr, dass man für die eigenen Fehler blind ist.
Unter «informell» versteht man, dass der Testprozess spontan, nach Bedarf, nicht schriftlich fixiert und darum nicht nachvollziehbar ist. Die meisten SW-Entwicklungsplattformen besitzen einen internen bzw. eingebauten SW-Debugger. Bevor der Debugger wirksam werden kann, muss das Programm zuerst meist abgespeichert werden. Der Debugger stellt unter anderem folgende Funktionen Verfügung:

• Programmausführung in Einzelschritten, vorwärts oder rückwärts.
• Programmausführung bis zu einem zuvor gesetzten Haltepunkt. (Breakpoint)
• Lesen von Variableninhalten.

3. Formelles Testen mit Testprotokoll

Im Gegensatz zum informellen, spontanen Testen, möchte man hier geplant und nachvollziehbar vorgehen. Formell getestet wird nicht nur in der SW-Entwicklung. Auch ein PC-Assembler erstellt am Schluss ein schriftliches Abnahmeprotokoll seiner PC-Kreation, mit dem er u.a. beweisen kann, dass sein Produkt die Produktionshallen fehlerfrei verlassen hat. Wie jeder Prozess muss auch der Testprozes vorher sorgfältig geplant werden. Man testet nicht einfach so konzeptlos drauflos. Am Schluss muss auch jemand gerade stehen, bzw. sich für die korrekte Testausführung verantwortlich zeigen. Und Last but not least: Es muss auch genau definiert sein, was, bzw. welche Lieferung man getestet hat. Und ja, falls mal ein zu behebender Fehler gefunden wurde: Verschlimmbessern geht gar nicht.

3.1 Testplan, Testdefinition

Ein Testplan besteht aus den Testanweisungen in Form der Testbeschreibung, dem Testprotokoll mit den Testfällen, welche in thematische Gruppen zusammengefasst sind und dem Testbericht oder Testbefund. (Sign-Off)

3.2 Testbeschreibung

Jeder Test sollte mit einer klar verständlichen Anleitung beschrieben werden. Dazu gehören folgende Punkte:

• Ziel des Tests
• Art des Tests
• Verwendete Hilfsmittel
• Anforderungen an das Testobjekt
• Testvorgaben (Set-Up)
• Abbruchkriterien (Check-Points)
• Weiteres (z.B Tear-Down/Aufräumarbeiten nach dem Test)

3.3 Spezifikation von Testfällen

Die Wahl und Anzahl der Testfälle bestimmt nicht nur die Qualität und Wirksamkeit des Tests, sondern auch über die Dauer und Kosten desselben. Da diese Anforderungen gegenläufig sind, ist ein Mittelweg zu finden. Man versucht mit möglichst wenigen, dafür klug ausgewählten Testfällen möglichst viele Fehlermöglichkeiten auszuschliessen. In der Praxis werden funktional zusammenhängende Testfälle gruppiert und als Ganzes beschrieben.

Kriterien für die Auswahl der Testfälle

• Funktionsüberdeckung: Jede spezifizierte Funktion wird mindestens von einem Testfall geprüft.
• Eingabeüberdeckung: Jedes korrekte Eingabedatum wird mindestens von einem Testfall verwendet.
• Extremwerteingaben: Jedes Eingabefeld wird mit mindestens einer Extremwerteingabe getestet.
• Falscheingaben: Jedes Eingabefeld wird mit mindestens einer Falscheingabe getestet und eine Fehlermeldung erwartet.
• Ausgabedatum: Jedes Ausgabedatum wird von mindestens einem Testfall erzeugt.

Zusätzliche Kriterien bei White-Box-Tests

• Anweisungs- und Zweigüberdeckung: Die Testfälle werden so ausgelegt, dass alle Zweige und Anweisungen mindestens einmal ausgeführt werden.
• Strukturierte Pfadüberdeckung: Die Testfälle werden so gewählt, dass alle möglichen Pfade und jede Schleife mehrmals durchlaufen werden.
• Bedingungsüberdeckung: Alle Bedingungen des Testobjektes werden mindestens einmal mit "True" und einmal mit "False" durchlaufen.

Abschliessender Testbericht bzw. Testbefund (Sign Off):

Nach der Durchführung eines Tests sollten die Testresultate dokumentiert werden. Der Bericht umfasst folgende Punkte:

• Einzel protokollierte Testfallergebnisse mit Status (OK / NOK / Ausnahme)
• Eventuell Review des Tests. Dient zur Verbesserung des Testplanes.
• Eventuell Mängelliste mit mögliche Fehlerquelle
• Schlussstatus (Vollständig akzeptiert / Nicht akzeptiert / Bedingt akzeptiert) mit Vorgehensempfehlung.
• Datum und Unterschriften der ausführenden Organe.

3.4 Zusammenfassung: SW-Testen

Was ist wichtig und worauf wollen wir uns hier fokussieren:

• In diesem Kurs beschränken wir uns auf SW-Abnahmetests in der Form von Blackboxtests.
• Die zu testende Lieferung soll über eine Produktbezeichnung und Versionsnummer verfügen und damit eindeutig identifizierbar sein. (Bsp. SUPERCALC_V2.3)
• Es wird formell getestet. Dies bedingt die schriftliche Form.
• Sämtliche Test müssen reproduzierbar bzw. nachvollziehbar sein und Darum muss mit konkreten Eingabewerten geprüft werden.
• Nach Testende muss in einem Schlusssatz bzw. Testbericht mitgeteilt werden, ob die Lieferung akzeptiert, mit Einschränkungen akzeptiert oder nicht akzeptiert wird.

Wenn die Lieferung nicht akzeptiert wird:

• Die Lieferung wird sie zwecks Fehlerbehebung an den Autor zurückgesandt.
• Der Lieferant/Autor (SW-Entwickler) kann anhand des Testprotokolls seine Fehler korrigieren
• Nach der Korrektur wird die korrigierte Version der Lieferung erneut vollständig getestet. Es wird ein weiteres Testprotokoll für die neue Version (z.B. CALC_V2.4) erstellt.

3.5 Praxisbeispiel Testen einer Taschenrechner-SW

Das fordert das Pflichtenheft:

• Robuste Eingabe der Zahl1 (-1'000'000 bis + 1'000'000)
• Robuste Eingabe der Zahl2 (-1'000'000 bis + 1'000'000)
• Mathematische Operationen: +, -, *, :
• Definierter Ausgabewertebereich (Resultat) (-1'000'000'000 bis + 1'000'000'000)
• Korrektes Resultat auf eine Nachkommastelle gerundet

Ein Negativbeispiel von Testfällen

So eben nicht...

Softwarelieferung: SuperCalc, neuste Version von heute früh.
************************************************************
Und das liebe Freunde habe ich heute getestet:	 
INPUT         Zwei schöne, fette, positive Zahlen
INPUT         Ein gültiges Operationszeichen dessen Funktion ich leider auch nicht richtig verstehe
OUTPUT-Soll   Das richtige Resultat, so hoffe ich
OUTPUT-IST    Auch das richtige Resultat, so nehme ich mal an
OK oder NOK   Dann doch lieber OK und hey Alter, für Dich immer wieder gerne und immer schön cool bleiben;-)


Falsch wäre auch ein Testfall wie der folgende: (Weil nicht reproduzierbar)

TESTFALL #001 (Testgruppe Eingabeüberdeckungen)
-------------
Eingabe Zahl1: Eine positive Zahl
Eingabe Zahl2: Eine noch positivere Zahl
Operation: +
Erwartete Ausgabe: Ausgabe erfolgt ohne Fehler
Tatsächliche Ausgabe: Ausgabe erfolgte ohne nennenswerte Fehler
OK/NOK: ?
 
  

Korrekte Testfälle

Ab jetzt nur noch auf diese Art:
(Es werden hier aus Platzgründen exemplarisch nur ein paar der erforderlichen Testfälle aufgezeigt.)

TESTPROTOKOLL
*************
Lieferung     : SUPERCALC
Version       : 2.3
Testart       : SW-Abnahmetest/Blackboxtest
SW-Entwickler : Felix Muster
Tester        : Hans Nötig
Datum         : 3. Januar 2022

-----------------------------------------------------------------

TESTFALL #001 (Testgruppe Eingabeüberdeckungen)
-------------
Eingabe Zahl1: 150
Eingabe Zahl2: 230
Operation: +
Erwartete Ausgabe: 380
Tatsächliche Ausgabe: 380
OK/NOK: OK

TESTFALL #002 (Wegen dem vorangegangenen Testfall #001 ist dieser unnötig, weil kein 100%-Testen realistisch ist!)
-------------
Eingabe Zahl1: 151 (Dieser Eingabewert ist dem in Testfall #001 zu ähnlich!)
Eingabe Zahl2: 231 (Dieser Eingabewert ist dem in Testfall #001 zu ähnlich!)
Operation: +
Erwartete Ausgabe: 382
Tatsächliche Ausgabe: 382
OK/NOK: OK

TESTFALL #003 (Testgruppe Eingabeüberdeckungen)
-------------
Eingabe Zahl1: -150
Eingabe Zahl2: -200
Operation: +
Erwartete Ausgabe: -350
Tatsächliche Ausgabe: -350
OK/NOK: OK

TESTFALL #017 (Testgruppe Ausgabedaten)
-------------
Eingabe Zahl1: 2
Eingabe Zahl2: 3
Operation: :
Erwartete Ausgabe: 0.7
Tatsächliche Ausgabe: 0.66666666666666666
OK/NOK: NOK

TESTFALL #057 (Testgruppe Extremwerteingaben)
-------------
Eingabe Zahl1: 1'000'001
Eingabe Zahl2: 1'000'001
Operation: +
Erwartete Ausgabe: Meldung: Eingabewerte zu gross!
Tatsächliche Ausgabe: Keine Meldung
OK/NOK: NOK

TESTFALL #058 (Testgruppe Extremwerteingaben)
-------------
Eingabe Zahl1: 120
Eingabe Zahl2: 0.000001
Operation: *
Erwartete Ausgabe: 0.0
Tatsächliche Ausgabe: 0.00012
OK/NOK: NOK

TESTFALL #059 (Testgruppe Extremwerteingaben)
-------------
Eingabe Zahl1: 1'000'000
Eingabe Zahl2: 0.0001
Operation: :
Erwartete Ausgabe: Meldung: Resultat ausserhalb Wertebereich!
Tatsächliche Ausgabe: Keine Meldung
OK/NOK: NOK

TESTFALL #067 (Testgruppe Falscheingaben)
-------------
Eingabe Zahl1: vierzehn
Eingabe Zahl2: elf
Operation: +
Erwartete Ausgabe: Meldung: Eingabewerte sind keine Zahlen!
Tatsächliche Ausgabe: Meldung: Eingabewerte sind keine Zahlen!
OK/NOK: OK

TESTFALL #125 (Testgruppe Falscheingaben)
-------------
Eingabe Zahl1: 150
Eingabe Zahl2: 0
Operation: :
Erwartete Ausgabe: Meldung: Division durch 0 ist verboten!
Tatsächliche Ausgabe: Meldung: Division durch 0 ist verboten!
OK/NOK: OK

Testbericht:
------------
Lieferung akzeptiert:                     [JA/NEIN]  NEIN!
Lieferung mit Einschränkungen akzeptiert: [JA/NEIN]  NEIN!
Lieferung nicht akzeptiert:               [JA/NEIN]  JA!
Datum und Unterschrift des Testers:       .........  Zürich, 3. Januar 2022, Hans Nötig