Bestimme, was getestet werden soll, definiere deine Testfälle und setze Prioritäten.
Im vorherigen Beitrag haben Sie mehr über Teststrategien und die Anzahl der Tests erfahren, die zum Testen einer Anwendung erforderlich sind, und wie Sie die beste Lösung finden, um unter Berücksichtigung Ihrer Ressourcen die höchste Zuverlässigkeit in den Ergebnissen zu erzielen. Dies gibt uns jedoch nur eine Vorstellung davon, wie viel getestet werden sollte. Sie müssen noch genau festlegen, was getestet werden soll. Die folgenden drei Kriterien können hilfreich sein, um zu verstehen, was Sie von einem Test erwarten können und um zu sehen, welcher Testtyp und welcher Detaillierungsgrad am besten geeignet sind:
- Sorge für deinen Happy Path. Dies ist die allgemeinste oder primäreste User Story Ihrer Anwendung, in der die Nutzenden sehr schnell einen Fehler bemerken werden.
- Entscheiden Sie sich sorgfältig über den Detaillierungsgrad. Sprechen Sie im Detail, wenn Ihr Anwendungsfall anfällig ist oder wo ein Fehler großen Schaden verursachen würde.
- Priorisieren Sie nach Möglichkeit niedrigere Tests wie Unit- und Integrationstests gegenüber übergeordneten End-to-End-Tests.
Im weiteren Verlauf dieses Artikels werden diese Kriterien und ihre Anwendung bei der Definition von Testfällen erläutert.
Was ist ein Testlauf?
In der Softwareentwicklung ist ein Testfall eine Abfolge von Aktionen oder Umständen, die entwickelt werden, um die Wirksamkeit eines Softwareprogramms oder einer Anwendung zu bestätigen. Ein Testlauf zielt darauf ab, sicherzustellen, dass die Software wie geplant funktioniert und alle Features und Funktionen ordnungsgemäß funktionieren. In der Regel erstellen Softwaretester oder -entwickler diese Testläufe, um zu gewährleisten, dass die Software die angegebenen Anforderungen und Spezifikationen erfüllt.
Wenn ein Testlauf ausgeführt wird, führt die Software eine Reihe von Prüfungen durch, um sicherzustellen, dass die gewünschten Ergebnisse erzielt werden. Dabei erfüllt ein Test die folgenden Aufgaben:
- Überprüfung: Der Prozess der gründlichen Überprüfung der Software, um sicherzustellen, dass sie fehlerfrei ist. Entscheidend ist zu bestimmen, ob das erstellte Produkt alle erforderlichen nichtfunktionalen Anforderungen erfüllt und seinen beabsichtigten Zweck erfolgreich erfüllt. Die Frage lautet: „Entwickeln wir das Produkt richtig?“
- Validierung: Der Prozess, mit dem sichergestellt wird, dass das Softwareprodukt die erforderlichen Standards oder hohen Anforderungen erfüllt. Dabei wird geprüft, ob das eigentliche Produkt mit dem erwarteten Produkt übereinstimmt. Im Wesentlichen beantworten wir die Frage: „Entwickeln wir das richtige Produkt für die Anforderungen der Nutzenden?“
Angenommen, das Programm liefert nicht das erwartete Ergebnis. In diesem Fall ist der Testlauf der Überbringer, d. h., ein erfolgloses Ergebnis wird gemeldet, und der Entwickler oder Tester muss das Problem untersuchen und eine Lösung finden. Stellen Sie sich die Prüfungen und Aktionen als Pfade vor, denen der Computer unabhängig von der Testart folgt. Gruppen von Eingabedaten oder Bedingungen, die zur Überprüfung verwendet werden, werden als „Äquivalenzklassen“ bezeichnet. Sie sollten ein ähnliches Verhalten oder ähnliche Ergebnisse vom zu testenden System erhalten. Die spezifischen Pfade, die in einem Test ausgeführt werden, können variieren, sollten aber mit den Aktivitäten und Assertions in Ihrem Test übereinstimmen.
Testpfade: Typische Arten von Testläufen
In der Softwareentwicklung ist ein Testfall ein Szenario zur Codeausführung, in dem ein bestimmtes Verhalten erwartet und getestet wird. Normalerweise gibt es drei Szenarien, aus denen Testläufe erstellt werden können.
Die erste ist die bekannteste, die Sie wahrscheinlich bereits verwenden. Dabei handelt es sich um den Happy Path, auch bekannt als „Happy Day-Szenario“ oder „goldener Pfad“. Er definiert den häufigsten Anwendungsfall deiner Funktion, Anwendung oder Änderung – also die Art und Weise, wie sie für den Kunden funktionieren sollte.
Der zweitwichtigste Testpfad, den Sie in Ihren Testläufen behandeln müssen, wird häufig ausgelassen, da er unkomfortabel ist – wie der Name schon andeutet. Das ist der „beängstigende Pfad“ oder, mit anderen Worten, der negative Test. Dieser Pfad zielt auf Szenarien ab, die zu unerwünschtem Verhalten des Codes oder einem Fehlerstatus führen. Das Testen dieser Szenarien ist besonders wichtig, wenn Sie sehr anfällige Anwendungsfälle haben, die ein hohes Risiko für Stakeholder oder Nutzende darstellen.
Es gibt einige andere Pfade, die Sie vielleicht kennen und verwenden möchten, die jedoch in der Regel weniger häufig verwendet werden. In der folgenden Tabelle sind sie zusammengefasst:
Testpfad | Erklärung |
---|---|
Wütender Pfad | Dies führt zu einem erwarteten Fehler, z. B. wenn Sie sicherstellen möchten, dass die Fehlerbehandlung korrekt funktioniert. |
Säumiger Pfad | Dieser Pfad berücksichtigt alle sicherheitsbezogenen Szenarien, die Ihre Anwendung erfüllen muss. |
Pfad trennen | Der Pfadtest für das Szenario in Ihrer Anwendung erhält nicht genügend Daten, um zu funktionieren, z. B. zum Testen von Nullwerten. |
Vergesslicher Pfad | Das Verhalten Ihrer Anwendung mit unzureichenden Ressourcen testen, z. B. durch das Auslösen eines Datenverlusts. |
Unentschlossener Pfad | Tests mit einem Nutzer, der versucht, Aktionen auszuführen oder User Stories in Ihrer Anwendung zu folgen, aber diese Workflows noch nicht abgeschlossen hat. Das kann beispielsweise der Fall sein, wenn der Nutzer seinen Workflow unterbricht. |
Gieriger Pfad | Sie versuchen, mit großen Mengen an Eingaben oder Daten zu testen. |
Stressiger Weg | Sie versuchen, Ihre Anwendung mit den erforderlichen Mitteln zu belasten, bis sie nicht mehr funktioniert (ähnlich wie bei einem Lasttest). |
Es gibt mehrere Methoden, diese Pfade zu kategorisieren. Zwei gängige Ansätze sind:
- Äquivalenzpartitionierung. Eine Testmethode, die Testfälle in Gruppen oder Partitionen kategorisiert und so bei der Erstellung von Äquivalenzklassen hilft. Dies basiert auf der Annahme, dass, wenn ein Testlauf in einer Partition einen Fehler aufdeckt, wahrscheinlich ähnliche Fehler in anderen Testläufen derselben Partition auftreten. Da alle Eingaben innerhalb einer bestimmten Äquivalenzklasse identisches Verhalten zeigen sollten, können Sie die Anzahl der Testläufe verringern. Weitere Informationen zur Äquivalenzpartitionierung
- Limitanalyse: Eine Testmethode, auch Grenzwertanalyse genannt, bei der die Grenzen oder Extremwerte von Eingabewerten untersucht werden, um potenzielle Probleme oder Fehler zu finden, die an den Grenzen der Fähigkeiten oder Beschränkungen des Systems auftreten können.
Best Practice: Testläufe schreiben
Ein klassischer Testfall, der von einem Tester geschrieben wurde, enthält spezifische Daten, die Ihnen helfen, den Inhalt des Tests, den Sie durchführen möchten, zu verstehen und natürlich den Test durchzuführen. Ein typischer Tester würde seine Testaktivitäten in einer Tabelle dokumentieren. In dieser Phase gibt es zwei Muster, die uns helfen können, unsere Testfälle und später auch die Tests selbst zu strukturieren:
- Anordnen, Handeln, Bestätigen. Das Testmuster „Anordnen, Handeln, Behaupten“ (auch als „AAA“ oder „Triple A“ bezeichnet) ist eine Möglichkeit, Tests in drei verschiedene Schritte zu gliedern: das Anordnen des Tests, das anschließende Durchführen des Tests und schließlich das Ziehen von Schlussfolgerungen.
- Angegebene, wann, dann-Muster. Dieses Muster ähnelt dem AAA-Muster, hat aber einige Wurzeln in der verhaltensorientierten Entwicklung.
In den nächsten Artikeln werden wir auf diese Muster noch ausführlicher eingehen, sobald wir über die Struktur eines Tests selbst sprechen. Wenn Sie in dieser Phase tiefer in diese Muster einsteigen möchten, lesen Sie die folgenden beiden Artikel: Arrange-Act-Assert: A pattern for write Good test und Given-When-Then.
Basierend auf allen Erkenntnissen aus diesem Artikel fasst die folgende Tabelle ein klassisches Beispiel zusammen:
Informationen | Erklärung |
---|---|
Voraussetzungen | Alle Aufgaben, die vor dem Schreiben des Tests ausgeführt werden müssen. |
Testobjekt | Was muss überprüft werden? |
Eingabedaten | Variablen und ihre Werte |
Auszuführende Schritte | Alle Dinge, die Sie tun werden, um Ihren Test zum Leben zu erwecken: alle Aktionen oder Interaktionen, die Sie in Ihren Tests durchführen. |
Erwartetes Ergebnis | Was sollte passieren und welche Erwartungen erfüllt werden müssen |
Tatsächliches Ergebnis | Was tatsächlich passiert. |
Bei automatischen Tests musst du nicht alle diese Testfälle so dokumentieren, wie es für einen Tester der Fall sein muss, auch wenn dies zweifellos hilfreich ist. All diese Informationen findest du in deinem Test, wenn du genau aufpassst. Lassen Sie uns nun diesen klassischen Testfall in einen automatisierten Test übertragen.
Informationen | Übersetzung in Testautomatisierung |
---|---|
Voraussetzungen | Alles, was Sie benötigen, die Durchführung des Tests und die Überlegungen darüber, was gegeben wird, um das Testszenario umzusetzen. |
Testobjekt | Bei diesem „Objekt“ kann es sich um verschiedene Elemente handeln: eine Anwendung, ein Ablauf, eine Einheit oder eine zu testende Komponente. |
Eingabedaten | Parameterwerte. |
Auszuführende Schritte | Alle Aktionen und Befehle, die innerhalb Ihres Tests ausgeführt werden, die Dinge, auf die Sie reagieren, und herausfinden, was passiert, wenn Sie bestimmte Dinge tun. |
Erwartetes Ergebnis | Die Assertion, die Sie zum Validieren Ihrer Anwendung verwenden, die Dinge, zu denen Sie in Ihrer Anwendung Assertions machen. |
Tatsächliches Ergebnis | Das Ergebnis Ihres automatisierten Tests. |