Testanalyse und Grundlagen des Testens

⚡ Intelligente Zusammenfassung

Die Testanalyse, auch Testgrundlage genannt, ist die strukturierte Überprüfung von Anforderungen, Designdokumenten und anderen Artefakten zur Ableitung testbarer Bedingungen. Dieser Artikel erläutert die Quellen, den schrittweisen Arbeitsablauf und die Einordnung der Testanalyse im V-Modell.

  • 📋 Grundprinzip: Die Testbasis ist die maßgebliche Quelle – SRS, BRS, Konstruktionsdokumente –, aus der jede Testbedingung und jeder Testfall abgeleitet werden muss.
  • ✅ Qualitätstreiber: Eine gründliche Testanalyse verhindert, dass Anforderungen übersehen werden, unklare Erwartungen entstehen und Nacharbeiten während der Ausführung und der Benutzerakzeptanztests erforderlich sind.
  • 🔍 Workflow-Fokus: RevArtefakte sichten, testbare Bedingungen identifizieren, diese nach Priorität und Typ klassifizieren und anschließend jeden einzelnen in strukturierte Testfälle umwandeln.
  • 🧪 Modellausrichtung: In jeder Phase des V-Modells wird ein zugehöriges Testartefakt erzeugt; die Testanalyse wird anhand des entsprechenden Entwicklungsdokuments durchgeführt.
  • ⚠️ Risikoeinblick: Eine uneindeutige oder unvollständige Testgrundlage ist die Hauptursache für unentdeckte Fehler, weshalb eine frühzeitige Analyse die wichtigste Maßnahme der Qualitätssicherung darstellt.

Was ist Testanalyse (Testgrundlage)?

Die Testanalyse – auch Testgrundlage genannt – steht ganz am Anfang des Testlebenszyklus. Jede Testbedingung und jeder Testfall wird letztendlich analysiert. tracZurück zum Thema. Die folgenden Abschnitte definieren den Begriff, erläutern seine Quellen, beschreiben den Analyseablauf und ordnen ihn in das V-Modell ein.

Was ist Testanalyse?

Testanalyse Im Softwaretest ist dies der Prozess der Überprüfung der Eingaben, die zur Ableitung von Testbedingungen und Testfällen verwendet werden. Diese Eingaben – Spezifikationen, Anforderungen, Designdokumente, User Stories und ähnliche Ergebnisse – werden zusammenfassend als Test bezeichnet. TestartefakteDas Ziel der Testanalyse ist es,tracDie Ziele des t-Tests sind so klar definiert, dass jedes einzelne in eine eindeutige Testbedingung umgewandelt werden kann. Da das analysierte Material die Grundlage bildet, von der alle Tests abgeleitet werden, wird es auch als Grundlage bezeichnet. Testbasis.

Typische Quellen, aus denen Tester Testinformationen beziehen, sind:

  • SRS – Software-Anforderungsspezifikation
  • BRS – Geschäftsanforderungsspezifikation
  • Funktionale Designdokumente
  • User Stories, Akzeptanzkriterien und Wireframes

Tester können Testbedingungen auch generieren, indem sie die zu testende Anwendung direkt untersuchen oder auf frühere Erfahrungen zurückgreifen, aber die meisten Testfälle werden aus Testartefakten abgeleitet, um zu pflegen tracFähigkeit.

👉 Melden Sie sich für ein kostenloses Live-Softwaretestprojekt an

Warum ist die Testbasis wichtig?

Die Testbasis ist der entscheidende Faktor dafür, ob eine Testsuite echte Fehler aufdeckt oder nur Scheinfehler verfolgt. Sie als optional zu behandeln, ist die häufigste Ursache dafür, dass unentdeckte Fehler in die Produktion gelangen. Eine fundierte Testanalyse bietet vier konkrete Vorteile:

  • TracFähigkeit: Jeder Testfall kann mit einer spezifischen Anforderung verknüpft werden, was die Analyse der Auswirkungen von Änderungen beschleunigt und Audit-Prüfungen unkompliziert macht.
  • Klarheit der Abdeckung: RevDurch das Betrachten der Basisoberflächen werden Lücken – unspezifizierte Fehlerzustände, fehlende Randfälle, undefinierte nicht-funktionale Schwellenwerte – aufgedeckt, bevor sie zu Produktionsvorfällen werden.
  • Abstimmung der Stakeholder: Wenn das Testteam die Bedingungen aus denselben Dokumenten ableitet, auf denen das Entwicklungsteam basiert, haben beide Seiten eine gemeinsame Definition von „fertig“.
  • Frühzeitige Fehlererkennung: Viele Mängel in den Anforderungen (Mehrdeutigkeiten, Widersprüche, fehlende Akzeptanzkriterien) werden bereits bei der Testanalyse aufgedeckt, lange bevor überhaupt Code geschrieben wird – mit Abstand der günstigste Zeitpunkt, um sie zu beheben.

Gemeinsame Quellen der Testgrundlage

Verschiedene Artefakte speisen unterschiedliche Testebenen. Nutzen Sie die folgende Tabelle als Kurzübersicht, um zu entscheiden, welches Dokument Sie beim Schreiben von Testfällen konsultieren sollten.

Quellartefaktam besten geeignet fürWas du Extract
Geschäftsanforderungsspezifikation (BRS)Abnahme- und SystemtestsEnd-to-End-Geschäftsregeln, regulatorische Beschränkungen, Erfolgskriterien
Software-Anforderungsspezifikation (SRS)SystemtestsFunktionale und nicht-funktionale Anforderungen mit messbaren Schwellenwerten
Funktionale/Technische KonstruktionsdokumenteIntegrationstestsModulschnittstellen, Datenfluss, Fehlerbehandlungsspezifikationen
Nutzergeschichten und AkzeptanzkriterienAgile Sprint-TestsVerhaltenserwartungen in der Form „Gegeben-Wenn-Dann“
Wireframes & UI-MockupsUI-/Usability-TestsLayout, Navigation, Eingabevalidierungsregeln
Anwendung im Test (explorativ)Exploratorische und RegressionstestsNicht dokumentiertes Verhalten, Arbeitsabläufe in der Praxis, Grenzfälle

Wie man eine Testanalyse Schritt für Schritt durchführt

Eine effektive Testanalyse folgt einem wiederholbaren fünfstufigen Arbeitsablauf, unabhängig von Projektgröße oder Methodik.

  1. Sammeln und inventarisieren Sie die Testgrundlagen. Sammeln Sie alle Artefakte, die das gewünschte Verhalten beschreiben – SRS, BRS, Designdokumente, User Stories, Mockups. Notieren Sie, welches Dokument welche Anforderung enthält. tracDie Funktionalität bleibt erhalten.
  2. RevBlick auf die Testbarkeit. Lesen Sie jedes Artefakt unter Berücksichtigung dreier Fragen: Ist diese Aussage messbar? Ist sie eindeutig? Ist sie vollständig? Kennzeichnen Sie jede Anforderung, die eine dieser Prüfungen nicht besteht, und melden Sie sie dem Autor zurück, bevor Sie Tests dagegen schreiben.
  3. Testbedingungen identifizieren. Listen Sie für jede testbare Aussage die zu überprüfenden Bedingungen auf (positive Pfade, negative Pfade, Grenzwerte, Fehlerbehandlung, Sicherheit, Leistung). Eine Testbedingung ist die absolutetract „was“ – zum Beispiel „Das System lehnt Bestellungen mit der Menge Null ab.“ — im Gegensatz zum konkreten „Wie“ eines Testfalls.
  4. Bedingungen priorisieren und gruppieren. Klassifizieren Sie jeden Zustand nach Risiko und Häufigkeit. Zustände mit hohem Risiko und hoher Häufigkeit werden detailliert erfasst; Zustände mit niedrigem Risiko können zusammengefasst oder stichprobenartig betrachtet werden. Hier entscheiden Sie auch, welche Zustände für eine Automatisierung in Frage kommen.
  5. Bedingungen in Testfälle umwandeln. Jede priorisierte Bedingung wird zu einem oder mehreren Punkten Testfälle mit Vorbedingungen, Schritten, Testdaten und erwarteten Ergebnissen. Anforderungen pflegen tracMachbarkeitsmatrix, die jeden Testfall mit seiner Ursprungsanforderung verknüpft.

Durch die Einhaltung dieser Vorgehensweise lassen sich die häufigsten Fehler bei der Testanalyse vermeiden: das Schreiben von Testfällen ohne klare Grundlage, das Übersehen negativer Szenarien und das Erstellen von Tests, die bei der Fehlerpriorisierung nicht mit einer Anforderung verknüpft werden können.

Testanalyse im V-Modell

Das V-Modell verknüpft jede Entwicklungsaktivität mit einer entsprechenden Testaktivität. Die Testanalyse erfolgt auf jeder Ebene anhand des jeweils verfügbaren Dokuments im Lebenszyklus.

Testanalyse im V-Testmodell

Abbildung 1: Testanalyse über die Phasen des V-Modell.

Fallstudie: Ableitung von Testfällen aus einer Kundenanforderung

Stellen Sie sich folgendes Szenario vor, in dem der Kunde die folgende einzeilige Anforderung sendet.

Client requirement: Add search functionality to an eCommerce Store

Auch wenn die Anwendung noch nicht erstellt wurde, kann ein Tester bereits mehrere Testbedingungen ableiten, indem er analysiert, was die Anforderung impliziert – sowohl das Verhalten im Normalfall als auch die Fehlermodi, die der Kunde nicht explizit angegeben hat. Einige Beispiele hierfür sind:

  • Überprüfen Sie das Suchergebnis, wenn kein Stichwort eingegeben wurde.
  • Überprüfen Sie das Suchergebnis, wenn für das eingegebene Stichwort kein passendes Produkt gefunden wird.
  • Überprüfen Sie das Suchergebnis, wenn mehrere passende Produkte für das Suchwort vorhanden sind.
  • Überprüfen Sie das Verhalten bei Sonderzeichen, führenden/nachfolgenden Leerzeichen und sehr langen Eingaben.
  • Überprüfen Sie die Groß-/Kleinschreibung und das Verhalten bei Teilübereinstimmungen.
  • Überprüfen Sie die Suchantwortzeit unter der erwarteten Benutzerlast.

Der Tester nimmt die Kundenanforderung (die Testgrundlage), analysiert sie und wandelt sie in Testbedingungen um. Dieses Muster wiederholt sich in jeder Phase des V-Modells – Testpläne und Testfälle werden anhand des jeweils verfügbaren Dokuments erstellt.

Video: Testanalyse erklärt

Falls das Video nicht geladen wird, können Sie es direkt ansehen auf YouTube.

Häufig gestellte Fragen

Eine Testbedingung beschreibt was muss verifiziert werden (z. B. „System blockiert leere Suchanfragen“). Ein Testfall fügt hinzu wieVoraussetzungen, Schritte, Daten und erwartetes Ergebnis. Mehrere Testfälle können eine Bedingung abdecken.

Ja. KI-Tools analysieren Anforderungen, z. B.tracTestbare Aussagen und vorgeschlagene Testbedingungen weisen häufig auf Unklarheiten hin, die einem menschlichen Prüfer entgehen könnten. Die menschliche Überprüfung bleibt jedoch unerlässlich, um Prioritäten, Geschäftsrisiken und domänenspezifische Grenzfälle zu validieren.

Tester melden festgestellte Lücken an Business-Analysten und Entwickler und nutzen anschließend exploratives Testen und erfahrungsbasierte Techniken, um die unbekannten Bereiche abzudecken. Jede Annahme wird dokumentiert, damit sie nach Stabilisierung der Anforderungen erneut validiert werden kann.

Die Prinzipien sind identisch; nur die Vorgehensweise unterscheidet sich. Agile Teams führen Testanalysen kontinuierlich, Story für Story, während der Sprintplanung und -verfeinerung durch. V-Modell-Teams hingegen tun dies in größeren Blöcken anhand formaler SRS- und Designdokumente.

Generative KI gleicht semantisch ähnliche Texte in Anforderungen und Testfällen ab und erstellt automatisch Builds. tracEs werden Machbarkeitsmatrizen erstellt und verwaiste Tests oder nicht abgedeckte Anforderungen erkannt. Dies verkürzt die Vorbereitungszeit für Audits und deckt Abdeckungslücken auf, die bei einer Stichwortsuche übersehen würden.

Fassen Sie diesen Beitrag mit folgenden Worten zusammen: