Modell eines Testplans

Modell eines Testplans

Übersetzt vom Link:
[Link]

1. EINLEITUNG

1.1. Übersicht des Systems „X“

Das Ziel dieser Phase des Projekts ist die Implementierung einer neuen Plattform des Systems "X", die ermöglichen wird:

Entfernung von Legacy-Bürosystemen

Einführung in "ABC"
Verarbeitung besonderer Transaktionen
Fehlen von Beschränkungen am Fangort
Erfassung von Transaktionen für andere Verarbeitungssysteme
Neuer Versöhnungsprozess
Positionierung für die Währung der Europäischen Union und zukünftige Initiativen

Dieses Programm wird zu erheblichen Veränderungen in den aktuellen Abteilungs- und Interprozessen führen.
Büro. Die Funktion wird in Phasen geliefert.

Die Phase 1 wird die folgenden Merkmale beinhalten:

Ersatz des Legacy-Systems A

Neues System der Versöhnung
Outsourcing-System für Abteilungen in verschiedenen europäischen Ländern
Neue/überarbeitete Merkmale der Prüfung und Recherche

[Detaillierte Ergänzungen sind weiter unten in diesem Dokument aufgeführt]

1.2. Zweck dieses Dokuments

Dieses Dokument soll als Entwurf des Testansatzes (Strategie) für das Projekt dienen.
Entwicklung von Geschäftssystemen.

Die Vorbereitung auf diesen Test besteht aus drei Hauptphasen:

Der Testansatz (Strategie) definiert den Umfang des Systemtests, die allgemeine Strategie, die verfolgt werden soll.
adoptiert, die abzuschließenden Aktivitäten, die erforderlichen allgemeinen Ressourcen und die Methoden und
Prozesse, die zur Testung der Version eingesetzt werden sollen. Sie beschreibt auch die Aktivitäten, Abhängigkeiten und
Aufwände, die erforderlich sind, um den Systemtest durchzuführen.
Der Testplan beschreibt die Aktivitäten, Abhängigkeiten und erforderlichen Ressourcen, um durchzuführen
der Systemtest.

Die Bedingungen/Fälle des Testdokuments dokumentieren die durchzuführenden Tests, die Daten, die zu verwenden sind.
verarbeitet, die automatisierte Testabdeckung und die erwarteten Ergebnisse.

Qualität und Test von Software Seite 1

 Modell eines Testplans

1.3. Formale Überprüfung

Es gibt mehrere formale Überprüfungspunkte vor und während des Systemtests. Dies ist ein wesentlicher Bestandteil für
ein qualitativ hochwertiges Produkt erreichen.

1.3.1. Formale Überprüfungspunkte erfolgen am Ende der Erstellung von:

1. Zeichnungsdokumentation
2. Testansatz
3. Pläne für Unit-Tests
4. Bedingungen und Ergebnisse des Unit-Tests
5. Bedingungen des Systemtests
6. Fortschritt des Systemtests
7. Überprüfung nach dem Systemtest

1.4. Ziele des Systemtests

Auf einem hohen Niveau zielt der Systemtest darauf ab zu beweisen, dass:

Die Funktionalität, die vom Entwicklungsteam geliefert wurde, entspricht den Spezifikationen.
des Geschäft im Dokument der Geschäftsspezifikationen und der Dokumentation von
Anforderungen.

Die Software ist von hoher Qualität; die Software wird die Geschäftsprozesse ersetzen/unterstützen.
gewünschten und die von der Firma für die Entwicklung neuer geforderten Standards zu erreichen
Systeme.

Die gelieferte Software hat die richtige Schnittstelle zu den bestehenden Systemen, einschließlich Windows 98.

[Detaillierte Ziele sind weiter unten in diesem Dokument aufgeführt]

1.4.1. Einbindung der Software-Qualitätssicherung

Das obenstehende "V"-Modell zeigt den idealen Testprozess, bei dem die Testvorbereitung beginnt, sobald die
Die Anforderungsermittlung wird erstellt. Die Systemtestplanung begann in einer frühen Phase, und

Qualität und Test von Software Seite 2

 Modell eines Testplans

Aus diesem Grund wird der Systemtest von Qualitätsinitiativen während des Lebenszyklus profitieren.
Projekt.

Die Verantwortlichkeiten zwischen der Abteilung für Software-Qualitätssicherung (SQA) und der Abteilung
do Projekt sind folgende:

Unit-Tests liegen in der Verantwortung des Entwicklungsteams

Systemtests liegen in der Verantwortung der Software-Qualitätssicherung.
Benutzereinverständnistests liegen in der Verantwortung des Benutzervertreterteams.
Technologische Konformitätstests liegen in der Verantwortung des Installations- und Supportteams von
Systeme

2. UMFANG UND ZIELE

2.1. Umfang des Testansatzes – Funktionen des Systems
2.1.1. INKLUSIONEN (UMFANG)

Der Inhalt dieser Version ist:

Liefergegenstände der Phase 1

Der neue und überarbeitete Transaktionsprozess mit automatisierter Unterstützung

Neue Prozesse für Kundenanfragen und Systeme
Überarbeiteter Prozess der internen Büroleitungsaudits
Neuzuweisung von Ausnahmen an die Zentrale
Neues zentrales Agenturmanagementsystem
Überarbeitetes Verfahren zur Verwaltung von Fragen
Der überprüfte Prozess der Rückgewinnungen
Neuer internationaler Versöhnungsprozess
oNovo Prozess der Buchhaltungsabstimmung

2.1.2. AUSSCHLÜSSE (NICHT IM GEBIET)

Wenn der Umfang jeder Phase vereinbart und abgeschlossen ist, werden Änderungen nicht mehr berücksichtigt.
Version, außer:

(1) Wo es ausdrückliche Genehmigung und Zustimmung des Business Analysts und des Testanalysten gibt;

(2) Wo die Änderungen/Ergänzungen keinen signifikanten Aufwand des Testteams erfordern (wie Vorbereitung
zusätzliche, neue Testbedingungen usw.) und den Testzeitplan nicht beeinträchtigen.

[Siehe Abschnitt 9.1.]

2.1.3. SPEZIFISCHE AUSNAHMEN

Das Cash Management ist in dieser Phase nicht enthalten.

Start-/Endfunktionen sind ausgeschlossen – sie werden durch bestehende Prozesse behandelt
Die bereits bestehende Funktion der Spezialbestellung wird nicht ersetzt.
Transaktionen mit Fremdwährung
Internationale Wechselkursdaten
Buchhaltung oder Transaktionsberichte in Euro

Referenzdokumentation & Quellen:

Qualität und Softwaretests Seite 3

 Modell eines Testplans

1. Dokument zur Zeichnung von Geschäftsprozessen - Referenz: BPD-1011

2. Transaktionsanforderungen für Phase 1 - Referenz: TR_PHASE1-4032
3. Probleme & Risiken des Projekts–T:\Data\Project\[Link]
4. Entwicklungsstandards für Systeme-Referenz: DEVSTD-1098-2
5. Lebenszyklus der Systementwicklung - Referenz: SDLC-301

2.2. Testverfahren

b. Zeichnen Sie das

Test von
System

c.
a. Planen Sie das Zeichnen/Bauen e. Auszuführen das f. Ausführen des g. TERMINO
Projekt ir Verfahren Systemtest Abnahmeprüfung
testes

d. Konstruieren
Umgebung von
Teste

Das obige Diagramm erklärt den Testprozessansatz, der verfolgt wird.

a. DAS PROJEKT ORGANISIEREN - umfasst die Erstellung eines Testplans für das System, den Ansatz des Zeitplans &
teste, und Ressourcen anfordern/delegieren.
b. TESTSYSTEM ENTWICKELN/BAUEN - umfasst die Identifizierung von Testzyklen, Testfällen, Kriterien
Eingangs- und Ausgangsbedingungen, erwartete Ergebnisse usw. Im Allgemeinen die Testbedingungen und die erwarteten Ergebnisse
werden von der Testgruppe zusammen mit dem Business Analysten des Projekts oder mit dem
Geschäftsexperte. Das Testteam wird dann die Testfälle und die erforderlichen Daten identifizieren. Die
Die Testbedingungen werden aus dem Geschäftsentwurf und den Dokumenten der Transaktionsanforderungen abgeleitet.
c. ENTWICKLUNG/BAUEN VON TESTPROZESSEN - beinhaltet die Vorbereitung von Prozessen wie Systeme von
Fehlerverwaltung und Statusberichterstattung sowie die Vorbereitung der Datentabellen für das automatisierte Werkzeug.
teste.
d. DEN TESTUMGEBUNG AUFBAUEN - umfasst das Anfordern/Bauen von Hardware und Software sowie die Vorbereitung von Daten
e. FÜHREN SIE INTEGRATIONSTESTS DES PROJEKTS DURCH - siehe Abschnitt 3 - Testzyklen und -phasen.
f. TESTAKZEPTANZ TEST AUSFÜHREN -siehe Abschnitt 3 –Testzyklen und Phasen.
g. BEGRIFF - Der Begriff tritt ein, wenn alle vorgegebenen Ausgabekriterien erreicht wurden. Siehe die
Abschnitt 2.4.

2.2.1. Ausschlüsse

Die Gewährleistung der Systemqualität wird nicht direkt mit dem Geschäftsentwurf in Bezug auf ...
alle Fragen zu Zeichnungen und funktionalen Themen.

Das Entwicklungsteam ist der Anbieter der Qualitätssicherung des Systems. Falls Fragen auftauchen
Funktionale oder designbezogene Fragen müssen vom Entwicklungsteam und seinen
Lieferanten.

2.3. Testumfang

Qualität und Softwaretest Seite 4

 Modell eines Testplans

Unten stehen die Haupttypen von Tests, die für diese Version durchgeführt werden. Alle Pläne und Bedingungen
Systemtests werden auf der Grundlage von funktionalen Spezifikationen und dem Dokument erstellt.
Anforderungen.

2.3.1. Funktionstest

Ziel dieses Tests ist es, sicherzustellen, dass jedes Element der Anwendung den funktionalen Geschäftsanforderungen entspricht.
gemäß beschrieben

Im Lastenheft
In der Spezifikation des Geschäftzeichnens
Nach den Standards der "Entwicklung des Jahres 2000"
In anderen funktionalen Dokumenten, die während des Projektverlaufs erstellt wurden, wie Beschlüssen von
Fragen, Änderungsanfragen und Rückmeldungen.

Diese Phase wird auch einen Validierungstest umfassen – das intensive Testen der neuen Bildschirme und „Front
Enden. Windows-GUI-Standards; Gültige, ungültige und eingeschränkte Eingabedaten; Bildschirmappearance und
Feld; Allgemeine Konsistenz mit dem Rest der Anwendung.

Die dritte Phase umfasst spezifische funktionale Tests - dies sind niedrigstufige Tests, die das Ziel haben
die einzelnen Prozesse und Datenfluss zu testen.

2.3.2. Integrationstest

Dieser Test beweist, dass alle Bereiche des Systems korrekt miteinander interagieren und dass es keine gibt.
Probleme im Datenfluss. Der abschließende Integrationstest beweist, dass das System als Einheit funktioniert.
integriert, wenn alle Teile abgeschlossen sind.

2.3.3. Akzeptanztest (Benutzer)

Dieser Test, der von den Vertretern des Unternehmens (Kunden) geplant und durchgeführt wird, stellt sicher, dass das
System funktioniert wie erwartet und das unterstützende Material (wie Verfahren und Formulare) ist
korrekt und dient seinem Zweck. Es ist ein Test auf hohem Niveau, der sicherstellt, dass es keine Probleme gibt bei
Funktionalität.

2.3.4. Leistungstest

Dieser Test stellt sicher, dass das System akzeptable Antwortzeiten liefert (die 4 nicht überschreiten dürfen
Sekunden).

2.3.5. Regressionstest

Ein Regressionstest sollte nach der Freigabe jeder Phase durchgeführt werden, um sicherzustellen, dass:

Es gibt keine Auswirkungen auf zuvor veröffentlichte Software.

Es gibt eine Zunahme der Funktionalität und Stabilität der Software.

Der Regressionstest wird mit dem Einsatz des automatisierten Testwerkzeugs automatisiert.

2.3.6. Teste von Bruch & Multi-Usability

Qualität und Softwaretest Seite 5

 Modell eines Testplans
Der Test der Multi-Benutzerfreundlichkeit wird beweisen, dass es möglich ist, dass eine akzeptable Anzahl von Benutzern an
System gleichzeitig. Der Break-Test ist ein maßgeschneiderter Versuch, das System zu brechen.

2.3.7. Technischer Test

Der technische Test liegt in der Verantwortung des Entwicklungsteams.

2.3.8. Test der operativen Akzeptanz (TAO)

Diese Testphase sollte vom Installations- und Supportteam durchgeführt werden, bevor das System implementiert wird.
Das System selbst. Dieses Team wird seine eigenen Testkriterien festlegen und anwenden.

2.4. Kriterien für Ein- und Austrittstests des Systems

2.4.1. Eingangskriterien

Die vom Systemcontroller festgelegten Eintrittskriterien müssen erfüllt sein, bevor der Test beginnt.
de System beginnen. Falls ein Kriterium nicht erfüllt ist, kann der Test beginnen, wenn das Team von
Das Geschäft und der Testcontroller sind sich einig, dass das Risiko beherrschbar ist.

Alle entwickelten Codes müssen separat getestet werden. Der Unit-Test und der Test
Die Links müssen vom Entwicklungsteam vervollständigt werden.
Testpläne müssen vom Business-Analysten und vom Testanalysten abgeschlossen werden.
Alle Ressourcen müssen verfügbar sein.
Alle Hardware- und Testumgebungen müssen bereit und frei sein, um im Test verwendet zu werden.
des Systems.
Der Akzeptanztest muss mit einer Erfolgsquote von mindestens 80% abgeschlossen werden.

Abnahmetests:
25 Fälle werden getestet. Um das Akzeptanzkriterium zu erreichen, müssen 20 dieser 25 abgeschlossen werden.
Erfolg. Das heißt, eine Erfolgsquote von mindestens 80 % muss erreicht werden, bevor die Software ...
Akzeptiere, um den Systemtest zu starten. Das bedeutet, dass Fehler, die während der Abnahmetests gefunden werden...
sollten nicht verhindern, dass 80 % der Anwendungen ihre Tests abschließen.

Hinweis: Diese Tests haben nicht die Absicht, eine gründliche Prüfung der Software durchzuführen.

Kriterien für den Neuanfang

Im Falle einer Aussetzung des Systemtests müssen Wiederanfangskriterien festgelegt werden, und der Test nicht
muss neu beginnen, solange die Software diese Kriterien nicht erfüllt.

Qualität und Softwaretest Seite 6

 Modell eines Testplans

2.4.2. Ausstiegskriterien

Die unten aufgeführten Ausstiegskriterien müssen erfüllt sein, bevor die Phase-1-Software freigegeben werden kann.
empfohlen für die Beförderung zum Status der Operationsakzeptanz. Darüber hinaus empfehlen wir, dass
es hätte mindestens 2 Tage für einen abschließenden Integrationstest gegeben, NACHDEM die letzte Version überarbeitet wurde.
testada.[Siehe Abschnitt 9.3]

Alle Hochprioritätsfehler des Systemtests müssen behoben und getestet werden.

Wenn ein Fehler von mittlerer oder niedriger Priorität auffällig ist, sollte das Implementierungsrisiko sein
als "akzeptabel" vom Business-Analysten und vom Fachspezialisten genehmigt.
Der Integrationstest des Projekts muss vom Testcontroller und vom Analysten abgeschlossen werden.
Geschäft.
Der Abnahmetest muss vom Fachspezialisten abgeschlossen werden.

3. PHASEN UND ZYKLEN DES TESTENS

Es wird zwei Haupttestphasen für neue Anwendungen während des Systemtests geben:

Systemtest
Akzeptanztest der Operation

3.1. Systemtestzyklen
Der Hauptantrieb der Herangehensweise (Strategie) besteht darin, die beiden ersten Freigaben intensiv zu testen, so
ungefähr 80 % der Fehler in diesem Zeitraum beheben. Mit den meisten Fehlern behoben, Maßnahmen-
Standards oder häufig verwendete Aktionen werden getestet, um individuelle Elemente und das
Gesamtverarbeitung des Systems in der Freigabe v0.3.

Wenn alle Fehler (die potenziell den Gesamtprozess beeinflussen) behoben sind, ein
Ein zusätzliches Set von Testfällen wird in der Version 0.4 verarbeitet, um sicherzustellen, dass das System
funktioniert integriert. Es wird erwartet, dass die Veröffentlichung v0.4 der endgültige Beweis des Systems ist, während
einzigartige Anwendung. Es dürfen vor Beginn des Tests der Freigabe v0.4 keine Fehler der Klassen A oder B auftreten.

Testfälle nach veröffentlichter Version:

Teste durch Phase

Akzeptanz 1
Version v0.1 Funktional 1
Benutzerauswahl
Akzeptanz 2
Version v0.2 Funktional 2
Regression 1
Akzeptanz 3
Funktional 3
Version v0.3 Leistung 1
Test der Behebung & der Mehrfachnutzung
Regressione 1
Regression 2
Integration 1

Qualität und Test von Software Seite 7

 Modell eines Testplans

Techniker 1
Version v0.4 Regression 1
Regression 2
Regression 3
Installationstest
KontingenzNur Test der Fehlerbehebung

3.1.2. Automatisierter Test

Automatisierte Testwerkzeuge werden in einer Testumgebung für Funktionstests und Tests von verwendet.
Regression. Der Hauptfokus des automatisierten Tests liegt auf dem Regressionstest der zuvor getesteten Funktionalität.
bereitsgestellt - das heißt, wenn Version 0.2 der Software bereitgestellt wird, die meisten Regressionstests der
Die in Version 0.1 bereitgestellte Funktionalität wird automatisch sein. Es wird erwartet, dass der gesamte Nutzen des Tests
Automatisiert soll es nur stattfinden, wenn die Tests drei oder mehr Mal ausgeführt wurden.

3.2. Lieferung von Software

Während des Systemtests muss die Freigabe neuer Versionen der Software zwischen dem Leiter der
Entwicklungsteam und der Systemtestanalyst. Es sei denn, sie dienen dazu, Fehler zu beheben.
Ein sehr schwerwiegender Fehler, neue Versionen sollten nur freigegeben werden, wenn vereinbarte Ziele erreicht sind.
erreicht (zum Beispiel enthält die nächste Version Korrekturen für eine Anzahl von X oder mehr Bugs).

Freigabezeitplan:

v0.1 v0.2 v0.3 v0.4 v1.0

Funktionalität, die geliefert werden soll* 1. Mai 17. Mai 31. Mai 18. Juni 29. Juni
1. Funktion A
2. Prozess B Keine Nur
3. Europäische Anforderungen Funktionalität Version von
4. Anforderungen Y2K nova zu sein Kontingenz
5. Inter-Office-Transaktionen geliefert für
Internationale Transaktionen nesta Reparatur
7. Sonstiges Version de bug

(nach Functional Specification, nach Priorität)

Beobachtungen:
Es wird erwartet, dass 80 % der Funktionen vor der Freigabe der Phase 3 vollständig getestet wurden.
Alle Funktionen müssen bei der Freigabe der Phase 3 vorhanden sein.
Keine zuvor nicht gelieferte Funktionalität wird nach Phase 3 zum Test akzeptiert.

3.3. Formale Überprüfung

Es gibt verschiedene formale Überprüfungspunkte vor und nach dem Systemtest, einschließlich der Überprüfung dieser.
Dokument. Dies ist ein entscheidendes Element, um ein qualitativ hochwertiges Produkt zu erhalten.

Qualität und Softwaretest Seite 8

 Modell eines Testplans
3.3.1. Formale Überprüfungspunkte

5. Bauen
2. Zeichnen der Test von 8. Teste de
o Teste de System Integration
System

3. Bauen
Planen Verfahren 7. Ausführen 10. Begriff
das Projekt Tests der Test von e Überprüfung
System

4. Zeichnung 6. Bauen 9. Beginne o

Umgebung von die Umgebung Testpilot
teste de teste
1. Dokumentation des Entwurfs - Spezifikation der Anforderungen und funktionale Spezifikationen
2. Testplan für das System
3. Testpläne für Unit-Tests & Testbedingungen
4. Ergebnisse der Unittest
5. Testbedingungen für das System
6. Fortschritte/Ergebnisse der Systemtests
7. Überprüfung nach dem Systemtest
8. Ergebnisse der Integrationstests
9. Überprüfung der Pilotimplementierung
10. Überprüfung des Projekts

Das obige Diagramm zeigt den Testansatz (Strategie). Die Kästen 1 bis 6 zeigen die Hauptpunkte.
Überprüfungsphasen vor der Durchführung des Tests. Die Kästen 7 bis 10 zeigen die geplanten Phasen für
vor und nach der Ausführung des Tests.

Das obige Diagramm konzentriert sich auf den Testaspekt der Rolle der Software-Qualitätssicherung, aber
Es gibt auch eine laufende Rolle, um die Qualität der wichtigsten Liefergegenstände während des Zyklus sicherzustellen.
des Lebenszyklus des Projekts. Die Rolle der Software-Qualitätssicherung besteht darin, sicherzustellen, dass alle Inspektionen
von hoher Qualität für alle vereinbarten Liefergegenstände stattfinden und dass Folgeaktionen und Initiativen ergriffen werden.
gesucht.

3.3.2. Überwachung von Fortschritten/Ergebnissen

Testergebnisse der Abnahme 1

Testergebnisse – Freigabe v0.1
Testergebnisse - Freigabe v0.2
Resultados de teste–liberação v0.3
Ergebnisse des Leistungstests 1
Ergebnisse der Regressionstests 1 und 2
Testergebnisse – Freigabe v0.4
Ergebnisse des technischen Tests

4. Zeitplan für den Systemtest

Qualität und Softwaretest Seite 9

 Modell eines Testplans

Dies sind Bilder einiger hochrangiger Projektzeitpläne. Diese Zeitpläne

dienen nur als Beispiele und entsprechen wahrscheinlich nicht genau mit dem
Rest des Testplans. Das beste Bild ist das letzte.

Qualität und Softwaretests Seite 10

 Modell eines Testplans

Qualität und Softwaretest Seite 11

 Modell eines Testplans

5. RESSOURCEN
5.1. Menschen

Ressourcentyp Titel Nr. Datum Wer Status

angefordert

Verwaltung von Business Analyst 1 - João da Ernannt

Projekt/Funktional Silva
Outro

Teste Testcontroller 1 - José da Benannt

Silva
Tester 4 1. Mai Zugewiesen werden

Unterstützungsteam von Programmierer von 4 15. Mai Eingesetzt werden

Teste Unterstützung
Technischer Support 1 1. Mai Einen zugewiesenen
WAN-Unterstützung 1 25. Mai Zu ernannt
Eingesetzer werden
Techniker - Extern Support CIS (Zentrale IT 1 25. Mai Ein zugewiesenes Ser
Dienstleistungen–Dienstleistungen

IT-Zentren
Buchhaltungsunterstützung 1 15. Mai Bestimmt zu werden
Unterstützung von Verbindungen 1 25. Mai João Designiert
extern Carlos

Geschäft Spezialist von 1 1. Mai Eingesetzt werden

Geschäft/Vertreter von
Geschäft

5.2. Hardware
Ein separat kontrolliertes System wird für die Anfangstestphase erforderlich sein.
eingerichtet als ein Standardgeschäftsumgebung. Um die Integrität der Umgebung zu gewährleisten
Ihr Netzwerk sollte für niemanden außerhalb des Projekts zugänglich sein. Die Drucker
sollten ebenfalls ausschließlich für den Einsatz im Testnetz verwendet werden.

Qualität und Test von Software Seite 12

 Modell eines Testplans

Benötigte Hardwarekomponenten

1 Netzwerkcontroller
6 PCs im Netzwerk (siehe unten)
1 Arbeitsstation als Download-Beschleuniger
1 Motorola 6520
1 Server Alpha AXP
1 Drucker Chargenabfall
1 HP LaserJet 4v Drucker

Spezifikationen der für die Testumgebung erforderlichen PCs

1 x P100, 1Gb HD, 16Mb RAM [Aktuelle Mindestanforderung]

3 x P166, 1,5 Gb HD, 32 Mb RAM [Aktuelle Mindestanforderung]
1 x P333, 2,5 Gb HD, 64 Mb RAM [Aktuelle Mindestanforderung]

1 Pentium mit Windows NT wird ebenfalls als Testzentrum benötigt, um zu steuern und
automatisierte Tests durchführen.

5.3. Software
Testen von IMS-Umgebungen
Das Testen von IMS-Umgebungen in der Region X ist notwendig für den Systemtest. Zusätzliche Daten
oder ergänzende werden bereitgestellt, wo erforderlich.

Qualität und Test von Software Seite 13

 Modell eines Testplans

Testen der Softwareumgebung

Der Systemtest wird auf den folgenden Softwareversionen durchgeführt:
Benutzerdefinierter Desktop Version 97.0.1
Windows 95
Visual Basic 5 Laufzeitdateien
MS Office 97
Novell Netware

Fehlererfassungssystem

Dieser Systemtest wird ein Datenbank-Fehlermanagementsystem verwenden.

MS Access. Eine neue Datenbank wird ausschließlich für diesen Zweck implementiert.
Projekt.

6. PAPIERE UND VERANTWORTUNGEN

6.1. Management-Team
Projektleiter – Herr Thiago Lacerda
Sicherstellen, dass Phase 1 im Zeitplan, Budget und in der Qualität geliefert wird.
Sicherstellen, dass die Ausstiegskriterien vor Beendigung des Tests erreicht werden.
System
Den Fortschritt des Tests regelmäßig mit dem Testcontroller überprüfen
Die Zusammenarbeit mit externen Teams, wie dem Team für neue Systeme, durch
Beispiel
Heben und verwalten von projektbezogenen oder außerhalb der Kontrolle stehenden Angelegenheiten/Risiken
Testteam
Überprüfung und Abschluss des Ansatzes, Plans und Zeitplans für den Test

Qualitätssicherung der Software – Projektleiter – Sr. Reynaldo Giannechini

Sicherstellen, dass Phase 1 termingerecht, im Budget und in der Qualität geliefert wird.
Den Fortschritt des Tests regelmäßig überprüfen
Management von Angelegenheiten/Risiken im Zusammenhang mit dem Systemtestteam
Die notwendigen Ressourcen bereitstellen, um den Systemtest abzuschließen

6.2. Testteam
Tester/Analyst – Sr. Brad Pitt
Sicherstellen, dass Phase 1 im Zeitplan, Budget und Qualität geliefert wird
Erstellen Sie detaillierte und hochrangige Testbedingungen
Die erwarteten Ergebnisse produzieren
Fortschritte in regelmäßigen Statusberichterstattungsbesprechungen melden
Koordinierung der Überprüfung und Beendigung der Testbedingungen
Einzelne Testzyklen verwalten und Fragen/Probleme der Tester lösen
Sichern Sie, dass die Ergebnisse/Probleme des Systemtests gemeldet werden.
Qualität und Softwaretests Seite 14
 Modell eines Testplans

sofort, und dass die Überwachung durchgeführt wird

Sicherstellen, dass die Eintrittskriterien erreicht werden, bevor der Systemtest beginnt.
startete
Sicherstellen, dass die Ausgangskriterien vor dem Ende des Tests erreicht werden.

Tester
Testdaten identifizieren
Die Testbedingungen ausführen
Fehlerberichte für Software erstellen
Das Fehlermesssystem verwalten

6.3. Geschäftsteam
Business Analyst – Sr. Keanu Reeves
Überprüfen Sie detaillierte und hochrangige Pläne für den Systemtest
Verfahren definieren
Zeichnungsangelegenheiten klären
Geschäftsangelegenheiten klären
An den täglichen Besprechungen des Fehlerüberprüfungsteams teilnehmen

Geschäftsvertreter –?? (wird noch benannt)

Benutzerakzeptanztest durchführen
Definieren Sie Testbedingungen und erwartete Ergebnisse für den Geschäftsanwendungstest.
Benutzeranliegen lösen
Zeichnungsangelegenheiten klären

6.4. Testsupport-Team
Support-Programmierer
Teilnahme an den täglichen Besprechungen des Fehlerüberprüfungsteams
Koordinieren und Unterstützung beim Systemtest
Fehler beheben
Software nach der Korrektur erneut freigeben
Den Systemtestern Unterstützung bieten

6.5. Externe Support-Team

Unterstützung für zentrale IT-Dienste
Unterstützung für zentrale IT-Dienste, falls erforderlich
Fragen zu zentralen IT-Diensten klären, falls erforderlich

IMS-Unterstützung
Unterstützung beim Systemtest bereitstellen
Unterstützung der IMS-Regionen
Lösen von Angelegenheiten, die an das Betriebssystem angepasste Lösungen benötigen, falls erforderlich
Integration und buchhalterische Konformität herstellen, falls erforderlich
Fragen zu lösen, die aus dem Remote-Backup entstehen

Qualität und Softwaretests Seite 15

 Modell eines Testplans
Buchhaltungsunterstützung
Technische Buchhaltungsunterstützung bereitstellen, falls erforderlich
Fragen klären, falls nötig

Technischer Support
Unterstützung für die Hardwareumgebung bereitstellen
Unterstützung für die Testsoftware bereitstellen
Software für die Testumgebung des Systems bereitstellen

Zugangssupport
Bereitstellung und Unterstützung der Testdatenbanken

7. Fehlerverwaltung & Verwaltung von

Konfiguration
Während des Systemtests werden Fehler in Fehlerberichten festgehalten, während
entdeckte Forem. Diese Berichte werden am Ende jedes Tages als Eingabedaten eingegeben.
im Fehlermanagementsystem, mit dem Status "Fehler aufgekommen" oder "Frage"
„levantada“. Das Fehlerprüfungsteam wird sich jeden Morgen um 10 Uhr im Raum treffen.
Besprechungen zur Überprüfung und Priorisierung der am vorherigen Tag angesprochenen Fakten und deren Zuordnung oder
Lassen Sie sie nach Bedarf beiseite. Das Team sollte die folgenden Vertreter haben:

A. Teamleiter der Entwicklung

B. Business-Analyst
C. Testanalyst
D. Geschäftsvertreter

Fehler, die als gültig anerkannt wurden, werden vom Überprüfungsteam kategorisiert.
de erros da seguinte forma:

Kategorie A–Erhebliche Fehler, die die Fortsetzung des Systemtests verhindern.

eine bestimmte Funktion oder schwerwiegende Datenfehler.
Kategorie B – Fehler in Bezug auf ernsthafte oder fehlende Daten, die nicht verhindern, dass
Implementierung.
Kategorie C – Kleine Fehler, die die Funktionalität nicht verhindern oder beeinträchtigen.

Fehler der Kategorie A müssen vom Bugfix-Team innerhalb von 48 Stunden behoben werden.
Stunden (ab dem Zeitpunkt, an dem der Fehler im Treffen des Überprüfungsteams angesprochen wird
Fehler bis die Korrektur in der Testumgebung freigegeben wird). Im Falle eines Fehlers
von Kategorie A, die das Fortfahren des Systemtests verhindert, muss die Beseitigung innerhalb stattfinden
de 4 horas.

Fehler der Kategorie B müssen innerhalb von 1 Tag behoben werden, und die der Kategorie C innerhalb von 3 Tagen.

Inzwischen sollten die Freigaben neuer Versionen der Software mit dem koordiniert werden
Testeranalyst – Neue Versionen dürfen nur freigegeben werden, wenn sie vereinbart sind, und
wo ein endgültiger Vorteil besteht (zum Beispiel, der Korrekturen für eine Nummer enthält
X de Bugs).

Qualität und Test von Software Seite 16

 Modell eines Testplans

8. SITUATIONSBERICHT
8.1. Lagebericht

Die Testvorbereitung und der Testfortschritt müssen formal in einem ...

Wöchentliche Statusbesprechung. Wer sollte an diesem Treffen teilnehmen:

Projektmanager
Leiter des Geschäftswettbewerbs-Teams
Leiter des Entwicklungsteams

Ein Statusbericht muss vom Testanalysten vorbereitet werden, um zu erleichtern

Dieses Treffen. Dieser Bericht sollte die folgenden Informationen enthalten:

Aktueller Status X Planung (Voraus/Ausstehend/Im Zeitplan)

2. Fortschritt der in der Vorwoche geplanten Aufgaben
3. Geplante Aufgaben für die nächste Woche, einschließlich ausstehender Aufgaben von
vorige Woche
4. Statistik der Fehler des Messsystems
5. Fragen/Risiken

9. Fragen, Risiken und Annahmen

9.1. Fragen/Risiken

1. Änderungen und Ergänzungen werden für diese Version nicht berücksichtigt, außer: (1) wo
die ausdrückliche Genehmigung und Zustimmung des Business Analysts und des Analysts von
teste; (2) wo die Änderungen/Ergänzungen keinen erheblichen Aufwand des Teams erfordern
testen Sie und beeinträchtigen Sie nicht den Testzeitplan. Dies ist ein potenzielles ernstes Thema, da
Jede größere Änderung am Design wird zusätzliche Zeit erfordern, um die Planung neu zu gestalten.
teste e um um Bedingungen für zusätzliche Tests zu schaffen.

Byron Ruthlenn
Abschluss der endgültigen Liste der Einschreibungen.

[Link] Design der Software muss final sein, und die Dokumentation muss vollständig sein.
informativ und von allen Parteien abgeschlossen, bevor der Systemtest beginnt.

Verantwortlich: D. A. Stone

Eine Schwäche des Ansatzes (Strategie) der "Phasenlieferung" ist, dass der hohe Grad von
Interdependenz im Code bedeutet, dass die kleinste Änderung schwerwiegende Auswirkungen haben kann auf
Bereiche der Anwendung, die anscheinend nicht geändert wurden. Die Annahme des Testteams ist
Welche zuvor gelieferten und getesteten Funktionen nur Tests erfordern von
Regression, um zu überprüfen, dass sie noch funktionieren, das heißt, die Tests werden nicht die Absicht haben.
um neue Fehler zu entdecken. Daher empfehlen wir, dass es mindestens zwei Tage gibt
Regressionstests NACHDEM die endgültige Korrektur erneut getestet wurde. Dies jedoch,

Qualität und Softwaretests Seite 17

 Modell eines Testplans

setzt eine Zeitbeschränkung für den Abschluss der Testphase, was eine Anforderung erfordert
Übereinstimmung des Projektleiters.

Byron Ruthlenn

4. Automatisierter Test
Der größte Teil der Regressionstests wird mit dem Testtool durchgeführt.
automatisiert. Dennoch, aufgrund der erforderlichen Arbeitsbelastung für die Implementierung
komplett und die Fehler des Testtools zu beseitigen, ist es wahrscheinlich, dass die Rückkehr
wird erst nach dem dritten Mal maximiert, dass der Test für jede Freigabe durchgeführt wird. Die
Weitere Hauptanwendungen des Testwerkzeugs sind: (1) den Test laden; (2) den Test ermöglichen
für Mehrbenutzer; (3) wiederholte Daten eingeben.

Tester

9.2. Prämissen
Die Software wird fristgerecht geliefert.
Die Software wird die erforderliche Qualität haben.
Die Software wird nicht von Y2K-Konformitätsänderungen betroffen sein.
äußere Struktur. Zum Beispiel muss jede externe Änderung kompatibel sein.
mit dieser Anwendung
Alle Bugs, die das System zum Absturz bringen könnten, werden umgehend vom Team Aufmerksamkeit erhalten.
der Entwicklung
Alle in einer Version der Software gefundenen Bugs werden behoben und
einzeln von der Entwicklungsabteilung getestet, bevor ein neues
Version freigegeben werden
Die Funktionalität wird fristgerecht geliefert
Die erforderlichen Ressourcen werden verfügbar sein
Alle Dienstvereinbarungen werden eingehalten
Das automatisierte Testwerkzeug wird korrekt funktionieren und interagieren mit dem
Software
Die gesamte Dokumentation wird aktualisiert und dem Testteam übergeben.
Funktionale und technische Spezifikationen werden vom Geschäft genehmigt.
Das Intranet wird vollständig funktionsfähig sein, bevor das Projekt beginnt.

10. Formeller Begriff

Dieses Dokument muss formal genehmigt werden, bevor der Systemtest durchgeführt werden kann.
anfangen. Die folgenden Personen müssen unterschreiben;

Unterschriften:
Projektleiter Byron Ruthlenn
SQA Colm Jones
Testteam Dion Hais
Entwicklungsteam Erwin Smith

Qualität und Test von Software Seite 18

 Modell eines Testplans

11. ANHANG
11.1. Zweck des Fehlerprüfungsteams

Die maximale Effizienz der Entwicklungs- und Testteams des Systems sicherstellen, um
die Freigabe der neuen Software durch die Zusammenarbeit aller beteiligten Parteien.

Dies wird durch tägliche Besprechungen erreicht, deren Funktionen Folgendes sind:

Den Status jedes angezeigten Fehlers klassifizieren

Gültige Fehler priorisieren
Sicherstellen, dass ausreichende Dokumentation über die Fehler verfügbar ist
Über Inhalte und Zeitrahmen für die Softwarefreigaben einig werden
Systemtest
Eine vereinbarte Quelle für Fehlerberichterstattung sicherstellen
Identifizieren Sie Themen, die die Leistung des Systemtests beeinträchtigen könnten.

11.2. Tagesordnung des Fehlerüberprüfungsteams

Überprüfung der Maßnahmen aus der vorherigen Sitzung
Fehler klassifizieren und priorisieren
Fehler überprüfen, um Duplikate zu prüfen
Die Priorität jedes Fehlers vereinbaren
Die Eignung der Dokumentation in Bezug auf jeden aufgeführten Fehler bestimmen
Über den Inhalt und den Zeitplan der Freigaben einig werden
Überprüfung der in früheren Sitzungen zugewiesenen Maßnahmen

11.3. Klassifizierung von Bugs

1. Ein Fehler "A" blockiert das System oder ist von solcher Wichtigkeit, dass er radikal die
Funktionalität des Systems.

Beispiele für Bugs, die das System zum Absturz bringen:

- Wenn aufgrund eines Absturzes während der Verarbeitung einer Anwendung ein Benutzer
kann diese Anwendung nicht abschließen

Falsche Daten werden an das System übergeben, was zu einer Beschädigung oder einem Absturz führt.
vom System.

Beispiele für schwer beeinträchtigte Funktionalität:

- Falsche Berechnung von Zahlungen

Falsche Erstellung von Kreditverträgen

2. Fehler werden als "B" klassifiziert, wenn:

Qualität und Test von Software Seite 19

 Modell eines Testplans

- Beeinflussen ein weniger wichtiges Element der Funktionalität. Beispiel: ein Standard von einem
Falor ist nicht korrekt und muss manuell korrigiert werden.

- Die betroffenen Daten haben keine große Auswirkung. Beispiel: Eine Kundendaten wurde nicht
korrekt an die Datenbank gesendet.

- Es gibt eine alternative Methode, um den Prozess abzuschließen. Beispiel: ein Problem beim Lesen
Die Einzelheiten eines Kredits. Diese Änderung kann manuell eingegeben werden.

3. Bugs vom Typ "C" sind harmlos. Beispiele: fehlender Text in Hilfe-Fenstern, Optionen
in Doppelung.

11.4. Verfahren zur Wartung des Fehlermeldesystems

Der Testcontroller muss alle größeren Fehler/Anomalien an den Teamleiter weiterleiten.

Entwicklung oder deren beauftragter Vertreter, bevor eine formelle Registrierung des Fehlers vorgenommen wird. Dies hat
einige Vorteile:
Vermeiden Sie unnötige Anstrengungen der Tester
Setzt den Entwickler sofort über das Problem in Kenntnis
- Ermöglicht es dem Entwickler, die erforderlichen Mechanismen zur Fehlersuche hinzuzufügen
2. Alle gemeldeten Fehler müssen in den richtigen Fehlerformularen aufgeführt sein und alle Informationen enthalten.
relevant
3. Der Fehler muss am Tag seines Auftretens mit dem Status 'AUFGETRETEN' vermerkt werden.
4. Es muss ein tägliches Treffen des Unterstützungsteams für Tests des Systems geben, um zu diskutieren, priorisieren und
alle registrierten Fehler zusagen. Während dieser Sitzungen können Fehler heruntergeladen werden,
als Duplikate identifiziert, an die Programmierer weitergegeben usw.
5. Das Fehlerprotokoll wird nach diesem Meeting mit dem Status aller Fehler aktualisiert. Beispiel:
Duplikat, mit Programmierer, usw.
6. Sobald der Fehler behoben ist und zur Freigabe bereit ist, die entsprechenden Formulare
müssen an den Testcontroller übergeben werden, damit er seinen Status auf "Repariert zu sein" ändert.
wieder getestet.
7. Wenn der Fehler erneut getestet und korrekt ist, sollte sich sein Status in 'Geschlossen' ändern.
8. Fehlerstatusberichte müssen vom Fehlersystem erstellt werden, zur Verwendung in den Besprechungen der
Fehlerüberprüfungsteam.

11.5. Nachtragsprozess – Überprüfung der Buchhaltung und Systeme

computerisierte Informationen

Testanforderung Zu überprüfende Punkte Testebene

Buchhaltung
Wenn die Datenübertragung abgeschlossen ist, Bericht 1. Bericht über das Erbe 1. Überprüfung in
muss überprüft werden gegen: Feldniveau
1. Ähnliche Transaktionen X
2. Testdateneingabeformulare 2. Überprüfung in
Bericht über Feldniveau
Transaktionen von
Büro

2. Bericht

Qualität und Softwaretest Seite 20

 Modell eines Testplans

Eingabeformulare
Nach dem Öffnen/Ändern muss der Änderungsbericht 1. Bericht über 1. Zufriedenstellen die
geprüft gegen: Änderungen Gründe für die Ablehnung
1. Anweisungen für abgelehnte Änderungen
2. Eingabedaten, die den Formularen entsprechen 2. Bericht über 2. Überprüfung in
Änderungen Feldniveau

Eingabeformulare
de teste
Drucken von Konten- und Kundendateien und Überprüfen der Details Entradas da Prüfung auf Ebene
zwei Felder gegen Eingabedaten der Formulare der Buchhaltung von der Landschaft

Filialen
X

Eingabeformulare
de teste

11.7. QUALITÄTSGARANTIEMASSNAHMEN
SOFTWARE
DATEN

Datum des Beginns des Engagements für die Softwarequalität

ESFORÇO

Anzahl der Tage/Mann der Softwarequalitätsgarantie für die Planung von

teste
Anzahl der Mann-Tage der Softwarequalitätsprüfung für die Überprüfung der Pläne
von Test
Anzahl der Personentage für die Qualitätssicherung der Software zur Durchführung der Tests

VOLUMEN

-Anzahl der identifizierten Tests

QUALITÄT

-Anzahl der beim ersten Mal bestandenen Tests

Prozentsatz der beim ersten Mal bestandenen Tests
Anzahl der Fehler, die während des Regressionstests aufgetreten sind
Anzahl der Fehler, die durch falsche Reparaturen verursacht wurden
Anzahl der Fehler nach Kategorie (A/B/C)
-Anzahl der Fehler, die nach dem Fehlergrund aufgeführt sind
-Anzahl der Fehler, die von hochrangigen Geschäftsbereichen gemeldet wurden

(v) TEMPO
Qualität und Test von Software Seite 21
 Modell eines Testplans

Durchschnittliche Reparaturzeit für Fehler

12. DOKUMENTATION DER KONTROLLE

12.1. Online-Fehlerbehandlungsformular
12.2. Dokumentation der Prüfkontrolle
12.3. Überprüfung & Ausgangstest
12.4. Fehlerformular für nicht behobene Fehler
12.5. Fehler, die dem Entwicklungsteam zugewiesen sind
12.6. Kommunikationswege des SQA
12.7. Fehlerverarbeitungswege
12.8. Unterstützung beim Systemtest
12.9. Fehlerstatusfluss.

12.9.1 Vorgeschlagener Weg für den Fehlerprozess

12.9.2 Verfahren zur Korrektur von Fehlern

Qualität und Softwaretest Seite 22

 Modell eines Testplans

12.9.3 Statusfluss von Fehlern

Qualität und Software-Test Seite 23