TESTWERKZEUGE

HANDBUCH
Prüfung:
 Der Prozess der Identifizierung der Fehler in einer Software (Projekt/Produkt) wird als
„Testen“ bezeichnet.
 Der Testingenieur muss überprüfen (validieren), ob die entwickelte Software den
Anforderungen des Kunden entspricht oder nicht. Er ist verantwortlich für die Lieferung
von Qualitätssoftware an den Kunden.

**Hinweis: Die Hauptverantwortung des Testingenieurs besteht darin, zu überprüfen(zu

validieren), ob die entwickelte Anwendung (Software) für den Endbenutzer nützlich ist oder
nicht.

Bug: Die Abweichung von der Anforderung wird als Bug oder Defekt bezeichnet.

Qualität:Die Begründung aller Kundenanforderungen mit Benutzerfreundlichkeit und

Sicherheit wird als Qualität bezeichnet.
 Nehmen wir ein Beispiel: Geliefert/Freigegeben

Business Analyst Erforderliches Dokument Unternehmen EntwicklerProjekt/Produkt

Ich Architekt Plan Erbauer Konstrukteur Startseite

Auftraggeber

Plan
Vorgesetzter

Testingenieur

Projekt:
Es wird auf der Grundlage der Anforderungen des Kunden entwickelt; sobald es entwickelt ist,
wird es an den Kunden geliefert. Basierend auf den Kundenbedürfnissen werden die
Teammitglieder (Endbenutzer) es verwenden.
Bsp.: Spicejet.com, selen4testing.com, Eigenes Haus mit unseren Anforderungen bauen.
Produkt:
Es wird auf der Grundlage der Anforderungen des Unternehmens entwickelt. Sobald es
entwickelt ist, wird es auf den Markt gebracht, basierend auf den Kundenbedürfnissen, die sie
für das Produkt auswählen.
Beispiel:Mobile App, Taschenrechner, Facebook, Yahoo, MS Office, Mac-Betriebssystem,
Windows-Betriebssystem, Gmail usw.
Testarten:

Testwerkzeuge

Funktionstests Nichtfunktionstests

Lasttests

Manuelle Tests Automatisierungstests Leistungstests

Selen, Stresstest für Läufer gewinnen

QTP-, RFT-, Silktest-, Wasser-, Watin-Einweichprüfung

Internetbasierte Anwendungen:
Auf diese Anwendungen kann weltweit mit einer unbegrenzten Anzahl von Benutzern
zugegriffen werden.

Beispiel: Gmail, Facebook, Selen-4-Test

Intranet-basierte Anwendungen:
Auf diese Anwendungen kann auch weltweit zugegriffen werden, jedoch mit einer begrenzten
Anzahl von Benutzern.

Beispiel: Anwendungen, die auf eine bestimmte Organisation beschränkt sind.

Ausschreibung des Projektes:

Beteiligte Rollen:
1. Marketing Business Analyst(BA)
2. Engagement Manager(EM)

 Marketing Business Analyst(BA):

 Marketing BA wird den Auftraggeber treffen und den Auftraggeber mit dem Angebot
überzeugen. Sobald der Kunde mit dem Angebot zufrieden ist, unterzeichnen der Kunde und
das Unternehmen das Projekt.

Sign Off:

Die offizielle Vereinbarung zwischen Auftraggeber und Unternehmen über die

Projektabwicklung wird als „Sign Off“ bezeichnet.

KickOff-Meeting:

Sobald das Projekt abgesegnet ist, wird das Unternehmen zu einem "Kickoff" -Treffen
gehen. Es ist ein schnelles Treffen, an dem das gesamte hochrangige Management
teilnimmt und das Projekt, den Kunden und den Projektmanager für das Projekt
ankündigt. Der Projektleiter ist verantwortlich für SDLC.

 Engagement Manager(EM):

Der Engagement Manager ist dafür verantwortlich, die Beziehung zwischen dem Kunden und
dem Unternehmen aufrechtzuerhalten. Er fungiert als Brücke zwischen dem Kunden und dem
Unternehmen.

Ausschreibung des Projektes

1 Cr
Auftraggeber
Über das 1 Jahr
Unternehmen

Geschichte
Vorschlag Abmelden
Schätzungen

Zeit & Kosten

Kick-off-Meeting
C1 C2 C3

2cr 1.5 cr 1 cr Projektleiter

2 Jahre 1,5 Jahre 1 Jahr

Projekthierarchie oder Benennungshierarchie oder Rollenhierarchie

LLM: Low Level Management

MLM: Mittleres Management

HLM: High Level Management

SOFTWAREENTWICKLUNGSLEBENSZYKLUS(SDLC):
Es besteht aus den folgenden Phasen,

1. Anforderungsphase
 2. Analysephase
3. Designphase
4. Codierungsphase
5. Testphase
6. Liefer- und Wartungsphase.

PIN: Projektinitiierungs-/Einweihungsnotiz:

Es handelt sich um eine E-Mail, die vom Projektmanager vorbereitet wird und das Start- und
Enddatum des Projekts enthält. Die Mail wird an den Auftraggeber und das übergeordnete
Management versendet.
PIN zeigt den Start des Projekts an.

1) Anforderungsphase:
Rollen:Business Analyst
Engagement-Manager
Projektmanager

 BA ist dafür verantwortlich, alle Anforderungen in einem

Anforderungsvorlagendokument (RTD) zu sammeln.
 Sobald alle Anforderungen in der Anforderungsvorlage gesammelt sind, werden sie die
Anforderungen abzeichnen,
 Das abgezeichnete Dokument wird als SRS (Software/System Requirements
Specification) oder BRS (Business Requirement Specification) oderFRS (Functional
Requirement Specification) oderBDD (Business Design Document) oder BD (Business
Document) bezeichnet.
 Sobald das SRS-Dokument baselined ist, ist die BA für POC (Proof of Concept)
verantwortlich.
 Während des POC ist die BA für die Entwicklung des Prototyps verantwortlich und wird
dem Kunden vorgestellt.

Prototyp: Es ist eine grobe und schnell entwickelte Beispielanwendung; sie enthält keine
der tatsächlichen Funktionalitäten. Es beschreibt einfach, wie das Projekt sein wird und
wie es angezeigt wird. Der Hauptzweck des Prototyps besteht darin, alle Anforderungen
richtig zu erfassen und alle Anforderungen richtig zu verstehen.

 Der Engagement Manager ist dafür verantwortlich, die Beziehung zwischen dem Kunden
und dem Unternehmen aufrechtzuerhalten. Er wird sich auch auf den zusätzlichen
Bedarf, die zusätzlichen Kosten und die zusätzliche Zeit des Projekts konzentrieren.
 Der Projektmanager ist für die Überwachung der Phasen verantwortlich und hilft sowohl
BA als auch EM, ihre Aktivitäten ordnungsgemäß abzuschließen.
 Hinweis: Das Ergebnis der Anforderungsphase ist SRS und Prototyp

2) Analysephase:Analyse der Anforderungen.

Rollen:High Level Management
Mittlere Führungsebene
Projektmanager
BA

 Alle oben genannten Rollen versammeln sich zu einem Meeting und führen die
folgenden Aktivitäten durch
a. Machbarkeitsstudie
b. Technologieauswahl
c. Ressourcenplan
d. H&S-Plan
a. Machbarkeitsstudie: Machbar bedeutet möglich oder nicht. Die oben
genannten Rollen nehmen jede Anforderung im SRS-Dokument auf. Die
Anforderungen werden analysiert und sie werden ermitteln, ob es möglich ist,
sie zu entwickeln oder nicht. Wenn es möglich ist, sie zu entwickeln, werden sie
ermitteln, wie viel Zeit für die Entwicklung, das Testen und die Bereitstellung an
den Kunden benötigt wird. Wenn eine Anforderung nicht realisierbar ist, wird sie
dem Kunden mitgeteilt.
b. Technologieauswahl: Die Liste der Technologien wie Java, .net, MSSQL, Oracle,
Selen usw., die für die Projektentwicklung, das Testen und die Lieferung an den
Kunden benötigt werden, wird hier beschrieben. Basierend auf den Technologien
werden sie die Ressourcen einstellen.
c. Ressourcenplan:Die Anzahl der Ressourcen wie Entwickler, Testingenieure,
Datenbankingenieure, die für die Projektentwicklung und das Testen benötigt
werden, wird hier beschrieben.
d. Hardware- und Softwareplan:Die Anzahl der Hardware wie Desktops, Laptops,
Handys, Drucker usw., die für das Projekt benötigt werden, wird hier
beschrieben.

 Alle oben genannten Punkte werden in einem Dokument namens Projektplan

dokumentiert. Es wird zur Überprüfung an den Kunden gesendet.

3) Designphase:
Rollen: Architekt/Chefarchitekt
Business Analyst (BA)
Projektmanager

 Der Architekt überprüft alle Anforderungen des SRS-Dokuments und prüft, ob Klärungen
zu den Anforderungen erforderlich sind. Die BA ist dann dafür verantwortlich, alle
ungeklärten Anforderungen zu bereinigen.
 Sobald der Architekt sich über alle Anforderungen im Klaren ist, teilt er die
Anforderungen in mehrere Module und Untermodule auf. Die Gruppe der zugehörigen
Anforderungen wird als "Modul" bezeichnet.
 Sobald alle Module aufgeteilt sind, stellt er das Architekturdiagramm (Flussdiagramm)
des gesamten Projekts mit Hilfe von UML (Unified Modeling Language) bereit
 Alle oben genannten Punkte werden in einem Dokument namens Designdokument oder
SRS dokumentiert.

4) Codierphase:
Rollen: Entwicklungsteam
Prüfteam
BA
Projektmanager
  Sobald die Module nach Architekten aufgeteilt sind, werden sie sowohl den Entwicklern
als auch dem Testteam zugewiesen.
 Die Entwickler sind dafür verantwortlich, den Quellcode für die Module zu entwickeln.
Sobald der Quellcode stabil ist, checken sie den Quellcode in das zentrale Repository
ein.
 Der Entwicklungsleiter überprüft den Quellcode auf seinem lokalen System, dann
erstellt der Entwicklungsleiter den Quellcode und der Build wird zum Testen an das
Testteam freigegeben.

Zentrales Repository:

Repository bezeichnet einen Speicherordner. Zentrales Repository bezeichnet den Ordner,

auf den alle Ressourcen in der Organisation gemeinsam zugreifen können. Es enthält alle
sicheren Dateien.
Beispiel: SVN- Unterversion
VSS- Visuelle Quelle sicher
TFS- Team Foundation Server
CVS- System mit gleichzeitiger Version
Perforce, GitHub
Einchecken:Der Vorgang des Hochladens der Dateien vom lokalen System in das zentrale
Repository wird als Einchecken oder Commit bezeichnet.

Auschecken:Der Vorgang des Herunterladens der Dateien aus dem zentralen Repository auf das
lokale System wird als Auschecken bezeichnet.

Build:Der Prozess der Konvertierung des Quellcodes in ausführbaren Code wird als Build
bezeichnet.
 5) Testphase:
Rollen: Testingenieure
Entwicklerteam
Business Analyst (BA)
Projektmanager

 Sobald das SRS-Dokument auf der Basis ausgekleidet (abgeschlossen) ist, wird es sowohl
an das Entwicklungsteam als auch an das Testteam gesendet.
 Das Entwicklungsteam ist dafür verantwortlich, das SRS-Dokument zu überprüfen, zu
verstehen und den Build zu entwickeln.
 Das Testteam ist auch dafür verantwortlich, das SRS-Dokument zu überprüfen. Wenn
bei der Überprüfung unklare Anforderungen (Zweifel) festgestellt werden, werden diese
in das Dokument „Überprüfungsbericht(RR)“ aktualisiert.
 Der Überprüfungsbericht wird an den Teamleiter gesendet, wo er alle
Überprüfungsberichte in einem einzigen Dokument namens "Konsolidierter
Überprüfungsbericht (CRR)" konsolidiert (ein Dokument erstellen) und an die BA
gesendet wird.
 BA ist dafür verantwortlich, alle unklaren Anforderungen zu überprüfen und er wird die
Klarstellungen liefern, dann wird der "Aktualisierte Überprüfungsbericht(URR)" an das
Testteam gesendet
 Das Testteam wird das SRS-Dokument erneut mit Klarstellungen überprüfen.
 Sobald das Testteam sich über alle Anforderungen im Klaren ist, wird es die
Testfallvorlage nehmen und die Testfälle für alle Anforderungen schreiben.
 Die Testfalldokumente werden an die BA gesendet. Wo er es überprüft und
kommentiert, ob neue Testfälle hinzugefügt werden müssen.
 Basierend auf den Kommentaren von BA wird das Testteam die Testfälle aktualisieren.
 Sobald die Testfälle ausgekleidet (abgeschlossen) sind, werden sie zur endgültigen
Überprüfung an den Kunden gesendet.
 Sobald der Build für das Testteam freigegeben ist, werden alle Testfälle auf dem Build
ausgeführt.
 Wenn beim Testen des Builds Fehler identifiziert werden, wird dies dem
Entwicklungsteam gemeldet (gesendet). Der Entwickler wird es reparieren und zum
Testen an das Testteam zurücksenden.
 Der Testingenieur wird testen, ob der Fehler wirklich behoben ist oder nicht, und
gleichzeitig wird er nach anderen Fehlern suchen.
 Wenn es identifiziert wird, wird es dem Entwickler gemeldet.
 Der gleiche Prozess wird fortgesetzt, bis der Build stabil ist (fehlerfrei oder keine Fehler).
 Der stabile Build wird an den Kunden geliefert.

6) Lieferung und Wartung:

Rollen: Testingenieure
Entwicklerteam
Business Analyst (BA)
Projektmanager
Auftraggeber
Lieferung:Sobald der Build in der Testumgebung stabil ist, sendet das Testteam (TL) eine E-
Mail an den Projektmanager, in der es angibt, dass der Build stabil ist, und der Projektmanager
liefert den Build an den Kunden.

 Der Kunde wird die Build-in-Phasenumgebung bereitstellen und Tests durchführen.

 Stage Environment ist die gemeinsame Umgebung, in der sowohl das Testteam als auch
das Team des Kunden die Anwendung testen, bevor sie live geht. Es wird auch als
Vorproduktionsumgebung bezeichnet.
 Sobald der Build in der Phasenumgebung stabil ist, stellt der Kunde den Build in der Live-
oder Produktionsumgebung bereit.
 Sobald der Build erfolgreich in der Produktions-/Live-Umgebung bereitgestellt wurde,
können wir zu dem Schluss kommen, dass das Projekt erfolgreich an den Kunden
geliefert wurde.

Wartung:
"Live" bedeutet, dass der Kunde oder die Endbenutzer die Anwendung verwenden. Die
Wartung wird fortgesetzt, solange die Anwendung live ist.

MaintenancePhase Tat
Beheben der Bugs,
Bearbeitungszeit
Auftraggeber CRs
BA/PM/TL
3 Bugs
(Erweiterung)
3 CRs Unternehmen

12/24 Stunden 3 Bugs – 3 Tage

3 CRS – 4 Tage
 7 Tage

 Sobald das Projekt erfolgreich an den Kunden geliefert und erfolgreich in der
Live-/Produktionsumgebung bereitgestellt wurde, wird die Wartung des Projekts
gestartet.
 Während der Wartung ist das Unternehmen für zwei Tätigkeiten verantwortlich.
a) Die Fehler beheben.
b) Aktualisierung der Erweiterungen/Change Requests CRs.
 Solange das Projekt live ist, wird die Wartung des Projekts fortgesetzt.
 Gemäß der Unterzeichnung (Vereinbarung) wird das Unternehmen zunächst eine
kostenlose Wartung von bis zu 3 bis 5 Jahren anbieten (dies hängt von der
Projektunterzeichnung ab).
 Nach Ablauf der kostenlosen Wartungsperiode verlängert der Auftraggeber den
Wartungsvertrag.
 Wann immer der Kunde Fehler und CRS sendet, muss vom Unternehmen jemand
(Entwickler, BA, Tester) die Bestätigungs-E-Mail innerhalb der vereinbarten Tat
( Bearbeitungszeit) an den Kunden senden. Dies kann 12/24 Stunden betragen.
 Die E-Mail enthält die Anzahl der Stunden, die wir benötigen, um den neuen Build zu
reparieren und an den Kunden zu liefern.
 Solange das Projekt live ist, wird die Wartung des Projekts fortgesetzt

F. Welche Art von Anwendungen haben Sie getestet?

ANWENDUNGSARTEN:

Es gibt drei Arten von Anwendungen, die getestet werden können;

1) Web-Anwendungen
2) Desktop-Anwendungen
3) Mobile Anwendungen
 1) WEBANWENDUNGEN:

Auf diese Anwendungen wird mit Hilfe eines Browsers zugegriffen.

Es handelt sich um zwei Typen
a) 3-Tier-Architekturanwendungen.
b) N-Tier-Architekturanwendungen.

Umgebung/System:

Alle Anwendungen sind eine Kombination der Umgebung.

Die Umgebung enthält:
1. Präsentationsschicht.
2. Business Layer.
3. Datenbankschicht.
UMWELT

ANWENDUNG PRÄSENTATION/KUNDENSCHICHT

Antwort anfordern
SERVER
BUSINESS- LAYER

Antwort anfordern
DATENBANK
DATENBANK-LAYER

1. Präsentationsschicht:

Das Frontend, auf das der Endbenutzer zugreifen wird, wird als
Präsentationsschicht/Client bezeichnet.

2. Business Layer:

Es ist der Server, der für die Zustellung der Anfrage verantwortlich ist. Es
bedeutet, dass es die Anfrage von der Anwendung nimmt, sie an die Datenbank
sendet, die Antwort von der Datenbank nimmt und sie an die Anwendung
zurückschickt. Der gesamte Prozess wird als Zustellung der Anfrage bezeichnet.

Beispiel: Tomacat, JBoss, Weblogic, WebSphere, IIS

3. Datenbankschicht:

Die Datenbankschicht ist dafür verantwortlich, die Daten in Form von Tabellen zu
speichern.
Beispiel: MS SQL, My SQL, ORACLE
a) 3-Tier-Architekturanwendungen:

In 3-Tier-Architekturanwendungen sind die oben genannten 3 Layer in drei verschiedenen

Maschinen (Layers) verfügbar, die wir als Tiers bezeichnen werden. Daher werden sie als 3-
Tier-Architekturanwendungen bezeichnet.

Beispiel: PL - Browser
SErver - Tomacat
Datenbank - Oracle

b) N- Tier-Architekturanwendungen:

Es ist wie bei 3-Tier-Architekturanwendungen, basierend auf der Anzahl der Benutzer (Last),
wir werden eine größere Anzahl von Servern und Datenbanken haben.

Basierend auf der Lastanforderung wird die Geschäftslogik auf die Server und DBs verteilt.
Daher werden wir es als verteilte Umgebungsanwendungen bezeichnen.

PL PL PL

Server Server Server

BL

DB DB DB

DBL

2) DESKTOP-ANWENDUNGEN:
Auf diese Anwendungen kann ohne Browser zugegriffen werden.
Bsp.: Skype, Taschenrechner, MS Office, VLC-Player usw.
Es gibt zwei Arten:
 1-stufig
 2-stufig

 1-Tier:

Diese Anwendungen sind auf ein bestimmtes System (PC) beschränkt. Alle 3 Schichten PL,
BL und DBL sind nur in diesem spezifischen System verfügbar.
Beispiel: VLC-Player , Calc

 2-stufig:

Die Präsentationsschicht wird in einem System verfügbar sein, die Geschäftsschicht und die
Datenbankschicht werden in einem anderen System verfügbar sein, mit Hilfe von LAN/WAN
können wir von mehreren Systemen auf diese Anwendungen zugreifen. Daher werden wir
es als 2-Tier-Anwendungen bezeichnen. Es wird auch als Client-Server-Architektur-
Anwendungen bezeichnet.
Bsp.: Skype

HINWEIS:Für Desktop-Anwendungen müssen wir die Anwendung auf Benutzer-/Clientseite

installieren, dann können nur wir darauf zugreifen. Um Tests für Desktop-Anwendungen
durchzuführen, müssen wir sie sowohl auf dem Client als auch auf dem Server durchführen.

Für die Webanwendung müssen wir sie nur im Client testen.

(BL)

Server + DBL

App
 LAN WAN LAN

M1 M2 M3
PL

3) MOBILE ANWENDUNGEN:
Die Anwendungen, auf die auf der mobilen Plattform zugegriffen werden kann,
werden als mobile Anwendungen bezeichnet.
Beispiel: Android, IOS, Blackberry, Windows usw.

Es gibt drei Arten von

a. Native Anwendungen
b. Web-Anwendungen
c. Hybridanwendungen

a. Native Anwendungen:

Auf diese Anwendungen kann ohne Browser zugegriffen werden.

Beispiel: Viber, Anruffunktionalität, Nachricht, Uhr usw.

b. Web-Anwendungen:

Auf diese Anwendungen kann mit Hilfe des Browsers im Handy zugegriffen werden.
Beispiel: selenium4testing.com

c. Hybridanwendungen:

Diese Anwendungen können sowohl ohne Browser als auch mit Browsern aufgerufen werden .
Beispiel: Gmail/Gmail-App, Facebook/Facebook-App, Banking-Websites/-App usw.

HINWEIS:ForWeb Applications ist nicht erforderlich, um die Anwendung auf

Benutzer-/Clientseite zu installieren, da wir mit Hilfe des Browsers darauf zugreifen können. Um
Tests für Webanwendungen durchzuführen, müssen wir sie nur im Client durchführen.

TESTMETHODEN:
F:Wer ist für die Prüfung verantwortlich? Auf welcher Ebene wird die Test Engg.
Es gibt drei Arten von

a. Black-Box-Tests
b. White-Box-Tests
c. Graukastenprüfung

a. Black-Box-Tests:

Wenn die Ressource Tests für den funktionalen Teil der Anwendung durchführt, wird sie
als "Black-Box-Tester" behandelt.

Funktionsteil bedeutet, ob die entwickelte Anwendung den Anforderungen des Kunden

entspricht oder nicht. Die Tester führen Blackbox-Tests in der Testumgebung und in der Phase
env (Vorproduktion env) durch

b. White-Box-Tests:

Wenn die Ressource den strukturellen Teil (die Programmierung) der Anwendung testet,
wird er als "White-Box-Tester" behandelt. Entwickler sind für White-Box-Tests in der
Entwicklungsumgebung verantwortlich.

c. Graukastenprüfung:

Wenn die Ressource die Erfahrung mit beiden Tests hat (White-Box-Tests und Black-
Box-Tests). Dann wird er als „Grey Box Tester“ behandelt.

TESTSTUFEN:
Wenn ein Projekt von der Signoff-Phase zum Leben(Produktion) übergehen muss, muss es die
folgenden Teststufen durchlaufen.

1) Testebene der Einheit

2) Prüfung auf Modulebene
3) Integrationsgrad der Tests
4) UAT(User Acceptance Testing)
5) Systemtests

1) Testebene der Einheit: Einheit bezeichnet den kleinsten Fluss oder das kleinste
Szenario in der Anwendung.
  Der Entwickler ist für Unit-Level-Tests verantwortlich.
 Er teilt das zugewiesene Modul in mehrere Einheiten auf und entwickelt den
Code für alle Einheiten.
 Er ist dafür verantwortlich, zu überprüfen, ob jede Einheit wie erwartet
funktioniert oder nicht.

2) Prüfung auf Modulebene:

 Ab dem Testen auf Modulebene sind sowohl das Testteam als auch das
Entwicklungsteam verantwortlich.
 Der Entwickler wird alle zugehörigen Einheiten zu einem Modul
zusammenfassen.
 Sobald das Modul entwickelt ist, ist der Entwickler für White-Box-Tests in der
Entwicklungsumgebung verantwortlich.
 Sobald das Modul für das Testteam freigegeben ist, sind sie für Blackbox-Tests in
der Testumgebung verantwortlich.

3) Testen auf Integrationsebene:

 Der Prozess der Kombination aller entwickelten Module wird als Integration
bezeichnet.
 Die Überprüfung, ob der Datenfluss von einem Modul zum anderen navigiert,
wird als Testen auf Integrationsebene bezeichnet.
 Sowohl das Entwicklungsteam als auch das Testteam sind für das Testen auf
Integrationsebene verantwortlich.
Beispiel: Erstellen Sie ein Konto in Gmail und überprüfen Sie, ob Sie sich mit dem
erstellten Konto bei der Anwendung anmelden können. Schreiben Sie dann eine
E-Mail und senden Sie sie, überprüfen Sie, ob sie ordnungsgemäß zugestellt
wurde oder nicht.
 Während die Integration fehlt, wenn ein obligatorisches Modul fehlt, ersetzt der
Entwicklungsleiter das obligatorische Modul durch einen Dummy-Code, der als
Stub oder Treiber bekannt ist.

D1 D2 D3 D4 D5
+ + + + +
Anmeldedaten Anmeldung Verfassen Senden
Abmelden

Stub/Driver:Beides ist nichts anderes als ein Dummy-Code, er enthält keine

Funktionalitäten.

 Wenn der Entwicklungsleiter einen Top-Down-Ansatz verwendet, um die

Module zu integrieren, während die Integration, wenn ein obligatorisches Modul
fehlt, durch Stub ersetzt wird.
 Wenn der Entwicklungsleiter den Bottom-up-Ansatz verwendet, um die Module
zu integrieren, während die Integration, wenn ein obligatorisches Modul fehlt,
durch Driver ersetzt wird.

4) Benutzerakzeptanztests:
 Es wird als Benutzer-/Client-Akzeptanztest bezeichnet. Sobald der Build in der
Testumgebung stabil ist, liefern wir den Build an den Kunden. Vor der Lieferung
des Builds an den Kunden sendet der Kunde dem Testteam Benutzerakzeptanz-
Testfälle zur Ausführung.
  Das Testteam führt alle UA-Testfälle in der Testumgebung aus; wenn alle
bestanden sind, liefert der Projektmanager den Build an den Kunden.
 Der Kunde führt erneut alle UA-Testfälle in der Umgebung des Kunden (Stage-
Umgebung) aus. Wenn alle übergeben werden, wird der Client den Build in der
Live- oder Produktionsumgebung bereitstellen.
 UAT ist von zwei Arten:

a. Alpha-Tests
b. Betatests UAT

Alpha-Test Beta-Test (UATCS)

(UATCs) TestumgebungStufenumgebung

a. Alpha-Test:Die Ausführung aller UA-Testfälle in einer Testumgebung durch das

Testteam wird als "Alpha-Test" bezeichnet.

b. Beta-Test:Die Ausführung aller UA-Testfälle in der Client-Phase-Umgebung durch das

Client-Team oder das Testteam wird als "Beta-Test" bezeichnet.

Sobald der Beta-Test bestanden ist, geht der Kunde in die Live-Umgebung.

Testumgebung Auftraggeber

Build (UATCS) Pass

Team-Build testen Start
Liefern

UATCS

5) Systemtests:
 Es wird auch als nicht-funktionales Testen bezeichnet. Sobald die Anwendung
stabil ist, können wir nicht-funktionale Tests durchführen.
 In nicht-funktionalen Tests wird die Leistung (Reaktionszeit) der Anwendung
identifiziert.
 Die Zeit zwischen Anfrage und Antwort wird als Antwortzeit bezeichnet. Es wird
mit Hilfe mehrerer nicht-funktionaler Testtypen wie Belastungstests,
Leistungstests, Belastungstests, Bruchpunkttests identifiziert.
SOFTWAREENTWICKLUNGSMODELLE:
F. Welchen Prozess haben Sie verwendet, um Ihr Projekt zu entwickeln

Die Modelle sind wie folgt.

1) Wasserfallmodell
2) Spiralmodell
3) V-Modell
4) Fischmodell
5) Agiler Prozess

1) Wasserfall-Modell:
Es war der ursprüngliche Prozess oder das Modell, das für die Softwareentwicklung
eingeführt wurde (alter Prozess). Die sequentielle Ausführung aller Phasen in SDLC wird
als Wasserfallmodell bezeichnet. Sobald die Phase abgeschlossen ist, analysiert das
übergeordnete Management diese Phase.

HINWEIS: Wie Wasserfälle von einer Ebene zur anderen,in der gleichen Weise
die Phasen von SDLC umgesetzt werden.

Vorteile:

 Es ist sehr einfach, das Projekt zu implementieren, da es sich um eine

sequentielle Ausführung handelt.
 Nachteile:

 Therisk kann nicht in der frühen Phase des Lebenszyklus identifiziert werden, so
dass es nicht verhindert werden kann.
 Es ist sowohl ein zeitaufwändiger als auch ein kostspieliger Prozess.
 Wir können die Anforderungsänderung mitten im Projekt nicht akzeptieren.
Wenn noch angenommen werden muss, akzeptieren wir die
Anforderungsänderung in Form von CRs-Änderungsanfragen.
Änderungsanfragen werden am Ende des Projekts durchgeführt und CRs werden
vom Unternehmen in Rechnung gestellt.

monat

2) Spiralmodell:
  Das Spiralmodell ist eine Kombination aus Wasserfallmodell und Prototyp.

 Anstatt alle Anforderungen einmal zu sammeln, sammelt die BA nur wenige

Anforderungen; sie wird mit Hilfe des Prototyps analysiert und entworfen. Dann
wird es an die Entwicklung gegeben.
 Sobald der Entwickler den Build entwickelt hat, wird er an das Testteam freigegeben.
Der gleiche Prozess wird für alle Anforderungen fortgesetzt.
 Sobald alle Anforderungen erfüllt sind und der Build stabil ist, wird der Build an den
Kunden geliefert.

Vorteile:

 Wir können Zeit und Kosten sparen, weil wir alle Phasen parallel durchführen.
 Das Risiko kann in einem frühen Stadium des SDLC identifiziert und in einem frühen
Stadium des Lebenszyklus verhindert werden.
 Die Bedarfsänderung kann in der Mitte des Prozesses übernommen werden.

Nachteile:

 Aufgrund der aggressiven Zeitlinien(weniger Zeit) besteht ein enormes Lieferrisiko.

 Anforderungsänderung in der Endphase des Projekts kann nicht akzeptiert werden,
um Lieferrisiken zu vermeiden.
 3) V-Modell(Verifikations- und Validierungsmodell):
Validierung:

Es ist auch als "QC" (Qualitätskontrolle) bekannt. Das Prüfteam ist für die Validierung
verantwortlich. Das Testteam prüft, ob die entwickelte Software den Anforderungen des
Kunden entspricht oder nicht.

Testingenieure sind Validatoren.

Verifizierung:

Def1: Prüfen Sie, ob jedes einzelne Phasenergebnisdokument den Unternehmens- und

Kundenrichtlinien entspricht oder nicht.

Def2:Prüfen Sie, ob jede einzelne Rolle in der Organisation gemäß

Unternehmen und Kunden orientieren sich an den Richtlinien oder nicht. Die
Verifizierung wird auch als QS (Qualitätssicherung) bezeichnet.

Für die Verifizierung ist die Projekt-/Prozessmanagementgruppe (PMG) bzw. Auditgruppe

zuständig.

 Ab dem V-Modell wird sich auch das Testteam an der Bedarfsermittlung beteiligen.
 BA ist dafür verantwortlich, die Anforderungen zu sammeln,parallel dazu analysiert
das Testteam alle Anforderungen, um zu überprüfen, ob es möglich ist, zu testen
oder nicht.
 Sobald der SRS als Basis festgelegt ist, ist das Validierungsteam für den Testplan
verantwortlich
 Auf der Grundlage der Analyse- und Entwurfsphasen erstellt das Validierungsteam
den Systemtestplan und den Entwurfsplan.
 Sobald der Code entwickelt ist, geben sie den Build an das Testteam weiter, wo sie
alle Teststufen durchführen. Sobald der Build stabil ist, wird er an den Kunden
geliefert.

Vorteile:
  Die Testaktivitäten werden ab der Anforderungsphase gestartet, damit wir die
Qualität sicherstellen können.
 Für jede Phase werden das Verifizierungsteam und das Validierungsteam die Phasen
überprüfen, damit wir die Qualität sicherstellen können.
 Das Risiko kann frühzeitig erkannt werden, da wir eine parallele Testaktivität haben,
so dass es verhindert werden kann.
 Wir können die Anforderungsänderung in der Mitte der Phase akzeptieren.

Nachteile:

 Es ist ein zeitaufwändiger und kostspieliger Prozess, aber wir können die Qualität
sicherstellen.

4) Fischmodell:

 Es ist das gleiche wie beim V-Modell.

 Im FISH-Modell werden wir mehrere Verifizierungsteams vom Kunden und vom
Unternehmen haben, um den Prozess zu überprüfen und mehr Qualität und
Sicherheit zu bieten.
 Es ist teurer als das V-Modell.
 Es bietet mehr Sicherheit und wird in hochrangigen Sicherheitsprojekten wie NASA,
Luftwaffe, Marine, Armee usw. eingesetzt.
 Hinweis: Das Validierungsteam überprüft die Ergebnisse der Unit-Testfälle, wenn
sich der Build in der Entwicklung befindet

5) Agiler Prozess:

 Es hat mehrere Untermodelle wie adaptives, Scrum, iteratives Modell usw.Das

Modell, das wir verwenden werden, ist das Scrum-Modell.
 Es ist ein iteratives und inkrementelles Modell. Das Scrum-Modell hat die folgenden
Aktivitäten.
a. Scrum Master
b. User Stories
c. Scrum-Meeting/Scrum Calls/DSM
d. Sprintplan
e. Sprint-Meeting
f. Rückstände

a. Scrum Master:

Der Scrum Master ist, wer das Projekt leiten wird. Der Projektleiter oder der
Auftraggeber fungiert als Scrum Master. Der Scrum Master ist für Scrum-Meetings und
Sprint-Meetings verantwortlich.
b. User Stories:

Die Anforderungen werden in Form von vom Endbenutzer verwendeten Flows (vom
Endbenutzer verwendete Methoden) erfasst. Daher werden wir es als User Stories
bezeichnen. BA ist dafür verantwortlich,

c. Scrum-Meeting:

 Täglich nehmen alle Teammitglieder an einem kurzen Meeting teil, in dem sie
beschreiben, welche Aktivitäten gestern durchgeführt wurden und welche
Aufgaben heute geplant sind und ob es Herausforderungen gibt.
 Alle Teammitglieder inklusive Scrum Master und Client müssen beschreiben.
 Der Hauptzweck des Scrum-Meetings besteht darin, die Ressourcen zu verfolgen
und auch die Transparenz aufrechtzuerhalten.

d. Sprintplan:

 Ein fester Zeitraum für den Sprint kann eine Woche/zwei Wochen/drei Wochen
usw. sein. Es wird vom Scrum Master entschieden.
 Sprint-Plan ist es, User Stories zu sammeln, zu analysieren, zu entwickeln, zu
testen und an den Kunden zu liefern.
 Wenn wir während des Sprints keine der Anforderungen erfüllen können, wird
der Sprint nicht verlängert. Und die ausstehenden Anforderungen sollten in den
nächsten Sprint mitgenommen werden. Sprint ist ein fester Zeitraum

e. Sprint-Meeting:

Sobald der Sprint abgeschlossen ist, wird der nächste Sprintplan im Rahmen des Sprint-
Meetings festgelegt. Sie werden besprechen, ob der aktuelle Sprint erfolgreich
durchgeführt wird oder nicht, ob es Herausforderungen gibt.

f. Rückstände:

Wenn während des Sprint-Plans User Stories nicht erreicht werden können, werden
diese als Backlogs betrachtet. Diese Backlogs müssen im nächsten Sprint abgeschlossen
werden.

Es gibt zwei Arten,

(i) Product Backlog

(ii) Sprint-Backlog
 Product Backlog: Die Anforderungen (User Stories), die wir im Rahmen des
Sprint-Plans sammeln, entwickeln, testen und an den Kunden liefern, werden als
Product Backlogs bezeichnet.
Sprint Backlog: Die Anforderungen, die nicht im Rahmen des Sprintplans
abgeschlossen werden, werden als Sprint Backlog behandelt.

Vorteile:

 Jeder einzelne Sprint wird mehrmals vom Testteam und vom Kunden getestet, damit wir
die Qualität sicherstellen können.
 Alle Phasen in SDLC werden parallel y durchgeführt, so dass wir Zeit und Kosten sparen
können.
 Die Anforderungsänderung kann in jeder Phase des Projekts (auch nach Lieferung des
Sprints) akzeptiert werden.
 Risiko kann frühzeitig erkannt und verhindert werden
 Wir können die Transparenz des Projekts aufrechterhalten.
 Der Kunde wird auch an Scrum-Meetings teilnehmen, so dass wir die Informationen sehr
schnell erhalten können.
 Jeder einzelne Sprint wird an den Kunden geliefert, so dass wir kein Lieferrisiko haben.
 Wir können die Kundenzufriedenheit gewinnen, indem wir alle Sprints an den Kunden
liefern.
 Der Sprint wird auch als iterativ bezeichnet. Its und iteratives und inkrementelles Modell
Nachteile:

Die Pflege aller Sprint-bezogenen Informationen ist eine sehr anspruchsvolle Aufgabe, aber wir
können sie mit Hilfe von Testmanagement-Tools wie Scrum Wise, Quality Center, JIRA und
Testlink usw. bewältigen.

Funktionsprüfungsarten (oder) Black-Box-Prüfungsarten:

1) Rauchprüfung:

 Sobald der Build entwickelt und in einer beliebigen Umgebung bereitgestellt wurde,
werden die ersten Tests durchgeführt, die als Rauchprüfung bekannt sind. Zunächst wird
das Entwicklungsteam den Build in der Entwicklungsumgebung bereitstellen und einen
Rauchtest durchführen. Sie überprüfen, ob jedes modulbezogene Feld ordnungsgemäß
auf ihren Seiten navigiert oder nicht, und überprüfen die Hauptfunktionalität der
Anwendung. Ziel der Rauchprüfung ist es, zu überprüfen, ob der Aufbau für weitere
Tests bereit ist oder nicht. Der Entwickler wird sich auf White-Box-Tests konzentrieren
 Wenn alle diese Felder ordnungsgemäß zu den zugehörigen Seiten navigieren, werden
sie zu dem Schluss kommen, dass der Rauchtest bestanden wurde.
 2) Gesundheitstests:
 Sobald der Build in der Testumgebung bereitgestellt wird, führt das Testteam den
Rauchtest in der Testumgebung durch. Es wird als Gesundheitstest bezeichnet.
 Im Sanity-Test führt das Testteam mindestens eine Runde der Hauptflussfunktionalität
durch und überprüft, ob sie ordnungsgemäß funktioniert oder nicht.
 Wenn der Sanity-Test bestanden wird, führt das Testteam alle Testfälle aus, wenn er
fehlschlägt, lehnt es den Build an das Entwicklungsteam ab.

Beispiel für den Hauptfluss: Erstellen Sie ein Konto in Gmail und melden Sie sich bei
diesem Konto an und verfassen Sie eine E-Mail und senden Sie sie an eine gültige E-Mail
und überprüfen Sie, ob sie ordnungsgemäß zugestellt wurde oder nicht.

Hinweis:Sobald der Sanity-Test durchgeführt wurde, muss das Testteam (Testleiter) eine E-Mail
mit den Ergebnissen des Sanity-Tests an das Entwicklungsteam senden.

3) Pre-SRN-Tests:SRN - Software-Versionshinweise

 Es enthält den Build-Status wie die Anzahl der Module, die im Build zum Testen
verfügbar sind.
 Anzahl der Module, die sich in der Entwicklung befinden.
 Anzahl der Stubs und Treiber sind im Build verfügbar.
 Anzahl der Fehler, die behoben und im Build verfügbar sind.
 Anzahl der Fehler, die sich in der Entwicklung befinden
 Bereitstellungsrichtlinien usw.

 Bevor das SRN-Dokument zusammen mit dem Build an das Testteam freigegeben
wird, führt das Testteam den Rauchtest in der Entwicklungsumgebung durch,
bekannt als Pre-SRN-Test
 Es wird auch als Build Acceptance Testing (bat) oder Build Verification Testing (BVT)
bezeichnet.

Hinweis: Sobald der Build für das Testteam freigegeben ist, überprüfen die Testingenieure das
SRN-Dokument, um den Build-Status zu erfahren (was der Build enthält). Dann führt der Test
einen Gesundheitstest durch.

2. Der Auftrag besteht zunächst darin, dass das Entwicklerteam Smoke-Tests durchführt, dann
führt das Testteam Pre-SRN-Tests in Dev Env durch. Wenn beide bestanden werden, gibt das
Entwicklerteam den Build an das Testteam frei, und der Test führt einen Sanity-Test durch
 4) GUI/UI-Tests:
Test der grafischen Benutzeroberfläche/der Benutzeroberfläche. Die folgenden fünf Aktivitäten
werden in der GUI getestet.

 Überprüfen Sie die Schreibweisen aller Felder.

 Überprüfen Sie die Schriftart aller Felder, in denen die Konsistenz beibehalten werden
soll.
 Überprüfen Sie die Farbe und Ausrichtung aller Felder, um die Konsistenz beizubehalten.
 Überprüfen Sie das allgemeine Erscheinungsbild der Seite

5) Regressionstests:
Die Durchführung von Tests an bereits getesteten Funktionalitäten auf den iterativen und
inkrementellen Builds wird als "Regressionstest" bezeichnet.

Es wird auf zwei Arten durchgeführt:

 Wann immer ein Fehler identifiziert wird, wird er dem Entwickler gemeldet. Der Entwickler
wird ihn beheben und dann den behobenen Fehler in Form eines neuen Builds(Build2) an
das Testteam freigeben. Der Testingenieur wird erneut testen, um zu überprüfen, ob der
Fehler wirklich behoben ist oder nicht.
 Die Testfälle, die auf dem alten Build übergeben werden, werden auf dem neuen Build
erneut ausgeführt und prüfen, ob diese wie bisher funktionieren oder nicht.

Das Testen bereits getesteter Funktionalitäten ist ein Regressionstest. Das Testen der neuen
Funktionalitäten ist kein Regressionstest. Es kommt unter Testfallausführung.

Hinweis:Wenn ein Code-Update vorhanden ist, kann sich dieser neue Code auf den
vorhandenen Code auswirken. Daher führen wir die Regressionstests durch.

6) Erneutes Testen:

 Das Testen derselben Funktionalitäten immer wieder mit mehreren Sätzen

verschiedener Testdaten auf demselben Build wird als "erneutes Testen" bezeichnet.
 Das Ausführen der fehlgeschlagenen Testfälle auf den iterativen und inkrementellen
Builds wird auch als "Re-Testing" bezeichnet.
 Testdaten:Die Daten, die das Testteam zum Testen verwendet, werden als „Testdaten“
bezeichnet.

Bsp.: 1. Testen Sie die Anmeldefunktionalität von Gmail mit mehreren Sätzen
verschiedener anmeldeinformationen.

2. Testen Sie die Spicejet One-Way-Suche mit den mehreren Sätzen

unterschiedlicher Herkunft und unterschiedlicher Passagiere.

F: Was ist der Unterschied zwischen Regressionstests und Wiederholungstests?

F: Was ist der Unterschied zwischen Regressionstests und Integrations-Level-

Tests?

7) End-to-End-Tests:
Der Testingenieur muss alle vom Endbenutzer verwendeten Szenarien der Anwendung
identifizieren und überprüfen, ob die End-to-End-Szenarien ordnungsgemäß funktionieren oder
nicht

Durch die Durchführung von End-to-End-Tests können wir Tests auf Integrationsebene
erreichen

Beispiel: Das Ende-zu-Ende-Szenario für Gmail.

8) Kompatibilitätstests:
  Testen, ob die Anwendung in allen Zielumgebungen wie erwartet funktioniert oder
nicht, wird als "Kompatibilitätstest" bezeichnet. Umgebung ist eine Kombination aus
Betriebssystem, Browser, Server, DB usw.
 Kompatibilitätstests sind zwei Arten von „Cross-Browser-Tests“ und „Cross-Plattform-
Tests“.
 Testen Sie, ob die Webanwendung in allen Zielbrowsern wie Firefox,Safari, Google
Chrome,IE usw. erwartungsgemäß funktioniert. Dies wird als "browserübergreifendes
Testen" bezeichnet.
 Testen, ob die Desktop-Anwendung wie erwartet auf verschiedenen Plattformen oder
Betriebssystemen wie Windows,LINUX, MAC,Solaris usw. funktioniert, wird als
"plattformübergreifendes Testen" bezeichnet.

Beispiel für Cross-Browser-Tests: Testen Sie, ob der Spicejet in den folgenden Umgebungen
funktioniert oder nicht.

Windows – Internet Explorer, Firefox, Google Chrome, Safari, Opera

Linux - Internet Explorer, Firefox, Google Chrome, Safari, Opera

MAC - Firefox, Google Chrome, Safari, Opera

Beispiel für plattformübergreifende Tests: Testen Sie, ob der Skype in den folgenden
Plattformen oder Umgebungen funktioniert

Windows
Linux
MAC und Handy

Hinweis: Wenn wir Kompatibilitätstests durchführen, müssen wir uns mehr auf die GUI
der Anwendung konzentrieren

9) Usability-Tests:

 Benutzerfreundlichkeit bedeutet Benutzerfreundlichkeit. Der Testingenieur muss die

Benutzerfreundlichkeit der Anwendung für die Zufriedenheit des Endbenutzers
bereitstellen.
 Abhängig von der Anwendung müssen wir die Benutzerfreundlichkeit bereitstellen.

Beispiel: Für (gesicherte) Banking-Anwendungen müssen wir mehr Sicherheit bieten, während
wir für soziale Websites (Facebook, Twitter) mehr Benutzerfreundlichkeit bieten müssen.
10) Adhoc-Tests:

 Adhoc bedeutet auf unsere Weise.

 Adhoc-Tests bedeutet, die Anwendung auf Ihre eigene Weise zu testen, nachdem Sie
alle Anforderungen verstanden haben und mindestens eine Runde manueller Tests an
der Anwendung abgeschlossen ist
 Der Hauptzweck von Adhoc-Tests besteht darin, der Anwendung Benutzerfreundlichkeit
zu verleihen.

11) Explorative Tests:

 Explorativ bedeutet, die neue Anforderung / neue Funktion zu identifizieren. Sobald der
Build stabil ist, werden die Domänenexperten die Anwendung gemäß ihrem
Domänenwissen testen, während sie testen, ob die vorhandenen Anforderungen
ausreichen, wenn nicht, werden sie die neuen Anforderungen bereitstellen.
 Der Hauptzweck von explorativen Tests besteht darin, der Anwendung
Benutzerfreundlichkeit und Sicherheit zu bieten.

12) Affentest/Gorillatest:

 Sobald die Anwendung stabil ist, können wir Affen testen.

  Das Testen der Anwendung durch Ausführen einiger Abnormalitäten wird als
Affen-/Gorillatest bezeichnet.
 Abnormale Aktionen bedeutet, dass Sie über einen längeren Zeitraum kontinuierlich auf
ein Feld klicken und überprüfen, ob die Anwendung abstürzt oder nicht.
 Testen Sie die Anwendung mit ungültigen Daten wie HTML-Tags (<html>) und
überprüfen Sie, ob die Anwendung abstürzt oder nicht.
Hinweis: Das Ziel von Affen-Tests ist es, zu überprüfen, ob die Anwendung abstürzt oder
nicht (Means erhält Server nicht gefunden Ausnahme)

13) Statische Prüfung:

 Das Testen der Anwendung ohne Durchführung einer Aktion wird als statisches
Testen bezeichnet.

Bsp.:1. GUI-Tests
2. Validierungen:- Die Überprüfung der Verfügbarkeit der Felder auf der Seite
wird statisch getestet.

14) Dynamische Tests:

 Testen Sie die Anwendung, indem Sie eine Aktion ausführen, die als dynamisches
Testen bezeichnet wird.

Beispiel: Regressionstests, Wiederholungstests, Adhoc-Tests usw.

15) Authentifizierungstests:
  Authentifizierung bedeutet, zu prüfen, ob die gesicherten
Anmeldeinformationen/Daten in der Datenbank verfügbar sind oder nicht.
 Authentifizierungstest bedeutet, die Anwendung mit mehreren Sätzen gültiger und
ungültiger Daten zu testen. Für gültige Daten sollte die Startseite angezeigt werden,
während für ungültige Daten die richtige Authentifizierungsmeldung
(Fehlermeldung) angezeigt werden sollte.

Beispiel: Testen Sie die Anmeldefunktionalität von HMS mit mehreren Sätzen gültiger und
ungültiger Anmeldeinformationen. Es muss die Anwendung ordnungsgemäß authentifizieren.

16) Direkte URL-Tests:

 Melden Sie sich auf einer sicheren Seite an und nehmen Sie die URL der gesicherten
Seite und greifen Sie in einem neuen Browser auf diese URL zu. Wo es nicht
zugänglich sein sollte, wenn es zugänglich ist, dann ist die Anwendung nicht
gesichert.

Beispiel: Melden Sie sich bei Gmail.com an und kopieren Sie die URL der Startseite. Öffnen Sie
in einem neuen Browser und greifen Sie direkt auf die URL zu, auf die nicht zugegriffen werden
sollte.

17) Firewall-Dichtheitsprüfung:

 Melden Sie sich als eine Benutzerebene bei der Anwendung an und versuchen Sie,
über Ihre Rollenbeschränkung hinaus auf die Daten zuzugreifen. Wenn darauf
zugegriffen werden kann, kommen wir zu dem Schluss, dass die Anwendung nicht
gemäß der Rolle funktioniert (es liegt ein Firewall-Leck vor).

Beispiel: Melden Sie sich als Junior bei der HMS-Anwendung an. Arzt und
versuchen, auf die Daten von Sr. Arzt, wo es nicht zugänglich sein sollte

18) Datenbank-Tests:

 Testen, ob die Daten ordnungsgemäß in die Datenbank aller Tabellen eingefügt

werden oder nicht, wird als Datenbanktest bezeichnet. Mit Hilfe von SQL-Abfragen
können wir DB-Tests durchführen.

Beispiel: Wenn wir die dauerhafte Registrierung in HMS erstellen, werden alle
Patientendaten in der HMS-Datenbank gespeichert. Als Testingenieur müssen wir
 uns in die Datenbank einloggen und überprüfen, ob die Daten in allen Tabellen
ordnungsgemäß eingefügt sind oder nicht.

Bereitstellungstest/ Installationstest: Das Bereitstellungsteam oder der

Testleiter stellt den Build in mehreren Umgebungen wie Dev, Testing, Stage1,
Stage2, Production usw. bereit und überprüft, ob er ordnungsgemäß bereitgestellt
wird oder nicht

F: Wie werden Sie den Build testen, sobald er freigegeben ist?

A: Zunächst werden wir Gesundheitstests durchführen, wenn sie bestanden werden, werden
wir alle Testfälle ausführen und dann alle Funktionstests wie folgt durchführen. Durch die
Durchführung aller folgenden Tests können wir dann die Qualität der Anwendung
sicherstellen

Funktionstesttypen – Ausführungsablauf des Funktionstests auf dem Build, sobald es für das
Testteam freigegeben wurde
 Hinweis: Für jede Anwendung werden alle oben genannten Tests durchgeführt, um
sicherzustellen, ob die Anwendung die Anforderungen des Kunden, die Qualität und den
Nutzen für den Endbenutzer erfüllt oder nicht.

2. Wenn es sich um eine Desktop-Top-Anwendung handelt, sind direkte URL-Tests und

Cross-Browser-Tests nicht möglich.

Berichtsvorlage überprüfen:
Überprüfen Sie das SRS-Dokument von Spice Jet und stellen Sie den Überprüfungsbericht in der
folgenden Vorlage zur Verfügung.

Anforderungs-ID Anforderungskommentare von TE-Kommentaren

Beschreibung

7. Erwachsener, Kind und Kleinkind fallen 1. Was ist der Unterschied zwischen

Daunen sollten vorhanden sein. Kind, Erwachsener und Kleinkind

2. Was schätzt die Felder für Erwachsene, Kinder

und Kleinkinder?

19) Globalisierungsprüfung:

Es handelt sich um zwei Typen

a. Lokalisierungstests.

b. Internationalisierungstests.

a. Lokalisierungstests:

 Testen Sie die Anwendung in allen lokalen Sprachen, die für unser Land
selektiv sind, wie Hindi, Bengali, Telugu usw., was als Lokalisierungstest
bekannt ist.
 Es unterstützt maximal 10 Sprachen für eine einzelne Integration. Daher
werden wir es als "L10N" -Test bezeichnen.

Bsp.:1. Testen Sie Google.co.in in allen lokalen Sprachen wie Hindi, Bengali,
Telugu usw....
 2. Testen Sie den Geldautomaten in lokalen Sprachen wie Hindi, Telugu und Englisch.

b. Internationalisierungstests:

 Testen Sie die Anwendung in allen internationalen Sprachen wie

Japanisch, Chinesisch und Spanisch usw. wird als
Internationalisierungstest bezeichnet. Es unterstützt maximal 18
Sprachen für eine einzige Integration. Daher werden wir es als "I18N" -
Test bezeichnen.

Beispiel: Testen Sie Gmail.com in allen internationalen Sprachen wie

Japanisch, Spanisch und Chinesisch usw.

SOFTWARETEST-LEBENSZYKLUS:
Es enthält die folgenden Phasen:

1) Software-Testplan.
2) Software-Testdesign.
3) Testdurchführung.
4) Ergebnisanalyse.
5) Reporting & BLC.
6) Lieferung und Wartung.
7) Testzusammenfassungsbericht/ Postmortem-Bericht erstellen.

1. Softwaretestplan:
 Plan ist ein strategisches Dokument, das beschreibt, wie eine Aufgabe effektiv und
effizient ausgeführt werden kann.
 Der Software-Testplan ist auch ein strategisches Dokument, das beschreibt, wie Tests
effektiv und effizient durchgeführt werden können. Der Testplan wird vom Testleiter
erstellt. Sobald er erstellt ist, wird er zur Überprüfung an das Testteam gesendet.
 Basierend auf dem Testplan sind wir für die Durchführung der Tests verantwortlich.
 Es enthält die unten aufgeführten Aktivitäten oder den Index.

Prüfplan Index
1. Zielsetzung

1.1 Prüfumfang
2. Referenzdokumente

3. Prüfgegenstände

3.1 Zu testende Merkmale

3.2 Nicht zu prüfende Merkmale

4. Teststrategie

4.1 Prüfarten

4.1.1 Funktionsprüfungsarten

5. Testumgebung

6. Test bestanden/Nicht bestanden-Kriterien

7. Fehleranalyse und -abschluss

8. Testergebnisse

9. Automatisierungsprüfung

10. Risiken und Eventualverbindlichkeiten

11. Hardware- und Softwareanforderungen

12. Ressourcenplan

13. Testzusammenfassungsbericht/ Postmortem-Bericht erstellen.

1. Ziel:

Der Hauptzweck des Prüfplans wird hier beschrieben. Sie enthält Prüfumfänge.

1.1 Prüfumfang:

Welche Arten von Tests das Testteam für das Testen der Anwendung verantwortlich ist,
wird als Testumfang bezeichnet.

Beispiel: Das Testteam ist für das manuelle Testen und die Automatisierung des Projekts
verantwortlich.

2. Referenzdokumente:
Hier wird die Liste der Dokumente beschrieben, mit denen der Prüfleiter den Prüfplan erstellt
hat.

Der Testleiter verwendet SRS-Dokumente, um den Testplan zu erstellen.

3. Prüfgegenstände:

3.1 Zu testende Merkmale:

Die Liste der Funktionalitäten oder Module, für die das Team verantwortlich ist, wird
hier beschrieben, und auch die Liste der Tests, die das Testteam an den Modulen
durchführt, wird hier beschrieben.

Beispiel: Das Testteam ist für die Buchung eines Fluges, die Buchung eines Hotels und
die Verwaltung meiner Buchung verantwortlich.

Für die oben genannten Module sind sie für die manuelle Prüfung und Automatisierung
verantwortlich.

3.2 Nicht zu prüfende Merkmale:

Die Liste der Module und Tests, für die das Testteam nicht verantwortlich ist, wird hier
beschrieben.

Beispiel: Das Testteam ist nicht für Zahlungsmodule verantwortlich und auch nicht für
Leistungstests, Lasttests und Stresstests.

4. Teststrategie:

Strategie bedeutet die Liste der Schritte, die wir unternehmen werden, um den Plan zu
erreichen.

 Die Teststrategie bedeutet die Liste der funktionalen Testtypen. Was das Testteam für
die Durchführung der Tests benötigt, wird als Teststrategie bezeichnet.
 Wir werden alle Arten von Funktionstests wie Regression, Re-Tests usw. an der
Anwendung durchführen
 Kurz gesagt, Plan bedeutet, was zu tun ist. Strategie bedeutet, wie man den Plan
erreicht.

5. Testumgebung:

Umgebung bedeutet, dass das System, das wir verwenden werden, um den Build
bereitzustellen und die Anwendung zu testen, als Testumgebung bezeichnet wird.
 Beispiel:Maschinentyp : Windows Server Enterprise
Betriebssystem : Windows
Prozessor : Intel Xeon CPU
Arbeitsspeicher : 4 GB/2,13 GHZ
Festplatte : 150 GB
Datenbank : Microsoft SQL Server 2008 Standard Edition
Webserver : IIS 7.0
Kunde : Microsoft Internet Explorer, Firefox, Google Chrome

6. Test bestanden nicht bestanden/Kriterien:

Wenn ein Testfall vom erwarteten Ergebnis abweicht, wird er als Fehler oder Fehler
behandelt.

Jeder Fehler hat die Kriterien oder den Fehlertyp.

Es gibt fünf Arten

a. Blocker
b. Sehr hoch
c. Hoch
d. Mittel
e. Niedrig

7. Abschluss der Fehleranalyse:

Zum Zeitpunkt der Lieferung des Builds, wenn Fehler/Defekte verfügbar sind, wird er vom
Testteam mit dem Projektmanager analysiert. Wenn ein Fehler nicht behoben werden muss,
wird er geschlossen.

8. Testergebnisse:

Die Liste der Module, die wir an den Kunden liefern werden, bekannt als Liefergegenstände.

Alle Module werden in mehrere Phasen unterteilt und auch der Lead liefert den angestrebten
Termin (Liefertermin).
 Phase Dead Lines
Nr. Module (Lieferdatum)

1. BookaFlight
2. Meine Buchung verwalten
1 3. PNR-Status 30. Juni

2 4. Flugpläne 31. Juli

5. Corporate Benefit

3 6. Spice Connect 30. Sept.

9. Automatisierungsprüfung:

Die Anzahl der Module, die das Testteam automatisieren wird, wird hier beschrieben, und auch
das Automatisierungstool und die Strategie, die die Testingenieure verfolgen werden, werden
hier beschrieben.

10. Risiken und Eventualverbindlichkeiten:

Die Liste der Risiken, denen das Team während der Durchführung des Projekts und auch mit der
zugehörigen Lösung ausgesetzt sein wird, wird hier beschrieben.

Eventualverbindlichkeit
Risiken en
Puffernde Ressourcen
Ressourcenmangel pflegen

Analysieren Sie die

Kontinuierliche Anforderungsänderungen Anforderungen

Fehlende Peer Reviews Peer-Reviews überwachen

 11. Hardware- und Softwareanforderungen:

Die Anzahl der Maschinen wie Laptops, Handys, Drucker usw., die für das Testen mit der
zugehörigen Software benötigt werden, wird hier beschrieben.

12. Ressourcenplan:

Die Anzahl der Ressourcen, die für manuelle Tests, Automatisierungsprüfungen,

Datenbankprüfungen benötigt werden, wird hier beschrieben.

13. Testzusammenfassungsbericht/Postmortem-Bericht erstellen:

Sobald die Prüfung abgeschlossen ist, muss der Testleiter den Prüfzusammenfassungsbericht
erstellen, der die Zusammenfassung der Prüfung enthält.

2) Software-Testdesign:
Der Prozess des Schreibens der Testfälle auf die Testfallvorlage nach dem Verständnis aller
Anforderungen ist als "Softwaretestdesign" bekannt.

 Jede Organisation wird ihre eigene Vorlage haben, die auf dieser Vorlage basiert; der
Testingenieur ist dafür verantwortlich, die Testfälle zu schreiben.
 Wir haben die folgenden Vorlagen, um die Testfälle zu schreiben. Es enthält Deckblatt,
Testfälle, Testdaten, Rückverfolgbarkeitsmatrix und Testbericht

Requirement- priorität TC Test Vor- Test Ist Erwartet Ergebni Komment

Test ID szenario produktio typen Ergebn Ergebnis s are
ment Types n is

ID

Deckblatt:

Modulname :

Gesamtanzahl der Testfälle :

 Anzahl der P1-Testfälle:

Anzahl der P2-Testfälle:

Anzahl der P3-Testfälle:

Anzahl der P4-Testfälle:

Anforderungs-ID: Die Anforderungsnummer, für die wir die Testfälle schreiben, wird hier
beschrieben.

Testtypen: Der Testfalltyp wird als Testtyp bezeichnet. Es gibt fünf Arten.

 GUI
 Validierung
 Positiver Testfall (oder) Funktionaler positiver Testfall.
 Negativer Testfall (oder) Funktionaler negativer Testfall
 Datenbank-Testfall

Positiver Testfall: Testen Sie die Anwendung mit allen gültigen Daten als positiven
Testfall.

Negativer Testfall: Testen Sie die Anwendung mit mindestens einem ungültigen
Datenwert, der als negativer Testfall bekannt ist.

Priorität: Es beschreibt, wie wichtig der Testfall ist. Es sind folgende Typen: P1, P2,P3 und P4.

P1: Wenn der Testfall die Hauptfunktionalität der Anwendung/des Moduls beschreibt,
wird er als P1 behandelt.

Die Hauptfunktionalität bedeutet, dass wir die Tests nicht fortsetzen können, wenn
der Testfall fehlgeschlagen ist, sodass die Priorität "P1" ist.

P2: Wenn der Testfall die Funktionalität auf Feldebene beschreibt, dann ist die Priorität
‘p2’.

Testfall auf Feldebene bedeutet, wenn er fehlschlägt, können wir den Test
fortsetzen, aber es ist wichtig, gemäß den Anforderungen des Kunden in der
Anwendung präsent zu sein.

P3: Alle GUI-Testfälle fallen unter die P3-Priorität.

 P4:Der Testingenieur hat die Möglichkeit, der Anwendung den Vorschlag zu geben.
Diese Vorschläge werden in Form von Testfällen erfasst und dann ist die Priorität ‘P4’.

Testfall-ID: Hier wird die Seriennummer des Testfalls beschrieben.

Testszenario: Szenario bezeichnet einen Flow oder die vom Endbenutzer verwendete Art und
Weise. Die Anforderung wird in alle vom Endbenutzer verwendeten Flows oder Szenarien
unterteilt, die hier beschrieben werden. Der Test Engg muss die maximal möglichen
Flüsse(Scenrios) für die Anforderung oder User Story identifizieren

Vorbedingung:Die Bedingung, die zum Testen des Szenarios erforderlich ist, wird hier
beschrieben.

Testschritte:Die Liste der Schritte, die zur Ausführung des Szenarios erforderlich sind, wird hier
beschrieben. Basierend auf den Testschritten wird der Test engg auf der Anwendung oder dem
Build ausgeführt

Erwartetes Ergebnis:Zum Zeitpunkt des Schreibens der Testfälle werden wir die Anwendung
nicht bei uns haben. Wir erwarten also das Ergebnis für das Szenario. Dieses erwartete Ergebnis
wird in der Spalte „Erwartetes Ergebnis“ aktualisiert.

Tatsächliches Ergebnis:Es wird zum Zeitpunkt der Ausführung der Testfälle aktualisiert. Der
Testingenieur beobachtet das tatsächliche Verhalten der Anwendung für das Szenario und wird
hier aktualisiert.

Ergebnis:Sobald die Testausführung abgeschlossen ist, vergleicht der Testingenieur das

tatsächliche Ergebnis mit dem erwarteten Ergebnis. Wenn beide übereinstimmen, aktualisiert
er das Ergebnis als bestanden, wenn nicht, aktualisiert er es als fehlgeschlagen.

Anmerkungen:Die BA oder der Kunde wird die Anmerkungen hier zur Verfügung stellen.

Siehe Gmail-Login TCS-Dokument

Testdesigntechniken:
Um Tests auf effektive und effiziente Weise durchzuführen, müssen wir die folgenden
Testdesigntechniken befolgen.
 1. Grenzwertanalyse (BVA)

2. Äquivalenzklassenpartition (ECP)

3. Fehler erraten

1. Grenzwertanalyse (BVA):

Immer wenn wir die Anforderung haben, den Bereich wie 1 bis 100 oder 1 bis 1000
oder 1 bis 1 Mangel oder 1 Mangel bis 2 Mängel zu testen, ist es nicht möglich, die
erschöpfende Prüfung durchzuführen (vollständige Prüfung). Also müssen wir die BVA-
Technik anwenden.

 Teilen Sie den Bereich auf mehrere Grenzen wie min-1, min, min+1, middle, max-
1, max und max+1 auf.
 Um die positive Prüfung durchzuführen, testen Sie das Feld mit min, min+1,
middle, max-1 und max. Wo es hinnehmen sollte. (Its +ve Testfall)
 Um einen negativen Test durchzuführen, testen Sie das Feld mit min-1 und
max+1. Wo es nicht akzeptiert werden sollte. (Its -ve Testfall)
 Wenn es wie oben beschrieben funktioniert, können wir daraus schließen, dass
es nur den Bereich akzeptiert.

+Ve Testszenario: Überprüfen Sie das Feld mit den Grenzen wie min, min+1, middle, max-1
und max

-Ve Testszenario: Überprüfen Sie das Feld mit den Grenzen wie min-1 und max+1
 2. Äquivalenzklassenpartition (ECP):

Immer wenn wir die spezielle Anforderung haben, überprüfen Sie, ob das Feld
(Benutzername oder Passwort) die Zeichen wie a bis z, A bis Z, 0 bis 9 und #%@$&*
akzeptiert. Gleichzeitig sollte das Feld die Sonderzeichen wie <>-+/\ nicht akzeptieren.

 In diesem Szenario ist es nicht möglich, den erschöpfenden Test mit allen
Zeichen durchzuführen. Wir müssen also der ECP-Technik folgen.
 Teilen Sie die Testdaten gleichmäßig in zwei Klassen ein.
a. Gültige Testdatenklasse b. Ungültige Testdatenklasse
 Bereiten Sie die Testdaten mit allen möglichen Methoden auf.
 Um einen positiven Test durchzuführen, testet das Feld mit gültigen Testdaten.
Wo es hinnehmen muss. (Its +ve Testfall)
 Um einen negativen Test durchzuführen, testen Sie das Feld mit ungültigen
Testdaten. Wo es nicht akzeptiert werden sollte.(Its -Ve Testfall)
 Wenn es wie erwartet funktioniert, können wir daraus schließen, dass es gemäß
der Anforderung funktioniert.

3) Fehler beim Raten:

 Wann immer ein Fehler vom Testingenieur identifiziert wird, sollte er dem Entwickler
gemeldet werden, wo er ihn beheben und an das Testteam zurücksenden wird. Der
Testingenieur prüft, ob der Fehler wirklich behoben ist oder nicht. Gleichzeitig muss er die
Fehler oder Bugs in den zugehörigen Funktionalitäten erraten. Er muss die Tests auch in den
zugehörigen Funktionalitäten durchführen. Dies wird als „Erratschen von Fehlern“ bezeichnet.

Beispiel: Auf der PR-Seite wird die Benachrichtigung msg nicht angezeigt, sie wurde vom
Entwickler behoben und vom Tester getestet. Wo die Warnmeldung auf der PR-Seite
ordnungsgemäß funktioniert. Jetzt muss der Test engg.. die zugehörigen Funktionalitäten wie
Zulassungsberatung und Zulassung durchgehen und dann nach der ähnlichen Art von Fehler
suchen (erraten).

Rückverfolgbarkeitsmatrix:

Es ist nachzuvollziehen, ob der Testingenieur alle Testfälle für die gesamten Anforderungen
abgedeckt hat oder nicht.

Basierend auf der Rückverfolgbarkeitsmatrix verfolgt der Lead oder der Kunde, ob der
Testingenieur alle Testfälle abgedeckt hat oder nicht.

Anford
erungs- Anzahl
ID der TCs Testfall-ID Kommentare
1 1 1
2 1 2
3 1 3
4 1 4
5 1 5
6 1 6
7 1 7
8&9 5 8 bis 12
Anforderung ist nicht
Noch nicht klar. Warten auf BA-
10 implementiert Kommentare

4) Testdurchführung:

 Der Prozess der Ausführung der Testfälle auf der Build-in-Testumgebung wird als
Testausführung bezeichnet. Immer wenn der Build an das Testteam freigegeben wird,
muss der Testingenieur das SRN-Dokument überprüfen, um den Build-Status zu
erfahren.
  Basierend auf dem SRN-Dokument wird der Testleiter den Build bereitstellen und das
Testteam führt einen Sanity-Test durch.
 Sobald der Gesundheitstest abgeschlossen ist, werden die Ergebnisse des
Gesundheitstests an den Entwickler gesendet.
 Wenn der Sanity-Test bestanden wurde, wird das Testteam die Testfälle weiterhin
ausführen. Wenn der Sanity-Test fehlgeschlagen ist, wird das Testteam den Build an das
Entwicklungsteam zurückweisen.
 Während der Ausführung der Testfälle beobachtet der Testingenieur das tatsächliche
Verhalten der Anwendung für das Szenario und es wird unter dem tatsächlichen
Ergebnisfeld aktualisiert. Dasselbe wird für alle Testfälle fortgesetzt.

5) Ergebnisanalyse:

 Während der Ausführung der Testfälle aktualisiert der Testingenieur das tatsächliche
Ergebnisfeld und vergleicht dann das tatsächliche Ergebnis mit dem erwarteten
Ergebnis. Wenn beide übereinstimmen, stellt er das Ergebnis als bestanden zur
Verfügung, andernfalls aktualisiert er es als fehlgeschlagen.
 Für den Pass geben wir die grüne Farbe an, während wir für den Fail die rote Farbe
angeben. Testdurchführung und Ergebnisanalyse, beides sind parallele Prozesse.

Hinweis: Sobald die Ausführung der Testfälle abgeschlossen ist, sind wir dafür verantwortlich,
alle Arten von Funktionstests in der Anwendung durchzuführen, um die Fehler zu identifizieren.

* Wie viele Testfälle können wir an einem Tag schreiben?

Es hängt alles von allen Anforderungen und dem Testingenieur ab, aber im Durchschnitt können
wir etwa 40-50 Testfälle an einem Tag schreiben. Das bedeutet, dass wir etwa 8-10 Minuten für
einen Testfall benötigen, um die Anforderung zu analysieren und den Testfall auf der
Testfallvorlage mit den Testdaten vorzubereiten.

* Wie viele Testfälle können wir an einem Tag ausführen?

Es hängt auch von den Testfällen und der Anwendung ab, aber im Durchschnitt können wir
50-60 Testfälle an einem Tag ausführen, um den Testfall zu überprüfen und ihn auf der
Anwendung auszuführen.

Wir benötigen durchschnittlich etwa 5-8 Minuten, um einen Testfall auszuführen.

6) Berichterstattung:
  Der Prozess des Meldens/Sendens der Fehler (fehlgeschlagene Testfälle) an den
Entwickler wird als Reporting bezeichnet.
 Es gibt zwei Arten.

1. Melden Sie die Fehler mithilfe von XL-Dateien.

2. Melden Sie die Fehler mithilfe von Reporting-Tools.

1. Melden Sie die Fehler mithilfe der XL-Datei:

Es war der alte Prozess, bei dem wir die folgende Vorlage verwendet haben, um den Fehler zu
aktualisieren und an den Entwickler zu senden.

Feh Fehlertitel Status Schwereg Prior Fehlerb Screens Bauen Gemel Zugewiesene
ler / rad ität eschrei hot Versio det Kommentare
ID Zusammen bung n Von
fassung bis
1.

Fehler-ID:

Die Seriennummer des Fehlers wird hier beschrieben.

Fehlertitel/Zusammenfassung:

Das tatsächliche Ergebnis des Fehlers wird hier beschrieben.

Status:

Basierend auf dem Fehler sind die Testingenieure sowie der Entwickler dafür verantwortlich,
den Status anzugeben. Es ist unten von Typen.

 Neu:
Immer dann, wenn der Testingenieur einen Fehler feststellt. Anfangs ist der Status des
Fehlers Neu. Der neue Fehler wird dem Entwickler gemeldet.
  Offen:
Der Entwickler wird prüfen, ob es sich bei dem neuen Bug wirklich um einen Bug
handelt oder nicht. Wenn ja, dann aktualisieren wir den Status von neu auf offen.
 Behoben/Geprüft:
Der Entwickler wird sich einige Zeit nehmen, um den offenen Fehler zu beheben, sobald
er behoben ist. Er wird den Status von offen auf behoben aktualisieren. Behobener
Fehler wird an den Testingenieur gesendet.
 Geschlossen:
Der Testingenieur prüft, ob der behobene Fehler wirklich wie erwartet funktioniert oder
nicht. Wenn es funktioniert, aktualisieren wir den Status von fest auf geschlossen.
Geschlossener Zustand ist das Ende des Fehlers.
 Erneut öffnen:
Der behobene Fehler wird vom Testingenieur getestet. Wenn er nicht wie erwartet
funktioniert, aktualisiert er den Status von behoben auf wieder geöffnet und der wieder
offene Fehler wird an den Entwickler zurückgeschickt.
Der Entwickler prüft, ob es sich wirklich um einen Fehler handelt oder nicht, wenn ja,
öffnet er ihn, behebt den Fehler und sendet ihn an das Testteam zurück.
 Abgelehnt/Kein Fehler/Halten/Differenziert:
Wenn der Testingenieur einen Fehler identifiziert hat, wird er dem Entwickler mit
neuem Status gemeldet. Wenn der Entwickler einen Fehler nicht akzeptiert, aktualisiert
er einen Status von neu auf Abgelehnt/Kein Fehler und sendet ihn an das Testteam
zurück.

Schweregrad:

Es beschreibt, wie stark sich der Fehler auf die Anwendung beim Testen ausgewirkt hat.
Schwere bedeutet Schwere des Fehlers. Es ist unter den Typen.

 Blocker:
Wenn der Fehler den gesamten Test des Moduls blockiert, ist der Schweregrad oder die
Art eines Fehlers Blocker.
 Sehr hoch:
Wenn der Fehler das Testen des Moduls teilweise blockiert, ist der Schweregrad des
Fehlers sehr hoch.
 Hoch:
Wenn der Fehler nur das spezifische Szenario des Moduls blockiert, ist der Schweregrad
hoch.
 Mittel:
Der Schweregrad aller GUI-Bugs ist mittel.
  Niedrig:
Der Testingenieur hat auch die Möglichkeit, den Vorschlag zu machen. Der Vorschlag
wird also in Form eines Fehlers gemeldet, bei dem der Schweregrad niedrig ist.

Priorität:

Die Priorität beschreibt, in welcher Reihenfolge der Fehler vom Entwickler behoben werden
muss. Basierend auf dem Schweregrad wird der Testingenieur dem Fehler wie folgt Priorität
einräumen

Schweregrad Priorität

Blocker/Dringend/Kritisch P1

Sehr hoch P2

Hoch P3

Mittel P4

Niedrig P5

Beschreibung:

Die detaillierten Schritte zum Produzieren/Erhalten des Fehlers werden hier beschrieben.
Basierend auf den Schritten wird der Entwickler prüfen, ob es sich wirklich um einen Fehler
handelt oder nicht.

Screenshot:

Der Testingenieur erstellt den Screenshot des Fehlers und lädt ihn in die Fehlervorlage hoch. Es
soll beweisen, dass der gemeldete Fehler gültig ist, und auch um den Fehler zu verstehen.

Build-Version:

Die Build-Nummer, auf der der Testingenieur den Fehler identifiziert hat, wird hier beschrieben.

Gemeldet von:
Der Testingenieur, der den Fehler identifiziert hat, wird hier beschreiben.

Zuweisen an:Der Name des Entwicklers oder des Entwicklers, der den Fehler beheben wird,
wird hier beschrieben.

Bemerkungen:

Beide Testingenieure, Entwickler können die Fragen in Form von Kommentaren stellen.

Hinweis:Die XL-Datei-Berichterstattung wird viel Zeit in Anspruch nehmen, daher ist es unser
Plan, die Berichterstattungstools zu verwenden.

Bsp.:

Fehlertitel
FEH /
Phase LER- Zusamme Schwer Priorit
n ID nfassung Status egrad ät Fehlerbeschreibung Screenshot

Anwendung 1. Öffnen Sie

zeigt nicht Spicejet.com 2. Klicken Sie auf das
beide Optionsfeld Roundtrip
Datumsausw 3. Die Anwendung zeigt nicht beide
I 1 ahlen an Neu Blocker P1 Datumsauswahlen an D:\Nagesh\SPicejet_Lo

Der Spicejet- 1. Öffnen Sie

Name wird Spicejet.com 2. Beachten Sie das
als Spacejet Spicejet-Logo 3. Seine Darstellung als
II 2 angezeigt Neu Mittel P4 Spacejet D:\Nagesh\SPicejet_Lo
Einweg-
Radio-
Button wird 1. Öffnen Sie
nicht Spicejet.com 2. Einweg-Radio-Button
III 3 angezeigt Neu VeryHigh P2 ist nicht verfügbar Pfad
Das
Kontrollkäst
chen für
Studenten 1. Öffnen Sie
ist nicht Spicejet.com 2. Das Kontrollkästchen
I 4 verfügbar Neu Hoch P3 für Studenten ist nicht verfügbar Pfad
Cheange die
Farbe der
Spicejet-
Homepage
II 5 auf blau Neu Niedrig P5 1. Öffnen Sie Spicejet.com Pfad
 Der Spicejet-
Club-Link 1. Öffnen Sie
navigiert Spicejet.com 2. Klicken Sie auf den
nicht zur Link Spiceje Connect
Spicejet- 3. Spiceje Connect-Link navigiert
III 6 Club-Seite Neu Blocker P1 nicht zur MySpicetrip-Seite Pfad

1. Öffnen Sie
http://selenium4testing.com/hms 2.
Melden Sie sich bei der Anwendung
Anwendung an
wird nicht 3. Klicken Sie auf Registrierung
gewartet suchen
I 7 GUI Neu Mittel P4 4. Anwendung pflegt GUI nicht Spicejet_GUI.png

Die 1. Öffnen Sie

Benutzerobe http://selenium4testing.com/hms 2.
rfläche der Melden Sie sich mit user1/user1 bei
Zulassungsar hms an
beitsliste 3. Klicken Sie auf ADT
wird nicht 4. Klicken Sie auf
ordnungsge Zulassungsarbeitsliste 5. Beachten
mäß Sie die GUI, die nicht
II 8 gepflegt Neu Mittel p4 ordnungsgemäß gewartet wird D:\Nagesh\hms_ADW

Erwachsene 1. Öffnen Sie

nfeld wird http://spicejet.com 2. Beachten Sie
nicht auf der alle Felder
Seite 3. Dropdown-Menü für Erwachsene
III 9 angezeigt Neu Blocker P1 ist nicht verfügbar D:\Nagesh\Spicejet\Sp

Anwendung
zeigt 1. Öffnen Sie
Hyderabad http://spicejet.com 2. Klicken Sie auf
und LeavingFrom Feld
Bangalore 3. Anwendung zeigt Hyderabad und
I 1 nicht an Neu VeryHigh P2 Bangalore nicht an D:\Nagesh\Spicejet\Sp
F: Was ist der Unterschied zwischen Schweregrad und Priorität?

F: Was ist der Unterschied zwischen Priorität in Testfällen und Priorität in der Fehlervorlage?

F.Wenn der Entwickler Ihren Fehler nicht akzeptiert, wie werden Sie dann beweisen, dass
Ihr Fehler gültig ist?

A: Basierend auf der Fehlerbeschreibung, dem SRS-Dokument und dem Screenshot

werden wir versuchen zu beweisen, dass der Fehler gültig ist, wenn er nicht akzeptiert wird,
dann werde ich das Serverprotokoll nehmen, um zu beweisen, dass der Fehler gültig ist,
wenn er immer noch nicht akzeptiert wird, und dann werde ich ihn an einen BA,
Projektmanager und schließlich an den Kunden senden.

F. Erklären Sie das Szenario, in dem der Fehler einen hohen Schweregrad mit niedriger
Priorität und eine niedrige Sicherheit mit hoher Priorität aufweist?

A: Dringlichkeitspriorität

Blocker - P1

Hohe Sicherheit Sehr hoch - P2 Hohe Priorität

Hoch - P3
 Mittel - P4

Niedrige Sicherheit Niedrig - P5 Niedrige

Priorität

Wir haben zwei Fehler, einer ist Blocker, der andere ist mittelgroß. Der Blocker wird
eine hohe Priorität haben und Medium wird eine niedrige Priorität haben.

Basierend auf dem Schweregrad wird der Test Engg.. Priorität geben. Basierend auf der
Priorität ist das Entwicklerteam dafür verantwortlich,

Aber der Entwicklungsleiter hat die Möglichkeit, die Priorität zu ändern, abhängig von
der Situation.

 Die Fehler, die mit der aktuellen Phasenlieferung zusammenhängen, werden

unabhängig vom Schweregrad mit hoher Priorität konvertiert.
 Die Fehler, die nicht Teil der aktuellen Lieferung sind, werden unabhängig vom
Schweregrad mit niedriger Priorität konvertiert.

Phase Bug Id Fehlertitel/Zusammenfassung Status Priorität

I. 1. Spice Jetname zeigt New Medium P4---P1 an

Als Space Jet

2. 2. Spice Jet Connect Link ist kein neuer Blocker P1----

P4

Navigation der SPICE-JET-Connect-Seite

Prüfbericht/Baustatusbericht:

Sobald die Testfallausführung für den Build abgeschlossen ist, ist der Testingenieur
dafür verantwortlich, einen Testbericht sowohl an den Lead als auch an den Kunden zu
senden. Es ist unterhalb des Formats
Baustatusbericht/Prüfbericht

Statusbericht / Testbericht erstellen

 Test Engg Name:
Build-Nr. 1
Anmeldedaten
Browser FF, IE GoogleChrome

Testmatrik
Gesamtzahl der Testfälle 200
Anzahl der durchgeführten
Testfälle 150
Anzahl der ausstehenden
Testfälle 50
Anzahl der Testfälle Bestanden 100
Anzahl der Testfälle Nicht
bestanden 50
Anzahl der übersprungenen
Testfälle 10
Anzahl der gemeldeten Fehler 3

Testmetriken:

Metriken bedeutet Messung der Aufgabe. Testmetriken sind Messungen der Tests.

Ausstehend:

Wenn der Entwickler überhaupt keine Funktionalität bereitstellt, können diese Testfälle nicht
ausgeführt werden. Es ist ausstehend.

Übersprungen:

Der Entwickler hat die Funktionalität bereitgestellt, aber wir können die
Funktionalitäten nicht testen, da die abhängigen Funktionalitäten fehlgeschlagen sind.

Beispiel: Wenn die Anmeldung fehlgeschlagen ist, können wir Compose nicht ausführen.

Die Erstellung von Testfällen wird übersprungen.

 Das Reporting wird fortgesetzt, bis der Build stabil ist, was bedeutet, dass die Mehrheit
der Testfälle bestanden ist und keine Blocker-Bugs im Reporting-Tool verfügbar sind.
 Der stabile Build wird an den Kunden geliefert.

F: Erklären Sie mir die Berichtsstruktur in Ihrer Organisation

Melden Sie die Fehler mithilfe von Reporting-Tools:

 Jedes Berichtstool mit zwei Arten von Benutzern: Einer ist Admin-Benutzer und ein
anderer ist Endbenutzer.
  Admin-Benutzer: Der Admin-Benutzer ist dafür verantwortlich, das Projekt zu erstellen,
Benutzer wie Testingenieure, Entwickler usw. zu erstellen. Er wird den Benutzer dem
Projekt zuordnen
 Endbenutzer: Er ist dafür verantwortlich, die Fehler zu verwenden (zu melden) oder zu
empfangen, z. B. Testingenieure, Entwickler usw.

Bsp.: QC, JIRA, Bugzilla, Redmine, Testmanager usw.…

BugZilla:

 Greifen Sie mit selenium4testing.com auf den Bugzilla zu

 Dann klicken Sie auf Bugzilla.
 Melden Sie sich als Testingenieur beim Bugzilla an (jan30selenium@gmail.com&
Passwort : selenium)
 Durch die Verwendung von Bugzilla können wir die folgenden Aktivitäten ausführen.
a. Einen Fehler melden.
b. Suche nach den Fehlern.
c. Wir können den Bericht annehmen.
d. Präferenz.

Einführung in Bugzilla
Was ist Bugzilla?
Bugzilla ist ein Open-Source-Problem-/Bug-Tracking-System, das es Entwicklern
ermöglicht, ausstehende Probleme mit ihrem Produkt effektiv zu verfolgen. Es ist
in Perl geschrieben und verwendet MYSQL-DATENBANK.

Bugzilla ist ein Fehler-Tracking-Tool, das jedoch als Testmanagement-

Tool verwendet werden kann, da es leicht mit anderen Testfall-Management-Tools
wie Quality Center, Testlink usw. verknüpft werden kann.

Dieser offene Bug-Tracker ermöglicht es Benutzern, mit ihren Kunden oder

Mitarbeitern in Verbindung zu bleiben und über Probleme in der gesamten
Datenverwaltungskette effektiv zu kommunizieren.

Zu den wichtigsten Funktionen von Bugzilla gehören

 Erweiterte Suchfunktionen
 E-Mail-Benachrichtigungen
 Bugs per E-Mail ändern/ablegen
 Zeiterfassung
 Starke Sicherheit
 Anpassung

Wie logge ich mich bei Bugzilla ein?

Schritt 1) Um ein Konto in Bugzilla zu erstellen oder sich in das bestehende Konto
einzuloggen, gehen Sie im Hauptmenü zu Neues Konto oder Anmelden .

Schritt 2) Geben Sie nun Ihre persönlichen Daten ein, um sich bei Bugzilla anzumelden

1. Benutzer-ID: jan30selenium@gmail.com
2. Passwort: selenium
3. Und dann klicken Sie auf "Anmelden"
Schritt 3) Sie sind erfolgreich im Bugzilla-System angemeldet

Erstellen eines Bug-Reports in Bugzilla

Schritt 1) Um einen neuen Bug in Bugzilla zu erstellen, besuchen Sie die Homepage
von Bugzilla und klicken Sie im Hauptmenü auf die NEUE REGISTERKARTE
Klicken Sie auf den Link Neu, dann öffnet die Anwendung das nächste Fenster wie unten.

Schritt 2) Im nächsten Fenster

Klicken Sie auf den Projektnamen wie HMS, dann öffnet die Anwendung ein neues
Fenster mit folgenden Optionen

1. Produkt eingeben
2. Komponente eingeben
3. Komponentenbeschreibung angeben
4. Version auswählen,
5. Schweregrad auswählen
6. Hardware auswählen
7. Betriebssystem auswählen
8. Zusammenfassung eingeben
9. Beschreibung eingeben
10. Anhang anhängen
11. Senden

HINWEIS: Die obigen Felder variieren je nach Ihrer Anpassung von Bugzilla

Geben Sie alle erforderlichen Felder in Bezug auf Ihren Fehler wie folgt ein,
Wenn Sie Anhänge zu Ihrem Meldefehler haben, können Sie diese anhängen, indem Sie auf die Schaltfläche
„Anhang hinzufügen“ und dann auf die Schaltfläche „Bestätigen“ am Ende der Seite klicken, um Ihren Fehler
zu melden.

Schritt 4) Fehler wird erstellt ID# 208 wird unserem Fehler zugewiesen. Sie können dem zugewiesenen
Fehler auch zusätzliche Informationen wie URL, Schlüsselwörter, Whiteboard, Tags usw. hinzufügen. Diese
zusätzlichen Informationen sind hilfreich, um mehr Details über den von Ihnen erstellten Fehler zu geben.

1. Großes Textfeld
2. URL
3. Whiteboard
4. Keywords
5. Tags
6. Abhängig von
7. Blöcke
8. Anhänge
Schritt 5) Im selben Fenster, wenn Sie weiter nach unten scrollen. Sie können das Stichtag und auch den Status
des Fehlers auswählen.Die Frist in Bugzilla gibt in der Regel die Frist an, um den Fehler in einem
bestimmten Zeitrahmen zu beheben.
Grafische Berichte erstellen

Grafische Berichte sind eine Möglichkeit, den aktuellen Status der Fehlerdatenbank anzuzeigen. Sie können
Berichte entweder über eine HTML-Tabelle oder eine grafische zeilen-/torten-/balkendiagrammbasierte
Tabelle ausführen. Die Idee hinter dem grafischen Bericht in Bugzilla besteht darin, eine Reihe von Fehlern
über die Standard-Suchoberfläche zu definieren und dann einen Aspekt dieses Satzes für die Darstellung auf
der horizontalen und vertikalen Achse auszuwählen. Sie können auch einen 3-dimensionalen Bericht erhalten,
indem Sie die Option "Mehrere Seiten" wählen.

Berichte sind in vielerlei Hinsicht hilfreich, zum Beispiel, wenn Sie wissen möchten, welche Komponente die
größte Anzahl von gemeldeten Fehlern aufweist. Um dies in der Grafik darzustellen, können Sie den
Schweregrad auf der X-Achse und die Komponente auf der Y-Achse auswählen und dann auf Bericht erstellen
klicken. Es wird ein Bericht mit wichtigen Informationen erstellt.

1. Klicken Sie oben im Fenster wie folgt auf Berichte

2. Klicken Sie auf Grafische Berichte

Die Seite mit den grafischen Berichten wird wie folgt angezeigt,
Wählen Sie Vertikale Achse als Schweregrad und Horizontale Achse als Priorität oder was auch immer
Sie möchten, Sie können es auswählen und Sie erhalten einen entsprechenden grafischen Bericht.

 Erstellen Sie einen Bericht mit erweiterten Funktionen, indem Sie weitere Details zum Fehler wie
folgt eingeben
Die folgende Grafik zeigt die Balkendiagrammdarstellung für den Fehler-Schweregrad in
der Komponente "Widget-Getriebe". In der folgenden Grafik sind die schwerwiegendsten Fehler oder
Blocker in Komponenten 88, während Fehler mit normalem Schweregrad mit 667 an der Spitze stehen.

Browse-Funktion

Schritt 1) Um Ihren Fehler zu finden, verwenden wir die Suchfunktion. Klicken Sie im Hauptmenü auf die
Schaltfläche Suchen.
Das Reporting wird so lange fortgesetzt, bis der Build stabil ist. Sobald sein Stall an den
Kunden geliefert wird, dann Liefer- und Wartungsphase empfehlen

Sobald der Build erfolgreich an den Kunden geliefert wurde, erstellt der Testleiter
einen Testzusammenfassungsbericht, der im Testplan aktualisiert und zum Zeitpunkt der
Lieferung des Builds an den Kunden gesendet wird.

TESTZUSAMMENFASSUNGSBERICHT /BUILD-POST-MARTUM-BERICHT

 Anzahl der vom Entwicklerteam veröffentlichten Builds - 50

 Anzahl der vom Testteam akzeptierten Builds - 25
 Anzahl der vom Testteam abgelehnten Builds - 25
 Anzahl der vom Testteam erstellten Testfälle - 1000
 P1 - 500, P2- 350, P3-100, P4-50

 Anzahl der identifizierten Fehler - 400

o Blocker - 100
o Sehr hoch - 150
o Hoch - 100
o Mittel - 40
o Niedrig - 10
 Anzahl der vom Kunden identifizierten Fehler - 100
 o Blocker - 10
o Sehr hoch - 50
o Hoch - 10
o Mittel - 10
o Niedrig - 20
 Erfolgsgeschichten
 Herausforderungen

F : Was sind die Eingangskriterien(Startkriterien) für die Prüfung und die

Ausgangskriterien(Endkriterien) für die Prüfung?

A: Prüfplan und SRS-Dokument sind die Eingangskriterien der Prüfung.

Es gibt kein Ende für Tests. Es wird fortgesetzt, solange der Build live ist. Die Testaktivitäten
ändern sich jedoch, nachdem der Build an den Kunden geliefert wurde. Während der Wartung
werden nicht alle Funktionstests durchgeführt. Wir werden die Regressionstests durchführen.

Terminologie
Gleichrangig bedeutet der Teamkollege mit gleicher
Bezeichnung. Alle Kollegen werden an einem
Meeting teilnehmen und über das Projekt
diskutieren, um Klarheit über alle Module zu
erhalten. Das Ziel des Peer-Reviews ist es, bei
jedem Test-Engagement funktionales Wissen über
Peer Review alle Module zu erlangen.
Während des Peer-Reviews wird der Senior Peer
das Dokument zum Peer-Review vorbereiten, das
Peer-Review-Bericht als Peer-Review-Bericht bekannt ist
Wenn das gleiche Peer-Review vor dem Lead oder
Projektmanager durchgeführt wird, wird dies als
"Durchgehen" bezeichnet. Der Leiter oder PM wird
beobachten, ob die Teammitglieder das Projekt
Durchgehen richtig verstehen oder nicht
Während der Walk-Through-Bericht erstellt wird,
wird das Dokument als Walk-Through-Bericht
Bericht durchgehen bezeichnet
Die Kombination mehrerer Testfälle wird als
Test-Suite Testsuite bezeichnet
Die Kombination aus Testsuite und Testumgebung
Prüfstand wird als Testbed bezeichnet
Täglicher Statusbericht.
Täglich müssen wir unseren Arbeitsstatus in einer
DSR Vorlage an den Lead senden
 Sitzungsprotokoll.
Wann immer wir an einer Besprechung teilnehmen,
wird die Besprechungsdiskussion in eine grobe
Notiz aufgenommen. Später wird es in einer E-Mail
aktualisiert und die E-Mail wird an alle
Teammitglieder gesendet. Der Zweck von MOM ist
es, die Transparenz über das Treffen zwischen den
MAMA Teammitgliedern aufrechtzuerhalten
Der Prozess der Überprüfung, ob das Unternehmen
die Richtlinien befolgt oder nicht. Die Inspektion
Inspektion erfolgt ohne Andeutung
Es ist auch der Prozess der Überprüfung, ob das
Unternehmen die Richtlinien befolgt oder nicht. Das
Audit Audit wird mit vorheriger Ankündigung durchgeführt
Stabil bedeutet, dass keine weiteren
Aktualisierungen erforderlich sind.
Stabiler Build bedeutet, dass die Mehrheit der
Testfälle bestanden wird und keine Blocker-Bugs im
Stabil Build identifiziert werden
AUT Anwendung im Test
Wenn der Build abgelehnt wird, analysiert der
Entwickler den Fehler. Wenn er den gleichen Build
erneut für das Testteam freigibt, ohne neue
Funktionalitäten hinzuzufügen, wird dies als
PatchBuild bezeichnet.
Wenn der Entwickler den Build mit einigen neuen
Funktionen veröffentlicht, wird dies als neuer Build
Patch-Build bezeichnet
Stellen Sie es den Zielbenutzern zur Verfügung.
Sobald das Testfälle- oder SRS-Dokument auf der
Basis ausgekleidet ist, wird es im zentralen
Repository für Zielbenutzer eingecheckt. Es ist
Veröffentlichen bekannt als veröffentlichen
Konstruktionsbedingte Fehler werden als Defekt
bezeichnet. Bsp.:
GUI-Defekte Funktionsbedingte Fehler sind Fehler
(Programmiererfehler).
Beispiel: Alle funktionalen Fehler
Fehler: Ausnahmen im Skript werden als Fehler
Fehler bezeichnet
Der Anwendungsfall ist eine Liste von Schritten, die
typischerweise Interaktionen zwischen einer Rolle
(bekannt als "Akteur") und einem System definieren,
um ein Ziel zu erreichen. Der Akteur kann ein
Testingenieur oder Endbenutzer sein.
Die Anforderungen werden von der BA in eine Liste
Anwendungsfälle von Schritten umgewandelt
Nichtkonformitätsberichte oder
Nichtkonformitätsänderungsanforderung. Die
NCR Anforderung, die erörtert wird
Korrekturmaßnahmen werden als Reaktion auf
Kundenbeschwerden umgesetzt
Vorbeugende Maßnahmen werden als Reaktion
auf die Identifizierung potenzieller Quellen
CAPA umgesetzt
 Im Software-Engineering ist das Software-
Konfigurationsmanagement (SCM oder SWCM) die
Aufgabe, Änderungen in der Software zu verfolgen
und zu steuern. Zu den SCM-Praktiken gehören die
Revisionskontrolle und die Festlegung von
SCM Basislinien.
SDN Software Lieferschein
Subsiding. Weg von der Aufgabe
Die Anzahl der Tage, an denen Sie von der
Schlupf Aufgabe abgerutscht sind
Defektes Produkt Das Produkt mit Mängeln
Das Fehleralter (in Zeit) ist die Zeitdifferenz
zwischen dem Datum, an dem ein Fehler gemeldet
wurde, und dem aktuellen Datum (wenn der Fehler
noch offen ist) oder dem Datum, an dem der Fehler
behoben wurde (wenn der Fehler bereits behoben
Defektalter ist).
Latente Defekte Versteckter Defekt
Produktportfoliomanagement ist die zentralisierte
Verwaltung der Prozesse, Methoden und
Technologien, die von Projektmanagern verwendet
PPM werden
PPR Berichte zur Überprüfung der Programmleistung
MRM Marketing-Ressourcenmanagement