Softwaretest

Unter Softwaretests versteht man die Untersuchung der Artefakte und des Verhaltens der zu testenden Software durch Validierung und Verifizierung. Softwaretests können auch eine objektive, unabhängige Sicht auf die Software bieten, damit das Unternehmen die Risiken der Softwareimplementierung einschätzen und verstehen kann. Zu den Testtechniken gehören unter anderem

Analyse der Produktanforderungen auf Vollständigkeit und Korrektheit in verschiedenen Zusammenhängen wie Branchenperspektive, Geschäftsperspektive, Machbarkeit und Durchführbarkeit der Implementierung, Benutzerfreundlichkeit, Leistung, Sicherheit, Infrastrukturüberlegungen usw.
Überprüfung der Produktarchitektur und des Gesamtdesigns des Produkts
Zusammenarbeit mit Produktentwicklern bei der Verbesserung von Codierungstechniken, Entwurfsmustern, Tests, die als Teil des Codes auf der Grundlage verschiedener Techniken wie Randbedingungen usw. geschrieben werden können
Ausführen eines Programms oder einer Anwendung mit dem Ziel, das Verhalten zu untersuchen
Überprüfung der Bereitstellungsinfrastruktur und der zugehörigen Skripte und Automatisierung
Teilnahme an den Produktionsaktivitäten mit Hilfe von Überwachungs- und Beobachtungstechniken ⓘ

Softwaretests können objektive, unabhängige Informationen über die Qualität der Software und das Risiko ihres Scheiterns für Benutzer oder Sponsoren liefern. ⓘ

Ein Softwaretest prüft und bewertet Software auf Erfüllung der für ihren Einsatz definierten Anforderungen und misst ihre Qualität. Die gewonnenen Erkenntnisse werden zur Erkennung und Behebung von Softwarefehlern genutzt. Tests während der Softwareentwicklung dienen dazu, die Software möglichst fehlerfrei in Betrieb zu nehmen. ⓘ

Von diesem, eine einzelne Testmaßnahme bezeichnenden Begriff ist die gleich lautende Bezeichnung 'Test' (auch 'Testen') zu unterscheiden, unter der die Gesamtheit der Maßnahmen zur Überprüfung der Softwarequalität (inkl. Planung, Vorbereitung, Steuerung, Durchführung, Dokumentation usw.; siehe auch Definitionen) verstanden wird. ⓘ

Den Nachweis, dass keine Fehler (mehr) vorhanden sind, kann das Softwaretesten nicht erbringen. Es kann lediglich fallibilistisch feststellen, dass bestimmte Testfälle erfolgreich waren. Edsger W. Dijkstra schrieb hierzu: „Program testing can be used to show the presence of bugs, but never show their absence!“ (Das Testen von Programmen kann die Existenz von Fehlern zeigen, aber niemals deren Nichtvorhandensein). Der Grund ist, dass alle Programmfunktionen und auch alle möglichen Werte in den Eingabedaten in allen ihren Kombinationen getestet werden müssten – was (außer bei sehr einfachen Testobjekten) praktisch nicht möglich ist. Aus diesem Grund beschäftigen sich verschiedene Teststrategien und -konzepte mit der Frage, wie mit einer möglichst geringen Anzahl von Testfällen eine große Testabdeckung zu erreichen ist. ⓘ

Pol, Koomen, Spillner erläutern 'Testen' wie folgt: „Tests sind nicht die einzige Maßnahme im Qualitätsmanagement der Softwareentwicklung, aber oft die letztmögliche. Je später Fehler entdeckt werden, desto aufwändiger ist ihre Behebung, woraus sich der Umkehrschluss ableitet: Qualität muss (im ganzen Projektverlauf) implementiert und kann nicht 'eingetestet' werden.“ Und: „Beim Testen in der Softwareentwicklung wird i. d. R. eine mehr oder minder große Fehleranzahl als 'normal' unterstellt oder akzeptiert. Hier herrscht ein erheblicher Unterschied zur Industrie: Dort werden im Prozessabschnitt 'Qualitätskontrolle' oft nur noch in Extremsituationen Fehler erwartet.“ ⓘ

Überblick

Obwohl Softwaretests die Korrektheit von Software unter der Annahme einiger spezifischer Hypothesen bestimmen können (siehe die Hierarchie der Testschwierigkeiten unten), können Tests nicht alle Fehler in der Software identifizieren. Stattdessen liefert es eine Kritik oder einen Vergleich, der den Zustand und das Verhalten des Produkts mit Testorakeln vergleicht - Prinzipien oder Mechanismen, durch die jemand ein Problem erkennen könnte. Zu diesen Orakeln können Spezifikationen, Verträge, vergleichbare Produkte, frühere Versionen desselben Produkts, Rückschlüsse auf den beabsichtigten oder erwarteten Zweck, Benutzer- oder Kundenerwartungen, relevante Normen, geltende Gesetze oder andere Kriterien gehören (sind aber nicht darauf beschränkt). ⓘ

Ein Hauptzweck des Testens ist die Erkennung von Softwarefehlern, so dass Mängel entdeckt und behoben werden können. Testen kann nicht feststellen, dass ein Produkt unter allen Bedingungen ordnungsgemäß funktioniert, sondern nur, dass es unter bestimmten Bedingungen nicht ordnungsgemäß funktioniert. Der Umfang von Softwaretests kann die Untersuchung von Code sowie die Ausführung dieses Codes in verschiedenen Umgebungen und unter verschiedenen Bedingungen umfassen und die Aspekte des Codes untersuchen: Tut er, was er tun soll, und tut er, was er tun muss. In der heutigen Kultur der Softwareentwicklung kann eine Testorganisation vom Entwicklungsteam getrennt sein. Es gibt verschiedene Rollen für die Mitglieder des Testteams. Die aus dem Testen von Software gewonnenen Informationen können dazu verwendet werden, den Prozess der Softwareentwicklung zu korrigieren. ⓘ

Jedes Softwareprodukt hat ein Zielpublikum. Zum Beispiel ist die Zielgruppe für Videospielsoftware eine völlig andere als für Bankensoftware. Wenn ein Unternehmen ein Softwareprodukt entwickelt oder anderweitig in ein solches investiert, kann es daher beurteilen, ob das Softwareprodukt für seine Endbenutzer, sein Zielpublikum, seine Käufer und andere Beteiligte akzeptabel sein wird. Softwaretests helfen bei dieser Beurteilung. ⓘ

Fehler und Ausfälle

Software-Fehler entstehen durch den folgenden Prozess: Ein Programmierer macht einen Fehler (Irrtum), der zu einem Fehler (Defekt, Bug) im Software-Quellcode führt. Wenn dieser Fehler ausgeführt wird, produziert das System in bestimmten Situationen falsche Ergebnisse und verursacht einen Fehler. ⓘ

Nicht alle Fehler führen zwangsläufig zu Fehlern. Zum Beispiel führen Fehler im toten Code nie zu Fehlern. Ein Fehler, der nicht zu Fehlern geführt hat, kann zu einem Fehler führen, wenn die Umgebung geändert wird. Beispiele für solche Umgebungsänderungen sind die Ausführung der Software auf einer neuen Computer-Hardware-Plattform, Änderungen der Quelldaten oder die Interaktion mit anderer Software. Ein einziger Fehler kann zu einem breiten Spektrum von Fehlersymptomen führen. ⓘ

Nicht alle Softwarefehler werden durch Kodierungsfehler verursacht. Eine häufige Ursache für teure Fehler sind Anforderungslücken, d. h. nicht erkannte Anforderungen, die zu Unterlassungsfehlern des Programmdesigners führen. Bei Anforderungslücken handelt es sich oft um nichtfunktionale Anforderungen wie Testbarkeit, Skalierbarkeit, Wartbarkeit, Leistung und Sicherheit. ⓘ

Eingabekombinationen und Vorraussetzungen

Ein grundlegendes Problem beim Testen von Software besteht darin, dass das Testen unter allen Kombinationen von Eingaben und Vorbedingungen (Anfangszustand) selbst bei einem einfachen Produkt nicht durchführbar ist. Das bedeutet, dass die Anzahl der Fehler in einem Softwareprodukt sehr groß sein kann und dass Fehler, die nur selten auftreten, beim Testen und Debuggen schwer zu finden sind. Noch wichtiger ist, dass die nicht-funktionalen Dimensionen der Qualität (wie es sein soll und was es tun soll) - Benutzerfreundlichkeit, Skalierbarkeit, Leistung, Kompatibilität und Zuverlässigkeit - sehr subjektiv sein können; was für den einen einen ausreichenden Wert darstellt, kann für den anderen unerträglich sein. ⓘ

Softwareentwickler können nicht alles testen, aber sie können mit Hilfe des kombinatorischen Testentwurfs die Mindestanzahl von Tests ermitteln, die erforderlich sind, um die gewünschte Abdeckung zu erreichen. Der kombinatorische Testentwurf ermöglicht es den Benutzern, mit weniger Tests eine größere Testabdeckung zu erreichen. Unabhängig davon, ob es ihnen um Geschwindigkeit oder Testtiefe geht, können sie mit kombinatorischen Testentwurfsmethoden strukturierte Variationen in ihre Testfälle einbauen. ⓘ

Wirtschaft

Eine vom NIST im Jahr 2002 durchgeführte Studie zeigt, dass Softwarefehler die US-Wirtschaft jährlich 59,5 Milliarden Dollar kosten. Mehr als ein Drittel dieser Kosten könnte vermieden werden, wenn bessere Softwaretests durchgeführt würden. ⓘ

Das Outsourcing von Softwaretests ist aus Kostengründen sehr verbreitet, wobei China, die Philippinen und Indien bevorzugte Ziele sind. ⓘ

Rollen

Softwaretests können von engagierten Softwaretestern durchgeführt werden; bis in die 1980er Jahre wurde der Begriff "Softwaretester" allgemein verwendet, später wurde er jedoch auch als eigenständiger Beruf angesehen. In Anbetracht der Zeiträume und der unterschiedlichen Ziele des Softwaretestens haben sich verschiedene Rollen herausgebildet, z. B. Testmanager, Testleiter, Testanalytiker, Testdesigner, Tester, Automatisierungsentwickler und Testadministratoren. Softwaretests können auch von nicht spezialisierten Softwaretestern durchgeführt werden. ⓘ

Geschichte

Glenford J. Myers führte 1979 erstmals die Trennung von Debugging und Testen ein. Obwohl sein Augenmerk auf dem Testen von Fehlern lag ("Ein erfolgreicher Testfall ist einer, der einen noch unentdeckten Fehler aufdeckt"), veranschaulichte er den Wunsch der Softwareentwicklungsgemeinschaft, grundlegende Entwicklungsaktivitäten wie das Debugging von der Verifikation zu trennen. ⓘ

Testansatz

Statisches, dynamisches und passives Testen

Für das Testen von Software gibt es viele verschiedene Ansätze. Reviews, Walkthroughs oder Inspektionen werden als statische Tests bezeichnet, während das Ausführen von programmiertem Code mit einer bestimmten Menge von Testfällen als dynamische Tests bezeichnet wird. ⓘ

Statisches Testen ist oft implizit, wie z. B. das Korrekturlesen, wenn Programmierwerkzeuge/Texteditoren die Quellcode-Struktur oder Compiler (Pre-Compiler) die Syntax und den Datenfluss als statische Programmanalyse überprüfen. Das dynamische Testen findet statt, wenn das Programm selbst ausgeführt wird. Dynamische Tests können beginnen, bevor das Programm zu 100 % fertig ist, um bestimmte Codeabschnitte zu testen, und werden auf diskrete Funktionen oder Module angewendet. Typische Techniken hierfür sind entweder die Verwendung von Stubs/Treibern oder die Ausführung in einer Debugger-Umgebung. ⓘ

Das statische Testen beinhaltet eine Verifizierung, während das dynamische Testen auch eine Validierung beinhaltet. ⓘ

Passives Testen bedeutet, dass das Systemverhalten ohne jegliche Interaktion mit dem Softwareprodukt überprüft wird. Im Gegensatz zum aktiven Testen stellen die Tester keine Testdaten bereit, sondern sehen sich Systemprotokolle und Traces an. Sie suchen nach Mustern und bestimmten Verhaltensweisen, um eine Art von Entscheidung zu treffen. Dies ist verwandt mit der Offline-Laufzeitüberprüfung und der Protokollanalyse. ⓘ

Beispiele für einzelne Aktivitäten: Auswählen der zu testenden Testfälle; Starten des Prüflings – manuell oder automatisch; Bereitstellen der Testdaten und des Ist-Ergebnisses zur Auswertung; Umgebungsinformationen für den Testlauf archivieren, ... ⓘ

Weitere Anmerkung: Ein Testobjekt sollte nicht vom Entwickler selbst, sondern von anderen, wenn möglich unabhängigen, Personen getestet werden. ⓘ

Explorativer Ansatz

Exploratives Testen ist ein Ansatz für das Testen von Software, der kurz und bündig als gleichzeitiges Lernen, Testdesign und Testdurchführung beschrieben wird. Cem Kaner, der den Begriff 1984 prägte, definiert exploratives Testen als "einen Stil des Softwaretestens, der die persönliche Freiheit und Verantwortung des einzelnen Testers betont, die Qualität seiner Arbeit kontinuierlich zu optimieren, indem er testbezogenes Lernen, Testdesign, Testdurchführung und Testergebnisinterpretation als sich gegenseitig unterstützende Aktivitäten behandelt, die während des gesamten Projekts parallel laufen." ⓘ

Der "Box"-Ansatz

Softwaretestmethoden werden traditionell in White- und Blackbox-Tests unterteilt. Diese beiden Ansätze werden verwendet, um die Sichtweise zu beschreiben, die der Tester beim Entwurf von Testfällen einnimmt. Ein hybrider Ansatz, der als Grey-Box-Testing bezeichnet wird, kann ebenfalls auf die Software-Testmethodik angewendet werden. Mit der zunehmenden Verbreitung des Konzepts des Grey-Box-Tests, bei dem Tests aus spezifischen Designelementen entwickelt werden, ist diese "willkürliche Unterscheidung" zwischen Black- und White-Box-Tests etwas verblasst. ⓘ

White-box-Tests

White-Box-Tests Diagramm ⓘ

Beim White-Box-Testing (auch bekannt als Clear-Box-Testing, Glass-Box-Testing, Transparent-Box-Testing und Strukturtesting) werden die internen Strukturen oder Abläufe eines Programms überprüft, im Gegensatz zu den Funktionen, die dem Endbenutzer zugänglich sind. Bei White-Box-Tests werden eine interne Perspektive des Systems (der Quellcode) sowie Programmierkenntnisse verwendet, um Testfälle zu entwerfen. Der Tester wählt Eingaben aus, um Pfade durch den Code zu üben und die entsprechenden Ausgaben zu bestimmen. Dies ist vergleichbar mit dem Testen von Knoten in einem Schaltkreis, z. B. In-Circuit-Testing (ICT). ⓘ

White-Box-Tests können zwar auf der Unit-, der Integrations- und der Systemebene des Softwaretestprozesses angewandt werden, werden aber normalerweise auf der Unit-Ebene durchgeführt. Es können Pfade innerhalb einer Einheit, Pfade zwischen Einheiten während der Integration und zwischen Subsystemen während eines Tests auf Systemebene getestet werden. Obwohl diese Methode des Testdesigns viele Fehler oder Probleme aufdecken kann, werden möglicherweise nicht implementierte Teile der Spezifikation oder fehlende Anforderungen nicht entdeckt. ⓘ

Zu den Techniken, die bei White-Box-Tests eingesetzt werden, gehören:

API-Tests - Testen der Anwendung über öffentliche und private APIs (Anwendungsprogrammierschnittstellen)
Codeabdeckung - Erstellung von Tests, die bestimmte Kriterien der Codeabdeckung erfüllen (z. B. kann der Testentwickler Tests erstellen, die bewirken, dass alle Anweisungen im Programm mindestens einmal ausgeführt werden)
Fehlerinjektionsmethoden - absichtliche Einführung von Fehlern, um die Wirksamkeit von Teststrategien zu überprüfen
Mutationstest-Methoden
Statische Testmethoden ⓘ

Code-Coverage-Tools können die Vollständigkeit einer Testsuite bewerten, die mit einer beliebigen Methode erstellt wurde, einschließlich Black-Box-Tests. Dies ermöglicht es dem Softwareteam, Teile eines Systems zu untersuchen, die selten getestet werden, und stellt sicher, dass die wichtigsten Funktionspunkte getestet worden sind. Die Codeabdeckung als Softwaremetrik kann als Prozentsatz angegeben werden für:

Funktionsabdeckung, die über die ausgeführten Funktionen berichtet
Anweisungsabdeckung, die die Anzahl der Zeilen angibt, die zur Durchführung des Tests ausgeführt wurden
Entscheidungsabdeckung, die angibt, ob sowohl der richtige als auch der falsche Zweig eines bestimmten Tests ausgeführt wurde ⓘ

Eine 100%ige Anweisungsabdeckung stellt sicher, dass alle Codepfade oder Verzweigungen (in Bezug auf den Kontrollfluss) mindestens einmal ausgeführt werden. Dies ist hilfreich, um korrekte Funktionalität zu gewährleisten, aber nicht ausreichend, da derselbe Code unterschiedliche Eingaben korrekt oder falsch verarbeiten kann. Pseudogetestete Funktionen und Methoden sind solche, die abgedeckt, aber nicht spezifiziert sind (es ist möglich, ihren Rumpf zu entfernen, ohne einen Testfall zu verletzen). ⓘ

Black-Box-Tests

Blackbox-Diagramm ⓘ

Beim Black-Box-Test (auch als funktionales Testen bezeichnet) wird die Software als "Black Box" behandelt, d. h. die Funktionalität wird ohne Kenntnis der internen Implementierung und ohne Einsicht in den Quellcode untersucht. Die Tester wissen nur, was die Software tun soll, aber nicht, wie sie es tut. Zu den Black-Box-Testmethoden gehören: Äquivalenzpartitionierung, Grenzwertanalyse, All-Pairs-Tests, Zustandsübergangstabellen, Entscheidungstabellentests, Fuzz-Tests, modellbasierte Tests, Anwendungsfalltests, explorative Tests und spezifikationsbasierte Tests. ⓘ

Spezifikationsbasiertes Testen zielt darauf ab, die Funktionalität der Software gemäß den geltenden Anforderungen zu testen. Bei dieser Art des Testens werden dem Tester in der Regel ausführliche Testfälle zur Verfügung gestellt, und er kann dann einfach überprüfen, ob der Ausgabewert (oder das Verhalten) für eine bestimmte Eingabe mit dem im Testfall angegebenen erwarteten Wert übereinstimmt oder nicht. Testfälle werden auf der Grundlage von Spezifikationen und Anforderungen erstellt, d. h. auf der Grundlage dessen, was die Anwendung tun soll. Es werden externe Beschreibungen der Software verwendet, einschließlich Spezifikationen, Anforderungen und Designs, um Testfälle abzuleiten. Diese Tests können funktional oder nicht-funktional sein, in der Regel jedoch funktional. ⓘ

Spezifikationsbasierte Tests können notwendig sein, um die korrekte Funktionalität zu gewährleisten, aber sie reichen nicht aus, um komplexe oder risikoreiche Situationen abzusichern. ⓘ

Ein Vorteil der Black-Box-Technik ist, dass keine Programmierkenntnisse erforderlich sind. Was auch immer die Programmierer für Vorurteile hatten, der Tester hat wahrscheinlich andere und kann andere Bereiche der Funktionalität hervorheben. Andererseits ist das Black-Box-Testing "wie ein Spaziergang in einem dunklen Labyrinth ohne Taschenlampe". Da der Quellcode nicht untersucht wird, gibt es Situationen, in denen ein Tester viele Testfälle schreibt, um etwas zu prüfen, das mit nur einem Testfall hätte geprüft werden können, oder einige Teile des Programms ungetestet lässt. ⓘ

Diese Testmethode kann auf allen Ebenen des Softwaretests angewendet werden: Einheitstest, Integrationstest, Systemtest und Abnahmetest. Sie umfasst in der Regel die meisten, wenn nicht sogar alle Tests auf höheren Ebenen, kann aber auch den Unit-Test dominieren. ⓘ

Testen von Komponentenschnittstellen ⓘ

Das Testen von Komponentenschnittstellen ist eine Variante des Black-Box-Tests, bei der der Schwerpunkt auf den Datenwerten liegt, die über die damit verbundenen Aktionen einer Subsystemkomponente hinausgehen. Das Testen von Komponentenschnittstellen kann verwendet werden, um die Handhabung von Daten zu überprüfen, die zwischen verschiedenen Einheiten oder Subsystemkomponenten weitergegeben werden, und zwar über das vollständige Integrationstesten zwischen diesen Einheiten hinaus. Die weitergegebenen Daten können als "Nachrichtenpakete" betrachtet werden, und der Bereich oder die Datentypen können bei Daten, die von einer Einheit erzeugt wurden, überprüft und auf ihre Gültigkeit getestet werden, bevor sie an eine andere Einheit weitergegeben werden. Eine Option für Schnittstellentests besteht darin, eine separate Protokolldatei der weitergegebenen Daten zu führen, oft mit einem Zeitstempel, um die Analyse von Tausenden von Daten zu ermöglichen, die über Tage oder Wochen zwischen den Einheiten weitergegeben wurden. Bei den Tests kann die Behandlung einiger extremer Datenwerte überprüft werden, während andere Schnittstellenvariablen als normale Werte weitergegeben werden. Ungewöhnliche Datenwerte in einer Schnittstelle können dazu beitragen, unerwartete Leistungen in der nächsten Einheit zu erklären. ⓘ

Visuelle Tests

Ziel des visuellen Testens ist es, den Entwicklern die Möglichkeit zu geben, zu untersuchen, was an der Stelle des Softwarefehlers passiert ist, indem die Daten so dargestellt werden, dass der Entwickler die benötigten Informationen leicht finden kann und die Informationen klar ausgedrückt werden. ⓘ

Der Kern des visuellen Testens ist die Idee, dass die Darstellung eines Problems (oder eines Testfehlers) anstelle einer bloßen Beschreibung die Klarheit und das Verständnis erheblich verbessert. Visuelles Testen erfordert daher die Aufzeichnung des gesamten Testprozesses, d. h. die Aufzeichnung aller Vorgänge auf dem Testsystem im Videoformat. Die Ausgabevideos werden durch Echtzeit-Eingaben des Testers über eine Bild-in-Bild-Webcam und Audiokommentare von Mikrofonen ergänzt. ⓘ

Visuelle Tests bieten eine Reihe von Vorteilen. Die Qualität der Kommunikation wird drastisch erhöht, da die Tester dem Entwickler das Problem (und die Ereignisse, die dazu führen) zeigen können, anstatt es nur zu beschreiben, und die Notwendigkeit, Testfehler zu wiederholen, entfällt in vielen Fällen. Der Entwickler verfügt über alle erforderlichen Beweise für ein Testversagen und kann sich stattdessen auf die Ursache des Fehlers und dessen Behebung konzentrieren. ⓘ

Ad-hoc-Tests und explorative Tests sind wichtige Methoden zur Überprüfung der Software-Integrität, da sie weniger Vorbereitungszeit für die Implementierung erfordern und die wichtigen Fehler schnell gefunden werden können. Bei Ad-hoc-Tests, bei denen das Testen auf improvisierte Weise erfolgt, kann die Fähigkeit der Tester, die Tests auf dokumentierte Methoden zu stützen und dann Variationen dieser Tests zu improvisieren, zu einer strengeren Prüfung der Fehlerbehebung führen. Eine der Grenzen von Ad-hoc-Tests ist jedoch die mangelnde Wiederholbarkeit, wenn keine strenge Dokumentation der Verfahren erfolgt. ⓘ

Grey-box-Tests

Beim Grey-Box-Testing (amerikanische Schreibweise: Gray-Box-Testing) geht es darum, interne Datenstrukturen und Algorithmen zu kennen, um Tests zu entwerfen, während diese Tests auf der Benutzer- oder Black-Box-Ebene ausgeführt werden. Der Tester hat oft Zugang sowohl zum Quellcode als auch zur ausführbaren Binärdatei. Zu den Grey-Box-Tests kann auch ein Reverse-Engineering (mit dynamischer Codeanalyse) gehören, um beispielsweise Grenzwerte oder Fehlermeldungen zu ermitteln. Die Manipulation von Eingabedaten und die Formatierung von Ausgaben zählen nicht zu den Grey-Box-Tests, da die Eingaben und Ausgaben eindeutig außerhalb der "Black Box" liegen, die wir das zu testende System nennen. Diese Unterscheidung ist besonders wichtig, wenn Integrationstests zwischen zwei von zwei verschiedenen Entwicklern geschriebenen Codemodulen durchgeführt werden, bei denen nur die Schnittstellen für den Test offengelegt werden. ⓘ

Durch die Kenntnis der zugrundeliegenden Konzepte, wie die Software funktioniert, kann der Tester beim Testen der Software von außen fundiertere Testentscheidungen treffen. In der Regel darf ein Grey-Box-Tester eine isolierte Testumgebung einrichten, in der er beispielsweise eine Datenbank mit Daten füttert. Der Tester kann den Zustand des zu testenden Produkts beobachten, nachdem er bestimmte Aktionen durchgeführt hat, z. B. die Ausführung von SQL-Anweisungen gegen die Datenbank und die anschließende Ausführung von Abfragen, um sicherzustellen, dass die erwarteten Änderungen berücksichtigt wurden. Grey-Box-Tests implementieren intelligente Testszenarien, die auf begrenzten Informationen basieren. Dies gilt insbesondere für die Behandlung von Datentypen, Ausnahmen und so weiter. ⓘ

Teststufen

Stufen des V-Modells ⓘ

Die Einordnung der Teststufen (zum Teil auch Testzyklen genannt) folgt gemäß V-Modell dem Entwicklungsstand des Systems. Ihr Inhalt orientiert sich dabei an den Entwicklungsstufen von Projekten. Dabei wird in jeder Teststufe (rechte Seite im 'V') gegen die Systementwürfe und Spezifikationen der zugehörigen Entwicklungsstufe (linke Seite) getestet, d. h., die Testziele und Testfälle basieren auf den jeweiligen Entwicklungsergebnissen. Dieses Vorgehensprinzip ist allerdings nur anwendbar, wenn evtl. in späteren Entwicklungsstufen vorgenommene Änderungen in den älteren Spezifikationen nachgeführt wurden. ⓘ

In der Realität werden diese Ausprägungen, abhängig von der Größe und Komplexität des Software-Produkts, weiter untergliedert. So könnten beispielsweise die Tests für die Entwicklung von sicherheitsrelevanten Systemen in der Transportsicherungstechnik folgendermaßen untergliedert sein: Komponententest auf dem Entwicklungsrechner, Komponententest auf der Ziel-Hardware, Produkt-Integrationstests, Produkttest, Produkt-Validierungstests, System-Integrationstest, Systemtest, System-Validierungstests, Feldtests und Akzeptanztest. ⓘ

Die nachfolgend beschriebenen Teststufen sind in der Praxis oft nicht scharf voneinander abgegrenzt, sondern können, abhängig von der Projektsituation, fließend oder über zusätzliche Zwischenstufen verlaufen. So könnte zum Beispiel die Abnahme des Systems auf der Grundlage von Testergebnissen (Reviews, Testprotokolle) von Systemtests erfolgen. ⓘ

Grob gesagt gibt es mindestens drei Testebenen: Einheitstests, Integrationstests und Systemtests. Eine vierte Ebene, die Akzeptanztests, kann jedoch von den Entwicklern einbezogen werden. Dabei kann es sich um betriebliche Abnahmetests oder einfache Endbenutzer-(Beta-)Tests handeln, die sicherstellen, dass die Software die funktionalen Erwartungen erfüllt. Auf der Grundlage des ISTQB Certified Test Foundation Level-Lehrplans umfassen die Teststufen diese vier Ebenen, wobei die vierte Ebene als Abnahmetest bezeichnet wird. Tests werden häufig in eine dieser Stufen eingeteilt, je nachdem, an welcher Stelle sie in den Softwareentwicklungsprozess eingefügt werden, oder je nach dem Grad der Spezifität des Tests. ⓘ

Unit-Tests

Unit-Tests beziehen sich auf Tests, die die Funktionalität eines bestimmten Codeabschnitts überprüfen, normalerweise auf Funktionsebene. In einer objektorientierten Umgebung geschieht dies normalerweise auf Klassenebene, und die minimalen Unit-Tests umfassen die Konstruktoren und Destruktoren. ⓘ

Diese Arten von Tests werden in der Regel von Entwicklern während der Arbeit am Code geschrieben (White-Box-Stil), um sicherzustellen, dass die spezifische Funktion wie erwartet funktioniert. Eine Funktion kann mehrere Tests haben, um Eckfälle oder andere Verzweigungen im Code abzufangen. Unit-Tests allein können die Funktionalität einer Software nicht verifizieren, sondern dienen vielmehr dazu, sicherzustellen, dass die Bausteine der Software unabhängig voneinander funktionieren. ⓘ

Unit-Tests sind ein Softwareentwicklungsprozess, der die synchrone Anwendung eines breiten Spektrums von Fehlervermeidungs- und -erkennungsstrategien umfasst, um Risiken, Zeit und Kosten bei der Softwareentwicklung zu reduzieren. Er wird vom Softwareentwickler oder -ingenieur während der Konstruktionsphase des Lebenszyklus der Softwareentwicklung durchgeführt. Unit-Tests zielen darauf ab, Konstruktionsfehler zu beseitigen, bevor der Code weiteren Tests unterzogen wird; diese Strategie soll die Qualität der resultierenden Software sowie die Effizienz des gesamten Entwicklungsprozesses erhöhen. ⓘ

Je nach den Erwartungen des Unternehmens an die Softwareentwicklung können Unit-Tests statische Code-Analysen, Datenflussanalysen, Metrik-Analysen, Peer-Code-Reviews, Code-Abdeckungsanalysen und andere Software-Testverfahren umfassen. ⓘ

Integrationstests

Integrationstests sind alle Arten von Softwaretests, die darauf abzielen, die Schnittstellen zwischen Komponenten anhand eines Softwaredesigns zu überprüfen. Softwarekomponenten können iterativ oder auf einen Schlag ("Big Bang") integriert werden. In der Regel wird die erste Variante als die bessere Praxis angesehen, da Schnittstellenprobleme so schneller gefunden und behoben werden können. ⓘ

Integrationstests dienen dazu, Fehler in den Schnittstellen und der Interaktion zwischen integrierten Komponenten (Modulen) aufzudecken. Nach und nach werden größere Gruppen von getesteten Softwarekomponenten, die den Elementen des Architekturentwurfs entsprechen, integriert und getestet, bis die Software als System funktioniert. ⓘ

Integrationstests sind in der Regel mit viel Code verbunden und erzeugen Spuren, die größer sind als die von Einheitstests. Dies wirkt sich auf die einfache Lokalisierung des Fehlers aus, wenn ein Integrationstest fehlschlägt. Um dieses Problem zu lösen, wurde vorgeschlagen, die großen Tests automatisch in kleinere Teile zu zerlegen, um die Fehlerlokalisierung zu verbessern. ⓘ

Der Integrationstest bzw. Interaktionstest testet die Zusammenarbeit voneinander abhängiger Komponenten. Der Testschwerpunkt liegt auf den Schnittstellen der beteiligten Komponenten und soll korrekte Ergebnisse über komplette Abläufe hinweg nachweisen. Mittels Integrationstests können im Schnitt 35 % der Fehler erkannt werden. ⓘ

Systemtests

Beim Systemtest wird ein vollständig integriertes System getestet, um zu überprüfen, ob das System seine Anforderungen erfüllt. Ein Systemtest könnte beispielsweise das Testen einer Anmeldeschnittstelle, das Erstellen und Bearbeiten eines Eintrags sowie das Senden oder Drucken von Ergebnissen umfassen, gefolgt von einer zusammenfassenden Verarbeitung oder dem Löschen (oder Archivieren) von Einträgen und der Abmeldung. ⓘ

Abnahmetest

Abnahmetests umfassen in der Regel die folgenden vier Arten:

Benutzerakzeptanztests (UAT)
Betriebliche Akzeptanztests (OAT)
Vertragliche und behördliche Akzeptanztests
Alpha- und Beta-Tests ⓘ

UAT sowie Alpha- und Beta-Tests werden im nächsten Abschnitt über Testarten beschrieben. ⓘ

Die betriebliche Abnahme dient der Überprüfung der Betriebsbereitschaft (vor der Freigabe) eines Produkts, einer Dienstleistung oder eines Systems als Teil eines Qualitätsmanagementsystems. OAT ist eine gängige Art von nicht-funktionalen Softwaretests, die hauptsächlich in Softwareentwicklungs- und Softwarewartungsprojekten eingesetzt wird. Diese Art des Testens konzentriert sich auf die Betriebsbereitschaft des Systems, das unterstützt werden oder Teil der Produktionsumgebung werden soll. Daher wird sie auch als ORT-Test (Operational Readiness Testing) oder OR&A-Test (Operations Readiness and Assurance) bezeichnet. Funktionale Tests innerhalb der OAT beschränken sich auf die Tests, die zur Überprüfung der nichtfunktionalen Aspekte des Systems erforderlich sind. ⓘ

Darüber hinaus sollen die Softwaretests sicherstellen, dass die Übertragbarkeit des Systems nicht nur wie erwartet funktioniert, sondern auch seine Betriebsumgebung nicht beschädigt oder teilweise beschädigt oder andere Prozesse innerhalb dieser Umgebung außer Betrieb setzt. ⓘ

Die vertraglichen Abnahmetests werden auf der Grundlage der bei Vertragsabschluss festgelegten Abnahmekriterien durchgeführt, während die behördlichen Abnahmetests auf der Grundlage der einschlägigen Vorschriften für das Softwareprodukt durchgeführt werden. Beide Tests können von Anwendern oder unabhängigen Testern durchgeführt werden. Bei behördlichen Abnahmetests werden die Testergebnisse manchmal von den Aufsichtsbehörden überprüft. ⓘ

Komponententest

Der Modultest, auch Komponententest oder Unittest genannt, ist ein Test auf der Ebene innerer, abgrenzbarer Einzelteile der Software wie beispielsweise Module, Unterprogramme, Units oder Klassen. Testziel dieser häufig durch den Softwareentwickler selbst durchgeführten Tests ist der Nachweis der technischen Lauffähigkeit und korrekter (Teil-)Ergebnisse. Mittels Unittests können im Schnitt 30 Prozent der Fehler erkannt werden; bei der Verwendung von testgetriebener Entwicklung 45 Prozent. Auf Grund der Tatsache, dass Unittests die Fehler bereits während der Entwicklungsphase erkennen, sind die durch Unittests vermiedenen Fehlerkosten gemäß der Rule of 10 um ein Vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen. ⓘ

Systemtest

Der Systemtest ist die Teststufe, bei der das gesamte System gegen die gesamten Anforderungen (funktionale und nicht-funktionale Anforderungen) getestet wird. Gewöhnlich findet der Test auf einer Testumgebung statt und wird mit Testdaten durchgeführt. Die Testumgebung soll die Produktivumgebung des Kunden simulieren, d. h. ihr möglichst ähnlich sein. In der Regel wird der Systemtest durch die realisierende Organisation durchgeführt. Mittels Systemtests können im Schnitt 40 % der Fehler erkannt werden. ⓘ

Testarten, Techniken und Taktiken

Verschiedene Bezeichnungen und Möglichkeiten der Gruppierung von Tests können Testarten, Softwaretesttaktiken oder -techniken sein. ⓘ

TestingCup - Polnische Meisterschaft im Softwaretesten, Kattowitz, Mai 2016 ⓘ

Motivation

„Kein umfangreiches System ist fehlerfrei.“ Jedes Softwaresystem von genügender Komplexität weist Fehler auf. Diesen können neben vielen anderen Fehlergründen zum Beispiel nicht bedachte Ausnahmesituationen oder nicht berücksichtigte Randbedingungen zugrunde liegen. ⓘ

In der Softwareentwicklung wird der Test verwendet um den Verlust von Geld, Zeit, Menschenleben oder anderen materiellen oder immateriellen Gütern, die durch mangelhafte Qualität eines Softwaresystems verursacht werden, zu minimieren. Durch das systematische Testen einer Software während der Entwicklung können Fehler früh festgestellt werden, was deren Fehlerkosten nach der Rule of ten minimiert. ⓘ

Die meisten Softwaresysteme haben Installationsverfahren, die erforderlich sind, bevor sie für ihren eigentlichen Zweck verwendet werden können. Das Testen dieser Verfahren, um ein installiertes Softwaresystem zu erhalten, das verwendet werden kann, wird als Installationstest bezeichnet. ⓘ

Kompatibilitätstests

Eine häufige Ursache für das Scheitern von Software (tatsächlich oder vermeintlich) ist die mangelnde Kompatibilität mit anderer Anwendungssoftware, Betriebssystemen (oder Betriebssystemversionen, alt oder neu) oder Zielumgebungen, die sich stark von der ursprünglichen Umgebung unterscheiden (z. B. eine Terminal- oder GUI-Anwendung, die auf dem Desktop ausgeführt werden sollte, wird nun zu einer Webanwendung, die in einem Webbrowser dargestellt werden muss). Eine fehlende Abwärtskompatibilität kann z. B. dadurch entstehen, dass die Programmierer die Software nur auf der neuesten Version der Zielumgebung entwickeln und testen, die aber möglicherweise nicht von allen Benutzern verwendet wird. Dies hat die unbeabsichtigte Folge, dass die neueste Arbeit möglicherweise nicht auf früheren Versionen der Zielumgebung oder auf älterer Hardware funktioniert, die in früheren Versionen der Zielumgebung verwendet werden konnte. Manchmal lassen sich solche Probleme beheben, indem die Betriebssystemfunktionalität proaktiv in ein separates Programmmodul oder eine Bibliothek abstrahiert wird. ⓘ

Smoke- und Sanity-Tests

Beim Sanity-Test wird festgestellt, ob es sinnvoll ist, mit weiteren Tests fortzufahren. ⓘ

Smoke-Tests bestehen aus minimalen Versuchen, die Software zu betreiben, um festzustellen, ob es grundlegende Probleme gibt, die verhindern, dass die Software überhaupt funktioniert. Solche Tests können als Build-Verifikationstest verwendet werden. ⓘ

Regressionstests

Regressionstests konzentrieren sich auf das Auffinden von Fehlern, nachdem eine größere Codeänderung stattgefunden hat. Konkret geht es darum, Software-Regressionen aufzudecken, d. h. verschlechterte oder verlorene Funktionen, einschließlich alter Fehler, die wieder aufgetaucht sind. Solche Regressionen treten immer dann auf, wenn Softwarefunktionen, die zuvor korrekt funktionierten, nicht mehr wie vorgesehen funktionieren. Typischerweise treten Regressionen als unbeabsichtigte Folge von Programmänderungen auf, wenn der neu entwickelte Teil der Software mit dem bereits vorhandenen Code kollidiert. Regressionstests sind in der Regel der größte Testaufwand in der kommerziellen Softwareentwicklung, da zahlreiche Details in früheren Softwarefunktionen überprüft werden. Sogar neue Software kann entwickelt werden, wobei einige alte Testfälle zum Testen von Teilen des neuen Designs verwendet werden, um sicherzustellen, dass die frühere Funktionalität weiterhin unterstützt wird. ⓘ

Zu den üblichen Methoden der Regressionstests gehören die erneute Ausführung früherer Testfälle und die Überprüfung, ob zuvor behobene Fehler erneut aufgetreten sind. Die Testtiefe hängt von der Phase im Freigabeprozess und dem Risiko der hinzugefügten Funktionen ab. Sie können entweder vollständig sein, wenn es sich um Änderungen handelt, die erst spät in der Version hinzugefügt wurden oder die als risikoreich eingestuft werden, oder sie können sehr oberflächlich sein und aus positiven Tests für jede Funktion bestehen, wenn die Änderungen früh in der Version sind oder als risikoarm eingestuft werden. Bei Regressionstests ist es wichtig, starke Aussagen über das bestehende Verhalten zu machen. Zu diesem Zweck ist es möglich, neue Behauptungen in bestehenden Testfällen zu generieren und hinzuzufügen; dies wird als automatische Testerweiterung bezeichnet. ⓘ

Abnahmetest

Abnahmetests können zweierlei bedeuten:

Ein Smoke-Test wird als Build-Akzeptanztest vor weiteren Tests verwendet, z. B. vor der Integration oder Regression.
Abnahmetests, die vom Kunden durchgeführt werden, oft in seiner Laborumgebung auf seiner eigenen Hardware, werden als User Acceptance Testing (UAT) bezeichnet. Abnahmetests können als Teil des Übergabeprozesses zwischen zwei beliebigen Entwicklungsphasen durchgeführt werden. ⓘ

Alpha-Tests

Alpha-Tests sind simulierte oder tatsächliche Betriebstests durch potenzielle Benutzer/Kunden oder ein unabhängiges Testteam am Standort des Entwicklers. Alphatests werden häufig bei Standardsoftware als eine Art interner Abnahmetest durchgeführt, bevor die Software in den Betatest geht. ⓘ

Beta-Tests

Beta-Tests folgen auf Alpha-Tests und können als eine Form der externen Benutzerakzeptanztests betrachtet werden. Versionen der Software, die als Betaversionen bezeichnet werden, werden für einen begrenzten Personenkreis außerhalb des Programmierteams, die so genannten Betatester, freigegeben. Die Software wird für Gruppen von Personen freigegeben, damit durch weitere Tests sichergestellt werden kann, dass das Produkt nur wenige Fehler oder Bugs aufweist. Betaversionen können der Öffentlichkeit zur Verfügung gestellt werden, um das Feedbackfeld auf eine maximale Anzahl künftiger Nutzer zu erweitern und den Wert des Produkts früher, für einen längeren oder sogar unbestimmten Zeitraum zu liefern (perpetual beta). ⓘ

Funktionale vs. nicht-funktionale Tests

Funktionstests beziehen sich auf Aktivitäten, die eine bestimmte Aktion oder Funktion des Codes überprüfen. Diese sind in der Regel in der Anforderungsdokumentation des Codes zu finden, obwohl einige Entwicklungsmethoden auf der Grundlage von Anwendungsfällen oder User Stories arbeiten. Funktionale Tests beantworten in der Regel die Frage "Kann der Benutzer dies tun" oder "Funktioniert diese bestimmte Funktion". ⓘ

Nicht-funktionale Tests beziehen sich auf Aspekte der Software, die nicht mit einer bestimmten Funktion oder Benutzeraktion zusammenhängen, wie z. B. Skalierbarkeit oder andere Leistung, Verhalten unter bestimmten Einschränkungen oder Sicherheit. Durch das Testen wird die Sollbruchstelle ermittelt, d. h. der Punkt, an dem die extreme Skalierbarkeit oder Leistung zu einer instabilen Ausführung führt. Nicht-funktionale Anforderungen sind in der Regel solche, die die Qualität des Produkts widerspiegeln, insbesondere im Zusammenhang mit der Eignungsperspektive seiner Benutzer. ⓘ

Geschäftsprozesstest: ... das Zusammenwirken von Programmteilen eines Geschäftsprozesses.

ähnlich wie End-to-End Test: ... Funktionen des Systems über alle Schritte hinweg (z. B. von der Benutzerschnittstelle bis zur Datenbank).

Verhaltenstest (behaviour test): ... die Anwendung aus der Sicht von Benutzern; bei werden unterschieden:

Featuretest (oder Funktionstest): ... eine einzelne vom Benutzer ausführbare Funktion.
Fähigkeitstest (englisch: capability test): ... ob eine bestimmte Benutzertätigkeit i. Z. mit den getesteten Funktionen ausgeführt werden kann.
Akzeptanztest (auch User Akzeptanztest UAT): ... ob die Software vor allem hinsichtlich ihrer Benutzeroberfläche definierte Anforderungen/Erwartungen erfüllt.

Oberflächentest: ... die Benutzerschnittstellen des Systems (z. B. Verständlichkeit, Anordnung von Informationen, Hilfefunktionen); für Dialogprogramme auch GUI-Test oder UI-Test genannt. ⓘ

Kontinuierliches Testen

Kontinuierliches Testen ist der Prozess der Ausführung automatisierter Tests als Teil der Softwarebereitstellungspipeline, um sofortiges Feedback über die mit einem Software-Release-Kandidaten verbundenen Geschäftsrisiken zu erhalten. Kontinuierliches Testen umfasst die Validierung sowohl funktionaler als auch nicht-funktionaler Anforderungen; der Umfang des Testens erstreckt sich von der Validierung von Bottom-up-Anforderungen oder User Stories bis hin zur Bewertung der Systemanforderungen im Zusammenhang mit übergreifenden Geschäftszielen. ⓘ

Destruktives Testen

Beim destruktiven Testen wird versucht, die Software oder ein Teilsystem zum Versagen zu bringen. Dabei wird überprüft, ob die Software auch dann ordnungsgemäß funktioniert, wenn sie ungültige oder unerwartete Eingaben erhält, wodurch die Robustheit der Eingabevalidierung und der Fehlerverwaltungsroutinen nachgewiesen wird. Software-Fehlerinjektion in Form von Fuzzing ist ein Beispiel für Fehlertests. Verschiedene kommerzielle Tools für nicht-funktionale Tests sind auf der Seite zur Software-Fehlerinjektion verlinkt; außerdem gibt es zahlreiche Open-Source- und kostenlose Software-Tools, die zerstörerische Tests durchführen. ⓘ

Software-Leistungstests

Leistungstests werden im Allgemeinen durchgeführt, um festzustellen, wie ein System oder Teilsystem in Bezug auf Reaktionsfähigkeit und Stabilität unter einer bestimmten Arbeitslast funktioniert. Sie können auch dazu dienen, andere Qualitätsmerkmale des Systems wie Skalierbarkeit, Zuverlässigkeit und Ressourcennutzung zu untersuchen, zu messen, zu validieren oder zu verifizieren. ⓘ

Bei Lasttests geht es in erster Linie darum, zu prüfen, ob das System unter einer bestimmten Last, sei es eine große Datenmenge oder eine große Anzahl von Benutzern, weiterarbeiten kann. Dies wird allgemein als Skalierbarkeit von Software bezeichnet. Die damit zusammenhängende Aktivität des Lasttests wird, wenn sie als nicht-funktionale Aktivität durchgeführt wird, oft als Dauertest bezeichnet. Volumentests sind eine Möglichkeit, Softwarefunktionen zu testen, auch wenn bestimmte Komponenten (z. B. eine Datei oder eine Datenbank) radikal an Größe zunehmen. Stresstests sind eine Möglichkeit, die Zuverlässigkeit unter unerwarteten oder seltenen Arbeitsbelastungen zu testen. Stabilitätstests (oft auch als Last- oder Ausdauertests bezeichnet) prüfen, ob die Software innerhalb eines akzeptablen Zeitraums oder darüber hinaus kontinuierlich gut funktionieren kann. ⓘ

Über die spezifischen Ziele von Leistungstests besteht wenig Einigkeit. Die Begriffe Lasttests, Leistungstests, Skalierbarkeitstests und Volumentests werden oft synonym verwendet. ⓘ

Echtzeitsoftwaresysteme haben strenge Zeitvorgaben. Um zu prüfen, ob die Zeitvorgaben eingehalten werden, werden Echtzeittests eingesetzt. ⓘ

Gebrauchstauglichkeitstests

Mit Usability-Tests wird geprüft, ob die Benutzeroberfläche einfach zu bedienen und zu verstehen ist. Dabei geht es hauptsächlich um die Nutzung der Anwendung. Diese Art von Tests kann nicht automatisiert werden; es werden tatsächliche menschliche Benutzer benötigt, die von erfahrenen UI-Designern beobachtet werden. ⓘ

Prüfung der Zugänglichkeit

Zugänglichkeitstests können die Einhaltung von Standards umfassen, wie zum Beispiel:

Americans with Disabilities Act von 1990
Abschnitt 508 Änderung des Rehabilitationsgesetzes von 1973
Web Accessibility Initiative (WAI) des World Wide Web Consortium (W3C) ⓘ

Sicherheitstests

Sicherheitstests sind für Software, die vertrauliche Daten verarbeitet, unerlässlich, um ein Eindringen in das System durch Hacker zu verhindern. ⓘ

Die Internationale Organisation für Normung (ISO) definiert dies als "eine Art von Tests, die durchgeführt wird, um zu bewerten, inwieweit ein Testobjekt und die damit verbundenen Daten und Informationen geschützt sind, so dass unbefugte Personen oder Systeme sie nicht verwenden, lesen oder verändern können und befugten Personen oder Systemen der Zugang zu ihnen nicht verwehrt wird". ⓘ

Internationalisierung und Lokalisierung

Durch die Prüfung der Internationalisierung und Lokalisierung wird sichergestellt, dass die Software in verschiedenen Sprachen und geografischen Regionen verwendet werden kann. Der Prozess der Pseudolokalisierung wird verwendet, um die Fähigkeit einer Anwendung zu testen, in eine andere Sprache übersetzt zu werden, und um leichter zu erkennen, wenn der Lokalisierungsprozess neue Fehler in das Produkt einführt. ⓘ

Beim Globalisierungstest wird überprüft, ob die Software an eine neue Kultur (z. B. unterschiedliche Währungen oder Zeitzonen) angepasst ist. ⓘ

Auch die tatsächliche Übersetzung in menschliche Sprachen muss getestet werden. Mögliche Fehler bei der Lokalisierung und Globalisierung sind:

Software wird oft durch die Übersetzung einer Liste von Zeichenfolgen aus dem Kontext heraus lokalisiert, und der Übersetzer wählt möglicherweise die falsche Übersetzung für eine mehrdeutige Ausgangszeichenfolge.
Technische Terminologie kann inkonsistent werden, wenn das Projekt von mehreren Personen ohne angemessene Koordination übersetzt wird oder wenn der Übersetzer unvorsichtig ist.
Wörtliche Wort-für-Wort-Übersetzungen können in der Zielsprache unangemessen, künstlich oder zu technisch klingen.
Nicht übersetzte Meldungen in der Ausgangssprache können im Quellcode fest kodiert bleiben.
Einige Meldungen können zur Laufzeit automatisch erstellt werden, und die daraus resultierende Zeichenkette kann ungrammatisch, funktional falsch, irreführend oder verwirrend sein.
Die Software kann eine Tastenkombination verwenden, die im Tastaturlayout der Ausgangssprache keine Funktion hat, aber für die Eingabe von Zeichen im Layout der Zielsprache verwendet wird.
Die Software unterstützt möglicherweise nicht die Zeichenkodierung der Zielsprache.
Schriftarten und Schriftgrößen, die in der Ausgangssprache geeignet sind, können in der Zielsprache ungeeignet sein; so können beispielsweise CJK-Zeichen unlesbar werden, wenn die Schrift zu klein ist.
Eine Zeichenkette in der Zielsprache kann länger sein, als die Software verarbeiten kann. Dies kann dazu führen, dass die Zeichenfolge für den Benutzer teilweise unsichtbar wird oder dass die Software abstürzt oder nicht richtig funktioniert.
Die Software unterstützt möglicherweise das Lesen oder Schreiben von bidirektionalem Text nicht richtig.
Die Software zeigt möglicherweise Bilder mit Text an, der nicht lokalisiert wurde.
Lokalisierte Betriebssysteme haben möglicherweise anders benannte Systemkonfigurationsdateien und Umgebungsvariablen sowie unterschiedliche Formate für Datum und Währung. ⓘ

Entwicklungstests

Entwicklungstests sind ein Softwareentwicklungsprozess, der die synchronisierte Anwendung eines breiten Spektrums von Fehlervermeidungs- und -erkennungsstrategien umfasst, um Risiken, Zeit und Kosten der Softwareentwicklung zu reduzieren. Er wird vom Softwareentwickler oder -ingenieur während der Konstruktionsphase des Softwareentwicklungslebenszyklus durchgeführt. Development Testing zielt darauf ab, Konstruktionsfehler zu beseitigen, bevor der Code weiteren Tests unterzogen wird; diese Strategie soll die Qualität der resultierenden Software sowie die Effizienz des gesamten Entwicklungsprozesses erhöhen. ⓘ

Je nach den Erwartungen des Unternehmens an die Software-Entwicklung kann das Development Testing statische Code-Analysen, Datenflussanalysen, Metrik-Analysen, Peer-Code-Reviews, Unit-Tests, Code-Abdeckungsanalysen, Rückverfolgbarkeit und andere Software-Testverfahren umfassen. ⓘ

A/B-Tests

Beim A/B-Testing wird ein kontrolliertes Experiment durchgeführt, um festzustellen, ob eine vorgeschlagene Änderung effektiver ist als der derzeitige Ansatz. Die Kunden werden entweder zu einer aktuellen Version (Kontrolle) einer Funktion oder zu einer geänderten Version (Behandlung) geleitet, und es werden Daten gesammelt, um festzustellen, welche Version das gewünschte Ergebnis besser erreicht. ⓘ

Gleichzeitige Tests

Parallel- oder Gleichzeitigkeitstests bewerten das Verhalten und die Leistung von Software und Systemen, die mit gleichzeitiger Datenverarbeitung arbeiten, im Allgemeinen unter normalen Nutzungsbedingungen. Typische Probleme, die durch diese Art von Tests aufgedeckt werden, sind Deadlocks, Race Conditions und Probleme mit gemeinsamem Speicher/Ressourcenhandling. ⓘ

Konformitätstests oder Typentests

Bei Softwaretests wird durch Konformitätstests überprüft, ob ein Produkt gemäß den vorgegebenen Standards funktioniert. Compiler werden zum Beispiel ausgiebig getestet, um festzustellen, ob sie den anerkannten Standard für diese Sprache erfüllen. ⓘ

Tests zum Vergleich der Ausgabe

Das Erstellen einer Anzeige der erwarteten Ausgabe, sei es als Datenvergleich von Text oder Screenshots der Benutzeroberfläche, wird manchmal als Snapshot-Test oder Golden Master-Test bezeichnet. Im Gegensatz zu vielen anderen Testformen können bei diesem Test Fehler nicht automatisch erkannt werden, sondern es ist erforderlich, dass ein Mensch die Ausgabe auf Inkonsistenzen hin auswertet. ⓘ

Eigenschaftstests

Das Testen von Eigenschaften ist eine Testtechnik, bei der nicht behauptet wird, dass bestimmte Eingaben zu bestimmten erwarteten Ausgaben führen, sondern bei der nach dem Zufallsprinzip viele Eingaben generiert werden, das Programm mit allen Eingaben ausgeführt wird und der Wahrheitsgehalt einer "Eigenschaft" bestätigt wird, die für jedes Paar von Eingaben und Ausgaben wahr sein sollte. Zum Beispiel sollte jede Eingabe einer Sortierfunktion die gleiche Länge wie ihre Ausgabe haben. Jede Ausgabe einer Sortierfunktion sollte eine monoton wachsende Liste sein. ⓘ

Eigenschaftsprüfungsbibliotheken ermöglichen es dem Benutzer, die Strategie zu steuern, mit der zufällige Eingaben konstruiert werden, um die Abdeckung degenerierter Fälle oder Eingaben mit spezifischen Mustern zu gewährleisten, die erforderlich sind, um Aspekte der zu prüfenden Implementierung vollständig zu testen. ⓘ

Eigenschaftstests werden manchmal auch als "generative Tests" oder "QuickCheck-Tests" bezeichnet, da sie durch die Haskell-Bibliothek "QuickCheck" eingeführt und populär gemacht wurden. ⓘ

Metamorphes Testen

Metamorphes Testen (MT) ist eine eigenschaftsbasierte Softwaretesttechnik, die ein effektiver Ansatz zur Lösung des Testorakelproblems und des Problems der Testfallgenerierung sein kann. Das Testorakelproblem ist die Schwierigkeit, die erwarteten Ergebnisse ausgewählter Testfälle zu bestimmen oder festzustellen, ob die tatsächlichen Ergebnisse mit den erwarteten Ergebnissen übereinstimmen. ⓘ

VCR-Tests

VCR-Tests, auch bekannt als "Playback-Tests" oder "Record/Replay"-Tests, sind eine Testtechnik zur Erhöhung der Zuverlässigkeit und Geschwindigkeit von Regressionstests, die eine Komponente einbeziehen, mit der nur langsam oder unzuverlässig kommuniziert werden kann, häufig eine API eines Drittanbieters, die sich der Kontrolle des Testers entzieht. Dabei werden die Interaktionen des Systems mit der externen Komponente aufgezeichnet ("Kassette") und dann bei späteren Testläufen als Ersatz für die Kommunikation mit dem externen System wiedergegeben. ⓘ

Diese Technik wurde in der Webentwicklung durch die Ruby-Bibliothek vcr populär gemacht. ⓘ

Testverfahren

Traditionelles Wasserfall-Entwicklungsmodell

Eine gängige Praxis in der Wasserfallentwicklung ist, dass die Tests von einer unabhängigen Gruppe von Testern durchgeführt werden. Dies kann geschehen:

nachdem die Funktionalität entwickelt wurde, aber bevor sie an den Kunden ausgeliefert wird. Diese Praxis führt häufig dazu, dass die Testphase als Projektpuffer genutzt wird, um Projektverzögerungen auszugleichen, wodurch die für das Testen aufgewendete Zeit beeinträchtigt wird.
zum gleichen Zeitpunkt, an dem das Entwicklungsprojekt beginnt, als kontinuierlicher Prozess bis zum Abschluss des Projekts. ⓘ

Aber auch im Wasserfall-Entwicklungsmodell werden die Unit-Tests häufig vom Software-Entwicklungsteam durchgeführt, selbst wenn die weiteren Tests von einem separaten Team vorgenommen werden. ⓘ

Agiles oder XP-Entwicklungsmodell

Im Gegensatz dazu verfolgen einige aufstrebende Software-Disziplinen wie Extreme Programming und die agile Software-Entwicklungsbewegung ein Modell der "testgesteuerten Softwareentwicklung". In diesem Prozess werden die Unit-Tests zuerst von den Software-Ingenieuren geschrieben (oft mit Pair Programming in der Extreme Programming-Methodik). Es wird erwartet, dass die Tests zunächst fehlschlagen. Nach jedem fehlgeschlagenen Test wird gerade so viel Code geschrieben, dass er bestanden wird. Das bedeutet, dass die Testsuiten laufend aktualisiert werden, wenn neue Fehlerbedingungen und Eckfälle entdeckt werden, und dass sie mit allen entwickelten Regressionstests integriert werden. Unit-Tests werden zusammen mit dem übrigen Software-Quellcode gepflegt und in der Regel in den Build-Prozess integriert (wobei inhärent interaktive Tests in einen teilweise manuellen Build-Akzeptanzprozess verbannt werden). ⓘ

Die obersten Ziele dieses Testprozesses sind die Unterstützung der kontinuierlichen Integration und die Verringerung der Fehlerquote. ⓘ

Diese Methodik erhöht den Testaufwand, der von der Entwicklung geleistet wird, bevor er ein formales Testteam erreicht. Bei einigen anderen Entwicklungsmodellen erfolgt der Großteil der Testdurchführung nach der Definition der Anforderungen und dem Abschluss des Codierungsprozesses. ⓘ

Ein Beispiel für einen Testzyklus

Obwohl es von Organisation zu Organisation Unterschiede gibt, gibt es einen typischen Zyklus für das Testen. Das nachstehende Beispiel ist in Organisationen üblich, die das Wasserfall-Entwicklungsmodell verwenden. Die gleichen Praktiken finden sich auch in anderen Entwicklungsmodellen, sind aber möglicherweise nicht so klar und deutlich. ⓘ

Analyse der Anforderungen: Das Testen sollte in der Anforderungsphase des Lebenszyklus der Softwareentwicklung beginnen. Während der Entwurfsphase ermitteln die Tester, welche Aspekte eines Entwurfs testbar sind und mit welchen Parametern diese Tests funktionieren.
Testplanung: Teststrategie, Testplan, Erstellung einer Testumgebung. Da während des Testens viele Aktivitäten durchgeführt werden, ist ein Plan erforderlich.
Testentwicklung: Testverfahren, Testszenarien, Testfälle, Testdatensätze, Testskripte für das Testen von Software.
Testdurchführung: Die Tester führen die Software auf der Grundlage der Pläne und Testdokumente aus und melden dann alle gefundenen Fehler an das Entwicklungsteam. Dieser Teil kann komplex sein, wenn die Tests ohne Programmierkenntnisse durchgeführt werden.
Testbericht: Nach Abschluss der Tests erstellen die Tester Metriken und Abschlussberichte über ihren Testaufwand und darüber, ob die getestete Software für die Veröffentlichung bereit ist oder nicht.
Analyse der Testergebnisse: Die Fehleranalyse wird vom Entwicklungsteam in der Regel zusammen mit dem Kunden durchgeführt, um zu entscheiden, welche Fehler zugewiesen, behoben, zurückgewiesen (d. h. die Software funktioniert ordnungsgemäß) oder zur späteren Bearbeitung zurückgestellt werden sollen.
Fehler-Nachprüfung: Sobald ein Fehler vom Entwicklungsteam behoben wurde, wird er vom Testteam erneut getestet.
Regressionstests: Es ist üblich, für jede Integration neuer, geänderter oder korrigierter Software ein kleines Testprogramm zu erstellen, das aus einer Teilmenge von Tests besteht, um sicherzustellen, dass die letzte Lieferung nichts kaputt gemacht hat und dass das Softwareprodukt als Ganzes noch korrekt funktioniert.
Test-Abschluss: Sobald der Test die Abschlusskriterien erfüllt, werden die Aktivitäten wie die Erfassung der wichtigsten Ergebnisse, Lessons Learned, Resultate, Protokolle und Dokumente im Zusammenhang mit dem Projekt archiviert und als Referenz für zukünftige Projekte verwendet. ⓘ

Automatisierte Tests

Insbesondere bei Tests, die häufig wiederholt werden, ist deren Automatisierung angeraten. Dies ist vor allem bei Regressionstests und bei testgetriebener Entwicklung der Fall. Darüber hinaus kommt Testautomatisierung bei manuell nicht oder nur schwer durchführbaren Tests zum Einsatz (z. B. Lasttests).

Durch Regressionstests wird nach Softwareänderungen meist im Zuge des System- oder Abnahmetests der fehlerfreie Erhalt der bisherigen Funktionalität überprüft.
Bei der testgetriebenen Entwicklung werden die Tests im Zuge der Softwareentwicklung im Idealfall vor jeder Änderung ergänzt und nach jeder Änderung ausgeführt.

Bei nicht automatisierten Tests ist in beiden Fällen der Aufwand so groß, dass häufig auf die Tests verzichtet wird. ⓘ

Die Automatisierung kann zwar nicht alles reproduzieren, was ein Mensch tun kann (und alle Möglichkeiten, die er sich ausdenkt), aber sie kann für Regressionstests sehr nützlich sein. Sie erfordert jedoch eine gut entwickelte Test-Suite mit Testskripten, um wirklich nützlich zu sein. ⓘ

Testwerkzeuge

Programmtests und Fehlererkennung können durch Testwerkzeuge und Debugger erheblich unterstützt werden. Zu den Test-/Debugging-Werkzeugen gehören Funktionen wie:

Programmmonitore, die eine vollständige oder teilweise Überwachung des Programmcodes ermöglichen, einschließlich:
- Befehlssatzsimulator, der eine vollständige Überwachung auf Befehlsebene und Trace-Funktionen ermöglicht
- Hypervisor, der die vollständige Kontrolle über die Ausführung von Programmcode ermöglicht, einschließlich
- Programmanimation, die eine schrittweise Ausführung und bedingte Haltepunkte auf Quellcodeebene oder im Maschinencode ermöglicht
- Code-Abdeckungsberichte
Formatierter Dump oder symbolisches Debugging, Werkzeuge, die eine Inspektion von Programmvariablen bei Fehlern oder an ausgewählten Punkten ermöglichen
Automatisierte funktionale GUI-Tests (Graphical User Interface) werden verwendet, um Tests auf Systemebene über die GUI zu wiederholen
Benchmarks, die Leistungsvergleiche während der Laufzeit ermöglichen
Leistungsanalyse (oder Profiling-Tools), die dabei helfen können, Hot Spots und Ressourcenverbrauch aufzuzeigen ⓘ

Einige dieser Funktionen können in ein einziges zusammengesetztes Werkzeug oder eine integrierte Entwicklungsumgebung (IDE) integriert werden. ⓘ

Aufzeichnung und Wiedergabe

Capture- und Replay-Tests bestehen in der Erfassung von End-to-End-Nutzungsszenarien während der Interaktion mit einer Anwendung und in der Umwandlung dieser Szenarien in Testfälle. Zu den möglichen Anwendungen von Capture und Replay gehört die Generierung von Regressionstests. Das SCARPE-Tool erfasst selektiv eine Teilmenge der untersuchten Anwendung, während diese ausgeführt wird. JRapture erfasst die Abfolge von Interaktionen zwischen einem ausgeführten Java-Programm und Komponenten auf dem Host-System wie Dateien oder Ereignisse auf grafischen Benutzeroberflächen. Diese Sequenzen können dann für beobachtungsbasierte Tests wiedergegeben werden. Saieva et al. schlagen vor, Ad-hoc-Tests zu generieren, die aufgezeichnete Benutzerausführungsspuren wiedergeben, um Patches für kritische Sicherheitslücken zu testen. Pankti sammelt Objektprofile in der Produktion, um gezielte differenzielle Unit-Tests zu erstellen. Dieses Tool verbessert die Erfassung und Wiedergabe durch die systematische Generierung von abgeleiteten Testorakeln. ⓘ

Messungen bei Softwaretests

Zu den Qualitätsmaßstäben gehören Themen wie Korrektheit, Vollständigkeit, Sicherheit und ISO/IEC 9126-Anforderungen wie Leistungsfähigkeit, Zuverlässigkeit, Effizienz, Portabilität, Wartbarkeit, Kompatibilität und Benutzerfreundlichkeit. ⓘ

Es gibt eine Reihe häufig verwendeter Software-Metriken oder -Maße, die zur Bestimmung des Zustands der Software oder der Angemessenheit der Tests herangezogen werden. ⓘ

Hierarchie der Testschwierigkeiten

Auf der Grundlage der Anzahl der Testfälle, die erforderlich sind, um in jedem Kontext eine vollständige Testsuite zu erstellen (d. h. eine Testsuite, die, wenn sie auf die zu testende Implementierung angewendet wird, genügend Informationen sammelt, um genau zu bestimmen, ob das System gemäß einer Spezifikation korrekt oder inkorrekt ist), wurde eine Hierarchie der Testschwierigkeit vorgeschlagen.

Sie umfasst die folgenden Testbarkeitsklassen:

Klasse I: es gibt eine endliche, vollständige Testsuite.
Klasse II: Jede partielle Unterscheidungsrate (d.h. jede unvollständige Fähigkeit, korrekte Systeme von inkorrekten Systemen zu unterscheiden) kann mit einer endlichen Testreihe erreicht werden.
Klasse III: Es existiert eine abzählbare vollständige Testsuite.
Klasse IV: Es existiert eine vollständige Testsuite.
Klasse V: alle Fälle. ⓘ

Es wurde bewiesen, dass jede Klasse strikt in der nächsten enthalten ist. Wenn wir zum Beispiel davon ausgehen, dass das Verhalten der zu testenden Implementierung durch einen deterministischen endlichen Automaten für einige bekannte endliche Mengen von Eingaben und Ausgaben und mit einer bekannten Anzahl von Zuständen beschrieben werden kann, gehört das Testen zur Klasse I (und allen nachfolgenden Klassen). Ist die Anzahl der Zustände jedoch nicht bekannt, so gehört sie nur zu allen Klassen ab Klasse II. Wenn die zu prüfende Implementierung ein deterministischer endlicher Automat sein muss, der die Spezifikation für eine einzelne Spur (und ihre Fortsetzungen) nicht erfüllt, und die Anzahl der Zustände nicht bekannt ist, dann gehört er nur zu den Klassen ab Klasse III. Das Testen von Zeitmaschinen, bei denen Übergänge ausgelöst werden, wenn Eingaben innerhalb eines real begrenzten Intervalls erzeugt werden, gehört nur zu den Klassen ab Klasse IV, während das Testen vieler nichtdeterministischer Systeme nur zu Klasse V gehört (aber nicht alle, und einige gehören sogar zu Klasse I). Die Einordnung in Klasse I erfordert nicht die Einfachheit des angenommenen Berechnungsmodells, da einige Testfälle, die in einer beliebigen Programmiersprache geschriebene Implementierungen einbeziehen, und das Testen von Implementierungen, die als Maschinen definiert sind, die von kontinuierlichen Größen abhängen, nachweislich zu Klasse I gehören. Andere ausgearbeitete Fälle, wie der Testrahmen von Matthew Hennessy unter Must-Semantik und temporale Maschinen mit rationalen Timeouts, gehören zu Klasse II. ⓘ

Test-Artefakte

Ein Softwaretestprozess kann mehrere Artefakte hervorbringen. Die tatsächlich produzierten Artefakte sind ein Faktor des verwendeten Softwareentwicklungsmodells sowie der Bedürfnisse der Beteiligten und der Organisation. ⓘ

Testplan: Ein Testplan ist ein Dokument, in dem der Ansatz für die geplanten Testaktivitäten detailliert beschrieben wird. Der Plan kann Aspekte wie Ziele, Umfang, Prozesse und Verfahren, Personalanforderungen und Notfallpläne enthalten. Der Testplan kann in Form eines einzelnen Plans vorliegen, der alle Testarten (wie ein Abnahme- oder Systemtestplan) und Planungsüberlegungen enthält, oder er kann als Gesamttestplan herausgegeben werden, der einen Überblick über mehr als einen detaillierten Testplan bietet (ein Plan eines Plans). Ein Testplan kann in einigen Fällen Teil einer umfassenden "Teststrategie" sein, die die allgemeinen Testansätze dokumentiert, die ihrerseits ein Master-Testplan oder sogar ein separates Artefakt sein kann.
Rückverfolgbarkeitsmatrix: Eine Rückverfolgbarkeitsmatrix ist eine Tabelle, die Anforderungs- oder Entwurfsdokumente mit Testdokumenten korreliert. Sie wird verwendet, um Tests zu ändern, wenn die zugehörigen Quelldokumente geändert werden, um Testfälle für die Ausführung auszuwählen, wenn Regressionstests unter Berücksichtigung der Anforderungsabdeckung geplant werden.
Testfall: Ein Testfall besteht normalerweise aus einem eindeutigen Bezeichner, Anforderungsreferenzen aus einer Entwurfsspezifikation, Vorbedingungen, Ereignissen, einer Reihe von Schritten (auch als Aktionen bezeichnet), die zu befolgen sind, Eingaben, Ausgaben, erwarteten Ergebnissen und dem tatsächlichen Ergebnis. Klinisch gesehen besteht ein Testfall aus einer Eingabe und einem erwarteten Ergebnis. Dies kann so knapp sein wie "für Bedingung x ist das abgeleitete Ergebnis y", obwohl Testfälle normalerweise das Eingabeszenario und die zu erwartenden Ergebnisse detaillierter beschreiben. Gelegentlich kann es sich um eine Reihe von Schritten handeln (häufig sind die Schritte jedoch in einer separaten Testprozedur enthalten, die aus Gründen der Wirtschaftlichkeit mit mehreren Testfällen durchgeführt werden kann), aber mit einem erwarteten Ergebnis oder einer erwarteten Folge. Bei den optionalen Feldern handelt es sich um die Testfall-ID, die Nummer des Testschritts oder der Ausführungsreihenfolge, die zugehörige(n) Anforderung(en), die Testtiefe, die Testkategorie, den Autor und die Kontrollkästchen, die angeben, ob der Test automatisierbar ist und automatisiert wurde. Größere Testfälle können auch vorausgesetzte Zustände oder Schritte und Beschreibungen enthalten. Ein Testfall sollte auch einen Platz für das eigentliche Ergebnis enthalten. Diese Schritte können in einem Textverarbeitungsdokument, einer Tabellenkalkulation, einer Datenbank oder in anderen gängigen Repositories gespeichert werden. In einem Datenbanksystem können Sie auch frühere Testergebnisse einsehen und erfahren, wer die Ergebnisse erzeugt hat und welche Systemkonfiguration zur Erzeugung dieser Ergebnisse verwendet wurde. Diese früheren Ergebnisse werden normalerweise in einer separaten Tabelle gespeichert.
Testskript: Ein Testskript ist eine Prozedur oder ein Programmiercode, der Benutzeraktionen nachbildet. Ursprünglich wurde der Begriff von dem Arbeitsergebnis abgeleitet, das von automatisierten Regressionstest-Tools erstellt wurde. Ein Testfall dient als Grundlage für die Erstellung von Testskripten mit Hilfe eines Tools oder eines Programms.
Test-Suite: Der gebräuchlichste Begriff für eine Sammlung von Testfällen ist Testsuite. Die Testsuite enthält oft auch detailliertere Anweisungen oder Ziele für jede Sammlung von Testfällen. Sie enthält auf jeden Fall einen Abschnitt, in dem der Tester die beim Testen verwendete Systemkonfiguration angibt. Eine Gruppe von Testfällen kann auch vorausgesetzte Zustände oder Schritte und Beschreibungen der folgenden Tests enthalten.
Testvorrichtungen oder Testdaten: In den meisten Fällen werden mehrere Sätze von Werten oder Daten verwendet, um die gleiche Funktionalität einer bestimmten Funktion zu testen. Alle Testwerte und veränderbaren Umgebungskomponenten werden in separaten Dateien gesammelt und als Testdaten gespeichert. Es ist auch sinnvoll, diese Daten dem Kunden und dem Produkt oder Projekt zur Verfügung zu stellen. Es gibt verschiedene Techniken zur Erzeugung von Testdaten.
Test-Kabelbaum: Die Software, die Werkzeuge, die Muster der Dateneingabe und -ausgabe sowie die Konfigurationen werden zusammen als Test-Kabelbaum bezeichnet.
Testlauf: Ein Bericht über die Ergebnisse der Ausführung eines Testfalls oder einer Testsuite. ⓘ

Hier werden alle Festlegungen und Vorbereitungen getroffen, die erforderlich sind, um einen bestimmten Testfall (unterscheide logischer und konkreter Testfall) ausführen zu können. ⓘ

Beispiele für einzelne Aktivitäten: Testfallfindung und Testfalloptimierung (orientiert an Testzielen und ggf. Testpfad-Kategorien); Beschreiben je Testfall (was genau ist zu testen); Vorbedingungen (inkl. Festlegen von Abhängigkeiten zu anderen Testfällen); Festlegen und Erstellen der Eingabedaten; Festlegungen zum Testablauf und zur Testreihenfolge; Festlegen Soll-Ergebnis; Bedingung(en) für 'Test erfüllt'; ... ⓘ

Zertifizierungen

Es gibt mehrere Zertifizierungsprogramme, um die beruflichen Ambitionen von Software-Testern und Qualitätssicherungsspezialisten zu unterstützen. Wie im Abschnitt "Kontroverse" erwähnt, argumentieren einige Praktiker, dass der Testbereich noch nicht reif für eine Zertifizierung ist. ⓘ

Kontroverse

Einige der wichtigsten Kontroversen im Bereich des Softwaretestens sind:

Agil vs. traditionell: Sollten Tester lernen, unter Bedingungen der Unsicherheit und des ständigen Wandels zu arbeiten, oder sollten sie eine "Prozessreife" anstreben? Die agile Testbewegung erfreut sich seit 2006 vor allem in kommerziellen Kreisen wachsender Beliebtheit, während staatliche und militärische Softwareanbieter diese Methodik, aber auch die traditionellen Test-Last-Modelle (z. B. im Wasserfallmodell) anwenden.
Manuelles vs. automatisiertes Testen: Einige Autoren sind der Meinung, dass die Testautomatisierung im Verhältnis zu ihrem Wert so teuer ist, dass sie sparsam eingesetzt werden sollte. Die Testautomatisierung kann dann als eine Möglichkeit zur Erfassung und Umsetzung der Anforderungen betrachtet werden. Generell gilt: Je größer das System und je komplexer es ist, desto höher ist der ROI der Testautomatisierung. Außerdem kann die Investition in Tools und Fachwissen über mehrere Projekte hinweg amortisiert werden, wenn der Wissensaustausch innerhalb einer Organisation stimmt.
Ist die Existenz der Softwaretestnorm ISO 29119 gerechtfertigt?: Aus den Reihen der kontextgesteuerten Schule des Softwaretests hat sich erheblicher Widerstand gegen die ISO 29119-Norm gebildet. Professionelle Testverbände, wie die International Society for Software Testing, haben versucht, die Norm zurückzuziehen.
Einige Praktiker erklären, der Testbereich sei noch nicht reif für eine Zertifizierung: Keine der derzeit angebotenen Zertifizierungen verlangt von den Bewerbern, dass sie ihre Fähigkeit zum Testen von Software nachweisen. Keine Zertifizierung basiert auf einem allgemein anerkannten Wissensfundus. Die Zertifizierung selbst kann nicht die Produktivität, die Fähigkeiten oder das praktische Wissen einer Person messen und kann nicht ihre Kompetenz oder Professionalität als Tester garantieren.
Studien zum Nachweis der relativen Kosten der Fehlerbehebung: Es gibt gegensätzliche Ansichten über die Anwendbarkeit von Studien, die den relativen Aufwand für die Behebung von Fehlern in Abhängigkeit von ihrer Einführung und Entdeckung aufzeigen sollen. Ein Beispiel:

Es wird allgemein angenommen, dass die Behebung eines Fehlers um so billiger ist, je früher er entdeckt wird. Die folgende Tabelle zeigt die Kosten für die Behebung des Fehlers in Abhängigkeit von der Phase, in der er gefunden wurde. Wenn beispielsweise ein Problem in den Anforderungen erst nach der Veröffentlichung gefunden wird, kostet die Behebung 10 bis 100 Mal mehr, als wenn es bereits bei der Anforderungsüberprüfung gefunden worden wäre. Mit dem Aufkommen moderner kontinuierlicher Bereitstellungspraktiken und Cloud-basierter Dienste können die Kosten für die erneute Bereitstellung und Wartung mit der Zeit sinken. ⓘ

Kosten für die Behebung eines Fehlers Zeitpunkt der Entdeckung ⓘ

Anforderungen Architektur Konstruktion Systemtest Post-Release

Zeit der Einführung Anforderungen 1× 3× 5–10× 10× 10–100×

Architektur – 1× 10× 15× 25–100×

Konstruktion – – 1× 10× 10–25×

ⓘ

Die Daten, auf die sich diese Tabelle stützt, sind spärlich. Laurent Bossavit sagt in seiner Analyse:

Die Kurve der "kleineren Projekte" stammt von nur zwei Teams von Studienanfängern, eine so kleine Stichprobe, dass eine Extrapolation auf "kleinere Projekte im Allgemeinen" völlig unhaltbar ist. In der GTE-Studie werden die Daten nicht erläutert, es wird lediglich gesagt, dass sie von zwei Projekten stammen, einem großen und einem kleinen. In der zitierten Studie über das "Safeguard"-Projekt von Bell Labs wird ausdrücklich bestritten, dass die feinkörnigen Daten, auf die Boehms Daten hinweisen, erhoben wurden. Die IBM-Studie (das Papier von Fagan) enthält Behauptungen, die Boehms Diagramm zu widersprechen scheinen, und keine numerischen Ergebnisse, die eindeutig mit seinen Datenpunkten übereinstimmen. ⓘ
Boehm zitiert nicht einmal ein Papier für die TRW-Daten, es sei denn, er schreibt für Making Software" im Jahr 2010, und dort zitiert er den Originalartikel von 1976. Es gibt eine große Studie, die bei TRW zur richtigen Zeit durchgeführt wurde, damit Boehm sie zitieren kann, aber dieses Papier enthält nicht die Art von Daten, die Boehms Behauptungen unterstützen würden.

ⓘ

Definition

Es gibt unterschiedliche Definitionen für den Softwaretest: Nach ANSI/IEEE Std. 610.12-1990 ist das Testen (engl. ‚Testing‘) „the process of operating a system or component under specified conditions, observing or recording the results and making an evaluation of some aspects of the system or component.“ ⓘ

Eine andere Definition liefert Ernst Denert, wonach der „Test […] der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen“ ist. ⓘ

Eine weitergehende Definition verwenden Pol, Koomen und Spillner: Unter Testen versteht man den Prozess des Planens, der Vorbereitung und der Messung, mit dem Ziel, die Eigenschaften eines IT-Systems festzustellen und den Unterschied zwischen dem tatsächlichen und dem erforderlichen Zustand aufzuzeigen. Bemerkenswert hierbei: Als Messgröße gilt 'der erforderliche Zustand', nicht nur die (möglicherweise fehlerhafte) Spezifikation. ⓘ

'Testen' ist ein wesentlicher Teil im Qualitätsmanagement von Projekten der Softwareentwicklung. ⓘ

Standardisierung

Im September 2013 wurde die Norm ISO/IEC/IEEE 29119 Software Testing veröffentlicht, die international erstmals viele (ältere) nationale Normen des Softwaretestens, wie z. B. die IEEE 829, zusammenfasst und ersetzt. Die Normreihe ISO/IEC 25000 ergänzt die Seite des Software-Engineering als Leitfaden für (die gemeinsamen) Qualitätskriterien und ersetzt die Norm ISO/IEC 9126. ⓘ

Ziele

Globales Ziel des Softwaretestens ist das Messen der Qualität des Softwaresystems. Dabei dienen definierte Anforderungen als Prüfreferenz, mittels derer ggf. vorhandene Fehler aufgedeckt werden. ISTQB: Der Wirkung von Fehlern (im produktiven Betrieb) wird damit vorgebeugt. ⓘ

Ein Rahmen für diese Anforderungen können die Qualitätsparameter gem. ISO/IEC 9126 sein, denen jeweils konkrete Detailanforderungen z. B. zur Funktionalität, Bedienbarkeit, Sicherheit usw. zugeordnet werden können. Im Besonderen ist auch die Erfüllung gesetzlicher und/oder vertraglicher Vorgaben nachzuweisen. ⓘ

Die Testergebnisse (die über verschiedene Testverfahren gewonnen werden) tragen zur Beurteilung der realen Qualität der Software bei – als Voraussetzung für deren Freigabe zum operativen Betrieb. Das Testen soll Vertrauen in die Qualität der Software schaffen. ⓘ

Individuelle Testziele: Da das Softwaretesten aus zahlreichen Einzelmaßnahmen besteht, die i. d. R. über mehrere Teststufen hinweg und an vielen Testobjekten ausgeführt werden, ergeben sich individuelle Testziele für jeden einzelnen Testfall und für jede Teststufe – wie z. B. Rechenfunktion X in Programm Y getestet, Schnittstellentest erfolgreich, Wiederinbetriebnahme getestet, Lasttest erfolgreich, Programm XYZ getestet usw. ⓘ

Testprozess / Testphasen

Pol, Koomen und Spillner beschreiben im Kap. 8.1 ‚TMap‘ ein Vorgehen nach einem Phasenmodell. Sie nennen dieses Vorgehen Testprozess, bestehend aus den Testphasen Testvorbereitung, Testspezifikation, Testdurchführung und -Auswertung, Testabschluss. Parallel sieht der Testprozess die Rahmenfunktionen Planung & Verwaltung vor. Das Vorgehen sei generisch, d. h., es wird – jeweils nach Erfordernis – für unterschiedliche Ebenen angewendet, für das Gesamtprojekt, für jede Teststufe und letztlich je Testobjekt und Testfall. ⓘ

Bei anderen Autoren oder Instituten finden sich zum Teil andere Gruppierungen und andere Bezeichnungen, die aber inhaltlich nahezu identisch sind. Z. B. wird bei ISTQB der fundamentale Testprozess mit folgenden Hauptaktivitäten definiert: Testplanung und Steuerung, Testanalyse und Testentwurf, Testrealisierung und Testdurchführung, Bewertung von Endekriterien und Bericht, Abschluss der Testaktivitäten. Die einzelnen Aktivitäten und deren Reihenfolge, die (im Testprozess festgelegt) für die einzelnen Testobjekte auszuführen sind – ggf. mehrfach, z. B. bei Testwiederholung/Regressionstest – nennt ISTQB ‚Testzyklus‘. ⓘ

Testaktivitäten werden (nach Pol, Koomen und Spillner) rollenspezifisch zu sog. Testfunktionen zusammengefasst: Testen, Testmanagement, Methodische Unterstützung, Technische Unterstützung, Funktionale Unterstützung, Verwaltung, Koordination und Beratung, Anwendungsintegrator, TAKT-Architekt und TAKT-Ingenieur (bei Einsatz von Testautomatisierung; TAKT = Testen, Automatisierung, Kenntnisse, Tools). Diese Funktionen (Rollen) haben Schwerpunkte in bestimmten Testphasen; sie können im Projekt selbst eingerichtet sein oder über spezialisierte Organisationseinheiten einbezogen werden. ⓘ

Personenbezogen können u. a. die folgenden Rollen beim Testen unterschieden werden:

Testmanager (Führung): Der Testmanager entwickelt die Teststrategie, plant die Ressourcen und dient als Ansprechperson für Projektleitung und Management. Wichtige Charakterzüge sind dabei Verlässlichkeit und Integrität.
Testarchitekt, Testengineer: Der Testengineer unterstützt den Testmanager bei der Entwicklung der Teststrategie. Zudem ist er für die optimale Auswahl der Testmethoden und Testwerkzeuge zuständig. Die Planung und Entwicklung einer projektspezifischen Testinfrastruktur liegt auch in seinem Aufgabenbereich.
Testanalyst: Der Testanalyst bestimmt die nötigen Testsszenarien, indem er sie aus den Anforderungen ableitet. Zudem definiert er welche Testdaten notwendig sind.
Testdatenverantwortlicher: Der Testdatenverantwortlicher kümmert sich um die Beschaffung und Aktualität der Testdaten. Er arbeitet eng mit dem Testanalyst zusammen. Diese Rolle wird meist unterschätzt, aber ohne die richtigen Testdaten, ist die Aussage der Testfälle nutzlos.
Tester (Fachperson): Der Tester hat die Aufgabe die Tests zuverlässig und exakt auszuführen. Zudem soll er die Testergebnisse präzise und wertfrei dokumentieren. Bei der Fehlersuche kann er die Testanalysten und IT-Spezialisten unterstützen. Allgemein wird oft diese Rolle als Tester angesehen, wobei die anderen Rollen vergessen werden. ⓘ

Testplanung

Ergebnis dieser i. d. R. parallel zur Softwareentwicklung stattfindenden Phase ist i. W. der Testplan. Er wird für jedes Projekt erarbeitet und soll den gesamten Testprozess definieren. In TMap wird dazu ausgeführt: Sowohl die zunehmende Bedeutung von IT-Systemen für Betriebsprozesse als auch die hohen Kosten des Testens rechtfertigen einen optimal verwaltbaren und strukturierten Testprozess. Der Plan kann und soll je Teststufe aktualisiert und konkretisiert werden, sodass die Einzeltests im Umfang zweckmäßig und effizient ausgeführt werden können. ⓘ

Inhalte im Testplan sollten z. B. folgende Aspekte sein: Teststrategie (Testumfang, Testabdeckung, Risikoabschätzung); Testziele und Kriterien für Testbeginn, Testende und Testabbruch – für alle Teststufen; Vorgehensweise (Testarten); Hilfsmittel und Werkzeuge zum Testen; Dokumentation (Festlegen der Art, Struktur, Detaillierungsgrad); Testumgebung (Beschreibung); Testdaten (allgemeine Festlegungen); Testorganisation (Termine, Rollen), alle Ressourcen, Ausbildungsbedarf; Testmetriken; Problemmanagement. ⓘ

Testvorbereitung

Aufbauend auf der Testplanung werden die dort festgelegten Sachverhalte zur operativen Nutzung vorbereitet und zur Verfügung gestellt. ⓘ

Beispiele für einzelne Aufgaben (global und je Teststufe): Bereitstellen der Dokumente der Testbasis; Verfügbar machen (z. B. Customizing) von Werkzeugen für das Testfall- und Fehlermanagement; Aufbauen der Testumgebung(en) (Systeme, Daten); Übernehmen der Testobjekte als Grundlage für Testfälle aus der Entwicklungsumgebung in die Testumgebung; Benutzer und Benutzerrechte anlegen; ...
Beispiele für Vorbereitungen (für Einzeltests): Transfer / Bereitstellung von Testdaten bzw. Eingabedaten in die Testumgebung(en). ⓘ

Testabschluss

Abschluss-Aktivitäten finden auf allen Testebenen statt: Testfall, Testobjekt, Teststufe, Projekt. Der Status zum Abschluss von Teststufen wird (z. B. mit Hilfe von Teststatistiken) dokumentiert und kommuniziert, Entscheidungen sind herbeizuführen und Unterlagen zu archivieren. Grundsätzlich ist dabei zu unterscheiden nach:

Regel-Abschluss = Ziele erreicht, nächste Schritte einleiten
Alternativ möglich: Teststufe ggf. vorzeitig beenden oder unterbrechen (aus diversen, zu dokumentierenden Gründen); in Zusammenarbeit mit dem Projektmanagement ⓘ

Klassifikation für Testarten

In kaum einer Disziplin der Softwareentwicklung hat sich, der Komplexität der Aufgabe ‚Testen‘ entsprechend, eine derart große Vielfalt an Begriffen gebildet wie beim Softwaretest. Dies trifft besonders auch für die Bezeichnungen zu, mit denen Testarten/Testvarianten benannt werden. ⓘ

Sie leiten sich in der Regel aus den unterschiedlichen Situationen ab, in denen sie ausgeführt werden sowie aus den Testzielen, auf die sie ausgerichtet sind. Dadurch ergibt sich eine Vielzahl an Begriffen. Dieser Vieldimensionalität entsprechend können für einen konkreten Test die Bezeichnungen mehrerer Testarten zutreffen. Beispiel: Ein Entwicklertest kann gleichzeitig ein dynamischer Test, Blackbox-Test, Fehlertest, Integrationstest, Äquivalenzklassentest, Batchtest, Regressionstest etc. sein. ⓘ

In Literatur und Praxis werden diese Bezeichnungen meist nur teilweise benutzt, zum Teil auch mit in Details abweichenden Bedeutungen. So könnten im praktischen Einsatz bestimmte Tests (zum Beispiel) einfach als Funktionstest bezeichnet werden – und nicht als Fehlertest, Batchtest, High-Level-Test etc. Die Testeffizienz wird hierdurch nicht beeinträchtigt – wenn die Tests ansonsten zweckmäßig geplant und ausgeführt werden. Durchaus im Sinn effizienter Testprozesse ist es dabei, mehrere Testziele mit nur einem Testfall abzudecken, z. B. dabei die Benutzeroberfläche, eine Rechenformel, korrekte Wertebereichsprüfungen und die Datenkonsistenz zu prüfen. ⓘ

Ein Mittel zum Verständnis dieser Begriffsvielfalt ist die nachfolgend angewendete Klassifikation – bei der Testarten nach unterschiedlichen Kriterien gegliedert, dazu passende Testarten aufgeführt und ihre Testziele kurz erläutert werden. ⓘ

Klassifikation nach der Prüftechnik

Qualitäts- und Testmethoden im Projektverlauf ⓘ

Analytische Maßnahmen

Als analytische Maßnahmen werden Softwaretests definiert, die erst nach Erstellung des Prüfgegenstandes durchgeführt werden können. Liggesmeyer klassifiziert diese Testmethoden folgendermaßen (verkürzt und z. T. kommentiert): Statischer Test (Test ohne Programmausführung)

Review
Statische Code-Analyse, auch Formale Verifikation

Dynamischer Test (Test mit Programmausführung)

Strukturorientierter Test
- Kontrollflussorientiert (Maß für die Überdeckung des Kontrollflusses)
  - Anweisungs-, Zweig-, Bedingungs- und Pfadüberdeckungstests
- Datenflussorientiert (Maß für die Überdeckung des Datenflusses)
  - Defs-/Uses Kriterien, Required k-Tupels-Test, Datenkontext-Überdeckung
Funktionsorientierter Test (Test gegen eine Spezifikation)
- Funktionale Äquivalenzklassenbildung, Zustandsbasierter Test, Ursache-Wirkung-Analyse (z. B. mittels Ursache-Wirkungs-Diagramm), Syntaxtest, Transaktionsflussbasierter Test, Test auf Basis von Entscheidungstabellen
- Positivtest (versucht die Anforderungen zu verifizieren) und Negativtest (prüft die Robustheit einer Anwendung)
Diversifizierender Test (Vergleich der Testergebnisse mehrerer Versionen)
- Regressionstest, Back-To-Back-Test, Mutationen-Test
Sonstige (nicht eindeutig zuzuordnen, bzw. Mischformen)
- Bereichstest bzw. Domain Testing (Verallgemeinerung der Äquivalenzklassenbildung), Error guessing, Grenzwertanalyse, Zusicherungstechniken ⓘ

Konstruktive Maßnahmen

Den analytischen Maßnahmen, bei denen Testobjekte ‚geprüft‘ werden, gehen die sog. konstruktiven Maßnahmen voraus, die bereits im Verlauf der Software-Erstellung zur Qualitätssicherung betrieben werden. Beispiele: Anforderungsmanagement, Prototyping, Review von Pflichtenheften. ⓘ

Spezifikationstechniken

Weiterhin sind von den Prüftechniken die Spezifikationstechniken zu unterscheiden: Sie bezeichnen keine Testarten, mit denen Testobjekte aktiv geprüft werden, sondern nur die Verfahren, nach denen die Tests vorbereitet und spezifiziert werden. ⓘ

Beispielbezeichnungen sind Äquivalenzklassentest und Überdeckungstest; Testfälle werden nach diesen Verfahren identifiziert und spezifiziert, konkret überprüft jedoch z. B. in einem Integrationstest, Batchtest, Sicherheitstest etc. ⓘ

Klassifikation nach Art und Umfang der Testobjekte

Debugging: für einzelne Codeteile: Überprüfen des Programmcodes unter schrittweiser oder abschnittsweiser Kontrolle und ggf. Modifikation des Entwicklers.
Modultest, Unittest oder Komponententest: Testen kleinst-möglicher testbarer Funktionalitäten isoliert von anderen; gilt auch als eine Teststufe.
Integrationstest: Test der Funktionalität bei der Zusammenarbeit voneinander unabhängiger Komponenten; wird auch Interoperabilitätstest genannt; gilt auch als eine Teststufe.
Systemtest: Teststufe mit Tests über das gesamte System.
Schnittstellentest: Testen ob die Schnittstellen zwischen sich gegenseitig aufrufenden Komponenten korrekt (d. h. insbesondere bzgl. der möglichen Parameter-Kombinationen) implementiert sind; meist gem. der Spezifikation, beispielsweise mit Hilfe von Mock-Objekten.
Batchtest / Dialogtest: werden Tests von Stapelprogrammen bzw. Tests für Dialogprogramme genannt.
Web-Test: Test von Internet- oder Intranet-Funktionen; auch Browsertest genannt.
Hardwaretest: Testen konkreter, Hardwarekomponenten betreffender Last- und anderer Kriterien - wie Netzlast, Zugriffszeit, Parallelspeichertechniken etc. ⓘ

Klassifikation nach besonderen Sichtweisen

Die jeweilige Testart testet ... ⓘ

Softwaretechnische Zusammenhänge

Datenkonsistenztest: ... Auswirkung der getesteten Funktion auf die Korrektheit von Datenbeständen (Testbezeichnungen: Datenzyklustest, Wertebereichstest, Semantiktest, CRUD-Test)
Wiederinbetriebnahmetest: ... ob ein System nach einem Abschalten oder Zusammenbruch (z. B. ausgelöst durch einen Stresstest) wieder in Betrieb genommen werden kann.
Installationstest: ... Routinen zur Softwareinstallation, ggfs. in verschiedenen Systemumgebungen (z. B. mit verschiedener Hardware oder unterschiedlichen Betriebssystemversionen)
Stresstest: ... das Verhalten eines Systems unter Ausnahmesituationen.
Crashtest: ist ein Stresstest, der versucht, das System zum Absturz zu bringen.
Lasttest: ... das Systemverhalten unter besonders hohen Speicher-, CPU-, o. ä. -Anforderungen. Besondere Arten von Last-Tests können Multi-User-Tests (viele Anwender greifen auf ein System zu, simuliert oder real) und Stresstests sein, dabei wird das System an die Grenzen der Leistungsfähigkeit geführt.
Performance Test: ... ob bei bestimmten Speicher- und CPU-Anforderungen ein korrektes Systemverhalten sichergestellt ist.
Rechnernetz-Test: ... das Systemverhalten in Rechnernetzen (z. B. Verzögerungen der Datenübertragung, Verhalten bei Problemen in der Datenübertragung).
Sicherheitstest: ... potentielle Sicherheitslücken. ⓘ

Weitere Teilaspekte beim Testen

Teststrategie

Pol, Koomen und Spillner beschreiben in die Teststrategie als umfassenden Ansatz: Eine Teststrategie ist notwendig, da ein vollständiger Test, d. h. ein Test, der alle Teile des Systems mit allen möglichen Eingabewerten unter allen Vorbedingungen überprüft, in der Praxis nicht durchführbar ist. Deswegen muss in der Test-Planung anhand einer Risikoabschätzung festgelegt werden, wie kritisch das Auftreten eines Fehlers in einem Systemteil einzuschätzen ist (z. B. nur finanzieller Verlust oder Gefahr für Menschenleben) und wie intensiv (unter Berücksichtigung der verfügbaren Ressourcen und des Budgets) ein Systemteil getestet werden muss oder kann. ⓘ

Demnach ist in der Teststrategie festzulegen, welche Teile des Systems mit welcher Intensität unter Anwendung welcher Testmethoden und -Techniken unter Nutzung welcher Test-Infrastruktur und in welcher Reihenfolge (siehe auch Teststufen) zu testen sind. ⓘ

Sie wird vom Testmanagement im Rahmen der Testplanung erarbeitet, im Testplan dokumentiert und festgelegt und als Handlungsrahmen für das Testen (durch die Testteams) zu Grunde gelegt. ⓘ

Nach einer anderen Interpretation wird "Teststrategie" als methodischer Ansatz verstanden, nach dem das Testen angelegt wird. ⓘ

So benennt z. B. ISTQB Ausprägungen für Teststrategien wie folgt:

top-down: Haupt- vor Detailfunktionen testen; untergeordnete Routinen werden beim Test zunächst ignoriert oder (mittels "Stubs") simuliert
bottom-up: Detailfunktionen zuerst testen; übergeordnete Funktionen oder Aufrufe werden mittels "Testdriver" simuliert
hardest first: Situationsbedingt das Wichtigste zuerst
big-bang: Alles auf einmal ⓘ

Weitere Prinzipien und Techniken für Teststrategien sind:

Risk based Testing: Testprinzip, nach dem die Testabdeckung an den Risiken ausgerichtet wird, die in den Testobjekten (für den Fall des Nichtfindens von Fehlern) eintreten können.
Data driven Testing: Testtechnik, mit der über Einstellungen in den Testscripts die Datenkonstellationen gezielt geändert werden können, um damit mehrere Testfälle hintereinander effizient testen zu können
Testgetriebene Entwicklung
SMART: Testprinzip "Specific, Measurable, Achievable, Realistic, time-bound"
Keyword driven testing
framework based Testing: Test-Automatisierung mittels Testwerkzeugen für bestimmte Entwicklungsumgebungen / Programmiersprachen
Testing nach ISO/IEC 25000: Die ISO/IEC-Norm 25000 ist ein Standard für Qualitätskriterien sowie Bewertungsmethoden für Software und Systeme. Dementsprechend kann ein Ansatz für eine Teststrategie auf den in dieser Norm vorhandenen Standards basieren. ⓘ

Beispiel für Risikobasiertes Testen - nach der RPI-Methode

Grundsätzlich ist es aus Gründen der Zeit und/oder den finanziellen Mitteln niemals möglich eine Software (oder Teile einer Software) komplett zu testen. Aus diesem Grund ist es wichtig Tests so zu priorisieren, dass diese Sinn ergeben. Eine bewährte Methode zur Priorisierung von Tests ist die risikobasierte Methode, auch RPI-Methode genannt, wobei RPI für Risiko-Prioritäts-Index steht. ⓘ

In der RPI-Methode werden zuerst die Anforderungen zu Gruppen zugeordnet. Anschließend werden Kriterien definiert, welche für das Endprodukt von Bedeutung sind. Diese Kriterien werden später verwendet, um die Anforderungsgruppen zu bewerten. Nachfolgend wird auf die drei Kriterien eingegangen, welche sich aus der Praxis bewährt haben. Mit den aufgezeigten Fragen soll es möglichst gut gelingen, die Anforderungen zu unterscheiden, womit die Bewertung ermöglicht wird. ⓘ

Businessrelevanz ⓘ

Wie groß ist der Nutzen für den/die Endanwender?
Wie groß ist der Schaden bei Nichterfüllung dieser Anforderung?
Wie viele Endanwender wären betroffen, wenn diese Anforderung nicht erfüllt wird?
Wie wichtig ist diese Anforderung gegenüber anderen Anforderungen? Muss/Soll/Kann es erfüllt werden? ⓘ

Auffindbarkeit ⓘ

Ist der Fehler bzw. ein Nichterfüllen der Anforderung schnell auffindbar?
Wird der Fehler überhaupt bemerkt?
Wie wird der Fehler ersichtlich?
Findet jeder den Fehler oder eher Anwender, welche erweitertes Wissen gegenüber dem Produkt vorweisen? ⓘ

Komplexität ⓘ

Wie komplex ist die Anforderung?
Wie sehr ist die Anforderungen von anderen Teilen abhängig? Wie viele andere Anforderungen hängen davon ab?
Wie komplex ist die Umsetzung der Anforderung?
Sind Technologien im Einsatz, welche eher einfach oder komplex sind? ⓘ

Sobald die Anforderungen gruppiert und die Kriterien definiert wurden, durchlaufen sämtliche Anforderungsgruppen die drei Kriterien. Die Anforderungen werden von 1 bis 3 bewertet, wobei 3 dem höchsten Wert (bezgl. Wichtigkeit) darstellt (für eine breitere Verteilung der Anforderungen kann die Skala beliebig angepasst werden). Ist dies getan, wird das Produkt aus den drei bewerteten Kriterien gebildet - woraus sich die Wichtigkeit der Anforderungen ergibt. ⓘ

Erläuterungen zur Teststrategie nach ISO 25000

ISO 25000 definiert 8 Dimensionen für Software-Qualitätsmerkmale. Diese Dimensionen sind die folgenden:

Funktionale Eignung (Ist die geforderte Funktionalität in der Software gegeben?):
- Angemessenheit
- Richtigkeit
- Interoperabilität
- Ordnungsmäßigkeit
Zuverlässigkeit (Wie zuverlässig arbeitet die Software?):
- Reife
- Fehlertoleranz
- Wiederherstellbarkeit
Benutzbarkeit (Ist die Software einfach bedienbar?):
- Verständlichkeit
- Erlernbarkeit
- Bedienbarkeit
Leistungseffizienz (Wie effizient arbeitet die Software?):
- Zeitverhalten
- Verbrauchsverhalten
Wartbarkeit (Wie leicht lässt sich die Software modifizieren?):
- Analysierbarkeit
- Modifizierbarkeit
- Stabilität
- Prüfbarkeit
- Anpassbarkeit
Übertragbarkeit (Wie leicht lässt sich die Software auf ein anderes System portieren?):
- Anpassbarkeit
- Installierbarkeit
- Konformität
- Austauschbarkeit
Sicherheit (Wie sicher sind unsere Daten und Programme vor nicht autorisiertem Zugriff?):
- Zugriffssicherheit
- Datenverschlüsselung
Kompatibilität (Wie kompatibel ist die Software beim Austausch und der Verarbeitung von Daten mit und von anderen Systemen?):
- Austauschbarkeit
- Erweiterbarkeit
- Abwärtskompatibilität ⓘ

Die Teststrategie ist auf diese 8 auf Erfahrungen und Standards basierenden Qualitätsmerkmale ausgerichtet. Durch gezielt dafür erstellte Testfälle soll sichergestellt werden, dass diese Kriterien von der zu testenden Software – soweit relevant – eingehalten/unterstützt werden. ⓘ

Dokumentation

Zusammenhang der Dokumente und Verfahrensschritte laut IEEE 829 ⓘ

Zur Testplanung gehört auch die Vorbereitung der Dokumentation. Eine normierte Vorgehensweise dazu empfiehlt der Standard IEEE 829. Laut diesem Standard gehören zu einer vollständigen Testdokumentation folgende Unterlagen:

Testplan: Beschreibt Umfang, Vorgehensweise, Terminplan, Testgegenstände.
Testdesignspezifikation: Beschreibt die im Testplan genannten Vorgehensweisen im Detail.
Testfallspezifikationen: Beschreibt die Umgebungsbedingungen, Eingaben und Ausgaben eines jeden Testfalls.
Testablaufspezifikationen: Beschreibt in Einzelschritten, wie jeder Testfall durchzuführen ist.
Testobjektübertragungsbericht: Protokolliert, wann welche Testgegenstände an welche Tester übergeben wurden.
Testprotokoll: Listet chronologisch alle relevanten Vorgänge bei der Testdurchführung.
Testvorfallbericht: Listet alle Ereignisse, die eine weitere Untersuchung erforderlich machen.
Testergebnisbericht: Beschreibt und bewertet die Ergebnisse aller Tests. ⓘ

Übersichten / Zusammenhänge

Begriffe und ihr Zusammenhang ⓘ

Begriffe beim Testen

Die nebenstehende Grafik zeigt Begriffe, die im Kontext 'Testen' auftreten – und wie sie mit anderen Begriffen in Verbindung stehen. ⓘ

Schnittstellen beim Testen

Wichtige Schnittstellen beim Testen ⓘ

Die Grafik zeigt die wichtigsten Schnittstellen, die beim Testen auftreten. Zu den von Thaller genannten 'Partnern' beim Testen wird nachfolgend beispielhaft angeführt, was jeweils kommuniziert bzw. ausgetauscht wird.

Projektmanagement: Termin- und Aufwandsrahmen, Status je Testobjekt ('testready'), Dokumentationssysteme
Linienmanagement (und Linienabteilung): Fachlicher Support, Testabnahme, fachliche Tester stellen
Rechenzentrum: Testumgebung(en) und Testwerkzeuge bereitstellen und betreiben
Datenbankadministrator: Testdatenbestände installieren, laden und verwalten
Konfigurations-Management: Testumgebung einrichten, Integrieren der neuen Software
Entwicklung: Test-Basisdokumente, Prüflinge, Support zum Testen, Testergebnisse erörtern
Problem- und CR-Management: Fehlermeldungen, Rückmeldung zum Retest, Fehlerstatistik
Lenkungsausschuss: Entscheidungen zur Test(stufen)abnahme oder zum Testabbruch ⓘ

Kosten für die Behebung eines Fehlers		Zeitpunkt der Entdeckung ⓘ
Kosten für die Behebung eines Fehlers		Anforderungen	Architektur	Konstruktion	Systemtest	Post-Release
Zeit der Einführung	Anforderungen	1×	3×	5–10×	10×	10–100×
	Architektur	–	1×	10×	15×	25–100×
	Konstruktion	–	–	1×	10×	10–25×

Software-Entwicklung
Teil einer Serie über ⓘ
Zentrale Aktivitäten Prozesse Anforderungen Entwurf Konstruktion Technik Prüfung Fehlersuche Einsatz Wartung
Paradigmen und Modelle Software-Entwicklung Agil Reinraum Inkrementell Prototyping Spirale V-Modell Wasserfall
Methodologien und Rahmenwerke ASD DevOps DAD DSDM FDD IID Kanban Lean SD LeSS MDD MSF PSP RAD RNP SAFe Scrum SEMAT TSP OpenUP UP XP
Unterstützende Disziplinen Konfigurationsmanagement Dokumentation Software-Qualitätssicherung Projektleitung Benutzererfahrung
Praktiken ATDD BDD CCO CI CD DDD PP SBE Stand-up TDD
Werkzeuge Compiler Debugger Profiler GUI-Designer Modellierung IDE Automatisierung der Erstellung Automatisierung der Freigabe Infrastruktur als Code Prüfung
Standards und Wissensbestände BABOK CMMI IEEE-Normen ISO 9001 ISO/IEC-Normen PMBOK SWEBOK ITIL IREB
Glossare Künstliche Intelligenz Computerwissenschaft Elektrotechnik und Elektronik
Umrisse Überblick über die Softwareentwicklung
v t e

Überblick

Fehler und Ausfälle

Eingabekombinationen und Vorraussetzungen

Wirtschaft

Rollen

Geschichte

Testansatz

Statisches, dynamisches und passives Testen

Explorativer Ansatz

Der "Box"-Ansatz

White-box-Tests

Black-Box-Tests

Visuelle Tests

Grey-box-Tests

Teststufen

Unit-Tests

Integrationstests

Systemtests

Abnahmetest

Komponententest

Systemtest

Testarten, Techniken und Taktiken

Motivation

Kompatibilitätstests

Smoke- und Sanity-Tests

Regressionstests

Abnahmetest

Alpha-Tests

Beta-Tests

Funktionale vs. nicht-funktionale Tests

Kontinuierliches Testen

Destruktives Testen

Software-Leistungstests

Gebrauchstauglichkeitstests

Prüfung der Zugänglichkeit

Sicherheitstests

Internationalisierung und Lokalisierung

Entwicklungstests

A/B-Tests

Gleichzeitige Tests

Konformitätstests oder Typentests

Tests zum Vergleich der Ausgabe

Eigenschaftstests

Metamorphes Testen

VCR-Tests

Testverfahren

Traditionelles Wasserfall-Entwicklungsmodell

Agiles oder XP-Entwicklungsmodell

Ein Beispiel für einen Testzyklus

Automatisierte Tests

Testwerkzeuge

Aufzeichnung und Wiedergabe

Messungen bei Softwaretests

Hierarchie der Testschwierigkeiten

Test-Artefakte

Zertifizierungen

Kontroverse

Verwandte Prozesse

Verifizierung und Validierung von Software

Software-Qualitätssicherung

Definition

Standardisierung

Ziele

Testprozess / Testphasen

Testplanung

Testvorbereitung

Testabschluss

Klassifikation für Testarten

Klassifikation nach der Prüftechnik

Analytische Maßnahmen

Konstruktive Maßnahmen

Spezifikationstechniken

Klassifikation nach Art und Umfang der Testobjekte

Klassifikation nach besonderen Sichtweisen

Softwaretechnische Zusammenhänge

Weitere Teilaspekte beim Testen

Teststrategie

Beispiel für Risikobasiertes Testen - nach der RPI-Methode

Erläuterungen zur Teststrategie nach ISO 25000

Dokumentation