Software Testing: Arten, Methoden und Ebenen - PDF

Softwarequalität ······························································································ 5 Systematisches Testen Lernziele des Kapitels: Traditionell am Ende des Entwicklungsprozesses angesiedelt, sind Tests heutzu- tage in jede Phase integriert, von der Anforderungsanalyse bis zur Wartung. Die- ser Wandel hin zu kontinuierlichen Tests trägt dazu bei, Fehler frühzeitig zu er- kennen und zu beheben, wodurch die Qualität verbessert und die Entwicklungs- zeit verkürzt wird. Hierbei gibt es eine Vielzahl unterschiedlicher Testverfahren. Nach dem Studium dieses Kapitels entwickeln die Leserinnen und Leser ein erstes Verständnis für:  wichtige Testarten (‚was getestet werden kann‘)  unterschiedliche Testmethoden (‚wie getestet werden kann‘)  unterschiedliche Testebenen  zum Beispiel, im Detail: Black-Box-Tests, White-Box-Tests, Unit-Tests, und viele weitere Verfahren Bei der Entwicklung qualitativ hochwertiger Software sind analytische Qualitäts- maßnahmen ein wesentlicher Bestandteil (vgl. z. B. Abschnitt 1.5). Sie dienen dazu, die Qualität des Produkts systematisch zu bewerten und zu verbessern. Unter die- sen Maßnahmen sind Softwaretests wiederum von besonderer Bedeutung. In der Vergangenheit, besonders im Kontext traditioneller Entwicklungsmodelle wie dem Wasserfallmodell, erfolgte die Testphase typischerweise am Ende des Ent- wicklungsprozesses. Diese sequenzielle Herangehensweise sah vor, dass die Kon- zeption, Gestaltung, Implementierung und schließlich die Verifizierung der Soft- ware in strikt getrennten Phasen durchgeführt wurden. Erst nachdem alle Entwick- lungsschritte abgeschlossen waren, wurden Tests durchgeführt, um die Qualität und Funktionalität des fertigen Produkts zu bewerten. Heutzutage hat sich die Perspektive auf den Testprozess in der Softwareentwick- lung deutlich gewandelt. Tests sind zu einem integralen Bestandteil aller Phasen des Entwicklungszyklus geworden, beginnend mit der Anforderungsanalyse über das Design und die Implementierung bis hin zur Wartung. Diese kontinuierliche In- tegration von Testverfahren ermöglicht es, Fehler und Probleme frühzeitig zu ······················································································································ 89 Softwarequalität ······························································································ erkennen und zu beheben, was die Qualität der Software erheblich verbessert und die Entwicklungszeit verkürzt. Diese Evolution spiegelt sich in modernen agilen und iterativen Entwicklungsansät- zen wider, in denen die kontinuierliche Rückmeldung und Anpassung zentrale Ele- mente sind (siehe auch Kapitel 6). Durch die Einbettung des Testens in jede Phase des Entwicklungsprozesses wird nicht nur die Qualität der Endprodukte gesteigert, sondern es entsteht auch eine engere Zusammenarbeit zwischen Entwicklern und Testern, was zu einer effizienteren und effektiveren Softwareentwicklung führt. 5.1 Wichtige Testarten (‚was alles getestet werden kann‘) Um sich dem Thema Softwaretests zu nähern, kann eine Einteilung in verschiedene Testarten vorgenommen werden. Im Grunde geht es dabei darum, ‚was getestet werden kann‘: Funktionale Tests: In der Softwareentwicklung bilden funktionale Tests das Rückgrat der Teststrategien. Sie sind darauf ausgerichtet, die Übereinstimmung der Softwarefunktionen mit den spezifizierten Anforderungen sicherzustellen. Dazu zählt die Überprüfung von Benutzeroberflächen, APIs, Datenbanken, Si- cherheitsfunktionen und Funktionalität unter verschiedenen Betriebsbedin- gungen. Funktionale Tests werden typischerweise ohne Betrachtung des inter- nen Codes oder der Struktur durchgeführt, was sie zu Black-Box-Tests macht (mehr Informationen dazu unten): Der Tester kennt die interne Struktur des zu testenden Objekts nicht und konzentriert sich ausschließlich darauf, ob es die erwarteten Ergebnisse liefert. Nicht-funktionale Tests: Im Gegensatz zu funktionalen Tests konzentrieren sich nicht-funktionale Tests auf Aspekte, die die Effizienz und Benutzerfreundlich- keit eines Systems bestimmen. Dazu gehören Leistungstests, bei denen bewer- tet wird, wie das System unter Lastbedingungen funktioniert, Volumentests, die die Handhabung großer Datenmengen überprüfen, und Stresstests, die die Stabilität des Systems unter Extrembedingungen testen. Auch Security-Tests, die die Widerstandsfähigkeit der Software gegenüber unerlaubten Zugriffen prüfen, und Usability-Tests, die sich mit der Benutzererfahrung beschäftigen, fallen in diese Kategorie. Nicht-funktionale Tests sind wesentlich, um zu ge- währleisten, dass die Software nicht nur korrekte Ergebnisse liefert, sondern auch in der realen Welt zuverlässig, sicher und benutzerfreundlich ist. Tabelle ······················································································································ 90 Softwarequalität ······························································································ 1 von Krypczyk und Bochkor (2018, S. 323-324) fasst wichtige Arten nicht-funk- tionaler Tests zusammen. Strukturbezogene Tests oder White-Box-Tests bieten einen tiefen Einblick in den Aufbau der Software. Im Gegensatz zu Black-Box-Tests, bei denen die in- neren Abläufe der Software verborgen bleiben, setzen White-Box-Tests Wissen über die interne Logik und Struktur voraus. Entwickler verwenden diese Tests, um spezifische Teile des Codes zu überprüfen, wobei der Schwerpunkt auf der Codeabdeckung liegt – also darauf, dass jeder Teil des Codes durch den Test- prozess ausgeführt wird. Dies ist besonders nützlich, um sicherzustellen, dass alle möglichen Wege durch den Code, einschließlich Schleifen und Verzweigun- gen, korrekt funktionieren (nähere Informationen zu White-Box-Tests unten). Änderungsbezogene Tests, oft auch als Regressionstests bezeichnet, sind von kritischer Bedeutung, wenn Software aktualisiert oder geändert wird. Ihr Hauptziel ist es, sicherzustellen, dass neue Codeänderungen keine unbeabsich- tigten Nebeneffekte in bereits geprüften Teilen des Systems verursachen. Diese Tests sollen die beständige Funktionalität der Software über die Zeit hinweg sicherstellen. Aufgrund ihrer wiederholten Natur bietet sich die Automatisie- rung von Regressionstests an. Sie ermöglicht es, dass diese Tests effizient und häufig durchgeführt werden können, was eine kontinuierliche Qualitätssiche- rung während der gesamten Softwareentwicklung und -wartung gewährleistet. Testautomatisierung hilft dabei, die Kosten zu senken und beschleunigt die Re- lease-Zyklen, da sie es ermöglicht, mehr Tests in kürzerer Zeit durchzuführen. ······················································································································ 91 Softwarequalität ······························································································ Nicht-funktionaler Test Beschreibung Lasttest Hier wird das Systemverhalten bei steigender Benutzer- oder Transaktionszahl gemessen. Dabei wird die Last schrittweise bis zu dem Punkt erhöht, den die Speziﬁkation vorsieht. Performance-Test Wir messen die Verarbeitungs- und Antwortzeiten des Systems. Diese sind meist abhängig von der Last, sodass die Werte gerade bei hoher Last geprüft werden müssen. Volumentest Wie verhält sich das System bei der Bewältigung sehr großer Datenmengen? Stresstest Die durch das System zu verarbeitende Last (Benutzer-/Transaktionszahl) wird über die festgelegten Grenzwerte hinaus gesteigert. Das Ziel: Prüfung des Systems bei Überlastung. Security-Test Das Ziel ist es, die Sicherheit des Systems vor unberechtigten Datenzugriﬀen zu prüfen. Gelingt es von außen, ohne das Vorhandensein von Berechtigungen, in das System einzudringen? Zuverlässigkeitstest Wie reagiert das System unter Dauerbetrieb? Es werden beispielsweise die Anzahl der Ausfälle in einem bestimmten Zeitintervall notiert. Robustheitstest Die Robustheit beschreibt, wie resistent das Programm gegenüber externen Fehlern, zum Beispiel Fehleingaben der Nutzer, ist. Kompatibilitätstest Wie leicht lassen sich die Daten der Software mit anderen Programmen austauschen? Gibt es hier eine entsprechende Kompatibilität bezüglich des verwendeten Datenformats, oder sind leistungsfähige Import- und Exportfilter vorhanden? Konﬁgurationstest Wie gut lässt sich das System in unterschiedlichen Systemumgebungen verwenden? Dies betrifft zum Beispiel unterschiedliche Betriebssysteme, Versionen von Betriebssystemen, Hardware oder Landessprachen. Usability-Test Kann das System als benutzerfreundlich gelten? Können die Anwenderinnen die Benutzung schnell erlernen? Werden sie dabei unterstützt, keine unnötigen Fehler zu begehen (z. B., weil die Informationen übersichtlich dargestellt sind)? Usw. Dokumentationstest Zu Software gehört auch sehr oft eine Dokumentation. Zum einem umfasst diese eine Nutzerdokumentation, zum Beispiel in Form einer integrierten Online-Hilfe, zum anderen die Softwareentwicklungsdokumentation. Beide Dokumente müssen vollständig und korrekt sein, nur dann sind sie eine sinnvolle Hilfe. Tabelle 1: Verschiedene Arten Nicht-funktionaler Tests übernommen, i. A. a. Krypczyk & Bochkor (2018, S. 323-324) 5.2 Testmethoden (‚wie getestet werden kann‘) Beim Testen gibt es zwei grundsätzliche Zugänge, ‚wie getestet werden kann‘: sta- tische Tests und dynamische Tests. Statische Tests sind Formen der Analyse, die ohne die tatsächliche Ausführung des Codes stattfinden. Sie konzentrieren sich darauf, den Quellcode, seine Struktur und die begleitende Dokumentation zu untersuchen, um potenzielle Fehlerquellen zu identifizieren. Diese Tests können sowohl manuell als auch au- tomatisiert erfolgen und stellen oft einen ersten Schritt in der Qualitätssiche- rung dar. Dynamische Tests betreffen das aktive Ausführen des Programms in einer Lauf- zeitumgebung. Ziel ist es, das tatsächliche Verhalten der Software unter ver- schiedenen Bedingungen zu beobachten und zu analysieren. Dynamische Tests ······················································································································ 92 Softwarequalität ······························································································ sind unverzichtbar, um zu überprüfen, ob die Software in der realen Anwen- dung funktioniert, wie beabsichtigt. Statische und dynamische Softwaretests bilden zusammen ein robustes Framework für analytische Qualitätsmaßnahmen. Sie erlauben es Entwicklerteams, Schwach- stellen frühzeitig zu erkennen und korrigierende Maßnahmen zu ergreifen. Im wei- teren Verlauf werden wir die spezifischen Techniken und Methoden beider Testar- ten detaillierter betrachten. 5.2.1 Statische Softwaretests Wir haben bereits eine Form statischer Softwaretests kennengelernt, ohne diese explizit so zu bezeichnen. Die in Kapitel 4 diskutierten Softwaremetriken können nämlich durchaus diesem Bereich zugeordnet werden. Um den Softwaremetriken eine tiefere Auseinandersetzung zu ermöglichen, wurde ihnen ein eigenes Kapitel gewidmet. Zu den statischen Softwaretests sind an prominenter Stelle außerdem Reviews und Inspektionen zu nennen. 5.2.1.1 Reviews und Inspektionen Auch mit Reviews und Inspektionen haben wir uns bereits beschäftigt, nämlich in Teil 1 dieser Lehrveranstaltung zum Requirements Engineering. Dort haben wir sie speziell für die Anforderungsanalyse herangezogen. Diese Techniken ermöglichen es aber auch, den Quellcode, die Softwarearchitektur und die begleitende Doku- mentation gründlich zu analysieren. Zur Wiederholung: Reviews (Stellungnahmen) sind systematische Untersuchungen von Software-Dokumenten (z. B. Anforderungsspezifikationen, Design-Dokumente, Quellcode) durch eine oder mehrere Personen. Das Ziel ist, Fehler zu finden, Ver- ständlichkeit zu gewährleisten und die Einhaltung der festgelegten Standards zu überprüfen. Bei einem Review wird das Dokument in der Regel von Kollegen gele- sen, die dann ihr Feedback, ihre Kommentare und etwaige Bedenken äußern. Dies kann in formellen Meetings oder durch schriftliche Kommentare geschehen. Inspektionen sind formalere Überprüfungsverfahren, die in der Regel strengen Richtlinien folgen. Sie sind oft Teil eines Qualitätskontrollprozesses. Während einer Inspektion überprüft ein Team, das typischerweise aus Entwicklern, Testern und manchmal auch Vertretern anderer Stakeholder besteht, die Software-Dokumente ······················································································································ 93 Softwarequalität ······························································································ und -Komponenten auf Fehler und Probleme. Inspektionen sind gründlich und strukturiert; sie beinhalten in der Regel Vorbereitung, Überprüfung, das eigentliche Inspektionstreffen und die Nachbearbeitung, bei der festgestellte Probleme beho- ben werden. Ein Walkthrough ist eine informellere Prüfungsmethode, bei der ein Autor das Do- kument oder den Code präsentiert und durchgeht. Das kann zum Beispiel eine Prä- sentation des Designs oder Quellcodes sein, bei der das Entwicklerteam gemeinsam durchgeht, um Designentscheidungen zu verstehen und potenzielle Fehlerquellen zu identifizieren. Ein Walkthrough zielt darauf ab, Feedback und Vorschläge zur Ver- besserung zu sammeln und das Verständnis aller Beteiligten zu fördern. Alle drei Methoden tragen dazu bei, die Softwarequalität zu verbessern, indem sie eine frühzeitige Fehlererkennung ermöglichen und die Einhaltung von Projektstan- dards sicherstellen. Sie ergänzen dynamische Testmethoden, indem sie mögliche Probleme identifizieren, bevor Zeit und Ressourcen für weitergehende Tests aufge- wendet werden. 5.2.2 Dynamische Softwaretests Dynamische Softwaretests beinhalten das Ausführen des Programms oder Codes in einer Laufzeitumgebung, um Fehler, Schwachstellen oder Abweichungen von den vorgegebenen Anforderungen zu identifizieren. Diese Art des Testens ist besonders wertvoll, da sie es ermöglicht, das tatsächliche Verhalten der Software unter ver- schiedenen Bedingungen zu beobachten und zu analysieren. Im Gegensatz zu stati- schen Tests, bei denen der Code nicht exekutiert wird, bieten dynamische Tests Einblicke in die Leistung, Stabilität und Zuverlässigkeit der Software während ihrer Ausführung. Sie helfen dabei, nicht nur Code-Fehler, sondern auch Probleme mit der Softwareintegration, Benutzerinteraktion und im Systembetrieb zu entdecken und zu beheben. 5.2.2.1 Testfälle Ein Testfall ist ein dokumentiertes Set von Bedingungen und Schritten, die ausge- führt werden, um zu testen, ob eine Softwarefunktion richtig arbeitet oder ein be- stimmtes Nutzerverhalten adäquat unterstützt wird. Testfälle sind unerlässlich, um systematisch Fehler und Probleme in der Software zu finden, bevor diese den End- benutzer erreicht. ······················································································································ 94 Softwarequalität ······························································································ Die Anzahl der benötigten Testfälle variiert und hängt vom Umfang und der Kom- plexität der Anwendung, den Risiken, den Arten der Tests (z. B. funktionale, nicht- funktionale Tests) und dem Detailgrad der Testabdeckung ab. Grundsätzlich sollten ausreichend Testfälle existieren, um alle Anforderungen abzudecken und alle Teile des Systems ausreichend zu prüfen (weitere vertiefende Informationen hierzu im nächsten Abschnitt zu den Black-Box-Tests). Es ist in der Praxis jedoch fast unmög- lich, eine Software komplett austesten, das heißt, alle möglichen Zustände und In- teraktionen innerhalb einer Anwendung zu überprüfen. Dies liegt unter anderem an folgenden Faktoren: Komplexität: Moderne Software kann extrem komplex sein, mit Millionen von Zeilen an Code und zahlreichen Funktionen, die in verschiedenen Kombinatio- nen und unter verschiedenen Bedingungen verwendet werden können. Kombinatorische Explosion: Bei vielen Programmen gibt es eine enorme Anzahl von Eingabe- und Zustandskombinationen. Selbst mit einer begrenzten Anzahl von Variablen können die Kombinationsmöglichkeiten exponentiell ansteigen, sodass es praktisch unmöglich ist, jede Kombination zu testen. Zeit und Ressourcen: Vollständiges Testen wäre extrem zeit- und kosteninten- siv. In den meisten Fällen ist es unwirtschaftlich, jeden möglichen Pfad und Zu- stand zu testen. Dynamische und interaktive Umgebungen: Viele Programme interagieren mit externen Systemen und Benutzern, die unvorhersehbares Verhalten aufweisen können, wodurch weitere Unsicherheiten in das Testen gebracht werden. In der Softwareentwicklung strebt man daher eine risikobasierte Annäherung an, indem man sich auf die wichtigsten und wahrscheinlichsten Anwendungsfälle kon- zentriert und die Bereiche mit dem höchsten Risiko priorisiert. Testfälle werden entwickelt, um die kritischsten Funktionen der Software abzudecken und um dieje- nigen Szenarien zu testen, die entweder am häufigsten auftreten oder die schwer- wiegendsten Folgen haben könnten, sollte es zu einem Fehler kommen. Der Anteil der Testabdeckung, der als ausreichend angesehen wird, hängt von der Anwendung ab. Für kritische Systeme, wie z. B. für die Luft- und Raumfahrt oder die Medizintechnik, strebt man sehr hohe Testabdeckungsraten an, die 95% oder mehr erreichen können. Für weniger kritische Anwendungen kann eine niedrigere Testabdeckung akzeptabel sein (Schneider, 2012). In vielen Fällen wird eine ······················································································································ 95 Softwarequalität ······························································································ Kombination aus manuellen und automatisierten Tests eingesetzt, um eine breite und effiziente Testabdeckung zu gewährleisten. Testfälle werden meist von Testerinnen entwickelt, die sich die Anwendungsfälle und Anforderungsdokumente genau ansehen. Sie überlegen sich, welche Aktionen und Eingaben von einem Benutzer erwartet werden und wie das System darauf re- agieren sollte. Auch mögliche Fehlerbedingungen und Randfälle werden berück- sichtigt. Die Dokumentation von Testfällen erfolgt oft in Testmanagement-Tools oder ein- fach mittels Tabellenkalkulationsprogrammen (siehe unten), die eine strukturierte Darstellung ermöglichen. Abbildung 14 veranschaulicht welche Informationen je Testfall festgehalten werden sollten. Da sich Softwareprojekte in einem fortwäh- renden Entwicklungsprozess befinden, ist es für Nachvollziehbarkeit sowie Repro- duzierbarkeit essentiell, für alle veränderlichen Komponenten die jeweiligen Versi- ons- oder Identifikationsnummern zu notieren: Testfall-ID (z. B. „T-39“) Eine Beschreibung des Testfalls Die Testumgebung und Vorbedingungen für die Durchführung des Testes Testdaten (abgeleitet aus der Spezifikation und aus dem zu testenden Pro- grammabschnitt – z. B. „Modul X-v2.14) Schritte zur Ausführung Erwartetes Ergebnis (festgeschrieben in der Spezifikation oder mit deren Hilfe ableitbar/festlegbar) Tatsächliches Ergebnis nach Durchführung des Tests Schlussfolgerung/Status (pass/fail) Bemerkungen oder Besonderheiten ······················································································································ 96 Softwarequalität ······························································································ Abbildung 14: Testfall inklusive dazugehörige Informationen, i. A. a. Schneider (2012, S. 86) Diese Dokumentation hilft dabei, den Testprozess nachvollziehbar und wiederhol- bar zu machen und bildet eine Basis für die kontinuierliche Verbesserung der Test- verfahren. Die Gesamtheit aller Testfälle kann im einfachsten Fall als Tabelle gespeichert wer- den. Abbildung 15 zeigt verschiedene Testfälle für ein Kassensystem zur Bestim- mung des Eintrittspreises (z. B. von einem Schwimmbad). Die Eingabe der Alters- stufen sollten das jeweilige Eintrittsgeld als Ergebnis liefern. Abbildung 15:Tabellarisch festgehaltene Testfälle nach Schneider (2012, S. 86) Abbildung 16 beinhaltet eine schematische Darstellung der Testumgebung für dy- namisches Testen. Wie oben beschrieben, sollten wir möglichst bald mit dem Tes- ten anfangen, auf jeden Fall, bevor die gesamte Anwendung fertig erstellt wurde. Aus diesem Grund benötigen wir eine Testumgebung, welche es ermöglicht, das Testobjekt unabhängig von der restlichen Anwendung auszuführen. ······················································································································ 97 Softwarequalität ······························································································ Abbildung 16: Testrahmen um ein Testobjekt für das dynamische Testen von Teilprogrammen, i. A. a. Krypczyk & Bochkor (2018, S. 330) Der Testrahmen wird eingesetzt, um die fehlenden oder im Rahmen eines separa- ten Komponententests nicht verfügbaren Programmteile für das Testobjekt zu si- mulieren. Über definierte Schnittstellen erfolgt der Aufruf des Testobjekts, wobei dieser Rahmen auch als sogenannter Testtreiber bekannt ist. Durch den Testtreiber wird das Testobjekt in verschiedenen Szenarien (Testfällen) aufgerufen und mit den notwendigen Daten versorgt. Der Verbindungspunkt zwischen Testtreiber und Testobjekt, der für die Steuerung zuständig ist, wird Point of Control (PoC) genannt, während die Komponenten, die das Testobjekt aufrufen und sein zukünftiges Ver- halten im Softwareumfeld nachahmen, als Stellvertreter – bekannt unter Begriffen wie Stub, Dummy oder Mock – fungieren. Die Überprüfung der Ausgaben des Test- objekts sowie der Vergleich der tatsächlichen mit den erwarteten Ergebnissen er- folgen am Point of Observation (PoO). Zusätzlich wird der Testrahmen mit Analyse- und Monitoringtools versehen, um den Testprozess zu optimieren (Krypczyk & Bochkor, 2018, S.331). 5.2.2.2 Black-Box-Tests Bei Black-Box-Tests konzentriert man sich ausschließlich auf das Ergebnis der Test- durchführung, ohne die internen Mechanismen des untersuchten Systems zu be- rücksichtigen. Ein Test gilt als erfolgreich, wenn das Ergebnis den Erwartungen ent- spricht, unabhängig von der internen Logik oder Komplexität der getesteten Ein- heit. Diese Testmethode ermöglicht keine Aussagen über die interne Stabilität der Software. Sollten bei der Durchführung Fehler auftreten, ist eine tiefergehende Un- tersuchung erforderlich. Häufig werden Black-Box-Tests bei extern bezogenen ······················································································································ 98 Softwarequalität ······························································································ Komponenten oder Klassen angewandt, da der Quellcode dieser Elemente oft nicht zugänglich ist. Dies ist ein wichtiger Aspekt beim Erwerb fertiger Softwarekompo- nenten, da zu klären ist, ob der Quellcode mitgeliefert wird und ob Anpassungen aus lizenzrechtlichen Gründen zulässig sind. Wie in Abbildung 17 dargestellt, wird beim Black-Box-Test das Testobjekt von extern evaluiert, was bedeutet, dass so- wohl der Point of Control (PoC) als auch der Point of Observation (PoO) außerhalb des Testobjekts liegen (Krypczyk & Bochkor, 2018, S. 331-332). Abbildung 17: Testrahmen mit Testobjekt, das in einem Black-Box-Verfahren geprüft wird, i. A. a. Krypczyk & Bochkor (2018, S. 332) Die Grundlage für Testfälle bildet die Spezifikation des Testobjekts, welche die zu erfüllenden Leistungsanforderungen definiert (siehe Abbildung 18). Somit be- schränkt sich der Umfang eines Black-Box-Tests auf die durch den Tester festge- legte Spezifikation. Schneider (2012, S. 93) empfiehlt zwei Prinzipien, um eine an- gemessene Anzahl von Testfällen zu bestimmen. Minimalforderung: „Jede spezifizierte Anforderung muss durch mindestens ei- nen Testfall angesprochen werden. Man sagt dann: »Der Testfall deckt die An- forderung ab«. Alle Testfälle zusammen sollen alle Anforderungen abdecken, also die gesamte Spezifikation“ (Schneider, 2012, S. 93). Effizienzprinzip: „Das Effizienzprinzip fordert, möglichst wenige Testfälle zu er- stellen und dabei möglichst auch mehrere Anforderungen durch einen gemein- samen Testfall abzudecken“ (Schneider, 2012, S. 93). ······················································································································ 99 Softwarequalität ······························································································ Abbildung 18: Die Spezifikation muss in einzelne Anforderungen zergliedert werden, welche wiede- rum durch Testfälle abzudecken sind, i. A. a. Schneider (2012, S. 92) Es sei nochmals auf die Wichtigkeit der Spezifikation hingewiesen. Eine unvollstän- dige oder inkorrekte Spezifikation kann zu einem fehlerfreien Testablauf führen (es wird also kein Fehler ‚geworfen‘), der jedoch nicht die Funktionskorrektheit der Komponente garantiert. Zusätzlich besteht die Möglichkeit, dass das Testobjekt Funktionen enthält, die von der aktuellen Spezifikation nicht erfasst und dement- sprechend nicht geprüft werden, was besonders bei der Wiederverwendung kom- plexer Komponenten zu beachten ist. Bei einer veränderten Anwendung einer teil- weise mit Black-Box-Verfahren getesteten Komponente können Fehler auftreten, die eine erneute Testung erfordern (Krypczyk & Bochkor, 2018, S. 332). Wie in der oben gezeigten Tabelle ersichtlich ist, werden häufig Grenzwerte zur Formulierung von Testfällen ausgewählt. Dies geschieht, weil an den Grenzen von Wertebereichen erfahrungsgemäß oft Fehler auftreten. Diese Methode, bei der systematisch Grenzwerte für Tests herangezogen werden, nennt man „Grenz- wertanalyse“. Sie ist eine effektive Technik, da viele Softwarefehler in der Nähe von Extremwerten – zum Beispiel bei sehr großen oder sehr kleinen Zahlen, bei der ma- ximalen Länge von Texteingaben oder an den Grenzen von Wertebereichen – auf- treten. ···················································································································· 100 Softwarequalität ······························································································ Die Grenzwertanalyse ist Teil eines breiteren Spektrums an heuristischen Metho- den, die zum Auffinden von verdächtigen oder fehleranfälligen Testfällen genutzt werden. Neben der Grenzwertanalyse gibt es weitere Heuristiken wie „Äquivalenz- klassenbildung“, bei der Eingaben in Gruppen mit ähnlichem Verhalten unterteilt werden, oder „Zustandsbasiertes Testen“, welches darauf abzielt, unterschiedliche Systemzustände und Übergänge zu überprüfen. Derartige Heuristiken helfen dabei, die Testabdeckung zu maximieren und dabei den Testaufwand ökonomisch zu hal- ten, indem sie gezielt jene Bereiche überprüfen, in denen die Wahrscheinlichkeit von Fehlern am höchsten ist. 5.2.2.3 White-Box-Tests Bei White-Box-Tests liegt der Schwerpunkt auf der Analyse und Überprüfung aller möglichen Pfade, die durch die interne Struktur des Testobjekts, wie beispielsweise eine Softwareklasse, führen, um potenzielle Fehlerquellen aufzudecken. Die Unter- suchung konzentriert sich auf die interne Logik und Aufbau der Softwarekompo- nente. Die Gestaltung der Testverfahren basiert auf der genauen Kenntnis der Pro- grammlogik und des Quelltexts. Ziel dieser Testmethode ist es, die Zuverlässigkeit von Schleifen, Verzweigungen und anderen Strukturelementen des Programms zu überprüfen, indem man den Grad der Codeabdeckung misst. Wie in Abbildung 19 dargestellt, befinden sich der Point of Control (PoC) und der Point of Observation (PoO) direkt im Testobjekt. Eine Grundvoraussetzung für White-Box-Tests ist der Zugang zum Quellcode. Die Absicht ist, sicherzustellen, dass jede Zeile des Codes im Rahmen der Tests mindestens einmal ausgeführt wird. Die Testfälle werden aus der Logik des Quellcodes abgeleitet. Dabei wird davon ausgegangen, dass die Im- plementierung der Anforderungen im Code bereits erfolgt und abgeschlossen ist, und somit nicht Gegenstand des Tests ist (Krypczyk & Bochkor, 2018, S. 333). Abbildung 19: Testrahmen mit Testobjekt, das in einem White-Box-Verfahren geprüft wird, i. A. a. Krypczyk & Bochkor (2018, S. 334) ···················································································································· 101 Softwarequalität ······························································································ 5.3 Testebenen Testebenen sind klar definierte Stadien im Software-Testprozess, bei denen unter- schiedliche Aspekte eines Softwareprodukts überprüft werden. Jede Ebene adres- siert spezifische Testziele und ist einem bestimmten Entwicklungsstadium zugeord- net. Sie helfen dabei, den Testaufwand zu strukturieren und sicherzustellen, dass die Software jeder Phase der Entwicklung die Qualitätserwartungen erfüllt. Beson- ders eingängig lassen sich die verschiedenen Testebenen und ihre Verortung im Entwicklungszyklus am bereits besprochenen V-Modell nachvollziehen. 5.3.1 Unit-Tests (Komponententests / Modul-Tests) Unit Tests, oft auch als Komponententests oder Modul-Tests bezeichnet, sind eine Methode des Softwaretestens, bei der die kleinsten testbaren Teile einer Anwen- dung, üblicherweise Klassen oder einzelne Funktionen, isoliert geprüft werden. Sie stellen die unterste Testebene dar. Ziel der Unit Tests ist es, sicherzustellen, dass jede isolierte Komponente korrekt funktioniert. Metaphorisch gesprochen, wird die Qualität jeder einzelnen Zutat mit Unit-Tests sichergestellt, damit das ‚fertig ge- kochte Gericht‘ nicht verunreinigt durch ein schlechtes ‚Lebensmittel‘ ist und somit die ‚Mahlzeit‘ insgesamt nicht optimal ‚schmecken‘ kann. Hier sind einige Kernpunkte zu Unit Tests: „Arrange-Act-Assert (AAA)“ Muster: Das sogenannte AAA-Pattern ist ein gän- giges Muster zur Strukturierung von Unit Tests. Es dient dazu, Tests klar und verständlich zu halten, indem es den Testprozess in drei definierte Schritte un- terteilt. 1) „Arrange“ (Aufbauen): In dieser Phase bereitet man alles vor, was für die Ausführung des Tests benötigt wird. Hierzu gehören das Initialisieren von Objekten, das Einrichten von Mocks oder Stubs für Abhängigkeiten und das Festlegen der Eingabewerte für die Methode, die getestet werden soll. Diese Vorbereitungen schaffen die Voraussetzungen, unter denen der Test ausge- führt wird. 2) „Act“ (Ausführen): In diesem Schritt wird die Aktion durchgeführt, die eigentlich getestet werden soll. Dies bedeutet in der Regel den Aufruf der Methode oder Funktion, deren Verhalten oder Rückgabewert man testen möchte. Der Act-Schritt sollte sich auf eine einzige Aktion beschränken, um den Test so spezifisch wie möglich zu halten (siehe weitere Punkte unten). 3) „As- sert“ (überprüfen): Der letzte Schritt ist die Überprüfung, ob die Aktion das er- wartete Ergebnis liefert. Hier werden die tatsächlichen Ergebnisse des Act- ···················································································································· 102 Softwarequalität ······························································································ Schritts mit den erwarteten Ergebnissen verglichen. Dies kann das Überprüfen von Rückgabewerten, das Überprüfen des Zustands eines Objekts oder das Be- stätigen sein, dass die richtigen Methoden auf Mock-Objekten aufgerufen wur- den. Isolation: Unit Tests werden so gestaltet, dass sie unabhängig von anderen Tei- len des Systems durchgeführt werden können. Oftmals werden dafür die eben genannten Mock-Objekte oder Stubs verwendet, um Abhängigkeiten von an- deren Klassen oder Modulen zu simulieren. Es geht also darum, nur das Verhal- ten einer einzelnen Komponente zu testen. Automatisierung: Unit-Tests sind in der Regel automatisiert, das heißt, sie wer- den als Teil des Entwicklungsprozesses in eine kontinuierliche Integration (CI) Umgebung integriert. CI ist ein Verfahren, bei dem Änderungen am Programm- code regelmäßig in ein gemeinsames Repository eingespielt und automatisch getestet werden. Jedes Mal, wenn eine Entwicklerin Änderungen am Code vor- nimmt und diese in die Codebasis integriert, werden die Unit-Tests automatisch ausgeführt. So kann bei jeder Aktualisierung des Codes ausgeführt sicherge- stellt werden, dass die neuen Änderungen keine unerwarteten Fehler verursa- chen. Schnelle Ausführung: Unit Tests sind klein und schnell, was bedeutet, dass sie häufig und wiederholt ausgeführt werden können, ohne den Entwicklungspro- zess zu verlangsamen. Dokumentation: Sie dienen als eine Form der lebenden Dokumentation des Systems. Da sie zeigen, wie eine Einheit unter verschiedenen Bedingungen ver- wendet wird, helfen sie Entwicklern zu verstehen, wie bestimmte Teile des Codes verwendet werden sollen. Frühe Fehlererkennung: Durch die frühzeitige und regelmäßige Ausführung von Unit Tests können Probleme schnell erkannt und behoben werden, lange bevor die Software für Integrationstests oder Veröffentlichungen bereit ist. Selbstvalidierung: Unit Tests sind selbstvalidierend, was bedeutet, dass sie so konzipiert sind, dass sie automatisch überprüfen, ob der Code korrekt funktio- niert, ohne dass eine manuelle Bewertung erforderlich ist. Sie liefern ein ···················································································································· 103 Softwarequalität ······························································································ direktes Feedback, da jeder Testfall mit einem klaren Erwartungswert versehen ist und der Test entweder als „bestanden“ oder „nicht bestanden“ markiert wird. Rechtzeitig: Unit Tests sollten idealerweise vor oder während der Entwicklung der entsprechenden Codeabschnitte geschrieben werden, nicht erst danach. Dies folgt der Praxis des „Test-Driven Development (TDD)“, einer Methode, bei der zuerst Tests für eine neue Funktion geschrieben werden, bevor der eigent- liche Code implementiert wird (siehe Kapitel 6). 5.3.1.1 Werkzeug-Unterstützung Zur Unterstützung der Durchführung von Unit-Tests gibt es eine Vielzahl von Frame- works in den verschiedensten Programmiersprachen. Die genaue Anzahl ist schwer zu bestimmen, da ständig neue Frameworks entwickelt werden und auch die Popu- larität sich über die Zeit ändert. Beispielsweise für Python ist eines der bekanntesten Unit-Testing-Frameworks ‚unittest‘ 12, welches Teil der Standardbibliothek ist. Ein anderes beliebtes Frame- work ist ‚pytest‘, das sich durch eine einfache Syntax und die Fähigkeit, Tests mit weniger ‚Boilerplate-Code‘ zu schreiben, auszeichnet. Hier ist ein einfaches Beispiel für einen Unit-Test in Python mit dem unittest Frame- work: import unittest def add(x, y): return x + y class TestAddFunction(unittest.TestCase): def test_add_integers(self): self.assertEqual(add(1, 2), 3) def test_add_floats(self): self.assertAlmostEqual(add(1.1, 2.2), 3.3, places=1) def test_add_strings(self): self.assertEqual(add("hello ", "world"), "hello world") if __name__ == '__main__': unittest.main() In diesem Beispiel definieren wir eine „add-Funktion“, die zwei Werte addiert. Dann erstellen wir eine Testklasse „TestAddFunction“, die von „unittest.TestCase“ erbt. 12 https://docs.python.org/3/library/unittest.html ···················································································································· 104 Softwarequalität ······························································································ Innerhalb dieser Klasse definieren wir verschiedene Testmethoden, um die add- Funktion mit verschiedenen Datentypen zu testen. Zum Schluss rufen wir „unit- test.main()“ auf, was den Testrunner 13 startet, wenn das Skript direkt ausgeführt wird. 5.3.2 Integrationstests Integrationstests spielen eine wichtige Rolle im Softwareentwicklungsprozess, in- dem sie die verschiedenen Module oder Komponenten einer Anwendung zusam- menführen und als Gruppe testen. Sie setzen dort an, wo Unit Tests enden: Nach- dem einzelne Einheiten unabhängig voneinander überprüft wurden, prüfen Integ- rationstests die Interaktionen und das Zusammenspiel dieser Teile. Im Fokus stehen die Schnittstellen zwischen den Modulen, die Art und Weise, wie Daten fließen und verarbeitet werden, und wie die Systemkomponenten auf Fehler reagieren. Integrationstests nähern sich dem realen Anwendungsfall eines Endbenutzers, da sie nicht nur die Funktionsweise isolierter Funktionen, sondern auch deren Interak- tion innerhalb der gesamten Anwendung bewerten. Sie sind darauf ausgelegt, In- konsistenzen und Kommunikationsfehler zwischen integrierten Einheiten zu identi- fizieren, die während der Unit-Testphase möglicherweise nicht aufgefallen sind. Obwohl Integrationstests sowohl manuell als auch automatisiert durchgeführt wer- den können, neigt die moderne Softwareentwicklung dazu, sie zu automatisieren, um den Prozess zu beschleunigen und die Konsistenz der Ergebnisse zu verbessern. Um den Test durchzuführen, wird eine Testumgebung eingerichtet, die der Produk- tionsumgebung ähnelt, um realitätsnahe Bedingungen zu schaffen. Hierbei werden auch notwendige Abhängigkeiten wie Datenbanken oder externe Dienste konfigu- riert. In manchen Fällen werden Mocks oder Stubs verwendet, um die Funktionen dieser externen Systeme zu simulieren, insbesondere wenn der Zugang zu diesen Systemen schwierig ist oder sie noch nicht verfügbar sind. Sobald die Vorbereitung abgeschlossen ist, werden spezifische Testfälle ausgeführt, die auf die Interaktion zwischen den Komponenten abzielen. Diese Testfälle bein- halten typischerweise eine Vielzahl von Eingabeparametern und Konfigurationsein- stellungen, um verschiedene Szenarien und Zustände innerhalb der Anwendung zu 13 Der „Testrunner“ ist ein wesentlicher Bestandteil eines jeden Testframeworks, der das Ausführen von Tests steuert und überwacht. Es ist ein spezielles Programm oder Tool, das die Testsammlung durchgeht, jeden Test ausführt und Feedback über die Ergebnisse gibt. ···················································································································· 105 Softwarequalität ······························································································ simulieren. Ziel ist es, die typischen Aktionen nachzubilden, die ein Benutzer aus- führen würde, und zu sehen, wie die Systemkomponenten darauf reagieren. Die Überprüfung der Korrektheit der Testausführung basiert auf dem Vergleich der tatsächlichen Ergebnisse mit den im Vorfeld definierten erwarteten Ergebnissen. Unterschiede zwischen diesen Ergebnissen deuten auf Probleme in der Interaktion der getesteten Komponenten hin. Wenn ein Test nicht besteht, wird eine detail- lierte Fehleranalyse durchgeführt, um die Ursache zu ermitteln und zu beheben. Abschließend werden die Ergebnisse der Integrationstests in Berichten zusammen- gefasst, die Auskunft über die erfolgreich durchgeführten Tests und die identifizier- ten Problembereiche geben. Diese Informationen dienen als Grundlage für die an- schließende Fehlerbehebung und Optimierung des Systems. 5.3.2.1 Werkzeug-Unterstützung Auch für Integrationstests kann auf eine Vielzahl unterstützender Werkzeuge zu- rückgegriffen werden. Die bei den Unit-Tests erwähnten Tools ‚unittest‘ und ‚py- test‘ sind beispielsweise nicht nur für das Testen einzelner Komponenten nützlich, sondern können auch effektiv für Integrationstests eingesetzt werden. Beide Frameworks bieten eine reiche Auswahl an Funktionen, die es ermöglichen, kom- plexe Test-Szenarien zu konstruieren, die notwendig sind, um die Interaktionen zwi- schen verschiedenen Modulen oder Diensten einer Anwendung zu überprüfen. Für Integrationstests ermöglicht unittest das Gruppieren von Tests sowie das Ein- richten und Aufräumen von Testumgebungen vor und nach Testgruppen oder ein- zelnen Tests. Dies ist besonders nützlich, wenn die Tests externe Ressourcen wie Datenbanken oder Netzwerkdienste nutzen, die vor dem Start der Tests initialisiert und nach Abschluss wieder bereinigt werden müssen. Das Framework pytest zeichnet sich durch seine hohe Flexibilität bei der Durchfüh- rung von Integrationstests aus. Dies liegt unter anderem an den leistungsfähigen „Fixture-Funktionen“, die es anbietet. Mit Fixtures können Entwickler komplexe Te- stumgebungen vorbereiten, indem sie Testdaten und Zustände definieren und diese dann in mehreren Tests verwenden. Das erleichtert es ungemein, einmal ein- gerichtete Zustände für eine Reihe von Tests zu nutzen, was gerade bei komplexe- ren Testszenarien von großem Vorteil ist. Ein weiteres hilfreiches Feature von pytest sind die“ Marker“. Sie erlauben es, Test- fälle mit zusätzlichen Informationen zu kennzeichnen, wodurch selektiv bestimmte ···················································································································· 106 Softwarequalität ······························································································ Untergruppen von Tests ausgeführt werden können. Das ist besonders nützlich, wenn man nur eine spezifische Reihe von Integrationstests durchführen möchte, ohne den gesamten Testsatz laufen zu lassen. Diese Funktionalitäten machen py- test zu einem starken Werkzeug im Arsenal eines jeden Entwicklers, der robuste Integrationstests implementieren möchte. Beide Frameworks unterstützen die Ausführung von Tests in einer bestimmten Rei- henfolge, was für Integrationstests entscheidend sein kann, wenn bestimmte Tests auf den Ergebnissen oder Zuständen aufbauen, die von vorherigen Tests hinterlas- sen wurden. In der Praxis bedeutet die Verwendung von unittest oder pytest für Integrations- tests, dass Entwickler und Tester die gleichen Werkzeuge und Praktiken nutzen kön- nen, die sie bereits von Unit Tests kennen. Dies vereinfacht den Übergang von der Überprüfung einzelner Komponenten zur Überprüfung ihrer Integration und Inter- aktion innerhalb der gesamten Anwendung. 5.3.3 Systemtests Systemtests werden typischerweise nach den Unit- und Integrationstests durchge- führt und bilden oft den letzten Schritt vor den Abnahme- oder Nutzertests. Sie sind darauf ausgelegt, zu überprüfen, ob die Software als Ganzes funktioniert und ob sie bereit für die Veröffentlichung ist. Die komplette und integrierte Anwendung wird dabei gegen die ursprünglichen Anforderungen und Spezifikationen getestet und in einer Umgebung ausgeführt, die so nah wie möglich an der realen Einsatzumge- bung der Endbenutzerinnen liegt. Der Fokus liegt auf der Bewertung des Gesamt- systems, einschließlich der Funktionen, Leistung, Sicherheit und Benutzerfreund- lichkeit. Somit decken Systemtests eine Vielzahl von Aspekten ab, die möglicher- weise nicht in den früheren Tests abgedeckt wurden, wie beispielsweise: Überprüfung der vollständigen Funktionalität gemäß den Anforderungen Beurteilung der Systemleistung unter Lastbedingungen Sicherstellung der Kompatibilität mit verschiedenen Betriebssystemen, Brow- sern oder anderen Anwendungen Evaluation der Benutzererfahrung, um sicherzustellen, dass die Software intui- tiv und leicht zu bedienen ist ···················································································································· 107 Softwarequalität ······························································································ Testen von Sicherheitsaspekten wie Authentifizierung, Autorisierung, Ver- schlüsselung und Schutz vor Angriffen Systemtests simulieren echte Betriebsbedingungen und prüfen, wie gut die Soft- ware im Zusammenspiel mit anderen Systemkomponenten wie Datenbanken, Netzwerken und Hardware funktioniert. Da bei Systemtests die gesamte Applika- tion in den Blick genommen wird, können übergreifende Fehler und Probleme iden- tifiziert werden, die in den früheren Testphasen möglicherweise unentdeckt blie- ben. Solche Probleme können sich aus der Komplexität der Interaktionen zwischen verschiedenen Softwaremodulen und Systemressourcen ergeben. Für die Automa- tisierung von Systemtests gibt es eine Reihe spezialisierter Tools und Frameworks, die helfen, Testskripte zu erstellen und auszuführen. Diese Werkzeuge können eine grafische Benutzeroberfläche nachbilden, API-Aufrufe durchführen, Datenbankt- ransaktionen simulieren und viel mehr, um eine umfassende Prüfung der Anwen- dung zu ermöglichen. Durch die ganzheitliche Prüfung wird nicht nur die Funktio- nalität der Software bestätigt, sondern auch sichergestellt, dass sie den Anforde- rungen der Benutzer entspricht und bereit für den Einsatz in der realen Welt ist. 5.3.4 Abnahme- und Nutzertests Abnahme- und Nutzertests sind Testphasen, bei denen die fertiggestellte Software von der Zielgruppe – den Endnutzerinnen – evaluiert wird. Diese Tests sind ent- scheidend, da sie Feedback direkt von denjenigen einholen, die die Software im Alltag nutzen werden. Es geht darum zu überprüfen, ob das Produkt den Erwartun- gen entspricht, ob es benutzerfreundlich ist und ob es die im Lastenheft definierten Anforderungen erfüllt. Zu diesem Zweck, werden gerne Use Cases herangezogen, welche wir in Unit 1 bereits kennengelernt haben. Abnahmetests können – im Ge- gensatz zu den zuvor beschriebenen Verfahren der anderen Testebenen (siehe Ab- bildung 7 zum V-Modell) – nicht automatisiert werden. Wir stellen drei geläufige Arten von Abnahmetests vor: Beta-Tests sind eine Form von Nutzertests, bei denen eine Softwareversion, die funktional bereits komplett ist, aber vielleicht noch Fehler enthalten kann, ei- ner Gruppe von realen Benutzerinnen zur Verfügung gestellt wird. Diese Benut- zer nutzen das Produkt im echten Einsatz und melden zurück, welche Erfahrun- gen sie gemacht haben. Die Rückmeldungen aus den Beta-Tests werden ver- wendet, um vor der endgültigen Veröffentlichung letzte Fehler zu beheben und Verbesserungen vorzunehmen. ···················································································································· 108 Softwarequalität ······························································································ Usability-Tests konzentrieren sich darauf, wie einfach und intuitiv die Software von den Benutzern gehandhabt werden kann. Hierbei wird untersucht, wie Nutzer mit der Anwendung interagieren, um Design- oder Bedienprobleme zu identifizieren, die die Benutzererfahrung beeinträchtigen könnten. A/B-Tests sind eine Methode, bei der zwei Versionen einer Anwendung – A und B – verwendet werden, um zu sehen, welche Version bei den Benutzern besser ankommt. Jede Version wird einer unterschiedlichen Benutzergruppe präsen- tiert, und anhand verschiedener Metriken wie Verweildauer, Konversionsrate oder Benutzerzufriedenheit wird dann bewertet, welche Version die besseren Ergebnisse erzielt. Diese Nutzertests liefern wertvolle Einsichten darüber, wie die Software in der rea- len Welt angenommen wird und ob sie tatsächlich die Bedürfnisse und Erwartun- gen der Endnutzer erfüllt. Sie sind oft entscheidend für den Erfolg oder Misserfolg einer Software, da sie die Perspektive der tatsächlichen Benutzer widerspiegeln. 5.4 Kontrollfragen Welcher der folgenden Tests wird genutzt, um die Widerstandsfähigkeit einer Software gegen externe Fehler zu prüfen? Multiple-Choice-Fragen: A) Performance-Test Übung B) Usability-Test C) Robustheitstest D) Dokumentationstest Was wird mit einem dynamischen Softwaretest hauptsächlich überprüft? Multiple-Choice-Fragen: A) die statische Struktur des Codes B) die Softwarequalität ohne Codeausführung C) die Korrektheit der Dokumentation D) das tatsächliche Verhalten der Software während der Ausführung ···················································································································· 109 Softwarequalität ······························································································ Was ist der Hauptzweck von Testfällen in der Softwareentwicklung? Multiple-Choice-Fragen: A) Die Komplexität des Codes zu reduzieren. B) Eine risikobasierte Annäherung an das Testen zu vermeiden. C) Fehler und Probleme systematisch zu finden und zu beheben, bevor die Software den Endbenutzer erreicht. D) Die Gesamtleistung der Entwickler zu bewerten. Was ist der Fokus von Black-Box-Tests in der Softwareentwicklung? Multiple-Choice-Fragen: A) Die interne Struktur des Codes zu analysieren. B) Die Implementierungsdetails der Software zu überprüfen. C) Den Grad der Codeabdeckung zu messen. D) Das Ergebnis der Testdurchführung, unabhängig von den internen Mechanismen des Systems zu bewerten. Welcher der folgenden Punkte ist KEIN Kernaspekt von Unit-Tests in der Soft- wareentwicklung? Multiple-Choice-Fragen: A) Nutzung von Mock-Objekten oder Stubs zur Isolation der zu testenden Kompo- nente B) automatische Ausführung als Teil einer kontinuierlichen Integration (CI) Umge- bung C) manuelle Bewertung des Codes nach jedem Testdurchlauf D) schnelle und wiederholte Ausführung ohne Verlangsamung des Entwicklungs- prozesses ···················································································································· 110

Software Testing: Arten, Methoden und Ebenen - PDF

Document Details

Tags

Related

Summary

Full Transcript