Teststufen

 

Alle Teststufen können durch die folgenden Aspekte charakterisiert werden: allgemeine Ziele; die Arbeitsergebnisse, von denen die Testfälle abgeleitet werden (also die Testbasis); das Testobjekt (also was getestet wird); typische Fehlerwirkungen und –zustände, die gefunden werden sollten; Anforderungen an den Testrahmen und Werkzeugunterstützung; spezifische Ansätze und Verantwortlichkeiten.

Das Testen der Konfigurationsdaten eines Systems soll in der Testplanung berücksichtigt werden.

 

Komponententest

Testbasis:

  • Anforderungen an die Komponente
  • detaillierter Entwurf
  • Code

 

Typische Testobjekte:

  • Komponenten
  • Programme
  • Datenumwandlung/Migrationsprogramme
  • Datenbankmodule

 

Der Komponententest (auch bekannt als Unit-, Modul- oder Programmtest) hat zum Ziel, Software, die separat getestet werden kann (z.B. Module, Programme, Objekte, Klassen, etc.), zu prüfen und darin vorhandene Fehler zu finden. In Abhängigkeit von Lebenszyklus und System kann das durch Isolierung vom Rest des Systems erreicht werden. Dabei werden meist Platzhalter, Treiber und Simulatoren eingesetzt.

Der Komponententest kann das Testen funktionaler wie auch nicht-funktionaler Aspekte umfassen, so etwa das Testen der Ressourcenverwendung (z.B. Suche nach Speicherengpässe), Robustheitstest oder auch struktureller Test (z.B. Entscheidungsüberdeckung). Testfälle werden von Entwicklungsdokumenten wie einer Komponentenspezifikation, dem Softwareentwurf oder dem Datenmodell abgeleitet.

Meistens stehen den Testern beim Komponententest der Quellcode wie auch Unterstützung aus der Entwicklungsumgebung zur Verfügung, beispielsweise eine spezielle Komponententestumgebung (Unittest-Framework) oder Debugging-Werkzeuge. In der Praxis sind oft die für den Code verantwortlichen Entwickler an den Komponententests beteiligt. Dabei werden die gefundenen Fehlerzustände häufig sofort korrigiert und gar nicht erst formell behandelt.

Ein Ansatz beim Komponententest ist es, die Testfälle vor der Implementierung der Funktionalität vorzubereiten und zu automatisieren. Dies wird Test-First-Ansatz oder testgetriebene Entwicklung (test-driven) genannt. Dieser Ansatz ist sehr iterativ und basiert auf Zyklen aus Entwicklung von Testfällen, der Entwicklung und Integration von kleinen Code-Stücken und der Ausführung von Komponententests im Wechsel mit der Behebung der Probleme, bis die Tests erfolgreich durchlaufen sind.

 

Integrationstest

Testbasis

  • Software- und Systementwurf
  • Architektur
  • Nutzungsabläufe/Workflows
  • Anwendungsfälle (use cases)

 

Typische Testobjekte

  • Subsysteme
  • Datenbankimplementierungen
  • Infrastruktur
  • Schnittstellen
  • Systemkonfiguration und Konfigurationsdaten

 

Der Integrationstest prüft die Schnittstellen zwischen Komponenten und die Interaktionen zwischen verschiedenen Teilen eines Systems, beispielsweise zum Betriebssystem, Dateisystem, zur Hardware, und er prüft die Schnittstellen zwischen Systemen.

 

Es können mehrere Integrationsstufen zum Einsatz gelangen und diese können Testobjekte unterschiedlichster Größe betreffen. Zum Beispiel:

  1. Ein Komponentenintegrationstest prüft das Zusammenspiel der Softwarekomponenten und wird nach dem Komponententest durchgeführt.
  1. Ein Systemintegrationstest prüft das Zusammenspiel verschiedener Softwaresysteme oder zwischen Hardware und Software und kann nach dem Systemtest durchgeführt werden. In einem solchen Fall hat das Entwicklungsteam oft nur die eine Seite der zu prüfenden Schnittstelle unter seiner Kontrolle. Dies kann als Risiko betrachtet werden. Geschäftsprozesse, die als Workflows implementiert sind, können eine Reihe von Systemen nutzen. Plattformübergreifende Fragestellungen können signifikant sein.

Je größer der Umfang einer Integration ist, desto schwieriger ist die Isolation von Fehlerzuständen in einer spezifischen Komponente oder einem System, was zur Erhöhung des Risikos und zusätzlichem Zeitbedarf zur Fehlerbehebung führen kann.

Systematische Integrationsstrategien können auf der Systemarchitektur (z.B. Top-Down und BottomUp), funktionalen Aufgaben, Transaktionsverarbeitungssequenzen oder anderen Aspekten des Systems oder seiner Komponenten basieren. Um die Fehlerisolation zu erleichtern und Fehlerzustände früh aufzudecken, sind inkrementelle Integrationsstrategien normalerweise der Big-Bang-Strategie vorzuziehen.

Das Testen spezieller nicht-funktionaler Eigenschaften (z.B. Performance) kann im Integrationstest ebenso enthalten sein, wie funktionale Tests.

Bei jeder Integrationsstufe sollen Tester sich ausschließlich auf die eigentliche Integration konzentrieren. Wenn zum Beispiel das Modul A mit dem Modul B integriert wird, so soll der Fokus auf der Kommunikation zwischen den Modulen und nicht etwa auf der Funktionalität der einzelnen Module liegen, welche Inhalt des Komponententests war. Sowohl funktionale als auch strukturelle Ansätze können genutzt werden.

Idealerweise sollten Tester die Architektur verstehen und entsprechend auf die Integrationsplanung Einfluss nehmen. Werden Integrationstests bereits vor der Erstellung der einzelnen Komponenten oder Systeme geplant, können diese dann in der für die Integration effizientesten Reihenfolge entwickelt werden.

 

Systemtest

Testbasis

  • System- und Anforderungsspezifikation
  • Anwendungsfälle (use cases)
  • funktionale Spezifikation
  • Risikoanalyseberichte

 

Typische Testobjekte

  • System-, Anwender- und Betriebshandbücher
  • Systemkonfiguration und Konfigurationsdaten

 

Der Systemtest beschäftigt sich mit dem Verhalten eines Gesamtsystems/-produkts. Das Testziel soll klar im Master- und/oder Stufentestkonzept dieser Teststufe festgelegt sein.

Beim Systemtest sollte die Testumgebung mit der finalen Ziel- oder Produktivumgebung so weit wie möglich übereinstimmen, um das Risiko umgebungsspezifischer Fehler, die nicht während des Testens gefunden werden, zu minimieren.

Systemtests können Tests einschließen, die auf einer Risikoanalyse basieren und/oder auf Anforderungsspezifikationen, Geschäftsprozessen, Anwendungsfällen oder anderen abstrakten textuellen Beschreibungen oder Modellen des Systemverhaltens, auf Interaktionen mit dem Betriebssystem und den Systemressourcen.

Systemtests sollen funktionale und nicht-funktionale Anforderungen an das System sowie Datenqualitätscharakteristiken untersuchen. Dabei müssen sich Tester auch oft mit unvollständigen oder undokumentierten Anforderungen befassen. Funktionale Anforderungen werden im Systemtest zunächst mit spezifikationsorientierten Testentwurfsverfahren (Black-Box-Testentwurfsverfahren) getestet. Beispielsweise kann eine Entscheidungstabelle für die Kombination der Wirkungen in Geschäftsregeln erstellt werden. Strukturbasierte Verfahren (White-Box-Testentwurfsverfahren) können eingesetzt werden, um die Überdeckung der Tests zu bewerten, bezogen auf ein strukturelles Element wie die Menüstruktur oder die Navigationsstruktur einer Website.

 

Systemtests werden oft durch unabhängige Testteams durchgeführt.

Abnahmetest

Testbasis:

  • Benutzeranforderungen
  • Systemanforderungen
  • Anwendungsfälle (use cases)
  • Geschäftsprozesse
  • Risikoanalyseberichte

 

Typische Testobjekte: 

  • Geschäftsprozesse des voll integrierten Systems
  • Betriebs- und Wartungsprozesse
  • Anwenderverfahren
  • Formulare
  • Berichte
  • Konfigurationsdaten

 

Der Abnahmetest liegt meist im Verantwortungsbereich der Kunden oder Benutzer des Systems. Andere Stakeholder können jedoch auch daran beteiligt sein.

Das Ziel des Abnahmetests besteht darin, Vertrauen in das System, Teilsystem oder in spezifische nicht-funktionale Eigenschaften eines Systems zu gewinnen. Das Finden von Fehlerzuständen ist nicht das Hauptziel beim Abnahmetest. Abnahmetests können die Bereitschaft eines Systems für den Einsatz und die Nutzung bewerten, obwohl sie nicht notwendigerweise die letzte Teststufe darstellen. So könnte beispielsweise ein umfangreicher Systemintegrationstest dem Abnahmetest eines der Systeme folgen.

Die Durchführung von Abnahmetests kann zu verschiedenen Zeiten im Lebenszyklus erfolgen:

  • Eine Standardsoftware kann einem Abnahmetest unterzogen werden, wenn sie installiert oder integriert ist.
  • Der Abnahmetest bezüglich der Gebrauchstauglichkeit einer Komponente kann während des Komponententests durchgeführt werden.
  • Der Abnahmetest einer neuen funktionalen Erweiterung kann vor dem Systemtest erfolg

 

Unter anderem gibt es folgende typische Ausprägungen des Abnahmetests:

Anwender-Abnahmetest

Er prüft die Tauglichkeit eines Systems zum Gebrauch durch Anwender bzw. Kunden.

Betrieblicher Abnahmetest Die Abnahme des Systems durch den Systemadministrator enthält:

  • Test des Erstellens und Wiedereinspielens von Sicherungskopien (backup/ restore)
  • Wiederherstellbarkeit nach Ausfällen • Benutzermanagement
  • Wartungsaufgaben
  • Datenlade- u. Migrationsaufgaben und
  • periodische Überprüfungen von Sicherheitslücken

 

Vertraglicher und regulatorischer Abnahmetest Beim vertraglichen Abnahmetest wird kundenindividuelle Software explizit gegen die vertraglichen Abnahmekriterien geprüft. Abnahmekriterien sollten beim Vertragsabschluss zwischen den beteiligten Parteien definiert werden. Regulatorische Abnahmetests werden gegen alle Gesetze und Standards durchgeführt, denen das System entsprechen muss – beispielsweise staatliche, gesetzliche oder Sicherheitsbestimmungen.   Alpha- und Beta-Test (oder Feldtest) Hersteller kommerzieller oder Standardsoftware wollen oft Feedback von potenziellen oder existierenden Kunden erhalten, bevor sie ein Produkt kommerziell zum Kauf anbieten. Der Alpha-Test wird am Herstellerstandort durchgeführt, nicht jedoch vom Entwicklungsteam. Der Beta- (oder Feldtest) wird von Kunden oder potenziellen Kunden an den Kundenstandorten durchgeführt.

Organisationen können ebenso andere Begriffe nutzen z.B. Fabrikabnahmetests oder Kundenakzeptanztests für Systeme, die getestet werden, bevor oder nachdem sie zum Einsatzort eines Kunden gebracht wurden.

 

Pin It on Pinterest

Shares