Softwaretest
Softwaretest ist der Akt der Untersuchung der Artefakte und des Verhaltens der Software zu Validierung und Überprüfung getestet. Software -Tests können auch eine objektive und unabhängige Sichtweise der Software bieten, damit das Unternehmen die Risiken der Software -Implementierung schätzen und verstehen kann. Die Testtechniken umfassen, aber nicht unbedingt beschränkt auf:
- Analyse der Produktanforderungen für Vollständigkeit und Richtigkeit in verschiedenen Kontexten wie Branchenperspektive, geschäftlicher Perspektive, Machbarkeit und Lebensfähigkeit der Implementierung, Benutzerfreundlichkeit, Leistung, Sicherheit, Überlegungen zur Infrastruktur usw.
- Überprüfung der Produktarchitektur und des Gesamtdesigns des Produkts
- Arbeiten Sie mit Produktentwicklern an der Verbesserung der Codierungstechniken, der Entwurfsmuster, den Tests, die als Teil des Codes geschrieben werden können, basierend auf verschiedenen Techniken wie Randbedingungen usw.
- Ausführung eines Programms oder einer Anwendung mit der Absicht, das Verhalten zu prüfen
- Überprüfung der Bereitstellungsinfrastruktur und zugehörigen Skripte und Automatisierung
- Nehmen Sie an Produktionsaktivitäten teil, indem Sie Überwachungs- und Beobachtbarkeitstechniken verwenden
Software -Tests können objektive, unabhängige Informationen über die Qualität der Software und das Risiko seines Versagens für Benutzer oder Sponsoren liefern.[1]
Überblick
Obwohl Softwaretests die Richtigkeit der Software unter der Annahme einiger spezifischer Hypothesen bestimmen können (siehe die Hierarchie der Testschwierigkeit Im Folgenden können Tests nicht alle Fehler innerhalb der Software identifizieren.[2] Stattdessen liefert es a Kritik oder Vergleich das vergleicht den Zustand und das Verhalten des Produkts mit Orakel testen - Prinzipien oder Mechanismen, nach denen jemand ein Problem erkennt. Diese Orakel können (aber nicht auf) Spezifikationen umfassen. Verträge,[3] Vergleichbare Produkte, frühere Versionen desselben Produkts, Schlussfolgerungen über beabsichtigte oder erwartete Zwecke, Benutzer- oder Kundenerwartungen, relevante Standards, anwendbare Gesetze oder andere Kriterien.
Ein Hauptzweck des Tests besteht darin, Softwarefehler zu erkennen, damit Defekte entdeckt und korrigiert werden können. Das Testen kann nicht feststellen, dass ein Produkt unter allen Bedingungen ordnungsgemäß funktioniert, sondern nur, dass es unter bestimmten Bedingungen nicht ordnungsgemäß funktioniert.[4] Der Umfang der Softwaretests kann die Prüfung des Codes sowie die Ausführung dieses Codes in verschiedenen Umgebungen und Bedingungen sowie die Untersuchung der Aspekte des Codes umfassen: Tut er, was er tun soll, und tun, was er tun muss. In der aktuellen Kultur der Softwareentwicklung kann eine Testorganisation vom Entwicklungsteam getrennt sein. Es gibt verschiedene Rollen zum Testen von Teammitgliedern. Informationen, die aus Software -Tests abgeleitet wurden, können verwendet werden, um den Prozess zu korrigieren, durch den Software entwickelt wird.[5]: 41–43
Jedes Softwareprodukt hat eine Zielgruppe. Zum Beispiel unterscheidet sich das Publikum für Videospielsoftware völlig von der Banksoftware. Wenn eine Organisation entwickelt oder auf andere Weise in ein Softwareprodukt investiert, kann dies beurteilen, ob das Softwareprodukt für seine akzeptabel ist Endverbraucher, seine Zielgruppe, seine Käufer und andere Stakeholder. Software -Tests hilft bei dieser Bewertung.
Fehler und Fehler
Softwarefehler treten im folgenden Prozess auf: Ein Programmierer macht eine Error (Fehler), was zu a führt Fehler (Defekt, Fehler) in der Software Quellcode. Wenn dieser Fehler ausgeführt wird, führt das System in bestimmten Situationen zu falschen Ergebnissen und verursacht a Versagen.[6]: 31
Nicht alle Fehler führen notwendigerweise zu Fehlern. Zum Beispiel Fehler in der Dead Code wird niemals zu Fehlern führen. Ein Fehler, der keine Ausfälle ergab, kann zu einem Fehler führen, wenn die Umgebung geändert wird. Beispiele für diese Umgebungsänderungen sind die Software, die auf einem neuen ausgeführt wird Computerhardware Plattform, Änderungen in Quelldatenoder interagieren mit unterschiedlicher Software.[7] Ein einzelner Fehler kann zu einer Vielzahl von Versagensymptomen führen.
Nicht alle Softwarefehler werden durch Codierungsfehler verursacht. Eine häufige Quelle teurer Defekte sind Anforderungslücken, d. H. Nicht anerkannte Anforderungen, die zu Auslassung durch den Programmdesigner führen.[5]: 426 Anforderungen Lücken können oft sein Nicht-funktionale Anforderungen wie zum Beispiel Testbarkeit, Skalierbarkeit, Wartbarkeit, Leistung, und Sicherheit.
Eingabekombinationen und Voraussetzungen
Ein grundlegendes Problem bei Softwaretests ist das Testen unter alle Kombinationen von Inputs und Voraussetzungen (Anfangszustand) sind auch bei einem einfachen Produkt nicht machbar.[4]: 17–18[8] Dies bedeutet, dass die Anzahl der Anzahl von Fehler In einem Softwareprodukt kann sehr groß sein und Defekte, die selten auftreten, sind beim Testen und Debuggen schwer zu finden. Bedeutungsvoller, nicht funktionsfähig Dimensionen der Qualität (wie es soll sein gegen was soll es sollen tun) - Benutzerfreundlichkeit, Skalierbarkeit, Leistung, Kompatibilität, und Verlässlichkeit - kann sehr subjektiv sein; Etwas, das für eine Person einen ausreichenden Wert ausmacht, kann für eine andere unerträglich sein.
Softwareentwickler können nicht alles testen, können jedoch kombinatorische Testdesign verwenden, um die minimale Anzahl von Tests zu identifizieren, die erforderlich sind, um die gewünschte Abdeckung zu erhalten. Mit kombinatorischem Testdesign können Benutzer mit weniger Tests eine stärkere Testabdeckung erhalten. Unabhängig davon, ob sie nach Geschwindigkeit oder Testtiefe suchen, können sie kombinatorische Testdesignmethoden verwenden, um strukturierte Variationen in ihre Testfälle aufzubauen.[9]
Wirtschaft
Eine Studie von durchgeführt von NIST Im Jahr 2002 berichtet, dass Softwarefehler die US -Wirtschaft jährlich 59,5 Milliarden US -Dollar kosten. Mehr als ein Drittel dieser Kosten könnte vermieden werden, wenn bessere Softwaretests durchgeführt würden.[10][zweifelhaft ]
Auslagerung Software -Tests aufgrund von Kosten sind sehr häufig, wobei China, die Philippinen und Indien bevorzugte Ziele sind.[11]
Rollen
Softwaretests können von speziellen Softwaretestern durchgeführt werden. Bis in die 1980er Jahre wurde der Begriff "Softwaretester" im Allgemeinen verwendet, aber später wurde er auch als separater Beruf angesehen. In Bezug auf die Perioden und die unterschiedlichen Ziele beim Softwaretest,,[12] Es wurden verschiedene Rollen festgelegt, wie z. Testmanager, Messleitung, Testanalyst, Testdesigner, Tester, Automatisierungsentwickler, und Testadministrator. Software-Tests können auch von nicht dedizierten Software-Tester durchgeführt werden.[13]
Geschichte
Glenford J. Myers Zunächst führte die Trennung des Debuggens von Tests im Jahr 1979 ein.[14] Obwohl seine Aufmerksamkeit auf Breakage-Tests lag ("ein erfolgreicher Testfall ist einer, der einen noch unentdeckten Fehler erkennt."[14]: 16), es illustrierte den Wunsch der Software -Engineering -Community, grundlegende Entwicklungsaktivitäten wie Debugging von der der Überprüfung zu trennen.
Testansatz
Statische, dynamische und passive Tests
Es gibt viele Ansätze im Softwaretest. Bewertungen, Walkthroughs, oder Inspektionen werden als statische Tests bezeichnet, während der ausführende programmierte Code mit einem bestimmten Satz von ausgeführt wird Testfälle wird bezeichnet als Dynamische Tests.[15][16]
Statische Tests sind häufig implizit, wie das Korrekturlesen sowie bei Programmierwerkzeugen/Texteditoren, die die Quellcodestruktur oder Compiler (Pre-Compiler) überprüfen Statische Programmanalyse. Dynamische Tests findet statt, wenn das Programm selbst ausgeführt wird. Dynamische Tests können beginnen, bevor das Programm zu 100% abgeschlossen ist, um bestimmte Codeabschnitte zu testen, und werden auf diskrete angewendet Funktionen oder Module.[15][16] Typische Techniken dafür verwenden entweder Stubs/Treiber oder Ausführung von a Debugger Umgebung.[16]
Statische Prüfung beinhaltet Überprüfungwährend auch dynamische Tests beinhalten Validierung.[16]
Passive Tests bedeutet, das Systemverhalten ohne Interaktion mit dem Softwareprodukt zu überprüfen. Im Gegensatz zu aktiven Tests liefern Tester keine Testdaten, sondern betrachten Systemprotokolle und -spuren. Sie haben Muster und spezifisches Verhalten ab, um Entscheidungen zu treffen.[17] Dies hängt mit Offline zusammen Laufzeitüberprüfung und Protokollanalyse.
Erkundungsansatz
Versuchsforschung ist ein Ansatz für Softwaretests, der genau als gleichzeitiges Lernen beschrieben wird, Testdesignund Testausführung. Cem Kaner, der den Begriff 1984 geprägt hat,[18]: 2 Definiert Erkundungstests als "einen Stil von Softwaretests, der die persönliche Freiheit und Verantwortung des einzelnen Testers betont unterstützende Aktivitäten, die während des gesamten Projekts parallel laufen. "[18]: 36
Der "Box" -Ansatz
Softwaretestmethoden werden traditionell in Weiß- und Black-Box-Tests unterteilt. Diese beiden Ansätze werden verwendet, um den Standpunkt zu beschreiben, den der Tester beim Entwerfen von Testfällen einnimmt. Ein hybrider Ansatz, der als Grey-Box-Test genannt wird, kann auch auf die Softwaretestmethodik angewendet werden.[19][20] Mit dem Konzept der Grey-Box-Tests, die Tests aus spezifischen Designelementen entwickelt-, ist diese "willkürliche Unterscheidung" zwischen Schwarz- und Weißbox-Tests etwas verblasst.[21]
White-Box-Test

White-Box-Tests (auch als Clear-Box-Test, Glasbox-Tests, transparente Box-Tests und Strukturprüfung) überprüft die internen Strukturen oder die Funktionsweise eines Programms im Gegensatz zu der Funktionalität, die dem Endbenutzer ausgesetzt ist. Bei White-Box-Tests wird eine interne Perspektive des Systems (Quellcode) sowie Programmierfähigkeiten verwendet, um Testfälle zu entwerfen. Der Tester wählt Eingaben aus, um Pfade durch den Code auszuüben und die entsprechenden Ausgänge zu bestimmen.[19][20] Dies ist analog zum Testen von Knoten in einer Schaltung, z. B., In-Circuit-Tests (IKT).
Während White-Box-Tests auf dem angewendet werden können Einheit, Integration, und System Niveaus des Software -Testprozesses erfolgt normalerweise auf Einheitenebene.[21] Es kann Pfade innerhalb einer Einheit, Pfade zwischen Einheiten während der Integration und zwischen Subsystemen während eines System -Level -Tests testen. Obwohl diese Methode des Testdesigns viele Fehler oder Probleme aufdecken kann, kann es nicht unimplementierte Teile der Spezifikation oder fehlende Anforderungen erkennen.
Zu den bei White-Box-Tests verwendeten Techniken gehören:[20][22]
- API -Tests - Testen der Bewerbung mit öffentlichem und privatem Antrag Apis (Anwendungsprogrammierschnittstellen)
- Codeabdeckung - Erstellen von Tests, um einige Kriterien für die Codeabdeckung zu erfüllen (z. B. kann der Testdesigner Tests erstellen, um alle Aussagen im Programm mindestens einmal auszuführen).
- Fehlerinjektion Methoden - Absichtlich Fehler einführen, um die Wirksamkeit von Teststrategien zu beurteilen
- Mutationstests Methoden
- Statische Prüfung Methoden
Tools zur Codeabdeckung können die Vollständigkeit einer Testsuite bewerten, die mit jeder Methode erstellt wurde, einschließlich Black-Box-Tests. Dies ermöglicht es dem Software -Team, Teile eines Systems zu untersuchen, die selten getestet werden, und stellt sicher, dass das wichtigste Funktionspunkte wurden getestet.[23] Codeabdeckung als Software -Metrik kann als Prozentsatz angegeben werden für:[19][23][24]
- Funktionsabdeckung, welche Berichte über ausgeführte Funktionen
- Erklärung der Berichterstattung, welche Berichte über die Anzahl der ausgeführten Zeilen, um den Test abzuschließen
- Entscheidungsberichterstattung, welche berichtet, ob sowohl der wahre als auch der falsche Zweig eines bestimmten Tests durchgeführt wurden
Die 100% ige Erklärung der Erklärung stellt sicher, dass alle Codepfade oder -zweige (in Bezug auf Steuerfluss) werden mindestens einmal ausgeführt. Dies ist hilfreich, um die korrekte Funktionalität sicherzustellen, aber nicht ausreichend, da derselbe Code unterschiedliche Eingaben korrekt oder falsch verarbeitet.[25] Pseudo-getestete Funktionen und Methoden sind diejenigen, die abgedeckt, aber nicht angegeben sind (es ist möglich, ihren Körper zu entfernen, ohne einen Testfall zu brechen).[26]
Black-Box-Tests

Black-Box-Tests (auch als Funktionstest bezeichnet) behandelt die Software als "Black Box", die die Funktionalität ohne Kenntnis der internen Implementierung untersucht, ohne den Quellcode anzusehen. Die Tester sind sich nur bewusst, was die Software tun soll, nicht wie sie es tut.[27] Zu den Black-Box-Testmethoden gehören: Äquivalenzpartitionierung, Grenzwertanalyse, All-Pair-Test, Zustandsübergangstabellen, Entscheidungstabelle testen, Fuzz -Test, Modellbasierte Tests, Anwendungsfall testen, Versuchsforschungund spezifikationsbasierte Tests.[19][20][24]
Spezifikationsbasierte Tests zielen darauf ab, die Funktionalität der Software gemäß den anwendbaren Anforderungen zu testen.[28] Diese Teststufe erfordert normalerweise gründlich Testfälle Um dem Tester zur Verfügung gestellt zu werden, der dann einfach überprüften kann, dass für einen bestimmten Eingang der Ausgangswert (oder das Verhalten) entweder "oder" nicht "der gleiche wie der im Testfall angegebene erwartete Wert ist. Die Testfälle basieren auf Spezifikationen und Anforderungen, d. H. Wie die Anwendung tun soll. Es verwendet externe Beschreibungen der Software, einschließlich Spezifikationen, Anforderungen und Designs, um Testfälle abzuleiten. Diese Tests können sein funktional oder nicht funktionsfähig, obwohl normalerweise funktional.
Spezifikationsbasierte Tests können erforderlich sein, um die korrekte Funktionalität zu gewährleisten. Es reicht jedoch nicht aus, um sich vor komplexen oder hohen Risikosituationen zu schützen.[29]
Ein Vorteil der Black Box -Technik ist, dass kein Programmierkenntnis erforderlich ist. Unabhängig von den Programmierern hat der Tester wahrscheinlich einen anderen Satz und kann unterschiedliche Bereiche der Funktionalität hervorheben. Andererseits wurde gesagt, dass Black-Box-Tests "wie ein Spaziergang in einem dunklen Labyrinth ohne Taschenlampe sein".[30] Da sie den Quellcode nicht untersuchen, gibt es Situationen, in denen ein Tester viele Testfälle schreibt, um etwas zu überprüfen, das nur durch einen Testfall getestet werden könnte oder einige Teile des Programms nicht getestet werden.
Diese Testmethode kann auf alle Ebenen des Softwaretests angewendet werden: Einheit, Integration, System und Annahme.[21] Es umfasst in der Regel die meisten, wenn nicht alle Tests auf höheren Ebenen, können aber auch die Einheitentests dominieren.
Komponenten -Schnittstellen -Tests
Komponenten -Schnittstellen -Tests sind eine Variation von Black-Box-Testsmit dem Fokus auf die Datenwerte über nur die damit verbundenen Aktionen einer Subsystemkomponente hinaus.[31] Die Praxis der Testen der Komponentenschnittstelle kann verwendet werden, um die Handhabung von Daten zu überprüfen, die zwischen verschiedenen Einheiten oder Subsystemkomponenten über die vollständigen Integrationstests zwischen diesen Einheiten hinausgehen.[32][33] Die übergebenen Daten können als "Nachrichtenpakete" angesehen werden, und die Bereiche oder Datentypen können für Daten überprüft werden, die aus einer Einheit generiert und auf eine Gültigkeit getestet werden, bevor sie in eine andere Einheit übergeben werden. Eine Option für Schnittstellentests ist die Übergabe einer separaten Protokolldatei mit Datenelementen, häufig mit einem Zeitstempel, um eine Analyse von Tausenden von Daten von Daten zu ermöglichen, die für Tage oder Wochen zwischen den Einheiten übergeben wurden. Die Tests können die Überprüfung der Behandlung einiger extremer Datenwerte umfassen, während andere Schnittstellenvariablen als Normalwerte übergeben werden.[32] Ungewöhnliche Datenwerte in einer Schnittstelle können dazu beitragen, die unerwartete Leistung in der nächsten Einheit zu erklären.
Visuelle Tests
Ziel des visuellen Tests ist es, den Entwicklern die Möglichkeit zu geben, zu untersuchen, was am Zeitpunkt des Softwareversagens geschah, indem die Daten so vorgestellt werden, dass der Entwickler leicht die Informationen finden kann, die sie benötigt, und die Informationen werden deutlich ausgedrückt .[34][35]
Im Kern des visuellen Tests steht die Idee, dass das Zeigen von jemandem ein Problem (oder einen Testfehler) zeigt, anstatt es nur zu beschreiben, die Klarheit und das Verständnis erheblich erhöht. Visuelle Tests erfordert daher die Aufzeichnung des gesamten Testprozesses und erfassen alles, was im Testsystem im Videoformat auftritt. Ausgabevideos werden durch Echtzeit-Testereingabe über Bild-in-a-Bild-Webcam und Audiokommentar aus Mikrofonen ergänzt.
Visuelle Tests bieten eine Reihe von Vorteilen. Die Qualität der Kommunikation wird drastisch erhöht, da Tester das Problem (und die Ereignisse, die dazu führen) dem Entwickler zeigen können, anstatt es nur zu beschreiben, und die Notwendigkeit, Testfehler zu replizieren, wird in vielen Fällen nicht mehr existieren. Der Entwickler hat alle Beweise, die sie oder er oder er benötigt, um einen Testfehler zu erhalten, und kann sich stattdessen auf die Ursache des Fehlers konzentrieren und wie er repariert werden sollte.
Ad -hoc -Tests und Versuchsforschung sind wichtige Methoden zur Überprüfung der Software -Integrität, da sie weniger Vorbereitungszeit für die Implementierung erfordern, während die wichtigen Fehler schnell gefunden werden können.[36] Bei Ad -hoc -Tests, bei denen die Tests improvisierten, spontanen Weise stattfinden, kann die Fähigkeit der Tester, dokumentierte Methoden auszubilden, und anschließend die Variationen dieser Tests zu einer strengeren Untersuchung von Defektfixes führen.[36] Sofern jedoch keine strenge Dokumentation der Verfahren beibehalten werden, ist eine der Grenzen der Ad -hoc -Tests nicht die Wiederholbarkeit.[36]
Grey-Box-Test
Grey-Box-Test (American Rechtschreibung: Gray-Box-Test) beinhaltet Kenntnisse über interne Datenstrukturen und Algorithmen zum Zwecke des Entwerfens von Tests bei der Ausführung dieser Tests auf dem Benutzer oder der Schwarzbox-Ebene. Der Tester hat häufig Zugriff auf "den Quellcode als auch den ausführbaren Binärdatum".[37] Grey-Box-Tests können auch enthalten Reverse Engineering (Verwenden der dynamischen Codeanalyse), um beispielsweise Grenzwerte oder Fehlermeldungen zu bestimmen.[37] Manipulieren Eingabedaten und Formatierungsausgabe qualifizieren sich nicht als Grey-Box, da die Eingabe und Ausgabe eindeutig außerhalb des "Black Box" liegen, das wir das untersuchende System aufrufen. Diese Unterscheidung ist besonders wichtig bei der Durchführung Integrationstests Zwischen zwei von zwei verschiedenen Entwicklern geschriebenen Codemodulen, wobei nur die Schnittstellen für den Test freigelegt werden.
Durch die Kenntnis der zugrunde liegenden Konzepte, wie die Software funktioniert, trifft der Tester besser informierte Testentscheidungen, während die Software von außen getestet wird. In der Regel dürfte ein Grey-Box-Tester eine isolierte Testumgebung mit Aktivitäten wie dem Aussaat a einrichten Datenbank. Der Tester kann den Zustand des Produkts beobachten, das nach Ausführung bestimmter Aktionen wie der Ausführung getestet wird Sql Aussagen gegen die Datenbank und dann die Ausführung von Abfragen, um sicherzustellen, dass die erwarteten Änderungen reflektiert wurden. Grey-Box-Test implementiert intelligente Testszenarien, die auf begrenzten Informationen basieren. Dies gilt insbesondere für die Handhabung des Datentyps. Ausnahmebehandlung, usw.[38]
Teststufen
Im Großen und Ganzen gibt es mindestens drei Teststufen: Unit -Tests, Integrationstests und Systemtests.[39][40][41][42] Eine vierte Ebene, Akzeptanztests, kann jedoch von Entwicklern einbezogen werden. Dies kann in Form von operativen Akzeptanztests oder Einfacher-Endbenutzer-Tests (Beta) sein, und Tests, um sicherzustellen, dass die Software die funktionalen Erwartungen erfüllt.[43][44][45] Basierend auf dem Lehrplan der ISTQB Certified Test Foundation Level umfasst die Teststufen diese vier Ebenen, und die vierte Ebene wird als Akzeptanzprüfung bezeichnet.[46] Tests werden häufig in eine dieser Ebenen eingeteilt, indem sie im Softwareentwicklungsprozess oder durch die Spezifität des Tests hinzugefügt werden.
Unit -Tests
Unit -Tests beziehen sich auf Tests, die die Funktionalität eines bestimmten Codeabschnitts normalerweise auf Funktionsebene überprüfen. In einer objektorientierten Umgebung befindet sich dies normalerweise auf Klassenebene, und zu den minimalen Einheiten-Tests gehören die Konstrukteure und Zerstörer.[47]
Diese Arten von Tests werden normalerweise von Entwicklern geschrieben, wenn sie am Code (White-Box-Stil) arbeiten, um sicherzustellen, dass die spezifische Funktion wie erwartet funktioniert. Eine Funktion kann mehrere Tests haben, um zu fangen Eckfälle oder andere Zweige im Code. Unit -Tests allein können die Funktionalität einer Software nicht überprüfen, sondern wird verwendet, um sicherzustellen, dass die Bausteine der Software unabhängig voneinander funktionieren.
Unit -Tests sind ein Softwareentwicklungsprozess, bei dem ein breites Spektrum der Defekt- und Erkennungsstrategien synchronisiert wird, um die Softwareentwicklungsrisiken, die Zeit und die Kosten zu verringern. Es wird vom Softwareentwickler oder Ingenieur während der Konstruktionsphase des Lebenszyklus für Softwareentwicklungen durchgeführt. Unit -Tests zielen darauf ab, Konstruktionsfehler zu beseitigen, bevor der Code zu zusätzlichen Tests gefördert wird. Diese Strategie soll die Qualität der resultierenden Software sowie die Effizienz des Gesamtentwicklungsprozesses erhöhen.
Abhängig von den Erwartungen der Organisation an die Softwareentwicklung können Unit -Tests enthalten sein Statische Codeanalyse, Datenflussanalyse, Metrikenanalyse, Peer -Code -Bewertungen, Codeabdeckung Analyse und andere Software -Testpraktiken.
Integrationstests
Integrationstests sind jede Art von Softwaretests, mit denen die Schnittstellen zwischen Komponenten mit einem Softwaredesign überprüfen sollen. Softwarekomponenten können auf iterative oder alle zusammen integriert werden ("Urknall"). Normalerweise wird ersterer als bessere Praxis angesehen, da die Schnittstellenprobleme schneller und repariert werden können.
Integrationstests erstellen Defekte in den Schnittstellen und die Wechselwirkung zwischen integrierten Komponenten (Modulen). Progressiv größere Gruppen getesteter Softwarekomponenten, die Elementen des architektonischen Designs entsprechen, werden integriert und getestet, bis die Software als System arbeitet.[48]
Integrationstests beinhalten normalerweise viel Code und erzeugen Spuren, die größer sind als die durch Unit -Tests hergestellten. Dies wirkt sich auf die einfache Lokalisierung des Fehlers aus, wenn ein Integrationstest fehlschlägt. Um dieses Problem zu überwinden, wurde vorgeschlagen, die großen Tests in kleineren Teilen automatisch zu schneiden, um die Fehlerlokalisierung zu verbessern.[49]
Systemtests
Systemtests testet ein vollständig integriertes System, um zu überprüfen, ob das System seine Anforderungen entspricht.[6]: 74 Beispielsweise kann ein Systemtest das Testen einer Anmeldeschnittstelle, das Erstellen und Bearbeiten eines Eintrags sowie das Senden oder Drucken von Ergebnissen, gefolgt von einer zusammenfassenden Verarbeitung oder Löschung (oder Archivierung) von Einträgen und Anmeldung umfassen.
Akzeptanzprüfung
Akzeptanztests umfassen häufig die folgenden vier Typen:[46]
- Benutzerakzeptanzprüfung (UAT)
- Operationale Akzeptanzprüfung (Hafer)
- Vertragliche und regulatorische Akzeptanztests
- Alpha- und Beta -Tests
UAT sowie Alpha- und Beta -Tests werden im nächsten beschrieben Testtypen Sektion.
Die operative Akzeptanz wird zur Durchführung einer Betriebsbereitschaft (Vorveröffentlichung) eines Produkts, eines Dienstes oder eines Systems als Teil von a verwendet Qualitätsmanagementsystem. Oat ist eine häufige Art von nicht funktionierenden Softwaretests, die hauptsächlich in verwendet wird Software-Entwicklung und Software-Wartung Projekte. Diese Art von Tests konzentriert sich auf die operative Bereitschaft des Systems, das unterstützt werden soll oder um Teil der Produktionsumgebung zu werden. Daher ist es auch als operative Bereitschaftstest (ORT) oder bekannt Operationsbereitschaft und Gewissheit (Oder & a) Tests. Funktionsprüfung Innerhalb von Hafer ist auf die Tests beschränkt, die zur Überprüfung der Verifizierung erforderlich sind nicht funktionsfähig Aspekte des Systems.
Darüber hinaus sollte die Softwaretests sicherstellen, dass die Portabilität des Systems sowie die Arbeit wie erwartet auch seine Betriebsumgebung nicht auch beschädigt oder teilweise verfälscht oder andere Prozesse innerhalb dieser Umgebung nicht funktionsfähig werden.[50]
Auf der Grundlage der während der Vertragsvereinbarung definierten Akzeptanzkriterien des Vertrags werden vertragliche Akzeptanzprüfungen durchgeführt, während auf der Grundlage der relevanten Vorschriften für das Softwareprodukt regulatorische Annahmeprüfungen durchgeführt werden. Diese beiden Tests können von Benutzern oder unabhängigen Tester durchgeführt werden. Regulierungsakzeptanztests umfassen manchmal die Aufsichtsbehörden, die die Testergebnisse prüfen.[46]
Testtypen, Techniken und Taktiken
Unterschiedliche Beschriftungen und Arten für die Gruppierung von Tests können Testen von Testen sein. Softwaretesttaktik oder Techniken.[51]

Installationstest
Die meisten Softwaresysteme haben Installationsverfahren, die benötigt werden, bevor sie für ihren Hauptzweck verwendet werden können. Das Testen dieser Verfahren zur Erreichung eines installierten Softwaresystems, das verwendet werden kann, wird als Installationstest bezeichnet.
Kompatibilitätstests
Eine häufige Ursache für Softwareversagen (real oder wahrgenommen) ist ein Mangel an seiner Kompatibilität mit anderen Anwendungssoftware, Betriebssysteme (oder Betriebssystem Versionen, alt oder neu) oder Zielumgebungen, die sich stark vom Original unterscheiden (wie z. Terminal oder GUI Anwendung, die auf dem ausgeführt werden sollen Desktop jetzt erforderlich, um ein zu werden Internetanwendung, was in a rendern muss Webbrowser). Zum Beispiel im Fall eines Mangels an RückwärtskompatibilitätDies kann auftreten, da die Programmierer Software nur in der neuesten Version der Zielumgebung entwickeln und testen, die möglicherweise nicht alle Benutzer ausführen. Dies führt zu der unbeabsichtigten Folge, dass die neueste Arbeit möglicherweise nicht in früheren Versionen der Zielumgebung oder auf älteren Hardware funktioniert, die frühere Versionen der Zielumgebung verwenden konnten. Manchmal können solche Probleme proaktiv behoben werden Zusammenfassung Betriebssystemfunktionalität in ein separates Programm Modul oder Bibliothek.
Rauch- und Vernunftstests
Vernunftstests Bestimmt, ob es vernünftig ist, mit weiteren Tests fortzufahren.
Rauchprüfung besteht aus minimalen Versuchen, die Software zu betreiben, um festzustellen, ob grundlegende Probleme vorliegen, die verhindern, dass sie überhaupt funktioniert. Solche Tests können als verwendet werden Verifizierungstest erstellen.
Regressionstests
Regressionstests konzentrieren sich auf das Auffinden von Defekten, nachdem eine große Codeänderung aufgetreten ist. Insbesondere versucht es aufzudecken Software -Regressionen, als degradierte oder verlorene Funktionen, einschließlich alter Fehler, die zurückgekommen sind. Solche Regressionen treten immer dann auf, wenn Softwarefunktionen, die zuvor korrekt funktionierte, nicht mehr wie beabsichtigt funktionieren. Typischerweise treten Regressionen als ein unbeabsichtigte Folge von Programmänderungen, wenn der neu entwickelte Teil der Software mit dem zuvor vorhandenen Code kollidiert. Regressionstests sind in der Regel der größte Testaufwand für die Entwicklung kommerzieller Software.[52] Aufgrund der Überprüfung zahlreicher Details in früheren Softwarefunktionen und sogar neue Software können einige alte Testfälle verwendet werden, um Teile des neuen Designs zu testen, um sicherzustellen, dass frühere Funktionen weiterhin unterstützt werden.
Zu den gemeinsamen Methoden der Regressionstests gehören das erneute Ablauf früherer Sätze von Testfällen und die Überprüfung, ob zuvor feste Fehler erneut aufgegriffen wurden. Die Testtiefe hängt von der Phase des Freisetzungsprozesses und der ab Risiko der zusätzlichen Funktionen. Sie können entweder abgeschlossen sein, für Änderungen, die spät in der Freisetzung hinzugefügt oder als riskant angesehen werden oder sehr flach sind, bestehend aus positiven Tests für jedes Merkmal, wenn die Änderungen frühzeitig in der Freisetzung oder als mit geringer Risiko eingestuft werden. Bei Regressionstests ist es wichtig, starke Behauptungen über das bestehende Verhalten zu haben. Hierzu ist es möglich, in vorhandenen Testfällen neue Behauptungen zu generieren und hinzuzufügen.[53] Dies wird als automatische Testverstärkung bezeichnet.[54]
Akzeptanzprüfung
Akzeptanztests können eines von zwei Dingen bedeuten:
- A Rauchtest wird vor weiteren Tests als Build -Akzeptanztest verwendet, z. B. zuvor Integration oder Regression.
- Akzeptanztests vom Kunden, häufig in seiner Laborumgebung auf seiner eigenen Hardware, ist bekannt als User Acceptance Testing (UAT). Akzeptanztests können im Rahmen des Übergabeprozesses zwischen zwei beliebigen Entwicklungsphasen durchgeführt werden.
Alpha -Test
Alpha -Tests werden simuliert oder tatsächliche Betriebstests von potenziellen Benutzern/Kunden oder einem unabhängigen Testteam auf der Website der Entwickler. Alpha-Tests werden häufig für off-the-Shelf-Software als Form von internen Akzeptanztests verwendet, bevor die Software zu Beta-Tests geht.[55]
Beta-test
Beta -Tests findet nach Alpha -Tests statt und kann als externe Form angesehen werden User Acceptance Testing. Versionen der Software, bekannt als Beta -Versionen, werden einem begrenzten Publikum außerhalb des Programmierteams, das als Beta -Tester bekannt ist, freigegeben. Die Software wird an Personengruppen freigegeben, damit weitere Tests sicherstellen können, dass das Produkt nur wenige Fehler hat oder Käfer. Beta -Versionen können der offenen Öffentlichkeit zur Verfügung gestellt werden, um die zu erhöhen Rückmeldung Feld zu einer maximalen Anzahl zukünftiger Benutzer und zu einem früheren Wert für einen erweiterten oder sogar unbestimmten Zeitraum (Zeitraum (Perpetual Beta).[56]
Funktionelle vs nicht funktionale Tests
Funktionsprüfung Bezieht sich auf Aktivitäten, die eine bestimmte Aktion oder Funktion des Codes überprüfen. Diese finden sich normalerweise in der Dokumentation der Codeanforderungen, obwohl einige Entwicklungsmethoden aus Anwendungsfällen oder Benutzergeschichten funktionieren. Funktionstests beantworten die Frage "Kann der Benutzer dies tun" oder "Funktioniert diese bestimmte Funktion."
Nicht funktionsfähige Tests bezieht sich auf Aspekte der Software, die möglicherweise nicht mit einer bestimmten Funktion oder Benutzeraktion zusammenhängen, wie z. Skalierbarkeit oder andere Leistung, Verhalten unter sicher Einschränkungen, oder Sicherheit. Das Testen bestimmt den Bruchpunkt, den Punkt, an dem Extreme der Skalierbarkeit oder Leistung zu einer instabilen Ausführung führen. Nicht funktionsfähige Anforderungen sind tendenziell solche, die die Qualität des Produkts widerspiegeln, insbesondere im Kontext der Eignungspiegel seiner Benutzer.
Kontinuierliche Tests
Kontinuierliche Tests sind der Ausführungsvorgang automatisierte Tests Im Rahmen der Software -Bereitstellungspipeline, um ein sofortiges Feedback zu den mit einem Software -Release -Kandidaten verbundenen Geschäftsrisiken zu erhalten.[57][58] Kontinuierliche Tests umfassen die Validierung beider funktionale Anforderungen und Nicht-funktionale Anforderungen; Der Testumfang erstreckt sich von der Validierung von Bottom-up-Anforderungen oder Benutzergeschichten bis hin zur Bewertung der Systemanforderungen, die mit übergreifenden Geschäftszielen verbunden sind.[59][60]
Destruktives Testen
Destruktive Tests Versuche, die Software oder ein Subsystem zu scheitern. Es wird überprüft, dass die Software auch dann ordnungsgemäß funktioniert, wenn sie ungültige oder unerwartete Eingaben empfängt, wodurch die Festlegung der Robustheit von Eingabevalidierung und Fehlermanagementroutinen. Software -Fehlerinjektion, in Form von Fuzzing, ist ein Beispiel für Fehlerprüfung. Verschiedene kommerzielle nicht funktionierende Testwerkzeuge sind aus dem verknüpft Software -Fehlerinjektion Seite; Es stehen auch zahlreiche Open-Source- und kostenlose Softwaretools zur Verfügung, die zerstörerische Tests durchführen.
Software -Leistungstests
Leistungstests werden im Allgemeinen ausgeführt, um festzustellen, wie ein System oder ein Subsystem in Bezug auf Reaktionsfähigkeit und Stabilität unter einer bestimmten Arbeitsbelastung funktioniert. Es kann auch dazu dienen, andere Qualitätsattribute des Systems zu untersuchen, zu messen, zu validieren oder zu überprüfen, z. B. Skalierbarkeit, Zuverlässigkeit und Ressourcenverbrauch.
Lastprüfung befasst sich in erster Linie mit der Prüfung, dass das System weiter unter einer bestimmten Belastung arbeiten kann, unabhängig davon Benutzer. Dies wird im Allgemeinen als Software bezeichnet Skalierbarkeit. Die verwandte Lasttestaktivität von bei der durchgeführten nicht funktionalen Aktivität wird häufig als bezeichnet als Ausdauerprüfung. Volumentests ist eine Möglichkeit, Softwarefunktionen zu testen, selbst wenn bestimmte Komponenten (z. B. eine Datei oder Datenbank) radikal angrisen. Belastbarkeitstest ist eine Möglichkeit, die Zuverlässigkeit unter unerwarteten oder seltenen Arbeitsbelastungen zu testen. Stabilitätstests (häufig als Last- oder Ausdauertests bezeichnet) Überprüft, ob die Software in oder über einem akzeptablen Zeitraum kontinuierlich gut funktionieren kann.
Es besteht kaum zu, was die spezifischen Ziele der Leistungstests sind. Die Begriffe Lasttests, Leistungstests, Skalierbarkeitstestund Volumentests werden häufig austauschbar verwendet.
Echtzeit-Software Systeme haben strenge Zeiteinschränkungen. Zu testen, ob Timing -Einschränkungen erfüllt sind, Echtzeit-Tests wird genutzt.
Usability-Tests
Usability-Tests ist zu prüfen, ob die Benutzeroberfläche einfach zu bedienen und zu verstehen ist. Es geht hauptsächlich um die Verwendung der Anwendung. Dies ist keine Art von Tests, die automatisiert werden kann. Tatsächliche menschliche Benutzer werden benötigt und werden von Fachkräften überwacht UI -Designer.
Zugänglichkeitstest
Barrierefreiheit Das Testen kann die Einhaltung von Standards wie:
- Amerikaner mit Behinderungengesetz von 1990
- Abschnitt 508 Änderung des Rehabilitationsgesetzes von 1973
- Initiative für Web -Accessibility (Wai) der World Wide Web Konsortium (W3C)
Sicherheitstests
Sicherheitstests ist wichtig für Software, die vertrauliche Daten verarbeitet, um sie zu verhindern Systemeindrückung durch Hacker.
Die internationale Organisation für Standardisierung (ISO) definiert dies als "Art der Tests, die durchgeführt wird, um den Grad zu bewerten, in dem ein Testelement und die zugehörigen Daten und Informationen geschützt sind, damit nicht autorisierte Personen oder Systeme sie nicht verwenden, lesen oder ändern können und können Autorisierte Personen oder Systeme werden keinen Zugang zu ihnen verweigert. "[61]
Internationalisierung und Lokalisierung
Testen für Internationalisierung und Lokalisierung bestätigt, dass die Software mit verschiedenen Sprachen und geografischen Regionen verwendet werden kann. Der Prozess von Pseudolokalisierung wird verwendet, um die Fähigkeit einer Anwendung zu testen, in eine andere Sprache übersetzt zu werden, und erleichtert es, zu identifizieren, wann der Lokalisierungsprozess neue Fehler in das Produkt einführen kann.
Die Globalisierungstests überprüft, ob die Software für eine neue Kultur angepasst ist (z. B. verschiedene Währungen oder Zeitzonen).[62]
Die tatsächliche Übersetzung in menschliche Sprachen muss ebenfalls getestet werden. Mögliche Lokalisierungs- und Globalisierungsfehler umfassen:
- Software wird häufig durch Übersetzen einer Liste von lokalisiert Saiten Aus dem Kontext kann der Übersetzer die falsche Übersetzung für eine mehrdeutige Quellzeichenfolge auswählen.
- Die technische Terminologie kann inkonsistent werden, wenn das Projekt von mehreren Personen ohne ordnungsgemäße Koordination übersetzt wird oder wenn der Übersetzer unklug ist.
- Wörtliche Wort für Wortübersetzungen können in der Zielsprache unangemessen, künstlich oder zu technisch klingen.
- Unbeschichtete Nachrichten in der Originalsprache können übrig bleiben hart codiert im Quellcode.
- Einige Nachrichten können automatisch erstellt werden Laufzeit und die resultierende Zeichenfolge kann ungrammatisch, funktionell falsch, irreführend oder verwirrend sein.
- Software kann a verwenden Tastaturkürzel Das hat keine Funktion auf der Quellsprache der Quellsprache Tastaturbelegung, wird aber zum Tippen von Zeichen im Layout der Zielsprache verwendet.
- Die Software kann die Unterstützung für die möglicherweise fehlen Zeichenkodierung der Zielsprache.
- Schriftarten und Schriftgrößen, die in der Quellsprache angemessen sind, können in der Zielsprache unangemessen sein. zum Beispiel, CJK -Charaktere kann unlesbar werden, wenn die Schriftart zu klein ist.
- Eine Zeichenfolge in der Zielsprache kann länger sein, als die Software verarbeiten kann. Dies kann die Zeichenfolge für den Benutzer teilweise unsichtbar machen oder die Software zum Absturz oder die Fehlfunktion bringen.
- In der Software kann das Lesen oder Schreiben nicht ordnungsgemäß unterstützt werden bidirektionaler Text.
- Software kann Bilder mit nicht lokalisierten Text anzeigen.
- Lokalisierte Betriebssysteme können unterschiedlich benanntes System haben Konfigurationsdateien und Umgebungsvariablen und anders Formate für das Datum und Währung.
Entwicklungstest
Entwicklungstests ist ein Softwareentwicklungsprozess, bei dem ein breites Spektrum der Defekt- und Erkennungsstrategien synchronisiert wird, um die Softwareentwicklungsrisiken, die Zeit und die Kosten zu verringern. Es wird vom Softwareentwickler oder Ingenieur während der Bauphase des Softwareentwicklungslebenszyklus durchgeführt. Entwicklungstests zielen darauf ab, Konstruktionsfehler zu beseitigen, bevor Code zu anderen Tests gefördert wird. Diese Strategie soll die Qualität der resultierenden Software sowie die Effizienz des Gesamtentwicklungsprozesses erhöhen.
Abhängig von den Erwartungen der Organisation an die Softwareentwicklung können Entwicklungstests umfassen Statische Codeanalyse, Datenflussanalyse, Metrikanalyse, Peer -Code -Überprüfungen, Unit -Tests, Codeabdeckungsanalyse, Rückverfolgbarkeitund andere Software -Testpraktiken.
A/B -Test
A/B -Tests sind eine Methode zum Ausführen eines kontrollierten Experiments, um festzustellen, ob eine vorgeschlagene Änderung effektiver ist als der aktuelle Ansatz. Kunden werden entweder in eine aktuelle Version (Steuerung) einer Funktion oder an eine modifizierte Version (Behandlung) geleitet, und es werden Daten gesammelt, um festzustellen, welche Version das gewünschte Ergebnis besser erzielt.
Gleichzeitige Tests
Gleichzeitige oder Parallelitätstests bewertet das Verhalten und die Leistung von Software und Systemen, die verwendet werden Gleichzeitiges Computer, im Allgemeinen unter normalen Nutzungsbedingungen. Typische Probleme, die diese Art von Tests entlarvt, sind Deadlocke, Rennbedingungen und Probleme mit dem gemeinsamen Speicher-/Ressourcenhandling.
Konformitätstests oder Typtests
Bei Softwaretests überprüft Konformitätstests, dass ein Produkt nach seinen festgelegten Standards funktioniert. Compiler werden beispielsweise ausführlich getestet, um festzustellen, ob sie den anerkannten Standard für diese Sprache erfüllen.
Ausgangsvergleichstest
Erstellen eines auf das Anzeigen erwarteten Ausgangs, ob als Datenvergleich von Text oder Screenshots der Benutzeroberfläche,[4]: 195 wird manchmal als Snapshot -Tests oder goldene Master -Tests bezeichnet. Im Gegensatz zu vielen anderen Testformen kann dies keine Fehler automatisch erkennen und erfordert stattdessen, dass ein Mensch die Ausgabe für Inkonsistenzen bewertet.
Immobilientests
Immobilientests ist eine Testtechnik, bei der der Praktiker, anstatt zu behaupten, dass bestimmte Eingaben spezifische erwartete Ausgänge erzeugen, zufällig viele Eingaben erzeugt, das Programm auf allen von ihnen ausführt und die Wahrheit einer "Eigenschaft" behauptet, die für jedes Paar zutreffen sollte von Eingang und Ausgabe. Beispielsweise sollte jede Eingabe für eine Sortierfunktion die gleiche Länge wie die Ausgabe haben. Jede Ausgabe einer Sortierfunktion sollte eine monotoner zunehmende Liste sein.
Immobilientestbibliotheken ermöglichen es dem Benutzer, die Strategie zu steuern, mit der zufällige Eingaben konstruiert werden, um die Abdeckung degenerierter Fälle oder Eingaben mit spezifischen Mustern zu gewährleisten, die erforderlich sind, um Aspekte der zu testenden Implementierung vollständig auszuüben.
Immobilientests werden manchmal auch als "generative Tests" oder "QuickCheck -Tests" bezeichnet, da es von der Haskell -Bibliothek eingeführt und populär gemacht wurde. "Schneller Check. "[63]
Metamorphe Tests
Metamorphe Tests (MT) ist eine projektionsbasierte Software-Testtechnik, die ein effektiver Ansatz zur Behebung des Problems mit dem Test Oracle und dem Problem der Testfallgenerierung sein kann. Das Problem mit dem Test Oracle ist die Schwierigkeit, die erwarteten Ergebnisse ausgewählter Testfälle zu ermitteln oder festzustellen, ob die tatsächlichen Ausgaben den erwarteten Ergebnissen übereinstimmen.
VCR -Test
VCR-Tests, auch als "Wiedergabetest" oder "Record/Replay" -Test bezeichnet, ist eine Testtechnik zur Erhöhung der Zuverlässigkeit und Geschwindigkeit von Regressionstests, die eine Komponente beinhalten, die langsam oder unzuverlässig zu kommunizieren ist, häufig eine API von Drittanbietern außerhalb der Kontrolle des Tester. Es umfasst eine Aufzeichnung ("Kassette") der Wechselwirkungen des Systems mit der externen Komponente und dann die aufgezeichneten Wechselwirkungen als Ersatz für die Kommunikation mit dem externen System auf nachfolgenden Läufen des Tests.
Die Technik wurde von der Ruby Library in der Webentwicklung populär gemacht VCR.
Testprozess
Traditionelles Wasserfallentwicklungsmodell
Eine übliche Praxis in der Wasserfallentwicklung besteht darin, dass Tests von einer unabhängigen Gruppe von Tester durchgeführt werden. Dies kann passieren:
- Nach der Entwicklung der Funktionalität, aber bevor sie an den Kunden versendet wird.[64] Diese Praxis führt häufig dazu, dass die Testphase als verwendet wird Projekt Puffer, um Projektverzögerungen zu kompensieren und damit die Zeit zu beeinträchtigen, die den Tests gewidmet ist.[14]: 145–146
- Gleichzeitig beginnt das Entwicklungsprojekt als kontinuierlicher Prozess bis zum Abschluss des Projekts.[65]
Aber selbst im Wasserfallentwicklungsmodell, Unit -Tests wird oft vom Softwareentwicklungsteam durchgeführt, auch wenn weitere Tests von einem separaten Team durchgeführt werden.[66]
Agile oder XP -Entwicklungsmodell
Im Gegensatz dazu einige aufstrebende Software -Disziplinen wie extremes Programmieren und die Agile Software Entwicklung Bewegung, haften Sie sich an einen "Testgetriebene Softwareentwicklung"Modell. In diesem Prozess, Unit -Tests werden zuerst von der geschrieben Software -Ingenieure (oft mit Paar-Programmierung in der extremen Programmiermethode). Es wird erwartet, dass die Tests zunächst scheitern. Auf jeden fehlenden Test wird gerade genug Code geschrieben, damit es bestanden wird.[67] Dies bedeutet, dass die Testsuiten kontinuierlich aktualisiert werden, wenn neue Fehlerbedingungen und Eckfälle entdeckt werden und in alle entwickelten Regressionstests integriert werden. Unit -Tests werden zusammen mit dem Rest des Software -Quellcodes beibehalten und im Allgemeinen in den Build -Prozess integriert (wobei interaktive interaktive Tests in einen teilweise manuellen Build -Akzeptanzprozess verwandelt werden).
Die ultimativen Ziele dieses Testprozesses sind die Unterstützung kontinuierliche Integration und um Defektraten zu senken.[68][67]
Diese Methodik erhöht die durch die Entwicklung durchgeführten Testaufwand, bevor er ein formelles Testteam erreicht. In einigen anderen Entwicklungsmodellen erfolgt der größte Teil der Testausführung, nachdem die Anforderungen definiert und der Codierungsprozess abgeschlossen wurde.
Ein Probenprüfzyklus
Obwohl zwischen Organisationen Variationen bestehen, gibt es einen typischen Zyklus zum Testen.[2] Die folgende Stichprobe ist unter Organisationen, die die beschäftigen Wasserfallentwicklung Modell. Die gleichen Praktiken finden sich häufig in anderen Entwicklungsmodellen, sind jedoch möglicherweise nicht so klar oder explizit.
- Anforderungsanalyse: Tests sollten in der Anforderungensphase der Anforderungen beginnen Lebenszyklus der Softwareentwicklung. Während der Entwurfsphase arbeiten die Tester, um festzustellen, welche Aspekte eines Designs prüfbar sind und welche Parameter diese Tests funktionieren.
- Testplanung: Teststrategie, Versuchsplan, Testbed Schaffung. Da während des Tests viele Aktivitäten durchgeführt werden, ist ein Plan erforderlich.
- Testentwicklung: Testverfahren, Testszenarien, TestfälleTesten Sie Datensätze, testen Sie Skripte für die Testsoftware.
- Testausführung: Tester führen die Software basierend auf den Plänen und Testdokumenten aus und melden dann alle Fehler beim Entwicklungsteam. Dieser Teil könnte komplex sein, wenn Tests mit einem Mangel an Programmierkenntnissen ausgeführt werden.
- Testberichterstattung: Sobald die Tests abgeschlossen sind, generieren Tester Metriken und erstellen Abschlussberichte über ihre Testanstrengung und ob die getestete Software zur Veröffentlichung bereit ist oder nicht.
- Testergebnisanalyse: oder Defektanalyse wird vom Entwicklungsteam normalerweise zusammen mit dem Kunden durchgeführt, um zu entscheiden, welche Mängel zugewiesen, festgelegt, abgelehnt (d. H. Fund Software ordnungsgemäß funktioniert) oder aufgeschoben werden, um später behandelt zu werden.
- Wiederholungstest: Sobald das Entwicklungsteam ein Defekt behandelt hat, wird er vom Testteam erneut getestet.
- Regressionstests: Es ist üblich, ein kleines Testprogramm für eine Teilmenge von Tests für jede Integration neuer, modifizierter oder fester Software zu erstellen, um sicherzustellen immer noch richtig arbeiten.
- Testschließung: Sobald der Test die Ausstiegskriterien erfüllt, werden die Aktivitäten wie die Erfassung der wichtigsten Ausgaben, Erkenntnisse, Ergebnisse, Protokolle und Dokumente, die sich mit dem Projekt beziehen, archiviert und als Referenz für zukünftige Projekte verwendet.
Automatisierte Tests
Viele Programmiergruppen[Wie wen?] verlassen sich immer mehr[vage] an automatisierte Tests, insbesondere Gruppen, die verwenden Testgetriebene Entwicklung. Es gibt viele Frameworks[angeben] Tests schreiben in und kontinuierliche Integration Die Software wird jedes Mal automatisch Tests ausführen, wenn der Code in a überprüft wird Versionskontrolle System.
Obwohl die Automatisierung nicht alles reproduzieren kann, was ein Mensch kann (und die Möglichkeiten, wie sie es tun), kann sie für Regressionstests sehr nützlich sein. Es erfordert jedoch eine gut entwickelte Testsuite Skripte testen, um wirklich nützlich zu sein.
Testwerkzeuge
Programmtests und Fehlererkennung können durch Testwerkzeuge erheblich unterstützt werden Debugger. Testen/Debug -Tools umfassen Funktionen wie:
- Programmmonitore, die eine vollständige oder teilweise Überwachung des Programmcode ermöglichen, einschließlich:
- Anweisungssatz SimulatorErmöglichen Sie eine vollständige Überwachung und Spureneinrichtungen für Anleitungen und Spuren
- Hypervisor, was die vollständige Kontrolle über die Ausführung des Programmcode ermöglicht, einschließlich:-
- ProgrammanimationSchritt-für-Schritt-Ausführung und -bedingte Erlaubnis Haltepunkt auf Quellenebene oder in Maschinensprache
- Codeabdeckung Berichte
- Formatiertes Dump oder Symbolisches Debuggen, Tools, die die Inspektion von Programmvariablen auf Fehler oder an ausgewählten Punkten ermöglichen
- Automatisierte Funktional Grafische Benutzeroberfläche (GUI) Testwerkzeuge werden verwendet, um Tests auf Systemebene durch die GUI zu wiederholen
- Benchmarks, damit die Leistungsvergleiche für die Laufzeit durchgeführt werden können
- Performance-Analyse (oder Profiling -Werkzeuge), die zum Hervorheben helfen können Hot Spots und Ressourcenverbrauch
Einige dieser Funktionen können in ein einzelnes Verbundwerkzeug oder in ein integriert werden Integrierte Entwicklungsumgebung (Ide).
Erfassen und wiederholen
Erfassungs- und Wiederholungstests besteht darin, ein End-to-End-Nutzungsszenario zu sammeln, während Sie mit einer Anwendung interagieren und diese Szenarien in Testfälle umwandeln. Mögliche Anwendungen der Erfassung und Wiederholung umfassen die Erzeugung von Regressionstests. Das Scarpe -Werkzeug [69] Erfasst selektiv eine Teilmenge der untersuchten Anwendung, während sie ausgeführt wird. Jrapture erfasst die Abfolge der Interaktionen zwischen einem ausführenden Java -Programm und Komponenten auf dem Hostsystem wie Dateien oder Ereignissen auf grafischen Benutzeroberflächen. Diese Sequenzen können dann für beobachtungsbasierte Tests wiederholt werden.[70] Saieva et al. Schlagen Sie vor, Ad-hoc-Tests zu generieren, bei denen die Ausführungsspuren von Benutzerausführungen wiederholt wurden, um Kandidatenpatches für kritische Sicherheitsfehler zu testen.[71] Pankti sammelt Objektprofile in der Produktion, um fokussierte Differential -Unit -Tests zu erstellen. Dieses Tool verbessert die Erfassung und Wiederholung mit der systematischen Erzeugung von abgeleiteten Orakel testen.[72]
Messung des Softwaretests
Qualitätsmaßnahmen umfassen Themen wie Richtigkeit, Vollständigkeit, Sicherheit und ISO/IEC 9126 Anforderungen wie Fähigkeiten, Verlässlichkeit, Effizienz, Portabilität, Wartbarkeit, Kompatibilität und Benutzerfreundlichkeit.
Es gibt eine Reihe von häufig verwendeten Software -Metrikenoder Maßnahmen, die zur Bestimmung des Zustands der Software oder der Angemessenheit der Tests verwendet werden.
Hierarchie der Testschwierigkeit
Basierend auf der Anzahl der Testfälle, die zum Erstellen einer vollständigen Testsuite in jedem Kontext erstellt werden (d. H. Eine Testsuite Nach einigen Spezifikationen wurde eine Hierarchie der Testschwierigkeit vorgeschlagen.[73] [74] Es enthält die folgenden Testbarkeit Klassen:
- Klasse I: Es gibt eine endliche vollständige Testsuite.
- Klasse II: Jede teilweise Unterscheidungsrate (d. H. Jede unvollständige Fähigkeit, korrekte Systeme von falschen Systemen zu unterscheiden) kann mit einer endlichen Testsuite erreicht werden.
- Klasse III: Es gibt eine zählbare vollständige Testsuite.
- Klasse IV: Es gibt eine vollständige Testsuite.
- Klasse V: Alle Fälle.
Es wurde bewiesen, dass jede Klasse im nächsten streng enthalten ist. Zum Beispiel das Testen, wenn wir davon ausgehen, dass das Verhalten der zu testenden Implementierung durch eine deterministische Bezeichnung bezeichnet werden kann Finite-State-Maschine Für einige bekannte endliche Sätze von Eingängen und Ausgängen und mit einer bekannten Anzahl von Zuständen gehören die Klasse I (und alle nachfolgenden Klassen). Wenn die Anzahl der Zustände jedoch nicht bekannt ist, gehört sie nur zu allen Klassen der Klasse II. Wenn die zu testende Implementierung eine deterministische Finite-State-Maschine sein muss, die die Spezifikation für eine einzige Spur (und ihre Fortschritte) fehlschlägt und ihre Anzahl der Zustände unbekannt ist, gehört sie nur Klassen aus der Klasse III an. Testen zeitlicher Maschinen, bei denen Übergänge ausgelöst werden, wenn Eingänge in einem realgebundenen Intervall erzeugt werden ). Die Einbeziehung in die Klasse I erfordert nicht die Einfachheit des angenommenen Berechnungsmodell Fälle wie das Testframework von Matthew Hennessy Unter Must Semantics und zeitlichen Maschinen mit rationalen Zeitüberschreitungen gehören der Klasse II.
Artefakte testen
Ein Software -Testprozess kann mehrere erzeugen Artefakte. Die tatsächlichen Artefakte sind ein Faktor für das verwendete Softwareentwicklungsmodell, die Stakeholder und die organisatorischen Anforderungen.
- Versuchsplan
- A Versuchsplan ist ein Dokument, in dem der Ansatz beschrieben wird, der für beabsichtigte Testaktivitäten verfolgt wird. Der Plan kann Aspekte wie Ziele, Umfang, Prozesse und Verfahren, Personalanforderungen und Notfallpläne umfassen.[43] Der Testplan kann in Form eines einzelnen Plans erfolgen, der alle Testtypen (wie ein Annahme- oder Systemtestplan) und Planungsüberlegungen enthält, oder er kann als Master -Testerplan ausgestellt werden, der einen Überblick über mehr als einen detaillierten Test bietet Plan (ein Plan eines Plans).[43] Ein Testplan kann in einigen Fällen Teil einer breiten sein. "Teststrategie"Welche Dokumente allgemeine Testansätze, die selbst ein Master -Testplan oder sogar ein separates Artefakt sein können.
- Rückverfolgbarkeitsmatrix
- A Rückverfolgbarkeitsmatrix ist eine Tabelle, die Anforderungen oder Entwurfsdokumente zum Testen von Dokumenten korreliert. Es wird verwendet, um Tests zu ändern, wenn verwandte Quelldokumente geändert werden, um Testfälle für die Ausführung bei der Planung von Regressionstests durch Berücksichtigung der Anforderungen abzuwählen.
- Testfall
- A Testfall Normalerweise besteht aus einer eindeutigen Kennung, Anforderungen Referenzen aus einer Entwurfsspezifikation, Voraussetzungen, Ereignissen, einer Reihe von Schritten (auch als Aktionen bezeichnet), um zu befolgen, Eingabe, Ausgabe, erwartetes Ergebnis und das tatsächliche Ergebnis. Klinisch definiert ist ein Testfall ein Eingang und ein erwartetes Ergebnis.[75] Dies kann so knapp sein wie "Für die Bedingung x Ihr abgeleitetes Ergebnis ist y", obwohl normalerweise Testfälle das Eingangsszenario detaillierter beschreiben und welche Ergebnisse möglicherweise erwartet werden. Es kann gelegentlich eine Reihe von Schritten sein (aber häufig sind Schritte in einem separaten Testverfahren enthalten, das aus wirtschaftlicher Hinsicht gegen mehrere Testfälle ausgeübt werden kann), jedoch mit einem erwarteten Ergebnis oder einem erwarteten Ergebnis. Die optionalen Felder sind ein Testfall -ID, ein Testschritt oder die Ausführungsnummer, die damit verbundenen Anforderungen, die Tiefe, die Testkategorie, der Autor und die Kontrollkästchen, ob der Test automatisch ist und automatisiert wurde. Größere Testfälle können auch Voraussetzungen für Zustände oder Schritte sowie Beschreibungen enthalten. Ein Testfall sollte auch einen Ort für das tatsächliche Ergebnis enthalten. Diese Schritte können in einem Textverarbeitungsprozessor, einer Tabelle, einer Datenbank oder anderen gemeinsamen Repositorys gespeichert werden. In einem Datenbanksystem können Sie möglicherweise auch frühere Testergebnisse sehen, die die Ergebnisse generiert haben und mit welcher Systemkonfiguration diese Ergebnisse generiert wurden. Diese früheren Ergebnisse würden normalerweise in einer separaten Tabelle gespeichert.
- Testskript
- A Testskript ist ein Prozedur- oder Programmiercode, der Benutzeraktionen wiederholt. Zunächst wurde der Begriff aus dem Produkt der Arbeiten, die durch automatisierte Regressionstest -Tools erstellt wurden, abgeleitet. Ein Testfall ist eine Grundlinie zum Erstellen von Testskripten mit einem Tool oder einem Programm.
- Testsuite
- Der häufigste Begriff für eine Sammlung von Testfällen ist a Testsuite. Die Testsuite enthält häufig auch detailliertere Anweisungen oder Ziele für jede Sammlung von Testfällen. Es enthält definitiv einen Abschnitt, in dem der Tester die während des Tests verwendete Systemkonfiguration identifiziert. Eine Gruppe von Testfällen kann auch Voraussetzungen oder Schritte sowie Beschreibungen der folgenden Tests enthalten.
- Testvorrichtung oder Testdaten
- In den meisten Fällen werden mehrere Werte oder Datensätze verwendet, um die gleiche Funktionalität einer bestimmten Funktion zu testen. Alle Testwerte und veränderbaren Umgebungskomponenten werden in separaten Dateien gesammelt und als Testdaten gespeichert. Es ist auch nützlich, diese Daten dem Kunden und mit dem Produkt oder einem Projekt zur Verfügung zu stellen. Es gibt Techniken zum Generieren von Testdaten.
- Testkabelbaum
- Die Software, Tools, Samples von Dateneingaben und Ausgabe sowie Konfigurationen werden zusammen als A bezeichnet Testkabelbaum.
- Testlauf
- Ein Bericht über die Ergebnisse aus dem Ausführen eines Testfalls oder einer Testsuite
Zertifizierungen
Es gibt mehrere Zertifizierungsprogramme, um die professionellen Bestrebungen von Softwaretestern und Qualitätssicherungsspezialisten zu unterstützen. Beachten Sie, dass einige Praktiker argumentieren, dass das Testfeld nicht zur Zertifizierung bereit ist, wie in der erwähnt Kontroverse Sektion.
Kontroverse
Einige der Major Software -Test -Kontroversen enthalten:
- Agil gegen traditionell
- Sollten Tester lernen, unter Bedingungen der Unsicherheit und der ständigen Veränderung zu arbeiten, oder sollten sie darauf abzielen Prozess "Reife"? Das Agile Tests Die Bewegung wird seit 2006 zunehmend beliebt, hauptsächlich in kommerziellen Kreisen,[76][77] während Regierung und Militär[78] Softwareanbieter verwenden diese Methodik, aber auch die traditionellen Testlastmodelle (z. B. in der Wasserfall-Modell).
- Handbuch vs. automatisierte Tests
- Einige Schriftsteller glauben das Testautomatisierung ist im Vergleich zu seinem Wert so teuer, dass es sparsam verwendet werden sollte.[79] Die Testautomatisierung kann dann als Möglichkeit angesehen werden, die Anforderungen zu erfassen und zu implementieren. Je größer das System und je größer die Komplexität ist, desto größer ist der ROI in der Testautomatisierung. Außerdem kann die Investition in Tools und Fachwissen über mehrere Projekte mit dem richtigen Wissensaustausch innerhalb einer Organisation abgeschrieben werden.
- Ist die Existenz der ISO 29119 Software -Teststandard gerechtfertigt?
- Eine signifikante Opposition hat sich aus den Reihen der kontextgetriebenen Schule für Softwaretests zum ISO 29119-Standard gebildet. Professionelle Testverbände wie die Internationale Gesellschaft für Softwaretests haben versucht, den Standard zurückzuziehen.[80][81]
- Einige Praktiker erklären, dass das Testfeld nicht zur Zertifizierung bereit ist
- [82] Für keine Zertifizierung muss der Bewerber tatsächlich seine Fähigkeit zum Testen von Software zeigen. Keine Zertifizierung basiert auf einem weit verbreiteten Wissen. Die Zertifizierung selbst kann die Produktivität, ihre Fähigkeiten oder ihr praktisches Wissen eines Einzelnen nicht messen und ihre Kompetenz oder Professionalität als Tester nicht garantieren.[83]
- Studien, die verwendet werden, um die relativen Kosten für Fixierungsfehlern zu zeigen
- Es gibt entgegengesetzte Ansichten über die Anwendbarkeit von Studien, die verwendet werden, um die relativen Kosten für die Fixierung von Mängel in Abhängigkeit von ihrer Einführung und Erkennung zu zeigen. Zum Beispiel:
Es wird allgemein angenommen, dass je früher ein Defekt gefunden wird, der billigere es ist, ihn zu reparieren. Die folgende Tabelle zeigt die Kosten für die Befestigung des Defekts in Abhängigkeit von der gefundenen Phase.[84] Wenn beispielsweise ein Problem in den Anforderungen nur nach der Veröffentlichung festgestellt wird, würde es 10 bis 100 Mal mehr kosten, um zu beheben, als wenn es bereits durch die Anforderungen überprüft worden wäre. Mit dem Aufkommen der Moderne kontinuierliche Bereitstellung Praktiken und Cloud-basierte Dienste, die Kosten für die Umsetzung und Wartung können sich im Laufe der Zeit verringern.
Kosten für die Behebung eines Defekts Zeit erkannt Anforderungen Die Architektur Konstruktion Systemtest Nachveröffentlichung Zeit eingeführt Anforderungen 1 × 3 × 5–10 × 10 × 10–100 × Die Architektur – 1 × 10 × 15 × 25–100 × Konstruktion – – 1 × 10 × 10–25 ×
Die Daten, aus denen diese Tabelle extrapoliert ist, sind spärlich. Laurent Bossavit sagt in seiner Analyse:
Die Kurve "kleinere Projekte" stellt sich als nur zwei Teams von Studenten im ersten Jahr heraus, eine Stichprobengröße, die so klein ist, dass es völlig unhaltbar ist, auf "kleinere Projekte im Allgemeinen" zu extrapolieren. Die GTE -Studie erklärt ihre Daten nicht, außer zu sagen, dass sie aus zwei Projekten stammt, einer großen und einer kleinen. Das für das Bell Labs "Safeguard" -Projekt zitierte Papier lehnt ausdrücklich ab, dass die feinkörnigen Daten gesammelt wurden, die die Datenpunkte von Boehm vorschlagen. Die IBM -Studie (Fagans Papier) enthält Behauptungen, die Boehms Diagramm zu widersprechen scheinen, und keine numerischen Ergebnisse, die seinen Datenpunkten eindeutig entsprechen.
Boehm zitiert nicht einmal ein Papier für die TRW -Daten, außer wenn er 2010 für "Software machen" schreibe, und dort zitierte er den ursprünglichen Artikel von 1976. Es gibt eine große Studie, die zum richtigen Zeitpunkt bei TRW durchgeführt wurde, damit Boehm sie zitiert, aber dieses Papier enthält nicht die Art von Daten, die die Behauptungen von Boehm unterstützen würden.[85]
Verwandte Prozesse
Softwareüberprüfung und Validierung
Softwaretests werden in Verbindung mit verwendet Verifizierung und Validierung:[86]
- Überprüfung: Haben wir die Software richtig erstellt? (d. h. implementiert es die Anforderungen).
- Validierung: Haben wir die richtige Software erstellt? (d. H. Befriedigen die Leistungen den Kunden).
Die Begriffe Überprüfung und Validierung werden in der Branche üblicherweise austauschbar verwendet. Es ist auch üblich, diese beiden Begriffe mit widersprüchlichen Definitionen zu sehen. Laut dem IEEE Standard Glossar der Software -Engineering -Terminologie:[6]: 80–81
- Überprüfung ist der Prozess der Bewertung eines Systems oder einer Komponente, um festzustellen, ob die Produkte einer bestimmten Entwicklungsphase die zu Beginn dieser Phase auferlegten Bedingungen erfüllen.
- Die Validierung ist der Prozess der Bewertung eines Systems oder einer Komponente während oder am Ende des Entwicklungsprozesses, um festzustellen, ob die festgelegten Anforderungen erfüllt.
Und gemäß dem ISO 9000 -Standard:
- Die Überprüfung ist die Bestätigung durch Prüfung und durch Bereitstellung objektiver Beweise dafür, dass festgelegte Anforderungen erfüllt wurden.
- Die Validierung ist die Bestätigung durch Prüfung und durch Bereitstellung objektiver Beweise dafür, dass die Anforderungen für eine bestimmte beabsichtigte Verwendung oder Anwendung erfüllt wurden.
Der Widerspruch wird durch die Verwendung der Konzepte von Anforderungen und festgelegten Anforderungen verursacht, jedoch mit unterschiedlichen Bedeutungen.
Im Falle von IEEE -Standards sind die angegebenen Anforderungen, die in der Definition der Validierung erwähnt werden, die Anzahl der Probleme, Bedürfnisse und Wünsche der Stakeholder, die die Software lösen und erfüllen muss. Diese Anforderungen werden in einer Softwareanforderungen Spezifikation (SRS) dokumentiert. Die in der Definition der Verifizierung erwähnten Produkte sind die Ausgangsartefakte jeder Phase des Softwareentwicklungsprozesses. Diese Produkte sind in der Tat Spezifikationen wie Architektur -Designspezifikation, detaillierte Entwurfsspezifikation usw. Das SRS ist ebenfalls eine Spezifikation, kann jedoch nicht überprüft werden (zumindest nicht im hier verwendeten Sinne, mehr zu diesem Thema unten).
Für die ISO 9000 sind die angegebenen Anforderungen jedoch die festgelegte Spezifikationen, wie oben erwähnt, die überprüft werden müssen. Eine Spezifikation ist, wie bereits erläutert, das Produkt einer Softwareentwicklungsprozessphase, die eine andere Spezifikation als Eingabe erhält. Eine Spezifikation wird erfolgreich überprüft, wenn sie die Eingabespezifikation korrekt implementiert. Alle Spezifikationen können überprüft werden, mit Ausnahme der SRS, da es das erste ist (es kann jedoch validiert werden). Beispiele: Die Entwurfsspezifikation muss die SRS implementieren. Die Konstruktionsphasenartefakte müssen die Entwurfsspezifikation implementieren.
Wenn diese Wörter in allgemeiner Begriffe definiert werden, verschwindet der offensichtliche Widerspruch.
Sowohl die SRS als auch die Software müssen validiert werden. Das SRS kann durch Beratung mit den Stakeholdern statisch validiert werden. Dennoch kann das Ausführen einer teilweisen Implementierung der Software oder eines Prototyps jeglicher Art (dynamischer Tests) und die Erlangung positiver Rückmeldungen von ihnen die Sicherheit, dass das SRS korrekt formuliert wird, weiter erhöhen. Andererseits muss die Software als endgültiges und laufendes Produkt (nicht ihre Artefakte und Dokumente, einschließlich des Quellcode) dynamisch mit den Stakeholdern validiert werden, indem die Software ausgeführt und sie versucht werden.
Einige könnten argumentieren, dass die Eingabe für SRS die Wörter der Stakeholder und daher die SRS -Validierung der SRS -Überprüfung der SRS -Überprüfung ist. Das zu denken ist nicht ratsam, da es nur mehr Verwirrung verursacht. Es ist besser, sich zu überprüfend als einen Prozess mit einem formellen und technischen Eingabedokument.
Software Qualitätssicherung
Softwaretests können als Teil von a angesehen werden Software Qualitätssicherung (SQA) Prozess.[4]: 347 In SQA befassen sich Softwareprozessspezialisten und Prüfer eher mit dem Softwareentwicklungsprozess als nur mit den Artefakten wie Dokumentation, Code und Systemen. Sie untersuchen und ändern die Softwareentwicklung Verarbeiten Sie sich, um die Anzahl der Fehler zu reduzieren, die in der gelieferten Software landen: die sogenannte Defektrate. Was eine akzeptable Defektrate ausmacht, hängt von der Art der Software ab; Ein Flugsimulator -Videospiel hätte eine viel höhere Defekt -Toleranz als Software für ein tatsächliches Flugzeug. Obwohl es enge Verbindungen zu SQA gibt, existieren häufig Testabteilungen unabhängig, und es gibt möglicherweise keine SQA -Funktion in einigen Unternehmen.
Software-Tests sind eine Aktivität, um die zu testende Software zu untersuchen, um den Stakeholdern qualitativ hochwertige Informationen bereitzustellen. Dagegen QA (Qualitätssicherung) Ist die Umsetzung von Richtlinien und Verfahren, die verhindern sollen, dass Mängel Kunden erreichen.
Siehe auch
- Datenvalidierung- Der Prozess der Sicherstellung von Computerdaten ist sowohl korrekt als auch nützlich
- Dynamische Programmanalyse- Analyse der Computersoftware, die durch Ausführung des Programms durchgeführt wird
- Formelle Überprüfung- Beweisen oder widerlegen die Richtigkeit bestimmter beabsichtigter Algorithmen
- Grafische Benutzeroberflächen -Tests- Term in Software Engineering
- Unabhängige Testorganisation- Organisation, die nach vereinbarten Anforderungen testet
- Manuelle Tests- Software ohne Verwendung spezieller Tools zur Automatisierung des Prozesses testen
- Orthogonale Array -Tests- Software -Testtechnik
- Paartests- Software -Testtechnik
- Reverse semantische Rückverfolgbarkeit- Qualitätskontrolltechnik
- Softwaretesttaktik- Überblick über mehrere bemerkenswerte Taktiken, die bei Softwareentests nützlich sind
- Testmanagement -Tool- Geschäfte Testschritte, Testplanung und Berichterstattung
- Spurenentisch- Software -Testtechnik
- Webtests- Softwaretests, die sich auf Webanwendungen konzentrieren
Verweise
- ^ Kaner, Cem (17. November 2006). Versuchsforschung (PDF). Quality Assurance Institute Worldwide Annual Software Testing Conference. Orlando, fl. Abgerufen November 22, 2014.
- ^ a b Pan, Jiantao (Frühjahr 1999). "Softwaretest" (Kursarbeit). Carnegie Mellon Universität. Abgerufen 21. November, 2017.
- ^ Leitner, Andreas; CIUPA, Ilinca; Oriol, Manuel; Meyer, Bertrand; Fiva, Arno (September 2007). Vertragsgetriebene Entwicklung = testgetriebene Entwicklung - Schreibprüfungsfälle (PDF). ESEC/FSE'07: Europäische Software -Engineering -Konferenz und das ACM Sigsoft Symposium über die Grundlagen von Software Engineering 2007. Dubrovnik, Kroatien. Abgerufen 8. Dezember, 2017.
- ^ a b c d Kaner, Cem; Falk, Jack; Nguyen, Hung Quoc (1999). Computersoftware testen (2. Aufl.). New York: John Wiley und Söhne. ISBN 978-0-471-35846-6.
- ^ a b Kolawa, Adam; Huizinga, Dorota (2007). Automatisierte Defektprävention: Best Practices im Softwaremanagement. Wiley-ieee Computer Society Press. ISBN 978-0-470-04212-0.
- ^ a b c 610.12-1990 - IEEE Standard Glossar der Software -Engineering -Terminologie, IEEE, 1990, doi:10.1109/IEEESTD.1990.101064, ISBN 978-1-55937-067-7
- ^ "Lehrplan der zertifizierten Tester Foundation Level" (PDF). Internationaler Qualifikationsausschuss für Software -Tests. 31. März 2011. Abschnitt 1.1.2. Abgerufen 15. Dezember, 2017.
- ^ "Lehrplan der zertifizierten Tester Foundation Level" (PDF). Internationaler Qualifikationsausschuss für Software -Tests. 1. Juli 2005. Prinzip 2, Abschnitt 1.3. Abgerufen 15. Dezember, 2017.
- ^ Ramler, Rudolf; Kopetzky, Theodorich; STZ, Wolfgang (17. April 2012). Kombinatorisches Testdesign im Tosca Testsuite: Lektionen erlernte und praktische Auswirkungen. IEEE Fifth International Conference für Software -Tests und -Validierung (ICST). Montreal, QC, Kanada. doi:10.1109/icst.2012.142.
- ^ "Die wirtschaftlichen Auswirkungen einer unzureichenden Infrastruktur für Softwaretests" (PDF). Nationales Institut für Standards und Technologie. Mai 2002. Abgerufen 19. Dezember, 2017.
- ^ Sharma, Bharadwaj (April 2016). "Ardentia Technologies: Bereitstellung hochrangiger Softwarelösungen und umfassender Testdienste". CIO -Bewertung (Indien ed.). Abgerufen 20. Dezember, 2017.
- ^ Gelperin, David; Hetzel, Bill (1. Juni 1988). "Das Wachstum von Software -Tests". Kommunikation der ACM. 31 (6): 687–695. doi:10.1145/62959.62965. S2CID 14731341.
- ^ Gregory, Janet; Crispin, Lisa (2014). Agilere Tests. Addison-Wesley Professional. S. 23–39. ISBN 978-0-13-374956-4.
- ^ a b c Myers, Glenford J. (1979). Die Kunst des Softwaretests. John Wiley und Söhne. ISBN 978-0-471-04328-7.
- ^ a b Graham, D.; Van Veenendaal, E.; Evans, I. (2008). Grundlagen des Softwaretests. Cengage -Lernen. S. 57–58. ISBN 978-1-84480-989-9.
- ^ a b c d Oberkampf, W. L.; Roy, C. J. (2010). Überprüfung und Validierung im wissenschaftlichen Computer. Cambridge University Press. S. 154–5. ISBN 978-1-139-49176-1.
- ^ Lee, D.; Netravali, A.N.; Sabnani, K.K.; SUGLA, B.; John, A. (1997). "Passive Tests und Anwendungen für das Netzwerkmanagement". Proceedings 1997 Internationale Konferenz über Netzwerkprotokolle. IEEE Comput. SOC: 113–122. doi:10.1109/ICNP.1997.643699. ISBN 978-0-8186-8061-8. S2CID 42596126.
- ^ a b Cem Kaner (2008), Ein Tutorial in explorativen Tests (PDF)
- ^ a b c d Limaye, M.G. (2009). Softwaretest. Tata McGraw-Hill Education. S. 108–11. ISBN 978-0-07-013990-9.
- ^ a b c d Saleh, K.A. (2009). Softwareentwicklung. J. Ross Publishing. S. 224–41. ISBN 978-1-932159-94-3.
- ^ a b c Ammann, P.; Offutt, J. (2016). Einführung in Softwaretests. Cambridge University Press. p. 26. ISBN 978-1-316-77312-3.
- ^ Everatt, G.D.; McLeod Jr., R. (2007). "Kapitel 7: Funktionstest". Softwaretests: Testen des gesamten Lebenszyklus für Softwareentwicklungszyklus. John Wiley & Sons. S. 99–121. ISBN 978-0-470-14634-7.
- ^ a b Cornett, Steve (ca. 1996). "Codeabdeckungsanalyse". Bullseye -Testtechnologie. Einführung. Abgerufen 21. November, 2017.
- ^ a b Black, R. (2011). Pragmatische Softwaretests: Ein effektiver und effizienter Testprofi werden. John Wiley & Sons. S. 44–6. ISBN 978-1-118-07938-6.
- ^ Als einfaches Beispiel das, das C Funktion
int f(int x){return x*x-6*x+8;}
besteht aus nur einer Erklärung. Alle Tests gegen eine Spezifikationf(x)>=0
wird erfolgreich sein, außer wennx=3
zufällig ausgewählt werden. - ^ Vera-Pérez, Oscar Luis; Danglot, Benjamin; Monperrus, Martin; Baudry, Benoit (2018). "Eine umfassende Studie über pseudo-getestete Methoden". Empirische Software -Engineering. 24 (3): 1195–1225. Arxiv:1807.05030. Bibcode:2018ArXIV180705030V. doi:10.1007/s10664-018-9653-2. S2CID 49744829.
- ^ Patton, Ron (2005). Softwaretest (2. Aufl.). Indianapolis: Sams Publishing. ISBN 978-0-672-32798-8.
- ^ Laycock, Gilbert T. (1993). Die Theorie und Praxis von spezifikationsbasierten Softwaretests (PDF) (Dissertationsthese). Abteilung für Computerwissenschaften, Universität von Sheffield. Abgerufen 2. Januar, 2018.
- ^ Bach, James (Juni 1999). "Risiko- und anforderungsbasierte Tests" (PDF). Computer. 32 (6): 113–114. Abgerufen 19. August, 2008.
- ^ Savenkov, Roman (2008). Wie man ein Softwaretester wird. Roman Savenkov Beratung. p. 159. ISBN 978-0-615-23372-7.
- ^ Mathur, A.P. (2011). Grundlagen des Softwaretests. Pearson Education India. p. 63. ISBN 978-81-317-5908-0.
- ^ a b Clapp, Judith A. (1995). Software -Qualitätskontrolle, Fehleranalyse und Tests. p. 313. ISBN 978-0-8155-1363-6. Abgerufen 5. Januar, 2018.
- ^ Mathur, Aditya P. (2007). Grundlagen des Softwaretests. Pearson Education India. p. 18. ISBN 978-81-317-1660-1.
- ^ Lönnberg, Januar (7. Oktober 2003). Visuelle Tests von Software (PDF) (MSC -These). Helsinki Universität für Technologie. Abgerufen 13. Januar, 2012.
- ^ Chima, Raspal. "Visuelle Tests". Testmagazin. Archiviert von das Original am 24. Juli 2012. Abgerufen 13. Januar, 2012.
- ^ a b c Lewis, W.E. (2016). Softwaretests und kontinuierliche Qualitätsverbesserung (3. Aufl.). CRC Press. S. 68–73. ISBN 978-1-4398-3436-7.
- ^ a b Ransome, J.; Misra, A. (2013). Kernsoftwaresicherheit: Sicherheit an der Quelle. CRC Press. S. 140–3. ISBN 978-1-4665-6095-6.
- ^ "SOA -Testwerkzeuge für schwarze, weiße und graue Box" (weißes Papier). CrossCheck -Netzwerke. Archiviert von das Original am 1. Oktober 2018. Abgerufen 10. Dezember, 2012.
- ^ Bourque, Pierre; Fairley, Richard E., Hrsg. (2014). "Kapitel 5". Leitfaden für die Software -Engineering -Karosserie. 3.0. IEEE Computer Society. ISBN 978-0-7695-5166-1. Abgerufen 2. Januar, 2018.
- ^ Bourque, P.; Fairley, R. D., Hrsg. (2014). "Kapitel 4: Software -Tests" (PDF). SWEBOK V3.0: Leitfaden für die Software -Engineering -Karosseriekenntnis. IEEE. S. 4–1–4–17. ISBN 978-0-7695-5166-1. Abgerufen 13. Juli, 2018.
- ^ Dooley, J. (2011). Softwareentwicklung und berufliche Praxis. Apress. S. 193–4. ISBN 978-1-4302-3801-0.
- ^ Wiegers, K. (2013). Erstellen einer Software -Engineering -Kultur. Addison-Wesley. S. 211–2. ISBN 978-0-13-348929-3.
- ^ a b c Lewis, W.E. (2016). Softwaretests und kontinuierliche Qualitätsverbesserung (3. Aufl.). CRC Press. S. 92–6. ISBN 978-1-4398-3436-7.
- ^ Machado, P.; Vincenzi, a.; Maldonado, J.C. (2010). "Kapitel 1: Softwaretest: Ein Überblick". In Borba, P.; Cavalcanti, a.; Sampaio, a.; Woodcook, J. (Hrsg.). Testtechniken im Software -Engineering. Springer Science & Business Media. S. 13–14. ISBN 978-3-642-14334-2.
- ^ Clapp, J.A.; Stanten, S.F.; Peng, W.W.; et al. (1995). Software -Qualitätskontrolle, Fehleranalyse und Tests. Nova Data Corporation. p. 254. ISBN 978-0-8155-1363-6.
- ^ a b c "ISTQB CTFL Lehrplan 2018" (PDF). ISTQB - Internationaler Qualifikationsausschuss für Software -Tests. Archiviert (PDF) vom Original am 24. März 2022. Abgerufen 11. April, 2022.
- ^ Binder, Robert V. (1999). Testen objektorientierte Systeme: Objekte, Muster und Werkzeuge. Addison-Wesley Professional. p.45. ISBN 978-0-201-80938-1.
- ^ BEIZER, BORIS (1990). Software -Testtechniken (Zweite Ausgabe). New York: Van Nostrand Reinhold. S. 21, 430. ISBN 978-0-442-20672-7.
- ^ Xuan, Jifeng; Monperrus, Martin (2014). "Testfallreinigung zur Verbesserung der Fehlerlokalisierung". Proceedings des 22. ACM Sigsoft International Symposium on Foundations of Software Engineering - FSE 2014: 52–63. Arxiv:1409.3176. Bibcode:2014ArXIV1409.3176X. doi:10.1145/2635868.2635906. ISBN 978-1-4503-3056-5. S2CID 14540841.
- ^ Woods, Anthony J. (5. Juni 2015). "Operative Akzeptanz - Eine Anwendung des ISO 29119 -Software -Teststandards" (Weißes Papier). Capgemini Australia. Abgerufen 9. Januar, 2018.
- ^ Kaner, CEM; Bach, James; Pettichord, Bret (2001). Lektionen, die im Software-Test gelernt wurden: Ein kontextgetriebener Ansatz. Wiley. pp.31–43. ISBN 978-0-471-08112-8.
- ^ Ammann, Paul; Offutt, Jeff (28. Januar 2008). Einführung in Softwaretests. Cambridge University Press. p. 215. ISBN 978-0-521-88038-1. Abgerufen 29. November, 2017.
- ^ Danglot, Benjamin; Vera-Pérez, Oscar Luis; Baudry, Benoit; Monperrus, Martin (2019). "Automatische Testverbesserung mit DSPOT: Eine Studie mit zehn ausgereiften Open-Source-Projekten". Empirische Software -Engineering. 24 (4): 2603–2635. Arxiv:1811.08330. doi:10.1007/s10664-019-09692-y. S2CID 53748524.
- ^ Danglot, Benjamin; Vera-Perez, Oscar; Yu, zhongxing; Zaidman, Andy; Monperrus, Martin; Baudry, Benoit (November 2019). "Eine Snowballing -Literaturstudie zur Testverstärkung" (PDF). Zeitschrift für Systeme und Software. 157: 110398. Arxiv:1705.10692. doi:10.1016/j.js.2019.110398. S2CID 20959692.
- ^ "Standard -Glossar von Begriffen, die bei Software -Tests verwendet werden" (PDF). Version 3.1. Internationaler Qualifikationsausschuss für Software -Tests. Abgerufen 9. Januar, 2018.
- ^ O'Reilly, Tim (30. September 2005). "Was ist Web 2.0". O'Reilly Media. Abschnitt 4. Ende des Software -Release -Zyklus. Abgerufen 11. Januar, 2018.
- ^ Auerbach, Adam (3. August 2015). "Teil der Pipeline: Warum kontinuierliche Tests unerlässlich sind". Techwell Insights. Techwell Corp. Abgerufen 12. Januar, 2018.
- ^ Philipp-Edmonds, Cameron (5. Dezember 2014). "Die Beziehung zwischen Risiko und kontinuierlichem Test: Ein Interview mit Wayne Ariola". Stickyminds. Abgerufen 16. Januar, 2018.
- ^ Ariola, Wayne; Dunlop, Cynthia (Oktober 2015). DevOps: Schieben Sie Fehler schneller an Kunden? (PDF). Pacific Northwest Software Quality Conference. Abgerufen 16. Januar, 2018.
- ^ Auerbach, Adam (2. Oktober 2014). "Verschiebung nach links und an erster Stelle die Qualität". Techwell Insights. Techwell Corp. Abgerufen 16. Januar, 2018.
- ^ "Abschnitt 4.38". ISO/IEC/IEEE 29119-1: 2013-Software- und Systemtechnik-Softwaretest-Teil 1-Konzepte und Definitionen. Internationale Standardisierungsorganisation. Abgerufen 17. Januar, 2018.
- ^ "Globalisierung schrittweise: Der weltbereite Ansatz zum Testen. Microsoft Developer Network". Msdn.microsoft.com. Archiviert von das Original am 23. Juni 2012. Abgerufen 13. Januar, 2012.
- ^ ""QuickCheck: Ein leichtes Tool zum zufälligen Test von Haskell -Programmen"". Verfahren der fünften ACM Sigplan Internationalen Konferenz über funktionale Programmierung. ICFP '00: 268–279. 2000. doi:10.1145/351240.351266. ISBN 978-1-58113-202-1. S2CID 5668071.
- ^ "Lebenszyklus zum Software -Test". ETESTINGHUB. Testphase im Softwaretesting. Abgerufen 13. Januar, 2012.
- ^ Dustin, Elfriede (2002). Effektive Softwaretests. Addison-Wesley Professional. p. 3. ISBN 978-0-201-79429-8.
- ^ Brown, Chris; Cobb, Gary; Culbertson, Robert (12. April 2002). Einführung in schnelle Softwaretests.
- ^ a b "Was ist die testgetriebene Entwicklung (TDD)?". Agile Allianz. 5. Dezember 2015. Abgerufen 17. März, 2018.
- ^ "Testgesteuerte Entwicklung und kontinuierliche Integration für mobile Anwendungen". msdn.microsoft.com. Abgerufen 17. März, 2018.
- ^ Joshi, Shrinivas; Orso, Alessandro (Oktober 2007). "Scarpe: Eine Technik und ein Werkzeug für die selektive Erfassung und Wiederholung von Programmausführungen". 2007 IEEE International Conference über Software -Wartung: 234–243. doi:10.1109/icsm.2007.4362636. ISBN 978-1-4244-1255-6. S2CID 17718313.
- ^ Steven, John; Chandra, Pravir; Fleck, Bob; Podgurski, Andy (September 2000). "Jrapture: Ein Erfassungs-/Wiederholungswerkzeug für beobachtungsbasierte Tests". ACM Sigsoft Software Engineering Notizen. 25 (5): 158–167. doi:10.1145/347636.348993. ISSN 0163-5948.
- ^ Saieva, Anthony; Singh, Shirish; Kaiser, Gail (September 2020). "Ad -hoc -Testgenerierung durch binäres Umschreiben". 2020 IEEE 20. Internationale Arbeitskonferenz zur Quellcodeanalyse und -manipulation (Betrug). Adelaide, Australien: IEEE: 115–126. doi:10.1109/scam51674.2020.00018. ISBN 978-1-7281-9248-2. S2CID 219618921.
- ^ Tiwari, Deepika; Zhang, lang; Monperrus, Martin; Baudry, Benoit (2021). "Produktionsüberwachung zur Verbesserung von Testsuiten". IEEE -Transaktionen zur Zuverlässigkeit: 1–17. Arxiv:2012.01198. doi:10.1109/tr.2021.3101318. ISSN 0018-9529. S2CID 227248080.
- ^ Rodríguez, Ismael; Llana, Luis; Rabanal, Pablo (2014). "Eine allgemeine Testbarkeitstheorie: Klassen, Eigenschaften, Komplexität und Testreduzierungen". IEEE -Transaktionen auf Software -Engineering. 40 (9): 862–894. doi:10.1109/tse.2014.2331690. ISSN 0098-5589. S2CID 6015996.
- ^ Rodríguez, Ismael (2009). "Eine allgemeine Testbarkeitstheorie". Concur 2009 - Concurrency Theory, 20. Internationale Konferenz, Concur 2009, Bologna, Italien, 1. bis 4. September 2009. Proceedings. S. 572–586. doi:10.1007/978-3-642-04081-8_38. ISBN 978-3-642-04080-1.
- ^ IEEE (1998). IEEE -Standard für Software -Testdokumentation. New York: IEEE. ISBN 978-0-7381-1443-9.
- ^ Strom, David (1. Juli 2009). "Wir sind alle Teil der Geschichte". Software -Test & Performance Collaborative. Archiviert von das Original Am 31. August 2009.
- ^ Griffiths, M. (2005). "Lehren agiles Projektmanagement für das PMI". Agile Development Conference (ADC'05). IEEE.org. S. 318–322. doi:10.1109/adc.2005.45. ISBN 978-0-7695-2487-0. S2CID 30322339.
- ^ Willison, John S. (April 2004). "Agile Softwareentwicklung für eine agile Kraft". Übersprechen. STSC (April 2004). Archiviert von das Original am 29. Oktober 2005.
- ^ Ein Beispiel ist Mark Fewster, Dorothy Graham: Software -Testautomatisierung. Addison Wesley, 1999, ISBN978-0-201-33140-0.
- ^ "Stop29119". commonsensetesting.org. Archiviert von das Original am 2. Oktober 2014.
- ^ Paul Krill (22. August 2014). "Software -Tester balken bei ISO 29119 Standards Vorschlag". InfoWorld.
- ^ Kaner, Cem (2001). "NSF -Zuschussvorschlag," eine Grundlage für erhebliche Verbesserungen der Qualität der akademischen und kommerziellen Kurse bei Softwaretests zu schaffen "" (PDF).
- ^ Kaner, Cem (2003). Messung der Effektivität von Softwaretestern (PDF). Stern nach Osten. Abgerufen 18. Januar, 2018.
- ^ McConnell, Steve (2004). Code vollständig (2. Aufl.). Microsoft Press. p.29. ISBN 978-0-7356-1967-8.
- ^ Bossavit, Laurent (20. November 2013). "Die Kosten für Mängel: eine illustrierte Geschichte". Die Kobold von Software Engineering: Wie Folklore sich in Tatsache verwandelt und was zu tun ist. Leanpub.
- ^ Tran, Eushiuan (1999). "Überprüfung/Validierung/Zertifizierung" (Kursarbeit). Carnegie Mellon Universität. Abgerufen 13. August, 2008.
Weitere Lektüre
- Meyer, Bertrand (August 2008). "Sieben Prinzipien des Softwaretests" (PDF). Computer. Vol. 41, Nr. 8. S. 99–101. doi:10.1109/mc.2008.306. Abgerufen 21. November, 2017.
- Was ist Softwaretests? - Beantwortet von der Community von Software -Tester im Software -Testboard