Grundlegende Testtheorie

Testen ist keine exakte Wissenschaft. Es gibt keine klaren, gut etablierten Definitionen, die in einem Wörterbuch gesammelt und vor einem Interview gelernt werden können. Jedes IT-Projekt ist einzigartig und generiert eine Vielzahl unterschiedlicher, oft widersprüchlicher Informationen. Das Verständnis der Prozesse und Ansätze wird beim Testen wichtig, wie in jedem Beruf. Es ist wichtig, nicht nur den Namen dieses oder jenes Prozesses, die Art des Testens zu kennen, sondern auch, was es ist und warum es für das Projekt benötigt wird.

Kommen wir zu den Grundkonzepten.

Software-Tests sind eine Überprüfung der Konformität der tatsächlichen und erwarteten Ergebnisse des Programmverhaltens, die mit einer endlichen Reihe von Tests durchgeführt werden, die auf eine bestimmte Weise ausgewählt wurden.



Der Zweck des Testens besteht darin, zu überprüfen, ob die Software die Anforderungen erfüllt, das Vertrauen in die Qualität der Software zu gewährleisten und nach offensichtlichen Fehlern in der Software zu suchen, die identifiziert werden müssen, bevor die Benutzer des Programms sie finden.



Warum sind Softwaretests erforderlich?

• Der Testprozess stellt sicher, dass die Software die erforderlichen Leistungen erbringt.
• Dies reduziert die Codierungszyklen, indem Probleme früh in der Entwicklungsphase erkannt werden. Das frühzeitige Erkennen von Problemen in der Entwicklungsphase stellt den korrekten Einsatz von Ressourcen sicher und verhindert Kostensteigerungen.
• , .
• , , , .

• 1 — (Testing shows presence of defects). , , , . , , .
• 2 — (Exhaustive testing is impossible). , . , .
• 3 — (Early testing). , , .
• 4 — (Defects clustering). – . . , .
• 5 — (Pesticide paradox). , . « », , , , , .
• 6 — (Testing is concept depending). - . , , , , .
• Prinzip 7 - Missverständnisse über das Fehlen von Fehlern (Ende der Fehlerfreiheit Der Irrtum) . Das Fehlen festgestellter Mängel während des Tests bedeutet nicht immer, dass das Produkt zur Freigabe bereit ist. Das System sollte benutzerfreundlich sein und die Erwartungen und Bedürfnisse des Benutzers erfüllen.

Qualitätssicherung (QS) und Qualitätskontrolle (QC) - Diese Begriffe ähneln austauschbaren Begriffen, es besteht jedoch immer noch ein Unterschied zwischen Qualitätssicherung und Qualitätskontrolle, obwohl die Prozesse in der Praxis einige Ähnlichkeiten aufweisen.



QC (Qualitätskontrolle) - Produktqualitätskontrolle - Analyse der Testergebnisse und Qualität neuer Versionen des freigegebenen Produkts.

Zu den Aufgaben der Qualitätskontrolle gehören:

• Überprüfung der Softwarebereitschaft für die Freigabe;
• Überprüfung der Einhaltung der Anforderungen und der Qualität dieses Projekts.

QA (Qualitätssicherung) - Produktqualitätssicherung - Erkundung von Möglichkeiten zur Änderung und Verbesserung des Entwicklungsprozesses, Verbesserung der Kommunikation im Team, wobei das Testen nur einer der Aspekte der Qualitätssicherung ist.



Zu den Zielen der Qualitätssicherung gehören:

• Überprüfung der technischen Eigenschaften und Softwareanforderungen;
• Risikoabschätzung;
• Planen von Aufgaben zur Verbesserung der Produktqualität;
• Vorbereitung von Dokumentation, Testumgebung und Daten;
• testen;
• Analyse der Testergebnisse sowie Erstellung von Berichten und anderen Dokumenten.

Verifikation und Validierung sind zwei Konzepte, die eng mit Test- und Qualitätssicherungsprozessen verbunden sind. Leider sind sie oft verwirrt, obwohl die Unterschiede zwischen ihnen ziemlich bedeutend sind.



Bei der Überprüfung wird ein System bewertet, um festzustellen, ob die Ergebnisse der aktuellen Entwicklungsphase die zu Beginn formulierten Bedingungen erfüllen.



Die Validierung ist die Feststellung, ob die entwickelte Software den Erwartungen und Bedürfnissen des Benutzers und seinen Anforderungen an das System entspricht.



: 310, , «», . , , «». , . , , , . «» — , «» — . , .







Die Dokumentation, die für Softwareentwicklungsprojekte verwendet wird, kann grob in zwei Gruppen unterteilt werden:

1. Projektdokumentation - enthält alles, was mit dem gesamten Projekt zu tun hat.
2. Die Produktdokumentation ist Teil der separat zugewiesenen Konstruktionsdokumentation, die sich direkt auf die entwickelte Anwendung oder das entwickelte System bezieht.

Testphasen:

1. Produktanalyse
2. Mit Anforderungen arbeiten
3. Entwicklung einer Teststrategie und Planung von Qualitätskontrollverfahren
4. Erstellung der Testdokumentation
5. Prototypentest
6. Grundlegende Tests
7. Stabilisierung
8. Ausbeutung

Softwareentwicklungsphasen - Die Phasen, die Softwareentwicklungsteams durchlaufen, bevor das Programm einer Vielzahl von Benutzern zur Verfügung steht.



Das Softwareprodukt durchläuft die folgenden Phasen:

1. Analyse der Projektanforderungen;
2. Design;
3. Implementierung;
4. Produkttest;
5. Implementierung und Unterstützung.

Bedarf

Anforderungen sind eine Spezifikation (Beschreibung) dessen, was implementiert werden muss.

Die Anforderungen beschreiben, was implementiert werden muss, ohne die technische Seite der Lösung zu beschreiben.



Anforderungen an Anforderungen:

1. Korrektheit - Jede Anforderung muss die gewünschte Funktionalität genau beschreiben.
2. Überprüfbarkeit - Die Anforderung sollte so formuliert sein, dass eindeutig überprüft werden kann, ob sie erfüllt ist oder nicht.
3. Vollständigkeit - Jede Anforderung muss alle erforderlichen Informationen enthalten, die der Entwickler zur Implementierung der Funktionalität benötigt.
4. Eindeutig - Die Anforderung wird ohne nicht offensichtliche Abkürzungen und vage Formulierungen beschrieben und erlaubt nur eine eindeutige Interpretation des Geschriebenen.
5. — .
6. — ( ). .
7. — .
8. — .
9. — , .

Defekt (Fehler) - Abweichung des tatsächlichen Ergebnisses vom erwarteten.



Ein Fehlerbericht ist ein Dokument, das die Situation beschreibt, die zur Entdeckung eines Fehlers geführt hat, und die Gründe und das erwartete Ergebnis angibt.



Fehlerberichtattribute:

1. Eindeutige Kennung (ID) - wird vom System automatisch vergeben.
   
   
2. Thema (Kurzbeschreibung, Zusammenfassung) - eine kurz formulierte Essenz des Defekts gemäß der Regel „Was? Wo? Wann?"
3. Beschreibung - eine breitere Beschreibung des Wesens des Defekts (optional angegeben).
4. Reproduktionsschritte - eine sequentielle Beschreibung der Aktionen, die zur Identifizierung des Fehlers geführt haben. Es ist notwendig, so detailliert wie möglich zu beschreiben und die spezifischen Eingabewerte anzugeben.
   
   
5. (Actual result) — , , .
6. (Expected result) — , , .
   
   
7. (Attachments) — , -.
8. (, Severity) — .
9. (, Priority) — .
10. (Status) — . - .
11. (environment) – , .

Severity vs Priority

Der Schweregrad gibt den Grad des Schadens an, der durch das Vorliegen eines Mangels am Projekt verursacht wurde. Der Schweregrad wird vom Tester angezeigt.



Bewertung des Schweregrads von Fehlern:

• Blocking (S1 - Blocker)
  
  -Tests eines wesentlichen Teils der Funktionalität sind überhaupt nicht verfügbar. Ein Blockierungsfehler, der die Anwendung funktionsunfähig macht, wodurch eine weitere Arbeit mit dem zu testenden System oder seinen Schlüsselfunktionen unmöglich wird.
• (S2 – Critical)
  
  , -, , , , - , workaround ( / ), .
• (S3 – Major)
  
  - /-, , workaround, - . visibility – , , , .
• (S4 – Minor)
  
  GUI, , . , .
• Trivial (S5 - Trivial)
  
  fast immer Fehler in der GUI - Tippfehler im Text, Nichtübereinstimmung von Schriftart und Farbton usw. oder ein schlecht reproduzierbarer Fehler, der keine Geschäftslogik betrifft, ein Problem mit Bibliotheken oder Diensten von Drittanbietern, a Problem, das keinen Einfluss auf die Gesamtqualität des Produkts hat.

Die Priorität gibt an, wie schnell der Fehler behoben werden soll. Die Priorität wird vom Manager, Teamleiter oder Kunden festgelegt.



Fehlerprioritätsabstufung (Priorität):

• P1 Hoch Der
  
  Fehler sollte so schnell wie möglich behoben werden. Ihre Präsenz ist für das Projekt von entscheidender Bedeutung.
• P2 Mittel Der
  
  Fehler muss korrigiert werden, sein Vorhandensein ist nicht kritisch, muss aber behoben werden.
• P3 (Low)
  
  , .

:

• (epic) — , .
• (story) — (), 1 .
• (task) — , .
• - (sub-task) — / , .
• (bug) — , .

• (Development Env) – , , , Unit-. .
• (Test Env) – . . , , . .
• (Integration Env) – , . end-to-end , , . , . – , .
• (Preview, Preprod Env) – , : , - , . , «». end-to-end , / (User Acceptance Testing (UAT)), L3 L2 DryRun ( ). L3 .
• (Production Env) – , . L2 , , . L3.

• Pre-Alpha: . . . .
• Alpha: . — . - . . .
• Beta: . , .
• Release Candidate (RC) : Basierend auf dem Beta-Test-Feedback nehmen Sie Softwareänderungen vor und möchten Fehlerbehebungen testen. An dieser Stelle möchten Sie keine drastischen Änderungen an der Funktionalität vornehmen, sondern nur nach Fehlern suchen. RC kann auch für die Öffentlichkeit freigegeben werden.
• Release: Alles funktioniert, Software wird für die Öffentlichkeit freigegeben.

Die wichtigsten Arten von Softwaretests

Eine Art von Test ist eine Reihe von Aktivitäten, die darauf abzielen, die festgelegten Eigenschaften eines Systems oder seines Teils basierend auf bestimmten Zielen zu testen.

1. Klassifizierung durch Ausführen von Code zur Ausführung:
   
   
   • — . , . «». — .
   • — . , / . — , . , , .
   
   
   
2. :
   
   
   • — , , // .
   • — , White Box Black Box . , .
   • — , – , .
   
   
   
3. :
   
   
   • — - ( , subprograms, subroutines, ) . , .
   • — , ( , ).
   • — , , .
   • — , - .
   
   
   
4. :
   
   
   • .
   • .
   
   
   
5. 
   
   
   • — , .
   • — , .
   
   
   
6. :
   
   
   • (smoke test) — , , .
   • (critical path) — , .
   • (extended) — .
   
   
   
7. :
   
   
   • - — . - .
   • - — . , .
   
   
   
8. :
   
   
   • (functional testing) — ( ).
   • (non-functional testing) — , , , « ».
     
     
     1. (performance testing) — , , .
     2. (load testing) — , , .
     3. (scalability testing) — .
     4. (volume testing) — , .
     5. (stress testing) — , .
     6. (installation testing) — , , .
     7. (GUI/UI testing) — .
     8. (usability testing) — , .
     9. (localization testing) — (, ).
     10. (security testing) — , .
     11. (reliability testing) — .
     12. Regressionstests - Testen zuvor getesteter Funktionen nach Änderungen am Anwendungscode, um sicherzustellen, dass diese Änderungen keine Fehler in Bereichen hervorrufen, die nicht geändert wurden.
     13. Erneutes Testen / Bestätigungstest - Testen, bei dem Testskripte ausgeführt werden, bei denen Fehler während des letzten Durchlaufs festgestellt wurden, um den Erfolg der Behebung dieser Fehler zu bestätigen.
   
   
   

Testdesign ist die Phase des Softwaretests, in der Testfälle (Testfälle) entworfen und erstellt werden.



Testdesign-Techniken:

1. (equivalence partitioning) — , , ( ) .
2. (boundary value testing) — () .
3. (pairwise testing) — , -.
4. (State-Transition Testing) — .
5. (Decision Table Testing) — , , .
6. (Exploratory Testing) — , -: .
7. (Domain Analysis Testing) — , .
8. (Use Case Testing) — Use Case ( — ).

White-Box- Test ist eine Softwaretestmethode, bei der davon ausgegangen wird, dass die interne Struktur / das Gerät / die Implementierung des Systems dem Tester bekannt ist.



White-Box-Tests sind laut ISTQB:

- Tests auf der Grundlage einer Analyse der internen Struktur einer Komponente oder eines Systems;

- Testdesign basierend auf der White-Box-Technik - ein Verfahren zum Schreiben oder Auswählen von Testfällen basierend auf einer Analyse der internen Struktur eines Systems oder einer Komponente.

Warum White Box? Das für den Tester getestete Programm ist eine transparente Box, deren Inhalt er perfekt sieht.



Gray-Box-Test- Softwaretestmethode, die eine Kombination von White-Box- und Black-Box-Ansätzen voraussetzt. Das heißt, wir kennen die interne Struktur des Programms nur teilweise.



Black-Box-Tests - auch als spezifikationsbasierte Tests oder Verhaltenstests bezeichnet - sind Testtechniken, die sich ausschließlich auf die externen Schnittstellen des zu testenden Systems stützen.



Laut ISTQB sind Black-Box-Tests:

- sowohl funktionale als auch nicht funktionale Tests, bei denen die interne Struktur einer Komponente oder eines Systems nicht bekannt ist;

- Testdesign basierend auf der Black-Box-Technik - ein Verfahren zum Schreiben oder Auswählen von Testfällen basierend auf einer Analyse der funktionalen oder nicht funktionalen Spezifikation einer Komponente oder eines Systems, ohne deren interne Struktur zu kennen.

Testdokumentation

Ein Testplan ist ein Dokument, das den gesamten Testumfang beschreibt, von der Beschreibung der Einrichtung, der Strategie, des Zeitplans, der Kriterien für den Beginn und das Ende der Tests bis hin zu den für den Betrieb erforderlichen Geräten, Spezialkenntnissen und der Risikobewertung mit Optionen für ihre Auflösung. ...



Der Testplan sollte die folgenden Fragen beantworten:

• Was soll getestet werden?
• Was wirst du testen?
• Wie wirst du testen?
• Wann wirst du testen?
• Teststartkriterien.
• Testbeendigungskriterien.

Die Hauptpunkte des Testplans:



Der IEEE 829-Standard listet die Punkte auf, aus denen der Testplan bestehen sollte:

a) Testplankennung;

b) Einführung;

c) Testgegenstände;

d) zu testende Merkmale;

e) nicht zu testende Merkmale;

f) Ansatz;

g) Pass / Fail-Kriterien für Artikel;

h) Suspendierungskriterien und Wiederaufnahmevoraussetzungen;

i) Prüfergebnisse;

j) Testaufgaben;

k) Umweltbedürfnisse;

l) Verantwortlichkeiten;

m) Personal- und Schulungsbedarf;

n) Zeitplan;

o) Risiken und Eventualverbindlichkeiten;

p) Zulassungen.



Eine Checkliste ist ein Dokument, das beschreibt, was getestet werden soll. Die Checkliste kann völlig unterschiedliche Detaillierungsgrade aufweisen.



Meistens enthält die Checkliste nur Aktionen ohne das erwartete Ergebnis. Die Checkliste ist weniger formalisiert.



Ein Testfall ist ein Artefakt, das eine Reihe von Schritten, spezifischen Bedingungen und Parametern beschreibt, die zum Testen der Implementierung einer zu testenden Funktion oder eines Teils davon erforderlich sind.



Testfallattribute:

• Voraussetzungen - Eine Liste von Aktionen, die das System in einen Zustand bringen, der für die Durchführung einer Basisprüfung geeignet ist. Oder eine Liste von Bedingungen, deren Erfüllung anzeigt, dass sich das System in einem Zustand befindet, der für die Durchführung des Haupttests geeignet ist.
• Schritte - Eine Liste von Aktionen, mit denen das System von einem Zustand in einen anderen übertragen wird, um ein Ergebnis zu erzielen, auf dessen Grundlage geschlossen werden kann, dass die Implementierung die Anforderungen erfüllt.
• Erwartetes Ergebnis - was sie eigentlich bekommen sollten.

Zusammenfassung

Versuchen Sie, die Definitionen zu verstehen, nicht auswendig zu lernen. Und wenn Sie eine Frage haben, können Sie uns jederzeit im @ qa_chillout- Telegrammkanal fragen .