So schreiben Sie Testfälle für Software: Beispiele und Lernprogramm

So erreichen Testfälle schreiben scheint kein so wichtiger Teil der Entwicklung zu sein. Damit ein Softwaretester seine Arbeit jedoch optimal ausführen kann, benötigt er eine kristallklare Reihe von Schritten und eine klare Definition dessen, was getestet wird.

Jeder aus NASA und GE zu Unternehmen auf Unternehmensebene kann von Teams profitieren, die von ihrer besten Seite arbeiten. Das Schreiben exzellenter Testfälle ist nur eine weitere Möglichkeit, die Effizienz und Effizienz des Teams zu verbessern. Bei Parasoft geht es darum, Teams dazu zu befähigen, genau das zu tun.

In diesem Blog behandeln wir die folgenden Themen im Zusammenhang mit dem Schreiben eines Testfalls:

1. Was ist ein Testfall?
2. Testskript vs. Testfall
3. Verschiedene Testfalltypen
4. So schreiben Sie Software-Testfälle
5. Standard-Testfallformat
6. Best Practices für das Schreiben von Testfällen
7. Testsuite vs. Testplan
8. Tools zum Schreiben von Testfällen

Was ist ein Testfall in Software?

Ein Testfall ist genau das, wonach er klingt: ein Testszenario, das die Funktionalität einer Reihe von Aktionen oder Bedingungen misst, um das erwartete Ergebnis zu überprüfen. Sie gelten für jede Softwareanwendung, können manuelle Tests oder eine automatisierter Test, und können Testfall-Management-Tools verwenden.

Wenn Sie Testfälle schreiben, sollten Sie unbedingt berücksichtigen, dass sie eine grundlegende Variable oder Aufgabe testen sollen, z. B. ob für das richtige Produkt auf einer E-Commerce-Webseite ein Rabattcode gilt oder nicht. Dies ermöglicht einem Software-Tester mehr Flexibilität beim Testen von Code und Funktionen.

Testskript vs. Testfall

Der Unterschied zwischen Testfällen und Testskripten sollte ebenfalls geklärt werden. Ein Testskript ist ein kurzes Programm zum Testen bestimmter Funktionen. Ein Testfall ist ein Dokument mit Schritten, die wie geplant im Voraus ausgeführt werden müssen.

Betrachten Sie Testfälle als sorgfältig geplante Reise und Testskripte als eine kurze Reise zum Lebensmittelgeschäft.

Verschiedene Arten von Testfällen

Testfälle können viele verschiedene Aspekte des Codes messen. Die damit verbundenen Schritte können auch dazu dienen, ein Fehlerergebnis zu induzieren, im Gegensatz zu einem positiven erwarteten Ergebnis, z. B. wenn ein Benutzer auf einem Anmeldebildschirm das falsche Kennwort eingibt.

Einige gängige Testfallbeispiele wären die folgenden:

Testfälle können auf eine beliebige Anzahl von Funktionen angewendet werden, die in einer bestimmten Software zu finden sind. Einige der beliebtesten sind:

• Beispiel für API-Tests - Sehen Sie es in Aktion.
• Beispiel für UI-Tests - Sehen Sie es in Aktion.
• Beispiel für Unit-Tests - Sehen Sie es in Aktion.
• Beispiel für Last- und Leistungstests - Sehen Sie es in Aktion.
• Sicherheitstests
• SQL-Abfragen
• Low-Code-Anwendungstests

Ein beliebtes Testfallbeispiel

Testfälle sind in einer Vielzahl von Softwareszenarien nützlich. Alles, vom Bankgeschäft bis zur persönlichen Software, erfordert eine Testfallanwendung. Wenn das Ziel beispielsweise darin besteht, verschlüsselte, vertrauliche Daten zu haben, muss die Software über Funktionen verfügen, die wie beabsichtigt funktionieren.

Funktionstests sind jedoch nur ein Aspekt beim Schreiben eines Testfalls. Softwaretests sollten jeden Aspekt des Codes von der Leistung über die Kompatibilität bis zur Sicherheit herausfordernd herausfordern. Deshalb muss persönliche Verschlüsselungssoftware so gründlich getestet werden - besonders wenn es darum geht Dinge wie Web-APIs.

So schreiben Sie Software-Testfälle

Das Schreiben von Testfällen hängt davon ab, was der Testfall misst oder testet. Dies ist auch eine Situation, in der das Teilen von Testressourcen zwischen Entwicklern und Testteams das Testen von Software beschleunigen kann. Aber alles beginnt damit, zu wissen, wie man einen Testfall effektiv und effizient schreibt.

Testfälle haben einige integrale Bestandteile, die in Feldern immer vorhanden sein sollten. Jeder Testfall kann jedoch in 8 grundlegende Schritte unterteilt werden.

Schritt 1: Testfall-ID

Testfälle sollten alle eindeutige IDs tragen, um sie darzustellen. In den meisten Fällen hilft das Befolgen einer Konvention für diese Namens-ID bei der Organisation, Klarheit und dem Verständnis.

Schritt 2: Testbeschreibung

Diese Beschreibung sollte detailliert beschreiben, welche Einheit, Funktion oder Funktion getestet oder verifiziert wird.

Schritt 3: Annahmen und Voraussetzungen

Dies beinhaltet alle Bedingungen, die vor der Ausführung des Testfalls erfüllt sein müssen. Ein Beispiel wäre das Erfordernis eines gültigen Outlook-Kontos für eine Anmeldung.

Schritt 4: Testdaten

Dies bezieht sich auf die Variablen und ihre Werte im Testfall. Im Beispiel einer E-Mail-Anmeldung sind dies der Benutzername und das Kennwort für das Konto.

Schritt 5: Auszuführende Schritte

Dies sollten leicht wiederholbare Schritte sein, wie sie aus Sicht des Endbenutzers ausgeführt werden. Ein Testfall für die Anmeldung bei einem E-Mail-Server kann beispielsweise die folgenden Schritte umfassen:

1. Öffnen Sie die E-Mail-Server-Webseite.
2. Geben Sie den Benutzernamen ein.
3. Passwort eingeben.
4. Klicken Sie auf "Enter" oder "Login".

Schritt 6: erwartetes Ergebnis

Dies zeigt das Ergebnis an, das nach der Ausführung des Testfallschritts erwartet wird. Nach Eingabe der richtigen Anmeldeinformationen wäre das erwartete Ergebnis eine erfolgreiche Anmeldung.

Schritt 7: Tatsächliches Ergebnis und Nachbedingungen

Im Vergleich zum erwarteten Ergebnis können wir den Status des Testfalls bestimmen. Im Falle der E-Mail-Anmeldung würde der Benutzer entweder erfolgreich angemeldet sein oder nicht. Die Nachbedingung ist das, was als Ergebnis der Schrittausführung geschieht, z. B. wenn sie in den E-Mail-Posteingang umgeleitet wird.

Schritt 8: Pass / Fail

Die Bestimmung des Bestanden / Nicht Bestanden-Status hängt davon ab, wie das erwartete Ergebnis und das tatsächliche Ergebnis miteinander verglichen werden.

Gleiches Ergebnis = Bestanden
Unterschiedliche Ergebnisse = Fehlschlagen

Standard-Unit-Testfallformat

Jeder Teil eines gut geschriebener Unit-Test wird mehrere Kernaspekte definieren, darunter:

1. Vom Test ausgeführte Funktionen
2. Im Test verwendete Daten
3. Erwartetes Ergebnis der Testausführung
4. Sicherstellen, dass der Test isoliert von anderen Teilen der Codebasis ausgeführt wurde

Es ist wichtig zu wissen, dass das Standardformat gut geschriebener Tests aus folgenden Teilen besteht:

• Sinnvoller Name der Testmethode
• Kontrollierte Daten oder Mocks, die zum Testen verwendet werden sollen
• Zu testende Methode oder Einheit (der Teil des Codes, den wir testen)
• Eine Behauptung anwenden
• Unit-Test isoliert durchführen

Gibt es eine Testfallvorlage?

Wie bereits erwähnt, gibt es ein Standardformat für Testfälle. Die Testfallvorlage würde jedoch wahrscheinlich von Unternehmen zu Unternehmen und sogar von Team zu Team variieren. Stattdessen ist eine Testfallvorlage das Dokument mit einer Liste von Testszenarien und nachfolgenden Testfällen.

Beispiel für einen Qualitätstestfall

Obwohl die Testfälle je nach Testart und Gesamttestfeld variieren, hängt die Erstellung eines Qualitätstestfalls von den wenigen oben genannten zuverlässigen Elementen ab. Denken Sie daran: Der Name der Testmethode muss die zu testende Methode oder Einheit und das erwartete Ergebnis enthalten.

Es sollte auch beachtet werden, dass jede Einheit isoliert getestet werden sollte. In diesem Fall bedeutet „Isolation“, dass die Tests so weit wie möglich fokussiert bleiben, um nur den Teil der Anwendung auszuführen, auf den wir testen.

Dieses Beispiel stammt aus einem bankbezogenen Testfall:

Mit diesem Methodennamen wissen wir, dass dies ein Komponententest ist, der:

• Testen der Methode 'isOverDrawn ()'.
• Der für die kontrollierten Daten verwendete Ausgleich betrug 500.
• Das erwartete Ergebnis ist wahr.

Ein aussagekräftiger Methodenname ermöglicht es jedem, die Ergebnisse zu überprüfen, um zu verstehen, worauf der Komponententest getestet wurde. Darüber hinaus signalisiert es die zu testenden Daten, das erwartete Ergebnis und was getestet wurde.

Wenn der Test fehlschlägt, ist es entscheidend, das erwartete Ergebnis zu kennen, um eine einfachere Fehlersuche zu ermöglichen und Sicherstellen, dass keine Regressionen eingeführt werden.

Testfalldaten

Die verwendeten Daten müssen ausreichen, um den Test auszuführen. Für Unit-Tests möchten wir es so einfach wie möglich machen, die grundlegendste Einheit unserer Anwendung zu testen. Die Daten können so einfach sein wie das Erstellen einer Zeichenfolge oder Objektvariablen, für die Sie die Daten steuern können. Oder es kann ein Scheinframework für den Test verwendet werden, wenn eine Abhängigkeit nicht verfügbar ist oder wenn sich diese Abhängigkeit in einem bestimmten Zustand befinden muss.

Ich habe gerade genug, um dieses eine Teil zu testen, wenn es ausreicht. Sie müssen NICHT jeden Teil der Anwendung konfigurieren, damit der Test ausgeführt werden kann.

All dies wirkt sich auf das Verhalten des Komponententests aus, da dies die Daten sind, die für die Ausführung des Komponententests verwendet werden. Daher ist dieser Teil des Komponententests am zeitaufwändigsten, da er ein gewisses Verständnis des zu testenden Codes erfordert, um zu wissen, welche Daten zum Testen verwendet werden sollen.

Halten Sie es einfach, indem Sie nur die Teile verwenden, die für den zu testenden Code erforderlich sind. Mocks sind in dieser Phase sehr nützlich, da Sie damit steuern können, wie sich Methoden aus diesen Objekten bei der Interaktion mit Ihrem Test verhalten.

Zum Beispiel bei folgenden Daten:

Wir haben die „echte Kundenklasse“ vermieden, indem wir ein Modell für die „Kundenklasse“ zum Testen der Isolation verwendet haben. Wir möchten kein anderes Objekt für diesen Test einführen oder konfigurieren, da dies eine weitere Ebene der Wartbarkeit für dieses Objekt hinzufügt und das Ergebnis der zu testenden Methode nicht beeinflusst.

Die nächste Variable, die erstellt werden muss, ist das „anfängliche Gleichgewicht“ - etwas, das aufgrund der Kenntnis des Codes bekannt ist. Die nächste Zeile zeigt das Kontoobjekt, das zusammen mit dem Mock und dem Anfangssaldo erstellt wird, um die Methode vorzubereiten, auf die wir mit den gerade verwendeten Daten testen.

In diesem Beispiel wird das Kontoobjekt mit dem Scheinkunden konfiguriert, da wir uns nicht um die Daten des Kundenobjekts kümmern und einen anfänglichen Saldo übergeben haben, den wir für unseren Test steuern können.

In der nächsten Zeile wird die Eingabe definiert, da für die zu testende Methode eine Nummer verwendet werden muss. Wir haben das „Gleichgewicht“ definiert, das in der Methode verwendet werden soll, auf die wir testen. Dann wird die Methode ausgeführt, wobei das Ergebnis der Methode in unserer Variablen gespeichert wird, damit wir sie später verwenden können.

Anwenden einer Behauptung

Sobald der Test erfolgreich abgeschlossen werden kann (wie er von Anfang bis Ende ohne Ausnahmen oder Fehler ausgeführt wird), ist es an der Zeit, eine Bestätigung auf den Komponententest anzuwenden. Ohne die Behauptung ist der Komponententest bedeutungslos, da Sie nichts erzwingen, um sicherzustellen, dass er wie beabsichtigt funktioniert.

Das Sammeln der Abdeckung darüber, welche Zeilen ausgeführt wurden, gibt Auskunft darüber, was ausgeführt wurde, bietet jedoch nicht genügend Details, um Folgendes zu bestimmen:

• Wenn sich der Code wie erwartet verhält.
• Wenn der Code die Qualitätsziele erfüllt.
• Wenn die zurückgegebenen Daten die erwarteten Daten sind.

Eine Behauptung kann so grundlegend sein wie:

Solange der Komponententest eine Behauptung enthält, die die Methode unter dem Testergebnis überprüft, ist dies ein aussagekräftiger Komponententest.

Durch Anwenden des Standardformats für Komponententests kann ein Team Tests einfacher verwalten, lesen und / oder aktualisieren, um leichter zu erkennen, wo weitere Tests auf den Rest der Anwendung angewendet werden können.

Was sind die Best Practices für das Schreiben von Qualitätstestfällen?

Wie man effektive Tests und Testfälle schreibt, kann im Laufe der Zeit rationalisiert werden. Etwas Best Practices Dazu gehören die Verwendung starker Titel, aussagekräftiger Beschreibungen und eine prägnante und klare Sprache.

Sie sollten aber auch Voraussetzungen, Annahmen und die erwarteten Ergebnisse berücksichtigen. Alle diese Informationen sind für den Software-Tester relevant - insbesondere, wenn festgestellt wird, ob der Testfall stattdessen ein „Bestanden“ oder ein „Nicht Bestanden“ sein soll.

Ein Spickzettel zum Erstellen gut funktionierender Testfälle lautet wie folgt:

• Halten Sie die Dinge einfach und transparent.
• Machen Sie Testfälle wiederverwendbar.
• Halten Sie die Testfall-IDs eindeutig.
• Peer-Review ist wichtig.
• Testfälle sollten den Endbenutzer oder definierte Anforderungen berücksichtigen.
• Geben Sie die erwarteten Ergebnisse und Annahmen an.

Einfach, einzigartig, spezifisch, offen für Rückmeldungen und auf Wiederverwendbarkeit ausgerichtet: Das ist der Weg eines großartigen Testfalls. Weitere Informationen zum Schreiben eines Qualitätstestfalls finden Sie im Parasoft-Webinar zu diesem Thema.

Testsuite vs. Testplan

Der andere Aspekt eines Testfalls umfasst Testsuiten und Testpläne. Diese unterscheiden sich in wesentlichen Punkten und beide sind für eine genaue Testfallentwicklung von entscheidender Bedeutung.

Was ist eine Testsuite?

Eine Testsuite kommt für Testfälle ins Spiel, wenn sie sich auf den Quellcode, die Sammlung von Abhängigkeiten oder die Testsuite bezieht, die für Code ausgeführt werden soll. Mit Testsuiten können Sie Testfälle so kategorisieren, dass sie mit allen Analyse- oder Planungsanforderungen übereinstimmen.

Dies bedeutet, dass die Kernsoftwarefunktionen möglicherweise über eine eigene Testsuite verfügen, während eine andere Testsuite für einen bestimmten Testtyp wie Rauch oder Sicherheit vorgesehen ist. Stellen Sie sich Testsuiten als Bücherregal vor, in dem Sie Ihre Testfälle organisieren können.

Was ist ein Testplan?

Im Gegensatz dazu ähnelt ein Testplan eher dem Regenschirm, der über allen Testsuiten steht. Wenn Testfälle Bücher und Testsuiten Bücherregale sind, sind Testpläne der Raum, in dem sich das Bücherregal befindet.

Im Allgemeinen werden Testpläne in Form von manuellen Tests, automatisierten Tests und einem allgemeinen Format für die Durchführung von Tests erstellt. Sie testen die Software von Grund auf mithilfe von Testsuiten und Testfällen, bevor sie Änderungen implementieren oder neue Funktionen hinzufügen.

Beste Tools zum Schreiben von Testfällen

Parasoft entwickelt seine Tools und Suiten im Allgemeinen unter Berücksichtigung der „George Jetson“ -Theorie. Das heißt, wir möchten, dass unsere Kunden auf Knopfdruck alles erledigen können. Dies ist zwar nicht ganz realistisch, aber Tools, die sich auf die Automatisierung konzentrieren, eignen sich am besten zum Schreiben von Testfällen.

Sie können nicht nur bei der Automatisierung helfen, sondern auch von Anfang an. Schließlich ist es zu leicht, sich von kleinen Details oder Merkmalen festzuhalten. Man könnte vergessen, dass Software nur zuerst funktionieren muss. Hier kommt ein Java-Unit-Test-Tool wie Parasoft Jtest ins Spiel.

Mit diesem Tool können Anfänger und Experten ihre Unit-Test-Fähigkeiten sowie die Unit-Test-Erfahrung schneller verbessern. Nach dem Einrichten einer Grundlage werden die Komponententests ausgeführt und der Benutzer angeleitet, um sicherzustellen, dass die Tests aussagekräftig sind. Wenn Sie verstehen, nach welchen Dingen Sie in einem Test suchen müssen, wird das Schreiben von Testfällen weniger einschüchternd.