Benutzer:VÖRBY/temp

aus Wikipedia, der freien Enzyklopädie

Diese Seite wird aktuell verwendet, um das Kapitel 'Klassifizierung' im Artikel Softwaretest neu zu ordnen; siehe Diskussion:Softwaretest#Testartenklassifikation überarbeiten. In den Artikel übernommen: [2]

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 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 bestimmten konkreten 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 [1] klassifiziert diese Testmethoden folgendermaßen (verkürzt und z. T. kommentiert):

Statischer Test (Test ohne Programmausführung)

Dynamischer Test (Test mit Programmausführung)

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 ...

Funktionale Sicht von Benutzern/Anwendern

  • Geschäftsprozesstest: ... das Zusammenwirken von Programmteilen eines Geschäftsprozesses.
ähnlich wie End-zu-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 [2] 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.

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.

Software-Qualitätsmerkmale

Aus den Qualitätsmerkmalen von Software (z. B. gem. ISO/IEC 9126 – die für die meisten Testanforderungen den Rahmen bilden können) lässt sich eine große Anzahl von Tests ableiten. Testartbezeichnungen gemäß dieser Klassifikation sind zum Beispiel:

  • Funktionaler Test bzw. Funktionstest: ... ein System in Bezug auf funktionale Anforderungsmerkmale wie Korrektheit und Vollständigkeit.
  • Nicht-funktionaler Test: ... die nicht-funktionalen Anforderungen, wie z. B. die Sicherheit, die Gebrauchstauglichkeit oder die Zuverlässigkeit eines Systems. Beispiele für konkrete Testarten hierzu sind Sicherheitstest, Wiederanlauftest, GUI-Test, Installationstest, Lasttest. Dabei steht nicht die Funktion der Software (Was tut die Software?) im Vordergrund, sondern ihre Funktionsweise (Wie arbeitet die Software?).
  • Fehlertest: ... ob die Verarbeitung von Fehlersituationen korrekt, d. h. wie definiert, erfolgt.

Weitere Klassifikationen für Testarten

Zeitpunkt der Testdurchführung
  • Die nach diesem Aspekt bedeutendsten und meist auch im allgemeinen Sprachgebrauch benutzten Testartbezeichnungen sind die Teststufen, die mit Komponententest, Integrationstest, Systemtest, Abnahmetest bezeichnet werden.
  • Als Testarten für frühe Tests sind auch bekannt: Alpha-Test (erste Entwicklertests), Beta-Test (oder Feldtest; spätere Benutzer testen eine Pre-Version der Software)
  • Produktionstests werden in produktionsähnlich konfigurierten Testumgebungen oder gar in der Produktionsumgebung selbst, zum Teil sogar erst im produktiven Betrieb der Software (nur für unkritische Funktionen geeignet) durchgeführt. Möglicher Grund: Nur die Produktionsumgebung verfügt über bestimmte, zum Testen erforderliche Komponenten.
  • Auch Test-Wiederholungen gehören zum Aspekt Testzeitpunkt: Diese Tests werden Regressionstest, Retest oder ähnlich genannt.
  • Indirekt mit Zeitbezug sind zu nennen: Entwicklertest (vor Anwendertest ...), statisches Testen (vor dynamischem Testen).
Zum Testen ausgewählte methodische Ansätze
  • Spezielle Teststrategien: SMART-Testing, Risk based testing, Data driven Testing, exploratives Testen, top-down / bottom-up, hardest first, big-bang.
  • Besondere Methoden sind für Entscheidungstabellentests, Use-Case- oder anwendungsfallbasierte Tests, Zustandsübergangs-/zustandsbezogene Tests, Äquivalenzklassentests, Mutationstests (gezieltes Verändern von Quelltextdetails zu Testzwecken) und Pair-wise-Tests die Grundlage für Testartbezeichnungen.
Testintensität
  • Unterschiedliche Grade der Testabdeckung (Test-Coverage- bzw. Code-Coverage) werden mit Überdeckungstests erreicht, die (auf Grund der geringen Größe der Testobjekte) besonders für Komponententests geeignet sind. Testartenbezeichnungen hierzu: Anweisungs- (C0-Test, C1-Test), Zweig-, Bedingungs- und Pfadüberdeckungstest.
  • Mit Vorbereitungstests werden vorerst nur wichtige Hauptfunktionen getestet.
  • Ohne systematisch spezifizierte Testdaten/-fälle werden Smoketests ausgeführt, Tests, bei denen lediglich ausprobiert werden soll, ob das Testobjekt ‚überhaupt irgend etwas tut - ohne abzurauchen‘ – zum Beispiel im Rahmen eines Vorbereitungstests oder auch als finale Stichprobe beim Abschluss einer Teststufe.
  • Beim Error Guessing provozieren (erfahrene) Tester bewusst Fehler.
Informationsstand über die zu testenden Komponenten

... der beim Spezifizieren/Durchführen von Tests genutzt wird:

  • Black-Box-Tests werden ohne Kenntnisse über den inneren Aufbau des zu testenden Systems, sondern auf der Basis von Entwicklungsdokumenten entwickelt. In der Praxis werden Black-Box-Tests meist nicht von den Software-Entwicklern, sondern von fachlich orientierten Testern oder von speziellen Test-Abteilungen oder Test-Teams entwickelt. In diese Kategorie fallen auch Anforderungstests (Requirements Tests); auf der Grundlage spezieller Anforderungen) und stochastisches Testen (statistische Informationen als Testgrundlage)
  • White-Box-Tests, auch strukturorientierte Tests genannt, werden auf Grund von Wissen über den inneren Aufbau der zu testenden Komponente entwickelt. Entwicklertests sind i. d. R. White-Box-Tests - wenn Entwickler und Tester dieselbe Person sind. Hierbei besteht die Gefahr, dass Missverständnisse beim Entwickler zwangsläufig zu ‚falschen‘ Testfällen führen, der Fehler also nicht erkannt wird.
  • Grey-Box-Test werden zum Teil Tests genannt, bei denen eine Kombination von White- und Blackbox-Tests parallel praktiziert wird bzw. die nur auf partiellen Codekenntnissen beruhen.[3]
  • Low-Level-Test/High-Level-Test: Fasst Testarten begrifflich danach zusammen, ob sie auf konkrete technische Komponenten ausgerichtet sind (wie Debugging, White-Box-Test für low-Level) oder aufgrund von Vorgaben zur Implementierung ausgeführt/spezifiziert werden, z. B. Reqirementstest (Anforderungstest), Black-Box-Test für high-Level.
Wer führt die Tests aus oder spezifiziert sie?
  • Entwicklertests (Programmierertests), Benutzertests, Anwendertests, Benutzerakzeptanztests (User Acceptance Tests - UAT) werden von der jeweiligen Testergruppe durchgeführt.
  • Abnahmetests führen die fachlich für die Software verantwortlichen Stellen aus.
  • Betriebstest, Installationstests, Wiederanlauftests, Notfalltests nehmen u. a. auch Vertreter des ‚Rechenzentrums‘ vor - zur Sicherstellung der Einsatzfähigkeit nach definierten Vorgaben.
  • Crowd Testing; nach dem Prinzip des Crowdsourcing werden Testaufgaben an eine Menge von Usern im Internet (die Crowd) ausgelagert.
Art der Softwaremaßnahme

Diese Kategorie ist von eher untergeordneter Bedeutung; aus ihr resultieren Testbegriffe wie die folgenden:

  • In Wartungsprojekten werden Wartungstests und Regressionstests ausgeführt; dabei werden i. d. R. bereits vorhandene Testfälle und Testdaten benutzt.
  • In Migrationsprojekten werden Migrationstests durchgeführt; die Datenüberführung und spezielle Migrationsfunktionen sind hierbei z. B. Testinhalte.

Temp Referenzen

  1. ↑ Peter Liggesmeyer: Software-Qualität. Testen, Analysieren und Verifizieren von Software. Spektrum Akademischer Verlag, Heidelberg u. a. 2002, ISBN 3-8274-1118-1, S. 34.
  2. ↑ Toby Clemson: Testing Strategies in a Microservice Architecture. In: Martin Fowler. 18. November 2014, abgerufen am 13. März 2017 (englisch).
  3. ↑ Tobias Weber, Uni Köln, Planung von Softwareprojekten [1] White Black and Grey Box Test
Abgerufen von „https://de.wikiup.org/index.php?title=Benutzer:VÖRBY/temp&oldid=163902926“