Softwaretests - Kurzanleitung

Was ist Testen?

Beim Testen wird ein System oder seine Komponente (n) bewertet, um festzustellen, ob es die angegebenen Anforderungen erfüllt oder nicht. Mit einfachen Worten, beim Testen wird ein System ausgeführt, um Lücken, Fehler oder fehlende Anforderungen zu identifizieren, die den tatsächlichen Anforderungen widersprechen.

Gemäß dem ANSI / IEEE 1059-Standard kann das Testen definiert werden als - ein Prozess zum Analysieren eines Softwareelements, um die Unterschiede zwischen vorhandenen und erforderlichen Bedingungen (dh Defekten / Fehlern / Fehlern) zu erkennen und die Merkmale des Softwareelements zu bewerten.

Wer testet?

Dies hängt vom Prozess und den zugehörigen Stakeholdern der Projekte ab. In der IT-Branche haben große Unternehmen ein Team, das dafür verantwortlich ist, die entwickelte Software im Kontext der gegebenen Anforderungen zu bewerten. Darüber hinaus führen Entwickler auch Tests durch, die aufgerufen werdenUnit Testing. In den meisten Fällen sind die folgenden Fachleute daran beteiligt, ein System innerhalb ihrer jeweiligen Kapazitäten zu testen:

Software-Tester
Softwareentwickler
Projektleiter / Manager
Endbenutzer

Verschiedene Unternehmen haben unterschiedliche Bezeichnungen für Personen, die die Software auf der Grundlage ihrer Erfahrung und ihres Wissens testen, z. B. Software-Tester, Software-Qualitätssicherungsingenieur, QS-Analyst usw.

Es ist zu keinem Zeitpunkt während des Zyklus möglich, die Software zu testen. In den nächsten beiden Abschnitten wird angegeben, wann der Test gestartet werden soll und wann er während des SDLC beendet werden soll.

Wann soll mit dem Testen begonnen werden?

Ein früher Testbeginn reduziert die Kosten und die Zeit für die Überarbeitung und Erstellung fehlerfreier Software, die an den Kunden geliefert wird. Im Software Development Life Cycle (SDLC) können die Tests jedoch ab der Phase der Anforderungserfassung gestartet und bis zur Bereitstellung der Software fortgesetzt werden.

Dies hängt auch vom verwendeten Entwicklungsmodell ab. Im Wasserfallmodell werden beispielsweise formale Tests in der Testphase durchgeführt. Im inkrementellen Modell wird der Test jedoch am Ende jedes Inkrements / jeder Iteration durchgeführt, und die gesamte Anwendung wird am Ende getestet.

Die Tests werden in jeder Phase der SDLC in verschiedenen Formen durchgeführt -

Während der Anforderungserfassungsphase wird die Analyse und Überprüfung von Anforderungen auch als Prüfung betrachtet.
Die Überprüfung des Entwurfs in der Entwurfsphase mit der Absicht, den Entwurf zu verbessern, wird ebenfalls als Test betrachtet.
Tests, die von einem Entwickler nach Fertigstellung des Codes durchgeführt werden, werden ebenfalls als Tests eingestuft.

Wann sollte der Test abgebrochen werden?

Es ist schwierig zu bestimmen, wann der Test abgebrochen werden soll, da das Testen ein nie endender Prozess ist und niemand behaupten kann, dass eine Software zu 100% getestet wurde. Die folgenden Aspekte sind zu berücksichtigen, um den Testprozess zu stoppen:

Testfristen
Abschluss der Testfallausführung
Abschluss der Funktions- und Codeabdeckung bis zu einem bestimmten Punkt
Die Fehlerrate unterschreitet ein bestimmtes Niveau und es werden keine Fehler mit hoher Priorität identifiziert
Managemententscheidung

Überprüfung und Validierung

Diese beiden Begriffe sind für die meisten Menschen, die sie austauschbar verwenden, sehr verwirrend. In der folgenden Tabelle werden die Unterschiede zwischen Verifizierung und Validierung hervorgehoben.

Sr.Nr.	Überprüfung	Validierung
1	Die Überprüfung behebt das Problem: "Bauen Sie es richtig?"	Die Validierung behebt das Problem: "Bauen Sie das Richtige?"
2	Stellt sicher, dass das Softwaresystem alle Funktionen erfüllt.	Stellt sicher, dass die Funktionen dem beabsichtigten Verhalten entsprechen.
3	Die Überprüfung erfolgt zuerst und umfasst die Überprüfung auf Dokumentation, Code usw.	Die Validierung erfolgt nach der Überprüfung und umfasst hauptsächlich die Überprüfung des Gesamtprodukts.
4	Von Entwicklern gemacht.	Von Testern gemacht.
5	Es verfügt über statische Aktivitäten, einschließlich des Sammelns von Überprüfungen, exemplarischen Vorgehensweisen und Inspektionen zur Überprüfung einer Software.	Es verfügt über dynamische Aktivitäten, einschließlich der Ausführung der Software gemäß den Anforderungen.
6	Es ist ein objektiver Prozess und es sollte keine subjektive Entscheidung erforderlich sein, um eine Software zu verifizieren.	Es ist ein subjektiver Prozess und beinhaltet subjektive Entscheidungen darüber, wie gut eine Software funktioniert.

Im Folgenden sind einige der häufigsten Mythen über Softwaretests aufgeführt.

Mythos 1: Testen ist zu teuer

Reality- Es gibt ein Sprichwort: Bezahlen Sie weniger für Tests während der Softwareentwicklung oder zahlen Sie später mehr für Wartung oder Korrektur. Frühes Testen spart in vielerlei Hinsicht Zeit und Kosten. Eine Reduzierung der Kosten ohne Testen kann jedoch zu einem fehlerhaften Design einer Softwareanwendung führen, wodurch das Produkt unbrauchbar wird.

Mythos 2: Testen ist zeitaufwändig

Reality- Während der SDLC-Phasen ist das Testen niemals ein zeitaufwändiger Prozess. Das Diagnostizieren und Beheben der beim ordnungsgemäßen Testen festgestellten Fehler ist jedoch eine zeitaufwändige, aber produktive Aktivität.

Mythos 3: Es werden nur vollständig entwickelte Produkte getestet

Reality- Zweifellos hängt das Testen vom Quellcode ab, aber das Überprüfen der Anforderungen und das Entwickeln von Testfällen ist unabhängig vom entwickelten Code. Ein iterativer oder inkrementeller Ansatz als Entwicklungslebenszyklusmodell kann jedoch die Abhängigkeit des Testens von der vollständig entwickelten Software verringern.

Mythos 4: Vollständige Tests sind möglich

Reality- Es wird zu einem Problem, wenn ein Kunde oder Tester glaubt, dass ein vollständiger Test möglich ist. Es ist möglich, dass alle Pfade vom Team getestet wurden, aber das Auftreten vollständiger Tests ist niemals möglich. Es kann einige Szenarien geben, die während des Softwareentwicklungszyklus niemals vom Testteam oder vom Client ausgeführt werden und nach der Bereitstellung des Projekts ausgeführt werden.

Mythos 5: Eine getestete Software ist fehlerfrei

Reality - Dies ist ein weit verbreiteter Mythos, an den Kunden, Projektmanager und das Managementteam glauben. Niemand kann mit absoluter Sicherheit behaupten, dass eine Softwareanwendung zu 100% fehlerfrei ist, selbst wenn ein Tester mit hervorragenden Testfähigkeiten die Anwendung getestet hat .

Mythos 6: Fehlende Fehler sind auf Tester zurückzuführen

Reality- Es ist kein korrekter Ansatz, Tester für Fehler verantwortlich zu machen, die auch nach dem Testen in der Anwendung verbleiben. Dieser Mythos bezieht sich auf Zeit, Kosten und Anforderungen, die Einschränkungen ändern. Die Teststrategie kann jedoch auch dazu führen, dass Fehler vom Testteam übersehen werden.

Mythos 7: Tester sind für die Produktqualität verantwortlich

Reality- Es ist eine sehr häufige Fehlinterpretation, dass nur Tester oder das Testteam für die Produktqualität verantwortlich sein sollten. Zu den Aufgaben der Tester gehört die Identifizierung von Fehlern gegenüber den Stakeholdern. Anschließend entscheiden sie, ob sie den Fehler beheben oder die Software freigeben. Die Veröffentlichung der Software zu diesem Zeitpunkt setzt die Tester stärker unter Druck, da sie für Fehler verantwortlich gemacht werden.

Mythos 8: Testautomatisierung sollte nach Möglichkeit verwendet werden, um die Zeit zu verkürzen

Reality- Ja, es stimmt, dass Testautomatisierung die Testzeit verkürzt, aber es ist zu keinem Zeitpunkt während der Softwareentwicklung möglich, die Testautomatisierung zu starten. Der Testautomat sollte gestartet werden, wenn die Software manuell getestet wurde und bis zu einem gewissen Grad stabil ist. Darüber hinaus kann die Testautomatisierung niemals verwendet werden, wenn sich die Anforderungen ständig ändern.

Mythos 9: Jeder kann eine Softwareanwendung testen

Reality- Leute außerhalb der IT-Branche denken und glauben sogar, dass jeder eine Software testen kann und das Testen kein kreativer Job ist. Tester wissen jedoch sehr gut, dass dies ein Mythos ist. Wenn Sie an alternative Szenarien denken und versuchen, eine Software zum Absturz zu bringen, um potenzielle Fehler zu untersuchen, ist dies für die Person, die sie entwickelt hat, nicht möglich.

Mythos 10: Die einzige Aufgabe eines Testers besteht darin, Fehler zu finden

Reality- Das Auffinden von Fehlern in einer Software ist Aufgabe der Tester, gleichzeitig sind sie jedoch Domänenexperten der jeweiligen Software. Entwickler sind nur für die spezifische Komponente oder den Bereich verantwortlich, der ihnen zugewiesen ist. Die Tester verstehen jedoch die Gesamtfunktion der Software, die Abhängigkeiten und die Auswirkungen eines Moduls auf ein anderes Modul.

Testen, Qualitätssicherung und Qualitätskontrolle

Die meisten Menschen sind verwirrt, wenn es darum geht, die Unterschiede zwischen Qualitätssicherung, Qualitätskontrolle und Prüfung festzustellen. Obwohl sie miteinander verbunden sind und zu einem gewissen Grad, können sie als dieselben Aktivitäten betrachtet werden, aber es gibt Unterscheidungsmerkmale, die sie auszeichnen. In der folgenden Tabelle sind die Punkte aufgeführt, die QA, QC und Testen unterscheiden.

Qualitätskontrolle	Qualitätskontrolle	Testen
Die Qualitätssicherung umfasst Aktivitäten, die die Implementierung von Prozessen, Verfahren und Standards im Zusammenhang mit der Überprüfung der entwickelten Software und der beabsichtigten Anforderungen sicherstellen.	Es umfasst Aktivitäten, die die Überprüfung einer entwickelten Software in Bezug auf dokumentierte (oder in einigen Fällen nicht) Anforderungen sicherstellen.	Es umfasst Aktivitäten, die die Identifizierung von Fehlern / Fehlern / Defekten in einer Software sicherstellen.
Konzentriert sich auf Prozesse und Verfahren, anstatt tatsächliche Tests am System durchzuführen.	Konzentriert sich auf das eigentliche Testen durch Ausführen der Software mit dem Ziel, Fehler durch die Implementierung von Verfahren und Prozessen zu identifizieren.	Konzentriert sich auf das eigentliche Testen.
Prozessorientierte Aktivitäten.	Produktorientierte Aktivitäten.	Produktorientierte Aktivitäten.
Vorbeugende Aktivitäten.	Es ist ein Korrekturprozess.	Es ist ein vorbeugender Prozess.
Es ist eine Teilmenge des Software Test Life Cycle (STLC).	QC kann als Teilmenge der Qualitätssicherung betrachtet werden.	Testen ist die Teilmenge der Qualitätskontrolle.

Audit und Inspektion

Audit- Es ist ein systematischer Prozess, um zu bestimmen, wie der eigentliche Testprozess innerhalb einer Organisation oder eines Teams durchgeführt wird. Im Allgemeinen handelt es sich um eine unabhängige Prüfung der Prozesse, die beim Testen einer Software beteiligt sind. Gemäß IEEE handelt es sich um eine Überprüfung dokumentierter Prozesse, die Organisationen implementieren und befolgen. Zu den Prüfungsarten gehören Legal Compliance Audit, Internal Audit und System Audit.

Inspection- Es handelt sich um eine formale Technik, bei der formelle oder informelle technische Überprüfungen von Artefakten durchgeführt werden, indem Fehler oder Lücken identifiziert werden. Gemäß IEEE94 ist die Inspektion eine formale Bewertungstechnik, bei der Softwareanforderungen, -designs oder -codes von einer anderen Person oder Gruppe als dem Autor eingehend untersucht werden, um Fehler, Verstöße gegen Entwicklungsstandards und andere Probleme zu erkennen.

Formelle Inspektionsbesprechungen können die folgenden Prozesse umfassen: Planung, Übersichtsvorbereitung, Inspektionsbesprechung, Nacharbeit und Nachverfolgung.

Testen und Debuggen

Testing- Es geht darum, Fehler in einer Software zu identifizieren, ohne sie zu korrigieren. Normalerweise sind Fachleute mit einem Hintergrund in der Qualitätssicherung an der Identifizierung von Fehlern beteiligt. Der Test wird in der Testphase durchgeführt.

Debugging- Es beinhaltet das Identifizieren, Isolieren und Beheben der Probleme / Fehler. Entwickler, die die Software codieren, führen das Debuggen durch, wenn ein Fehler im Code auftritt. Das Debuggen ist Teil von White Box Testing oder Unit Testing. Das Debuggen kann in der Entwicklungsphase während der Durchführung von Unit-Tests oder in Phasen während der Behebung der gemeldeten Fehler durchgeführt werden.

Viele Unternehmen auf der ganzen Welt entwickeln und implementieren unterschiedliche Standards, um die Qualitätsanforderungen ihrer Software zu verbessern. In diesem Kapitel werden einige der weit verbreiteten Standards für Qualitätssicherung und -prüfung kurz beschrieben.

ISO / IEC 9126

Dieser Standard behandelt die folgenden Aspekte, um die Qualität einer Softwareanwendung zu bestimmen:

Qualitätsmodell
Externe Metriken
Interne Metriken
Metriken für die Verwendungsqualität

Dieser Standard enthält einige Qualitätsattribute für jede Software wie -

Functionality
Reliability
Usability
Efficiency
Maintainability
Portability

Die oben genannten Qualitätsmerkmale sind weiter in Unterfaktoren unterteilt, die Sie untersuchen können, wenn Sie den Standard im Detail studieren.

ISO / IEC 9241-11

Teil 11 dieser Norm befasst sich mit dem Umfang, in dem ein Produkt von bestimmten Benutzern verwendet werden kann, um bestimmte Ziele mit Wirksamkeit, Effizienz und Zufriedenheit in einem bestimmten Verwendungskontext zu erreichen.

Dieser Standard schlug ein Framework vor, das die Usability-Komponenten und die Beziehung zwischen ihnen beschreibt. In diesem Standard wird die Benutzerfreundlichkeit in Bezug auf Benutzerleistung und Zufriedenheit berücksichtigt. Gemäß ISO 9241-11 hängt die Benutzerfreundlichkeit vom Verwendungskontext ab, und der Grad der Benutzerfreundlichkeit ändert sich, wenn sich der Kontext ändert.

ISO / IEC 25000: 2005

ISO / IEC 25000: 2005 ist allgemein als Standard bekannt, der die Richtlinien für Softwarequalitätsanforderungen und -bewertung (SQuaRE) enthält. Dieser Standard hilft bei der Organisation und Verbesserung des Prozesses in Bezug auf Softwarequalitätsanforderungen und deren Bewertungen. In Wirklichkeit ersetzt ISO-25000 die beiden alten ISO-Standards, dh ISO-9126 und ISO-14598.

SQuaRE ist in Unterteile wie - unterteilt

ISO 2500n - Abteilung Qualitätsmanagement
ISO 2501n - Abteilung für Qualitätsmodelle
ISO 2502n - Abteilung Qualitätsmessung
ISO 2503n - Abteilung Qualitätsanforderungen
ISO 2504n - Abteilung Qualitätsbewertung

Die Hauptinhalte von SQuaRE sind -

Begriffe und Definitionen
Referenzmodelle
Allgemeiner Reiseführer
Einzelne Abteilungsführer
Standard in Bezug auf Requirement Engineering (dh Spezifikations-, Planungs-, Mess- und Bewertungsprozess)

ISO / IEC 12119

Dieser Standard behandelt Softwarepakete, die an den Kunden geliefert werden. Es konzentriert sich nicht auf den Produktionsprozess der Kunden. Der Hauptinhalt bezieht sich auf die folgenden Elemente -

Anforderungen für Softwarepakete.
Anweisungen zum Testen eines gelieferten Softwarepakets anhand der angegebenen Anforderungen.

Verschiedenes

Einige der anderen Standards in Bezug auf QS- und Testprozesse sind unten aufgeführt -

Sr.Nr.	Standard & Beschreibung
1	IEEE 829 Ein Standard für das Format von Dokumenten, die in verschiedenen Phasen des Softwaretests verwendet werden.
2	IEEE 1061 Eine Methode zur Festlegung von Qualitätsanforderungen, zur Identifizierung, Implementierung, Analyse und Validierung des Prozesses und des Produkts von Softwarequalitätsmetriken.
3	IEEE 1059 Leitfaden für Softwareüberprüfungs- und -validierungspläne.
4	IEEE 1008 Ein Standard für Unit-Tests.
5	IEEE 1012 Ein Standard für die Softwareüberprüfung und -validierung.
6	IEEE 1028 Ein Standard für Software-Inspektionen.
7	IEEE 1044 Ein Standard zur Klassifizierung von Softwareanomalien.
8	IEEE 1044-1 Ein Leitfaden zur Klassifizierung von Software-Anomalien.
9	IEEE 830 Ein Leitfaden zum Entwickeln von Systemanforderungsspezifikationen.
10	IEEE 730 Ein Standard für Software-Qualitätssicherungspläne.
11	IEEE 1061 Ein Standard für Softwarequalitätsmetriken und -methoden.
12	IEEE 12207 Ein Standard für Software-Lebenszyklusprozesse und Lebenszyklusdaten.
13	BS 7925-1 Ein Vokabular von Begriffen, die beim Testen von Software verwendet werden.
14	BS 7925-2 Ein Standard für das Testen von Softwarekomponenten.

In diesem Abschnitt werden die verschiedenen Testarten beschrieben, mit denen eine Software während der SDLC getestet werden kann.

Manuelles Testen

Manuelles Testen umfasst das manuelle Testen einer Software, dh ohne Verwendung eines automatisierten Tools oder eines Skripts. Bei diesem Typ übernimmt der Tester die Rolle eines Endbenutzers und testet die Software, um unerwartetes Verhalten oder Fehler zu identifizieren. Es gibt verschiedene Phasen für manuelle Tests, z. B. Unit-Tests, Integrationstests, Systemtests und Benutzerakzeptanztests.

Tester verwenden Testpläne, Testfälle oder Testszenarien, um eine Software zu testen und die Vollständigkeit der Tests sicherzustellen. Manuelle Tests umfassen auch Erkundungstests, da Tester die Software untersuchen, um Fehler darin zu identifizieren.

Automatisierungstests

Beim Automatisierungstest, der auch als Testautomatisierung bezeichnet wird, schreibt der Tester Skripte und verwendet eine andere Software zum Testen des Produkts. Dieser Prozess beinhaltet die Automatisierung eines manuellen Prozesses. Automatisierungstests werden verwendet, um die Testszenarien erneut auszuführen, die manuell, schnell und wiederholt durchgeführt wurden.

Neben Regressionstests werden auch Automatisierungstests verwendet, um die Anwendung unter Last-, Leistungs- und Belastungsgesichtspunkten zu testen. Es erhöht die Testabdeckung, verbessert die Genauigkeit und spart Zeit und Geld im Vergleich zu manuellen Tests.

Was ist zu automatisieren?

Es ist nicht möglich, alles in einer Software zu automatisieren. Die Bereiche, in denen ein Benutzer Transaktionen wie das Anmeldeformular oder Registrierungsformulare ausführen kann, sollten automatisiert werden. Jeder Bereich, in dem eine große Anzahl von Benutzern gleichzeitig auf die Software zugreifen kann.

Darüber hinaus können alle GUI-Elemente, Verbindungen mit Datenbanken, Feldvalidierungen usw. durch Automatisierung des manuellen Prozesses effizient getestet werden.

Wann automatisieren?

Testautomatisierung sollte unter Berücksichtigung der folgenden Aspekte einer Software verwendet werden:

Große und kritische Projekte
Projekte, bei denen dieselben Bereiche häufig getestet werden müssen
Anforderungen ändern sich nicht häufig
Zugriff auf die Anwendung für Last und Leistung mit vielen virtuellen Benutzern
Stabile Software für manuelle Tests
Verfügbarkeit von Zeit

Wie automatisiere ich?

Die Automatisierung erfolgt mithilfe einer unterstützenden Computersprache wie VB-Scripting und einer automatisierten Softwareanwendung. Es stehen viele Tools zum Schreiben von Automatisierungsskripten zur Verfügung. Bevor wir die Tools erwähnen, lassen Sie uns den Prozess identifizieren, mit dem der Testprozess automatisiert werden kann.

Identifizieren von Bereichen innerhalb einer Software für die Automatisierung
Auswahl des geeigneten Tools für die Testautomatisierung
Testskripte schreiben
Entwicklung von Testanzügen
Ausführung von Skripten
Erstellen Sie Ergebnisberichte
Identifizieren Sie mögliche Fehler oder Leistungsprobleme

Software-Test-Tools

Die folgenden Tools können für Automatisierungstests verwendet werden:

HP Quick Test Professional
Selenium
IBM Rational Functional Tester
SilkTest
TestComplete
Überall testen
WinRunner
LoadRunner
Visual Studio Test Professional
WATIR

Es gibt verschiedene Methoden, die zum Testen von Software verwendet werden können. In diesem Kapitel werden die verfügbaren Methoden kurz beschrieben.

Black-Box-Tests

Die Testtechnik ohne Kenntnis des Innenlebens der Anwendung wird als Black-Box-Test bezeichnet. Der Tester kennt die Systemarchitektur nicht und hat keinen Zugriff auf den Quellcode. Während eines Black-Box-Tests interagiert ein Tester normalerweise mit der Benutzeroberfläche des Systems, indem er Eingaben bereitstellt und Ausgaben untersucht, ohne zu wissen, wie und wo die Eingaben bearbeitet werden.

In der folgenden Tabelle sind die Vor- und Nachteile von Black-Box-Tests aufgeführt.

Vorteile	Nachteile
Gut geeignet und effizient für große Codesegmente.	Begrenzte Abdeckung, da nur eine ausgewählte Anzahl von Testszenarien tatsächlich durchgeführt wird.
Codezugriff ist nicht erforderlich.	Ineffizientes Testen aufgrund der Tatsache, dass der Tester nur begrenzte Kenntnisse über eine Anwendung hat.
Trennt die Benutzerperspektive durch sichtbar definierte Rollen klar von der Entwicklerperspektive.	Blinde Abdeckung, da der Tester nicht auf bestimmte Codesegmente oder fehleranfällige Bereiche abzielen kann.
Eine große Anzahl von mäßig erfahrenen Testern kann die Anwendung ohne Kenntnisse der Implementierung, Programmiersprache oder Betriebssysteme testen.	Die Testfälle sind schwer zu entwerfen.

White-Box-Tests

White-Box-Tests sind die detaillierte Untersuchung der internen Logik und Struktur des Codes. White-Box-Tests werden auch genanntglass testing oder open-box testing. Um durchzuführenwhite-box Beim Testen einer Anwendung muss ein Tester die internen Abläufe des Codes kennen.

Der Tester muss einen Blick in den Quellcode werfen und herausfinden, welche Einheit / welcher Teil des Codes sich unangemessen verhält.

In der folgenden Tabelle sind die Vor- und Nachteile von White-Box-Tests aufgeführt.

Vorteile	Nachteile
Da der Tester den Quellcode kennt, ist es sehr einfach herauszufinden, welcher Datentyp beim effektiven Testen der Anwendung hilfreich sein kann.	Aufgrund der Tatsache, dass ein erfahrener Tester für die Durchführung von White-Box-Tests benötigt wird, erhöhen sich die Kosten.
Es hilft bei der Optimierung des Codes.	Manchmal ist es unmöglich, in jede Ecke zu schauen, um versteckte Fehler herauszufinden, die Probleme verursachen können, da viele Pfade ungetestet bleiben.
Zusätzliche Codezeilen können entfernt werden, was zu versteckten Fehlern führen kann.	Es ist schwierig, White-Box-Tests aufrechtzuerhalten, da spezielle Tools wie Codeanalysatoren und Debugging-Tools erforderlich sind.
Aufgrund des Wissens des Testers über den Code wird beim Schreiben des Testszenarios eine maximale Abdeckung erreicht.

Gray-Box-Test

Gray-Box-Tests sind eine Technik zum Testen der Anwendung mit begrenzten Kenntnissen der internen Funktionsweise einer Anwendung. Je mehr Sie beim Testen von Software wissen, desto besser ist beim Testen einer Anwendung das Gewicht.

Das Beherrschen der Domäne eines Systems gibt dem Tester immer einen Vorteil gegenüber jemandem mit begrenzten Domänenkenntnissen. Im Gegensatz zu Black-Box-Tests, bei denen der Tester nur die Benutzeroberfläche der Anwendung testet. Beim Gray-Box-Test hat der Tester Zugriff auf Entwurfsdokumente und die Datenbank. Mit diesem Wissen kann ein Tester bessere Testdaten und Testszenarien vorbereiten, während er einen Testplan erstellt.

Vorteile	Nachteile
Bietet nach Möglichkeit kombinierte Vorteile von Black-Box- und White-Box-Tests.	Da der Zugriff auf den Quellcode nicht verfügbar ist, ist die Möglichkeit, den Code und die Testabdeckung zu überprüfen, eingeschränkt.
Gray-Box-Tester verlassen sich nicht auf den Quellcode. Stattdessen stützen sie sich auf die Definition der Schnittstelle und die Funktionsspezifikationen.	Die Tests können redundant sein, wenn der Software-Designer bereits einen Testfall ausgeführt hat.
Basierend auf den begrenzten verfügbaren Informationen kann ein Gray-Box-Tester hervorragende Testszenarien entwerfen, insbesondere in Bezug auf Kommunikationsprotokolle und Datentypverarbeitung.	Das Testen jedes möglichen Eingabestreams ist unrealistisch, da dies unangemessen viel Zeit in Anspruch nehmen würde. Daher bleiben viele Programmpfade ungetestet.
Der Test wird aus Sicht des Benutzers und nicht des Designers durchgeführt.

Ein Vergleich der Testmethoden

In der folgenden Tabelle sind die Punkte aufgeführt, die zwischen Black-Box-Tests, Gray-Box-Tests und White-Box-Tests unterscheiden.

Black-Box-Tests	Gray-Box-Test	White-Box-Tests
Die internen Abläufe einer Anwendung müssen nicht bekannt sein.	Der Tester hat nur begrenzte Kenntnisse über die internen Abläufe der Anwendung.	Der Tester verfügt über umfassende Kenntnisse der internen Funktionsweise der Anwendung.
Wird auch als Closed-Box-Test, datengesteuertes Testen oder Funktionstest bezeichnet.	Wird auch als durchscheinendes Testen bezeichnet, da der Tester nur begrenzte Kenntnisse über die Innenseiten der Anwendung hat.	Wird auch als Clear-Box-Test, Strukturtest oder Code-basierter Test bezeichnet.
Wird von Endbenutzern sowie von Testern und Entwicklern durchgeführt.	Wird von Endbenutzern sowie von Testern und Entwicklern durchgeführt.	Normalerweise von Testern und Entwicklern durchgeführt.
Das Testen basiert auf externen Erwartungen - Das interne Verhalten der Anwendung ist unbekannt.	Die Tests werden auf der Grundlage von übergeordneten Datenbankdiagrammen und Datenflussdiagrammen durchgeführt.	Die internen Abläufe sind vollständig bekannt und der Tester kann die Testdaten entsprechend gestalten.
Es ist erschöpfend und am wenigsten zeitaufwändig.	Teilweise zeitaufwändig und erschöpfend.	Die umfassendste und zeitaufwändigste Art von Tests.
Nicht zum Testen von Algorithmen geeignet.	Nicht zum Testen von Algorithmen geeignet.	Geeignet für Algorithmus-Tests.
Dies kann nur durch Ausprobieren erfolgen.	Falls bekannt, können Datendomänen und interne Grenzen getestet werden.	Datendomänen und interne Grenzen können besser getestet werden.

Während des Testprozesses gibt es verschiedene Ebenen. In diesem Kapitel wird eine kurze Beschreibung dieser Ebenen gegeben.

Die Teststufen umfassen verschiedene Methoden, die beim Durchführen von Softwaretests verwendet werden können. Die Hauptstufen der Softwaretests sind -

Funktionsprüfung
Nichtfunktionale Tests

Funktionsprüfung

Dies ist eine Art Black-Box-Test, der auf den Spezifikationen der zu testenden Software basiert. Die Anwendung wird durch Bereitstellung von Eingaben getestet und anschließend werden die Ergebnisse untersucht, die der Funktionalität entsprechen müssen, für die sie vorgesehen war. Die Funktionsprüfung einer Software wird auf einem vollständigen, integrierten System durchgeführt, um die Konformität des Systems mit den festgelegten Anforderungen zu bewerten.

Beim Testen einer Anwendung auf Funktionalität sind fünf Schritte erforderlich.

Schritte	Beschreibung
ich	Die Bestimmung der Funktionalität, die die beabsichtigte Anwendung ausführen soll.
II	Die Erstellung von Testdaten basierend auf den Spezifikationen der Anwendung.
III	Die Ausgabe basiert auf den Testdaten und den Spezifikationen der Anwendung.
IV	Das Schreiben von Testszenarien und die Ausführung von Testfällen.
V.	Der Vergleich von tatsächlichen und erwarteten Ergebnissen basierend auf den ausgeführten Testfällen.

Bei einer effektiven Testpraxis werden die oben genannten Schritte auf die Testrichtlinien jeder Organisation angewendet, und daher wird sichergestellt, dass die Organisation die strengsten Standards in Bezug auf die Softwarequalität einhält.

Unit Testing

Diese Art von Tests wird von Entwicklern durchgeführt, bevor das Setup an das Testteam übergeben wird, um die Testfälle formell auszuführen. Unit-Tests werden von den jeweiligen Entwicklern an den einzelnen Einheiten der zugewiesenen Quellcode-Bereiche durchgeführt. Die Entwickler verwenden Testdaten, die sich von den Testdaten des Qualitätssicherungsteams unterscheiden.

Ziel des Unit-Tests ist es, jeden Teil des Programms zu isolieren und zu zeigen, dass einzelne Teile hinsichtlich Anforderungen und Funktionalität korrekt sind.

Einschränkungen beim Unit-Test

Das Testen kann nicht jeden einzelnen Fehler in einer Anwendung abfangen. Es ist unmöglich, jeden Ausführungspfad in jeder Softwareanwendung zu bewerten. Gleiches gilt für Unit-Tests.

Die Anzahl der Szenarien und Testdaten, mit denen ein Entwickler einen Quellcode überprüfen kann, ist begrenzt. Nachdem alle Optionen ausgeschöpft sind, bleibt keine andere Wahl, als den Komponententest zu beenden und das Codesegment mit anderen Einheiten zusammenzuführen.

Integrationstests

Integrationstests sind definiert als das Testen kombinierter Teile einer Anwendung, um festzustellen, ob sie ordnungsgemäß funktionieren. Integrationstests können auf zwei Arten durchgeführt werden: Bottom-up-Integrationstests und Top-down-Integrationstests.

Sr.Nr.	Integrationstestmethode
1	Bottom-up integration Dieser Test beginnt mit dem Testen von Einheiten, gefolgt von Tests von zunehmend höheren Kombinationen von Einheiten, die als Module oder Builds bezeichnet werden.
2	Top-down integration Bei diesem Test werden zuerst die Module der höchsten Ebene und danach schrittweise die Module der unteren Ebene getestet.

In einer umfassenden Softwareentwicklungsumgebung werden Bottom-Up-Tests normalerweise zuerst durchgeführt, gefolgt von Top-Down-Tests. Der Prozess endet mit mehreren Tests der gesamten Anwendung, vorzugsweise in Szenarien, die tatsächliche Situationen nachahmen sollen.

Systemtests

Systemtests testen das gesamte System. Sobald alle Komponenten integriert sind, wird die gesamte Anwendung streng getestet, um sicherzustellen, dass sie den angegebenen Qualitätsstandards entspricht. Diese Art der Prüfung wird von einem spezialisierten Prüfteam durchgeführt.

Systemtests sind aus folgenden Gründen wichtig:

Systemtests sind der erste Schritt im Software Development Life Cycle, in dem die Anwendung als Ganzes getestet wird.
Die Anwendung wird gründlich getestet, um sicherzustellen, dass sie den funktionalen und technischen Spezifikationen entspricht.
Die Anwendung wird in einer Umgebung getestet, die sich sehr nahe an der Produktionsumgebung befindet, in der die Anwendung bereitgestellt wird.
Durch Systemtests können wir sowohl die Geschäftsanforderungen als auch die Anwendungsarchitektur testen, verifizieren und validieren.

Regressionstests

Wenn eine Änderung an einer Softwareanwendung vorgenommen wird, ist es durchaus möglich, dass andere Bereiche innerhalb der Anwendung von dieser Änderung betroffen sind. Regressionstests werden durchgeführt, um sicherzustellen, dass ein behobener Fehler nicht zu einer anderen Funktionalität oder einem Verstoß gegen Geschäftsregeln geführt hat. Mit Regressionstests soll sichergestellt werden, dass eine Änderung, z. B. eine Fehlerbehebung, nicht dazu führt, dass ein weiterer Fehler in der Anwendung aufgedeckt wird.

Regressionstests sind aus folgenden Gründen wichtig:

Minimieren Sie die Testlücken, wenn eine Anwendung mit vorgenommenen Änderungen getestet werden muss.
Testen der neuen Änderungen, um sicherzustellen, dass die vorgenommenen Änderungen keinen anderen Bereich der Anwendung betreffen.
Reduziert Risiken, wenn Regressionstests für die Anwendung durchgeführt werden.
Die Testabdeckung wird erhöht, ohne die Zeitpläne zu beeinträchtigen.
Erhöhen Sie die Geschwindigkeit, um das Produkt zu vermarkten.

Abnahmetests

Dies ist wohl die wichtigste Art der Prüfung, da sie vom Qualitätssicherungsteam durchgeführt wird, das beurteilt, ob die Anwendung den beabsichtigten Spezifikationen entspricht und die Anforderungen des Kunden erfüllt. Das QA-Team verfügt über eine Reihe vorab geschriebener Szenarien und Testfälle, die zum Testen der Anwendung verwendet werden.

Weitere Ideen werden über die Anwendung ausgetauscht, und es können weitere Tests durchgeführt werden, um die Genauigkeit und die Gründe für die Initiierung des Projekts zu beurteilen. Abnahmetests sollen nicht nur auf einfache Rechtschreibfehler, kosmetische Fehler oder Schnittstellenlücken hinweisen, sondern auch auf Fehler in der Anwendung, die zu Systemabstürzen oder schwerwiegenden Fehlern in der Anwendung führen.

Durch die Durchführung von Abnahmetests für eine Anwendung reduziert das Testteam die Leistung der Anwendung in der Produktion. Es gibt auch gesetzliche und vertragliche Anforderungen für die Annahme des Systems.

Alpha-Test

Dieser Test ist die erste Testphase und wird zwischen den Teams (Entwickler- und QS-Teams) durchgeführt. Unit-Tests, Integrationstests und Systemtests werden in Kombination als Alpha-Tests bezeichnet. In dieser Phase werden folgende Aspekte in der Anwendung getestet:

Rechtschreibfehler
Kaputte Links
Bewölkte Richtungen
Die Anwendung wird auf Computern mit der niedrigsten Spezifikation getestet, um Ladezeiten und Latenzprobleme zu testen.

Beta-test

Dieser Test wird durchgeführt, nachdem der Alpha-Test erfolgreich durchgeführt wurde. Beim Betatest testet eine Stichprobe der Zielgruppe die Anwendung. Beta-Tests werden auch als bezeichnetpre-release testing. Beta-Testversionen von Software werden idealerweise an ein breites Publikum im Web verteilt, teils um dem Programm einen "realen" Test zu geben, teils um eine Vorschau auf die nächste Version zu geben. In dieser Phase wird das Publikum Folgendes testen:

Benutzer werden die Anwendung installieren, ausführen und ihr Feedback an das Projektteam senden.
Tippfehler, verwirrender Anwendungsfluss und sogar Abstürze.
Nachdem das Projektteam das Feedback erhalten hat, kann es die Probleme beheben, bevor die Software für die tatsächlichen Benutzer freigegeben wird.
Je mehr Probleme Sie beheben, um echte Benutzerprobleme zu lösen, desto höher ist die Qualität Ihrer Anwendung.
Eine qualitativ hochwertigere Anwendung, wenn Sie sie für die breite Öffentlichkeit freigeben, erhöht die Kundenzufriedenheit.

Nichtfunktionale Tests

Dieser Abschnitt basiert auf dem Testen einer Anwendung anhand ihrer nicht funktionalen Attribute. Bei nicht funktionsfähigen Tests wird eine Software anhand der Anforderungen getestet, die nicht funktionsfähig, aber wichtig sind, wie Leistung, Sicherheit, Benutzeroberfläche usw.

Einige der wichtigen und häufig verwendeten nicht funktionalen Testtypen werden unten diskutiert.

Leistungstest

Es wird hauptsächlich verwendet, um Engpässe oder Leistungsprobleme zu identifizieren, anstatt Fehler in einer Software zu finden. Es gibt verschiedene Ursachen, die dazu beitragen, die Leistung einer Software zu verringern -

Netzwerkverzögerung
Clientseitige Verarbeitung
Verarbeitung von Datenbanktransaktionen
Lastausgleich zwischen Servern
Datenwiedergabe

Leistungstests werden in Bezug auf die folgenden Aspekte als einer der wichtigsten und obligatorischen Testtypen angesehen:

Geschwindigkeit (dh Reaktionszeit, Datenwiedergabe und Zugriff)
Capacity
Stability
Scalability

Leistungstests können entweder qualitativ oder quantitativ sein und können in verschiedene Untertypen unterteilt werden, wie z Load testing und Stress testing.

Lasttest

Es ist ein Prozess zum Testen des Verhaltens einer Software durch Anwenden einer maximalen Last in Bezug auf Software, die auf große Eingabedaten zugreift und diese bearbeitet. Dies kann sowohl unter normalen als auch unter Spitzenlastbedingungen erfolgen. Diese Art des Testens identifiziert die maximale Kapazität von Software und ihr Verhalten zu Spitzenzeiten.

In den meisten Fällen werden Lasttests mithilfe automatisierter Tools wie Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer und Visual Studio Load Test usw. durchgeführt.

Virtuelle Benutzer (VUsers) werden im automatisierten Testtool definiert und das Skript wird ausgeführt, um die Lasttests für die Software zu überprüfen. Die Anzahl der Benutzer kann je nach den Anforderungen gleichzeitig oder schrittweise erhöht oder verringert werden.

Belastbarkeitstest

Stresstests umfassen das Testen des Verhaltens einer Software unter abnormalen Bedingungen. Dies kann beispielsweise das Entfernen einiger Ressourcen oder das Anwenden einer Last über das tatsächliche Lastlimit hinaus umfassen.

Ziel von Stresstests ist es, die Software zu testen, indem die Last auf das System aufgebracht und die von der Software zur Ermittlung der Bruchstelle verwendeten Ressourcen übernommen werden. Dieser Test kann durchgeführt werden, indem verschiedene Szenarien getestet werden, wie z.

Herunterfahren oder Neustarten von Netzwerkports nach dem Zufallsprinzip
Ein- oder Ausschalten der Datenbank
Ausführen verschiedener Prozesse, die Ressourcen wie CPU, Speicher, Server usw. verbrauchen

Usability-Tests

Usability-Tests sind eine Black-Box-Technik und werden verwendet, um Fehler und Verbesserungen in der Software zu identifizieren, indem die Benutzer durch ihre Verwendung und ihren Betrieb beobachtet werden.

Laut Nielsen kann die Benutzerfreundlichkeit anhand von fünf Faktoren definiert werden: Effizienz der Nutzung, Lernfähigkeit, Gedächtnisfähigkeit, Fehler / Sicherheit und Zufriedenheit. Ihm zufolge wird die Verwendbarkeit eines Produkts gut sein und das System ist verwendbar, wenn es die oben genannten Faktoren besitzt.

Nigel Bevan und Macleod waren der Ansicht, dass Benutzerfreundlichkeit die Qualitätsanforderung ist, die als Ergebnis von Interaktionen mit einem Computersystem gemessen werden kann. Diese Anforderung kann erfüllt werden und der Endbenutzer wird zufrieden sein, wenn die beabsichtigten Ziele mit dem Einsatz geeigneter Ressourcen effektiv erreicht werden.

Molich erklärte im Jahr 2000, dass ein benutzerfreundliches System die folgenden fünf Ziele erfüllen sollte: leicht zu erlernen, leicht zu merken, effizient zu bedienen, zufriedenstellend zu bedienen und leicht zu verstehen.

Zusätzlich zu den verschiedenen Definitionen der Benutzerfreundlichkeit gibt es einige Standards und Qualitätsmodelle und -methoden, die die Benutzerfreundlichkeit in Form von Attributen und Unterattributen wie ISO-9126, ISO-9241-11, ISO-13407 und IEEE std definieren. 610.12 usw.

UI vs Usability-Tests

Beim Testen der Benutzeroberfläche wird die grafische Benutzeroberfläche der Software getestet. UI-Tests stellen sicher, dass die GUI gemäß den Anforderungen funktioniert und hinsichtlich Farbe, Ausrichtung, Größe und anderen Eigenschaften getestet wird.

Auf der anderen Seite gewährleisten Usability-Tests eine gute und benutzerfreundliche Benutzeroberfläche, die einfach zu handhaben ist. UI-Tests können als Teil von Usability-Tests betrachtet werden.

Sicherheitstests

Sicherheitstests umfassen das Testen einer Software, um etwaige Mängel und Lücken unter Sicherheits- und Schwachstellengesichtspunkten zu identifizieren. Nachfolgend sind die Hauptaspekte aufgeführt, die Sicherheitstests gewährleisten sollten:

Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
Software ist sicher gegen bekannte und unbekannte Schwachstellen
Softwaredaten sind sicher
Software entspricht allen Sicherheitsbestimmungen
Eingabeprüfung und -validierung
SQL-Einfügungsangriffe
Einspritzfehler
Probleme bei der Sitzungsverwaltung
Cross-Site-Scripting-Angriffe
Puffer läuft über Schwachstellen
Directory Traversal-Angriffe

Portabilitätstests

Portabilitätstests umfassen das Testen einer Software mit dem Ziel, ihre Wiederverwendbarkeit sicherzustellen und sicherzustellen, dass sie auch von einer anderen Software verschoben werden kann. Im Folgenden sind die Strategien aufgeführt, die für Portabilitätstests verwendet werden können:

Übertragen einer installierten Software von einem Computer auf einen anderen.
Erstellen einer ausführbaren Datei (.exe), um die Software auf verschiedenen Plattformen auszuführen.

Portabilitätstests können als einer der Unterteile des Systemtests betrachtet werden, da dieser Testtyp das Gesamttest einer Software hinsichtlich ihrer Verwendung in verschiedenen Umgebungen umfasst. Computerhardware, Betriebssysteme und Browser stehen im Mittelpunkt der Portabilitätstests. Einige der Voraussetzungen für Portabilitätstests sind folgende:

Software sollte unter Berücksichtigung der Portabilitätsanforderungen entworfen und codiert werden.
An den zugehörigen Komponenten wurden Unit-Tests durchgeführt.
Integrationstests wurden durchgeführt.
Testumgebung wurde eingerichtet.

Die Testdokumentation umfasst die Dokumentation von Artefakten, die vor oder während des Testens von Software entwickelt werden sollten.

Die Dokumentation für Softwaretests hilft bei der Schätzung des erforderlichen Testaufwands, der Testabdeckung, der Nachverfolgung / Rückverfolgung von Anforderungen usw. In diesem Abschnitt werden einige der häufig verwendeten dokumentierten Artefakte im Zusammenhang mit Softwaretests beschrieben, z.

Versuchsplan
Testszenario
Testfall
Rückverfolgbarkeitsmatrix

Versuchsplan

In einem Testplan werden die Strategie zum Testen einer Anwendung, die verwendeten Ressourcen, die Testumgebung, in der die Tests durchgeführt werden, sowie die Einschränkungen der Tests und der Zeitplan für die Testaktivitäten beschrieben. In der Regel ist der Leiter des Qualitätssicherungsteams für die Erstellung eines Testplans verantwortlich.

Ein Testplan enthält Folgendes:

Einführung in das Testplandokument
Annahmen beim Testen der Anwendung
Liste der Testfälle, die beim Testen der Anwendung enthalten sind
Liste der zu testenden Funktionen
Welche Art von Ansatz beim Testen der Software zu verwenden
Liste der zu testenden Ergebnisse
Die zum Testen der Anwendung zugewiesenen Ressourcen
Alle während des Testprozesses verbundenen Risiken
Ein Zeitplan mit zu erreichenden Aufgaben und Meilensteinen

Testszenario

Es handelt sich um eine einzeilige Anweisung, die angibt, welcher Bereich in der Anwendung getestet wird. Mithilfe von Testszenarien wird sichergestellt, dass alle Prozessabläufe von Ende zu Ende getestet werden. Ein bestimmter Bereich einer Anwendung kann je nach Größe und Komplexität der Anwendung nur ein Testszenario bis zu einigen hundert Szenarien aufweisen.

Die Begriffe "Testszenario" und "Testfälle" werden synonym verwendet. Ein Testszenario besteht jedoch aus mehreren Schritten, während ein Testfall aus einem einzigen Schritt besteht. Aus dieser Perspektive betrachtet sind Testszenarien Testfälle, enthalten jedoch mehrere Testfälle und die Reihenfolge, in der sie ausgeführt werden sollen. Abgesehen davon hängt jeder Test von der Ausgabe des vorherigen Tests ab.

Testfall

Testfälle umfassen eine Reihe von Schritten, Bedingungen und Eingaben, die beim Ausführen von Testaufgaben verwendet werden können. Mit dieser Aktivität soll vor allem sichergestellt werden, ob eine Software hinsichtlich ihrer Funktionalität und anderer Aspekte erfolgreich ist oder nicht. Es gibt viele Arten von Testfällen, z. B. funktionale, negative, fehlerhafte, logische Testfälle, physische Testfälle, UI-Testfälle usw.

Darüber hinaus werden Testfälle geschrieben, um die Testabdeckung einer Software zu verfolgen. Im Allgemeinen gibt es keine formalen Vorlagen, die beim Schreiben von Testfällen verwendet werden können. Die folgenden Komponenten sind jedoch immer verfügbar und in jedem Testfall enthalten -

Testfall-ID
Produktmodul
Produktversion
Versionsgeschichte
Purpose
Assumptions
Pre-conditions
Steps
Erwartetes Ergebnis
Tatsächliches Ergebnis
Post-conditions

Viele Testfälle können aus einem einzigen Testszenario abgeleitet werden. Darüber hinaus werden manchmal mehrere Testfälle für eine einzelne Software geschrieben, die zusammen als Testsuiten bezeichnet werden.

Rückverfolgbarkeitsmatrix

Die Rückverfolgbarkeitsmatrix (auch als Anforderungsrückverfolgbarkeitsmatrix - RTM bezeichnet) ist eine Tabelle, mit der die Anforderungen während des Softwareentwicklungslebenszyklus verfolgt werden. Es kann für die Vorwärtsverfolgung (dh von Anforderungen zu Design oder Codierung) oder rückwärts (dh von Codierung zu Anforderungen) verwendet werden. Es gibt viele benutzerdefinierte Vorlagen für RTM.

Jede Anforderung im RTM-Dokument ist mit dem zugehörigen Testfall verknüpft, sodass die Tests gemäß den genannten Anforderungen durchgeführt werden können. Darüber hinaus ist die Bug-ID enthalten und mit den zugehörigen Anforderungen und dem Testfall verknüpft. Die Hauptziele für diese Matrix sind -

Stellen Sie sicher, dass die Software gemäß den genannten Anforderungen entwickelt wurde.
Hilft bei der Suche nach der Grundursache eines Fehlers.
Hilft bei der Rückverfolgung der entwickelten Dokumente in verschiedenen Phasen der SDLC.

Die Schätzung des Testaufwands ist eine der wichtigsten und wichtigsten Aufgaben von SDLC. Die richtige Schätzung hilft beim Testen der Software mit maximaler Abdeckung. In diesem Abschnitt werden einige der Techniken beschrieben, die bei der Abschätzung des zum Testen erforderlichen Aufwands hilfreich sein können.

Funktionspunktanalyse

Diese Methode basiert auf der Analyse der funktionalen Benutzeranforderungen der Software mit den folgenden Kategorien:

Outputs
Inquiries
Inputs
Interne Dateien
Externe Dateien

Testpunktanalyse

Dieser Schätzprozess wird für die Funktionspunktanalyse für Black-Box- oder Abnahmetests verwendet. Die Hauptelemente dieser Methode sind: Größe, Produktivität, Strategie, Schnittstelle, Komplexität und Einheitlichkeit.

Mark-II-Methode

Es ist eine Schätzmethode, die zum Analysieren und Messen der Schätzung basierend auf der Funktionsansicht des Endbenutzers verwendet wird. Das Verfahren für die Mark-II-Methode ist wie folgt:

Bestimmen Sie den Standpunkt
Zweck und Art der Zählung
Definieren Sie die Zählgrenze
Identifizieren Sie die logischen Transaktionen
Identifizieren und Kategorisieren von Datenentitätstypen
Zählen Sie die Eingabedatenelementtypen
Zählen Sie die Funktionsgröße

Verschiedenes

Sie können andere gängige Schätztechniken verwenden, z.

Delphi Technik
Analogiebasierte Schätzung
Auf Testfällen basierende Schätzung
Aufgabenbasierte (aktivitätsbasierte) Schätzung
IFPUG-Methode