Der Zweck eines Testplans ist, die Absicht der Testaufgaben zu vermitteln. Es ist äußerst wichtig, dass dieses Dokument
in einem möglichst frühen Stadium erstellt wird. Wenn Sie eine der ersten Iterationen der Ausarbeitungsphase als
Zeitpunkt für die Generierung dieses Artefakts festlegen, ist dies keinesfalls zu früh. Es kann sinnvoll sein, den
Testplan iterativ zu entwickeln und weitere Abschnitte hinzuzufügen, sobald neue Informationen verfügbar sind.
Sie sollten darauf achten, dass der Testumfang, die Anforderungen an den Test, die Teststrategien und der
Ressourcenbedarf klar und deutlich beschrieben werden. Mit diesen Informationen werden Zweck und Grenzen der einzelnen
Tests, der Testgegenstand, das Testverfahren und die erforderlichen Testressourcen festgelegt. Klare Formulierungen
beschleunigen die Überprüfung der einzelnen Tests sowie die entsprechenden Rückmeldungen und Bestätigungen.
Gleich zu Beginn eines Projekts sollte ein so genannter Master-Testplan erstellt werden, in dem die insgesamt für das
Projekt vorgesehenen Tests angegeben sind. Bei der Planung der einzelnen Iterationen können genauere
Iterationstestpläne (oder auch mehrere, nach Testtyp organisierte Testpläne pro Iteration) erstellt werden, in denen
nur die für die Iteration relevanten Daten (zu testende Anforderungen, Teststrategien, Ressourcen usw.) enthalten sind.
Diese Informationen können alternativ auch in den Iterationsplan aufgenommen werden, sofern dadurch nicht die
Verwendung oder Verwaltung des Iterationsplans erschwert wird.
Nachfolgend finden Sie einige Richtlinien für die bessere Festlegung und Vermittlung der zu testenden Anforderungen,
Testrisiken, Prioritäten und Teststrategien.
Die zu testenden Anforderungen geben an, was getestet werden soll. Sie sind das spezifische Testobjekt. Es gibt einige
allgemeine Regeln für die Ableitung von zu testenden Anforderungen:
-
Die zu testende Anforderung muss ein beobachtbares, messbares Verhalten sein. Wenn eine zu testende Anforderung
nicht beobachtbar oder messbar ist, kann nicht festgestellt werden, ob die Anforderung erfüllt ist.
-
Es gibt keine 1:1-Beziehung zwischen Anwendungsfall oder Zusatzanforderung eines Systems und zu testender
Anforderung. Ein Anwendungsfall enthält oft mehr als eine zu testende Anforderung und aus einer Zusatzanforderung
können mehrere zu testende Anforderungen abgeleitet werden oder auch keine (z. B. bei Marketing- oder
Konfektionierungsanforderungen).
Die zu testenden Anforderungen können aus vielen Quellen abgeleitet werden, z. B. aus Anwendungsfällen,
Anwendungsfallmodellen, zusätzlichen Spezifikationen, Designanforderungen, Geschäftsfällen, Interviews mit Benutzern
und Dokumenten zur Softwarearchitektur. Alle diese Quellen sollten auf Informationen geprüft werden, die geeignet sind,
um die zu testenden Anforderungen festzulegen.
Zu testende funktionale Anforderungen werden, wie der Name schon sagt, aus den Beschreibungen des funktionalen
Verhaltens des Testobjekts abgeleitet. Jeder Anwendungsfall sollte mindestens eine abgeleitete zu testende Anforderung
enthalten. Eine detailliertere Liste zu testender Anforderungen würde mindestens eine Anforderung pro Ereignisablauf in
einem Anwendungsfall enthalten.
Zu testende Leistungsanforderungen werden aus dem spezifizierten Leistungsverhalten des Testobjekts abgeleitet. Die
Leistung wird in der Regel als messbare Reaktionszeit und/oder Ressourcennutzung unter verschiedenen Bedingungen
angegeben. Zu diesen Bedingungen gehören unter anderem:
-
verschiedene Auslastungen und/oder Systembedingungen
-
verschiedene Anwendungsfälle
-
verschiedene Konfigurationen
Anforderungen an das Leistungsverhalten sind in den ergänzenden Spezifikationen beschrieben. Achten Sie beim
Durcharbeiten dieser Materialien besonders auf Angaben, die Folgendes enthalten:
-
Zeitangaben, z. B. Angaben zur Reaktionszeit oder Ablaufsteuerungsprofile
-
Hinweise darauf, dass eine bestimmte Anzahl von Ereignissen oder Anwendungsfällen in einem festgelegten Zeitraum
eintreten muss
-
Vergleiche des Verhaltens mehrerer Elemente
-
Vergleiche des Anwendungsverhaltens in mehreren Konfigurationen
-
Hinweise zur Zuverlässigkeit über einen bestimmten Zeitraum (MTTF oder Zeit, nach der bei normalem Betrieb ein
Fehler auftritt)
-
Hinweise zu Konfigurationen oder Einschränkungen
Aus jeder Angabe in der Spezifikation, die Informationen wie die oben genannten enthält, sollten Sie mindestens eine zu
testende Anforderung ableiten.
Zu testende Anforderungen an die Zuverlässigkeit werden aus verschiedenen Quellen abgeleitet, die in der Regel in
ergänzenden Spezifikationen, Richtlinien zur Benutzerschnittstelle, Designrichtlinien und Programmierungsrichtlinien
enthalten sind.
Achten Sie beim Durcharbeiten dieser Materialien besonders auf Angaben, die Folgendes enthalten:
-
Hinweise auf die Zuverlässigkeit oder Fehlerbeständigkeit und Laufzeitfehler (z. B. Speicherverluste)
-
Hinweise auf die Integrität und Struktur des Codes (sprachliche Konformität und Einhaltung der Syntax)
-
Hinweise zur Ressourcennutzung
Aus jeder Angabe in den Materialien, die Informationen wie die oben genannten enthält, sollten Sie mindestens eine zu
testende Anforderung ableiten.
Erfolgreiche Tests sind nur möglich, wenn beim Festlegen des Testaufwandes verschiedene Faktoren (z. B.
Ressourcenengpässe und Risiken) in ausgewogenem Maße Berücksichtigung finden. Zur Erreichung dieses Ziels sollten
Prioritäten für die einzelnen Tests vergeben werden, so dass die wichtigsten oder mit den meisten Risiken behafteten
Anwendungsfälle bzw. Komponenten zuerst getestet werden. Für die Festlegung der Testprioritäten werden eine
Risikobewertung und ein Nutzungsprofil erstellt und herangezogen.
In den folgenden Absätzen ist die Bestimmung der Testprioritäten beschrieben.
Die Festlegung der zu testenden Anforderungen ist nur ein Schritt bei der Bestimmung des Testgegenstands. Darüber
hinaus müssen Prioritäten vergeben werden, damit klar ist, was in welcher Reihenfolge getestet werden soll. Dieser
Schritt ist unter anderem aus folgenden Gründen erforderlich:
-
Es muss sichergestellt werden, dass das Hauptaugenmerk der Tests auf den wirklich relevanten Anforderungen liegt.
-
Es muss sichergestellt werden, dass die kritischsten, wichtigsten oder mit den meisten Risiken behafteten
Anforderungen so früh wie möglich Tests unterzogen werden.
-
Es muss sichergestellt werden, dass alle Abhängigkeiten (Folgen oder Daten) getestet werden.
Zur Einschätzung des Risikos und zur Festlegung der Testprioritäten gehören drei Schritte:
Nachfolgend sind die Richtlinien für diese drei Schritte beschrieben.
Die Festlegung der Testpriorität beginnt mit der Einschätzung des Risikos. Anwendungsfälle oder Komponenten, die bei
bei einem Ausfall oder Fehler ein großes Risiko mit sich bringen oder mit einer hohen Ausfall-/Fehlerwahrscheinlichkeit
behaftet sind, sollten zu den ersten getesteten Anwendungsfällen gehören.
Benennen Sie zunächst die zu verwendenden Indikatoren für die Risikohöhe und beschreiben Sie sie. Vergleichen Sie dazu
die folgenden Beispiele:
-
H - Hohes, nicht tolerierbares Risiko. Schwerwiegende Auswirkungen nach außen. Das Unternehmen wird hohe
finanzielle Verluste erleiden, in Haftung genommen werden oder seinen guten Ruf verlieren.
-
M - Mittleres Risiko, das tolerierbar, aber dennoch unerwünscht ist. Minimale Auswirkungen nach außen. Das
Unternehmen kann finanzielle Verluste erleiden. Die Möglichkeit, dass das Unternehmen haftbar gemacht werden kann
oder seine Reputation verliert, ist begrenzt.
-
L - Niedriges, tolerierbares Risiko. Geringfügige oder keine Auswirkungen nach außen. Das Unternehmen wird nur
geringe oder keine finanziellen Verluste hinnehmen müssen. Die Wahrscheinlichkeit, in Haftung genommen zu werden,
ist ebenfalls gering. Die Reputation des Unternehmens wird nicht beeinträchtigt.
Listen Sie nach Festlegung der Indikatoren für die Risikohöhe alle zum Testobjekt gehörenden Anwendungsfälle oder
Komponenten auf. Ordnen Sie jedem Anwendungsfall bzw. jeder Komponente in Ihrer Liste einen Indikator für die
Risikohöhe zu und begründen Sie den ausgewählten Indikator (mit einer kurzen Angabe).
Das Risiko kann aus drei verschiedenen Perspektiven eingeschätzt werden:
-
Wirkung - Die Auswirkung bzw. die Konsequenzen bei einem Fehler/Ausfall in einem angegebenen
Anwendungsfall (einer Anforderung usw.)
-
Ursache - Das durch einen Fehler in einem Anwendungsfall bewirkte unerwünschte Resultat als
Ausgangspunkt einer Untersuchung
-
Wahrscheinlichkeit - Die Wahrscheinlichkeit für einen Fehler in einem Anwendungsfall
Wählen Sie eine Perspektive aus, geben Sie einen Indikator für die Risikohöhe an und begründen Sie Ihre Auswahl. Sie
müssen nicht für jede Perspektive einen Indikator angeben. Wenn ein niedriger Indikator zugeordnet wurde, sollten Sie
jedoch versuchen, das entsprechende Element aus einer anderen Risikoperspektive zu beurteilen, um sicherzustellen, dass
das Risiko tatsächlich nur gering ist.
Nachfolgend ist die Einschätzung des Risikos aus den genannten drei Perspektiven detaillierter beschrieben.
Für eine Einschätzung des Risikos nach der Wirkung müssen Sie eine Bedingung, ein Ereignis oder eine Aktivität für die
Feststellung der Auswirkungen festlegen. Stellen Sie die folgende Frage:
"Was würde passieren, wenn ___________?"
Beispiele:
-
"Was würde passieren, wenn während der Softwareinstallation festgestellt wird, dass nicht genug
Plattenspeicherplatz verfügbar ist?"
-
"Was würde passieren, wenn während einer Anfragetransaktion die Internet-Verbindung unterbrochen wird?"
-
"Was würde passieren, wenn während einer Kauftransaktion die Internet-Verbindung unterbrochen wird?"
-
"Was würde passieren, wenn der Benutzer einen unerwarteten Wert eingibt?"
Nachfolgend sehen Sie eine Beispielmatrix für diese Punkte:
Beschreibung
|
Risikofaktor
|
Begründung
|
Nicht genug Plattenspeicherplatz während der Installation
|
H
|
Bei der Installation der Software erhält der Benutzer einen ersten Eindruck vom Produkt. Unerwünschte
Ergebnisse wie die nachfolgend aufgelisteten würden die Qualität des Benutzersystems und der
installierten Software herabsetzen und beim Benutzer einen negativen Eindruck hinterlassen:
-
Die Software wird nur teilweise installiert (einige Dateien und Registry-Einträge) und ist
dadurch instabil.
-
Die Installation wird abgebrochen und das System wird dadurch instabil.
|
Die Internet-Verbindung wird während einer Anfrage unterbrochen.
|
L
|
Weder Daten noch die Datenbank werden durch die Unterbrechung beschädigt. Es besteht die Möglichkeit,
dass dem Benutzer durch den Vorfall ein negativer Eindruck vermittelt wird.
|
Die Internet-Verbindung wird während eines Einkaufs.
|
H
|
Alle unterbrochenen Verbindungen oder Transaktionen mit den nachfolgend aufgelisteten Resultaten sind
inakzeptabel, denn Sie erhöhen den Systemaufwand und schmälern den Gewinn:
-
beschädigte Datenbank
-
unvollständiger Auftrag
-
Verlust von Daten oder Aufträgen
-
Mehrfachbestellungen (durch Replikation)
|
Ein unerwarteter Wert wird eingegeben.
|
H
|
Alle Transaktionen mit den nachfolgend aufgelisteten Resultaten sind inakzeptabel:
-
beschädigte Datenbank
-
ungenaue Daten
|
Die Einschätzung des Risikos nach der Ursache ist die entgegengesetzte Perspektive zur Einschätzung nach der Wirkung.
Geben Sie zunächst ein unerwünschtes Ereignis oder eine unerwünschte Situation an und beschreiben Sie dann die
Ursachen, die zum Entstehen dieses Ereignisses bzw. dieser Situation führen können. Stellen Sie die folgende Frage:
"Wie konnte es dazu kommen, dass ___________ ?
Beispiele:
-
"Wie konnte es dazu kommen, dass sich nur einige Dateien auf dem System befinden und nicht alle Einträge in die
Registry geschrieben wurden?"
-
"Wie konnte es kommen, dass eine Transaktion in der zentralen Datenbank nicht richtig widergespiegelt wird?"
-
"Wie konnte es dazu kommen, dass der Rechnungsstellungszyklus nur einige der Datensätze aus der Datenbank enthält,
die die gewünschten Kriterien erfüllen?"
Nachfolgend sehen Sie eine Beispielmatrix für diese Punkte:
Beschreibung
|
Risikofaktor
|
Begründung
|
Fehlende Anwendungsdateien und Registry-Einträge
|
H
|
Die Anwendung wird unbrauchbar (und das System potenziell auch). Bei der Installation macht sich der
Benutzer einen ersten Eindruck von der Anwendung. Scheitert die Installation, sieht der Benutzer die
Software in einem ungünstigen Licht.
Für diese Situation kann es unter anderem folgende Ursachen geben:
-
Während des Installationsprozesses wurden nicht alle Dateien installiert und die Registry nicht
ordnungsgemäß aktualisiert.
-
Der Installationsprozess wurde durch einen Benutzereingriff gestoppt (Abbruch oder Beendigung).
-
Der Installationsprozess wurde durch die Software oder Hardware gestoppt (nicht genug
Plattenspeicherplatz, nicht unterstützte Konfiguration usw.).
-
Der Installationsprozess wurde aufgrund unbekannter Bedingungen gestoppt.
-
Der Benutzer hat Dateien/Registry-Einträge gelöscht.
Nur der letzte der genannten Anwendungsfälle kann nicht vom Installationsprozess selbst
festgestellt und gehandhabt werden.
|
Unvollständiger Auftrag
|
H
|
Unvollständige Aufträge können nicht ausgeführt werden. Dies führt zu Umsatzeinbußen und möglicherweise
zu einem Verlust des Kunden.
Hierfür kann es unter anderem folgende Ursachen geben:
-
Die Internet-Verbindung wird aufgrund einer Benutzeraktion unterbrochen (Ausschalten des Modems
oder Herunterfahren des PC usw.).
-
Die Internet-Verbindung wird vom IP unterbrochen.
-
Die Internet-Verbindung wird aufgrund einer Mitarbeiteraktion unterbrochen (Ausschalten des
Modems oder Herunterfahren von Servern usw.).
|
Beschädigte Daten/Datenbank
|
H
|
Beschädigte Daten können auf keinen Fall toleriert werden.
Hierfür kann es unter anderem folgende Ursachen geben:
-
Eine Transaktion, die Daten in die Datenbank schreibt, wurde wegen eines Benutzereingriffs
nicht abgeschlossen/festgeschrieben.
-
Eine Transaktion, die Daten in die Datenbank schreibt, wurde wegen einer Unterbrechung der
Internet-Verbindung nicht abgeschlossen/festgeschrieben.
-
Der Benutzer gibt ungültige Daten für die Transaktion ein.
-
Methoden/Dienstprogramme für den Datenbankzugriff
-
Die Datenbank wurde (bei der Erstellung der ersten Instanz) nicht ordnungsgemäß mit Daten
gefüllt.
|
Replizierte Bestellungen
|
H
|
Replizierte Bestellungen erhöhen den Systemaufwand des Unternehmens, denn sie erzeugen Mehrkosten für
Versand, Bearbeitung und Nachfüllen der Lagerbestände. Dies führt zu Gewinneinbußen.
Hierfür kann es unter anderem folgende Ursachen geben:
-
Eine Transaktion, die eine Bestellung in die Datenbank schreibt, wird durch einen
Benutzereingriff (doppelte Eingabe oder Eingabe ohne Bestätigung) repliziert.
-
Eine Transaktion, die eine Bestellung in die Datenbank schreibt, wird durch einen Eingriff des
Systems (Wiederherstellung einer unterbrochenen Internet-Verbindung, Wiederherstellung der
Datenbank) repliziert.
|
Ungenaue Daten für einen Auftrag
|
H
|
Alle Aufträge, die nicht vollständig ausgeführt werden können oder durch erhöhten Systemaufwand
Zusatzkosten verursachen, sind inakzeptabel.
Hierfür kann es unter anderem folgende Ursachen geben:
-
Eine Bestelltransaktion wurde wegen eines Benutzereingriffs nicht
abgeschlossen/festgeschrieben.
-
Eine Bestelltransaktion wurde wegen einer Unterbrechung der Internet-Verbindung nicht
abgeschlossen/festgeschrieben.
-
Der Benutzer gibt ungültige Daten ein.
|
Die Anweisung spiegelt nicht die richtige Anzahl von Datensätzen wider.
|
H
|
Von der Genauigkeit dieser Berichte hängen Geschäftsentscheidungen und Außenstände ab.
Hierfür kann es unter anderem folgende Ursachen geben:
-
fehlerhafte Such-/Auswahlkriterien
-
fehlerhafte SQL-Anweisung
-
beschädigte Daten in der Datenbank
-
fehlerhafte Daten in der Datenbank
|
Wenn Sie ein Risiko nach Wahrscheinlichkeit einschätzen wollen, müssen Sie feststellen, wie wahrscheinlich es ist, das
es bei einem Anwendungsfall (oder einer Komponente für die Implementierung eines Anwendungsfalls) zu einem
Fehler/Ausfall kommt. Die Wahrscheinlichkeit wird in der Regel anhand externer Faktoren wie der folgenden ermittelt:
-
Ausfallquote
-
Änderungsrate
-
Komplexität
-
Ursprung / Urheber
Beachten Sie, dass sich die Risikofaktoren bei Verwendung dieser Risikoperspektive nur auf die Wahrscheinlichkeit eines
Fehlers/Ausfalls beziehen und nicht auf die Auswirkungen, die ein solcher auf die Organisation hat (wie es bei er
Einschätzung nach Wirkung und Ursache) der Fall ist.
Zwischen diesen Faktoren und der Wahrscheinlichkeit eines Fehlers/Ausfalls besteht folgende Korrelation:
Externer Faktor
|
Wahrscheinlichkeit
|
Fehlererkennungsquote
|
Mit zunehmender Fehlererkennungsquote oder -dichte steigt die Wahrscheinlichkeit eines
Fehlers/Ausfalls. Mängel haben die Tendenz, weitere Mängel nach sich zu ziehen. Wenn die Anzahl der
erkannten Mängel für einen Anwendungsfall oder eine Komponente steigt, erhöht sich die
Wahrscheinlichkeit, dass ein weiterer Mangel gefunden wird. Die Erkennungsquote oder -dichte früherer
Releases sollte bei der Einschätzung des Risikos aus dieser Perspektive mit berücksichtigt werden, da
eine hohe Erkennungsquote oder -dichte in diesen Releases auf eine hohe Wahrscheinlichkeit weiterer
Fehler/Ausfälle hinweisen.
|
Änderungsrate
|
Mit zunehmender Änderungsrate für einen Anwendungsfall oder eine Komponente steigt die
Wahrscheinlichkeit eines Fehlers/Ausfalls. Bei wachsender Anzahl der Änderungen erhöht sich die
Wahrscheinlichkeit, dass mit einer Änderung ein Fehler eingebracht wird. Jedes Mal, wenn der Code
geändert wird, besteht die Gefahr, dass sich ein Fehler einschleicht.
|
Komplexität
|
Mit zunehmender Komplexität des Anwendungsfalls oder der Komponente steigt die Wahrscheinlichkeit eines
Fehlers/Ausfalls.
|
Ursprung / Urheber
|
Das Wissen um den Ursprung und Urheber des Codes kann die Wahrscheinlichkeit eines Fehlers erhöhen oder
senken.
Die Verwendung von Komponenten eines Fremdanbieters kann die Fehlerwahrscheinlichkeit verringern,
sofern diese Komponenten zertifiziert sind, d. h. durch formale Tests oder aus Erfahrung nachweislich
Ihre Anforderungen erfüllen.
Je größer das Know-how des Implementierenden ist, desto geringer ist in der Regel die
Fehlerwahrscheinlichkeit. Dennoch können Faktoren wie die Verwendung neuer Tools oder Technologien und
die Verteilung von Aktivitäten auf mehrere Rollen die Fehlerwahrscheinlichkeit trotz guter
Teammitglieder erhöhen.
|
Beispiele:
-
Installation der neuen Software
-
"Laut Protokoll wurden viele Mängel bei den Komponenten festgestellt, die für die Implementierung der
Anwendungsfälle 1, 10 und 12 verwendet werden. Unsere Kunden haben viele Änderungen an den Anwendungsfällen 14 und
19 gefordert."
Nachfolgend sehen Sie eine Beispielmatrix für diese Punkte:
Beschreibung
|
Risikofaktor
|
Begründung
|
Installation neuer Software
|
H
|
Wir schreiben unser eigenes Installationsdienstprogramm.
Die Anwendung kann unbrauchbar sein. Bei der Installation macht sich der Benutzer einen ersten
Eindruck von der Anwendung. Scheitert die Installation, sieht der Benutzer die Software in einem
ungünstigen Licht.
|
Installation neuer Software
|
L
|
Wir verwenden ein bewährtes kommerzielles Installationsdienstprogramm.
Bei einer gescheiterten Installation ist die Anwendung zwar nicht brauchbar, aber das ausgewählte
Installationsdienstprogramm stammt von einem Hersteller, der mit diesem Produkt Marktführer und
seit Jahren erfolgreich im Geschäft ist. Unsere Auswertung hat ergeben, dass dieses Produkt unseren
Anforderungen genügt und andere Kunden mit dem Produkt und dem Hersteller sowie dessen Service und
Unterstützung zufrieden sind.
|
Hohe Fehlererkennungsquote/Mängeldichte in den Anwendungsfällen 1, 10, 12.
|
H
|
Aufgrund der bisherigen hohen Fehlererkennungsquote und Mängeldichte sind die Anwendungsfälle 1, 10 und
12 als mit hohem Risiko behaftet anzusehen.
|
Änderungsanfragen für die Anwendungsfälle 14 und 19
|
H
|
Die hohe Anzahl der Änderungen an diesen Anwendungsfällen erhöhen die Wahrscheinlichkeit, dass sich
Mängel in den Code eingeschlichen haben.
|
Der nächste Schritt bei der Einschätzung des Risikos und der Festlegung einer Testpriorität ist die Ermittlung des
Nutzungsprofils für das Testobjekt.
Benennen Sie zunächst die zu verwendenden Indikatoren für die Nutzungshäufigkeit und beschreiben Sie sie. Vergleichen
Sie dazu die folgenden Beispiele:
-
H - Sehr häufige Nutzung, viele Male pro Zeitraum oder durch viele Akteure bzw. Anwendungsfälle
-
M - Häufige Nutzung, mehrere Male pro Zeitraum oder durch mehrere Akteure bzw. Anwendungsfälle
-
L - Gelegentliche Nutzung oder Nutzung durch wenige Akteure bzw. Anwendungsfälle
Die Auswahl des Indikators für das Nutzungsprofil sollte auf der Häufigkeit basieren, mit der ein Anwendungsfall
ausgeführt oder eine Komponente verwendet wird. Diese Häufigkeit drückt sich unter anderem durch Folgendes aus:
-
die Häufigkeit, mit der EIN Akteur (oder Anwendungsfall) den Anwendungsfall (oder die Komponente) innerhalb einer
gegebenen Zeit ausführt
-
die Anzahl der AKTEURE (oder Anwendungsfälle), die den Anwendungsfall (oder die Komponente) ausführen
Je häufiger ein Anwendungsfall ausgeführt oder eine Komponente verwendet wird, desto höher ist in der Regel der
Indikator für das Nutzungsprofil.
Listen Sie nach Festlegung der Indikatoren für die Nutzungshäufigkeit alle zum Testobjekt gehörenden Anwendungsfälle
oder Komponenten auf. Bestimmen Sie für jeden Listeneintrag einen Nutzungsprofilindikator und geben Sie eine Begründung
für den Indikator an. Für diese Einschätzung können Sie das Dokument zur Auslastungsanalyse heranziehen (siehe Arbeitsergebnis: Modell für Auslastungsanalyse).
Beispiele:
-
Installation neuer Software
-
Bestellung von Artikeln aus dem Onlinekatalog
-
Onlinenachfragen von Kunden nach Aufgabe der Bestellung
-
Dialog für Produktauswahl
Beschreibung
|
Nutzungsprofilfaktor
|
Begründung
|
Installation neuer Software
|
H
|
Wird (normalerweise) nur einmal durchgeführt, jedoch von vielen Benutzern. Ohne Installation kann die
Anwendung nicht genutzt werden.
|
Bestellung von Artikeln aus dem Katalog
|
H
|
Dies ist der häufigste Anwendungsfall bei den Benutzern.
|
Kundennachfragen zu Bestellungen
|
L
|
Nur wenige Kunden haben Nachfragen, nachdem Sie ihre Bestellungen aufgegeben haben.
|
Dialog für Produktauswahl
|
H
|
Dieser Dialog wird von Kunden für die Bestellung von Produkten und von der Lagerverwaltung zur
Auffüllung des Warenbestandes genutzt.
|
Der letzte Schritt bei der Einschätzung des Risikos und der Festlegung einer Testpriorität ist die Festlegung der
Testpriorität.
Benennen Sie zunächst die zu verwendenden Indikatoren für die Höhe der Testpriorität und beschreiben Sie sie.
Vergleichen Sie dazu die folgenden Beispiele:
-
H - Muss getestet werden
-
M - Sollte getestet werden, jedoch erst, nachdem alle Elemente mit Indikator H getestet wurden
-
L - Kann getestet werden, jedoch erst, wenn alle Elemente mit den Indikatoren H und M getestet wurden
Listen Sie nach Festlegung der Indikatoren für die Höhe der Priorität alle zum Testobjekt gehörenden Anwendungsfälle
oder Komponenten auf. Bestimmen Sie für jeden Listeneintrag einen Indikator für die Testpriorität und geben Sie eine
Begründung an. Nachfolgend sind einige Richtlinien für die Festlegung eines Prioritätsindikators angegeben.
Berücksichtigen Sie bei der Festlegung der Prioritätsindikatoren für die einzelnen Einträge Folgendes:
-
den zuvor festgelegten Indikator für die Risikohöhe
-
den zuvor festgelegten Indikator für das Nutzungsprofil
-
die Beschreibungen der Akteure (Sind sie erfahren? Kennen sie Strategien zur Behebung von Problemen?)
-
vertragliche Verpflichtungen (Ist das Testobjekt annehmbar, wenn ein Anwendungsfall oder eine Komponente nicht
geliefert wird?)
Es gibt unter anderem folgende Strategien für die Festlegung einer Testpriorität:
-
Verwenden Sie den höchsten Bewertungsfaktor (Risiko, Nutzungsprofil usw.) als Faktor für die generelle Priorität.
-
Geben Sie an, welcher der Bewertungsfaktoren (Risiko, Nutzungsprofil usw.) die größte Bedeutung hat, und verwenden
Sie diesen Faktor als Prioritätsfaktor.
-
Nutzen Sie eine Kombination aus mehreren Bewertungsfaktoren zur Bestimmung der Priorität.
-
Gewichten Sie die einzelnen Bewertungsfaktoren nach einem Gewichtungsschema und berechnen Sie die Priorität nach
der Gewichtung.
Beispiele:
-
Installation neuer Software
-
Bestellung von Artikeln aus dem Onlinekatalog
-
Onlinenachfragen von Kunden nach Aufgabe der Bestellung
-
Dialog für Produktauswahl
Festlegung der Priorität nach höchstem Bewertungsfaktor:
Punkt
|
Risiko
|
Nutzungsprofil
|
Akteur
|
Vertrag
|
Priorität
|
Installation neuer Software
|
H
|
H
|
L
|
H
|
H
|
Bestellung von Artikeln aus dem Katalog
|
H
|
H
|
H
|
H
|
H
|
Kundenrückfragen
|
L
|
L
|
L
|
L
|
L
|
Dialog für Produktauswahl
|
L
|
H
|
L
|
L
|
H
|
Festlegung der Priorität nach dem Wert eines Bewertungsfaktors (Risiko):
Punkt
|
Risiko
|
Nutzungsprofil
|
Akteur
|
Vertrag
|
Priorität
|
Installation neuer Software
|
H
|
H
|
L
|
H
|
H
|
Bestellung von Artikeln aus dem Katalog
|
H
|
H
|
H
|
H
|
H
|
Kundenrückfragen
|
L
|
L
|
L
|
L
|
L
|
Dialog für Produktauswahl
|
L
|
H
|
L
|
L
|
L
|
Berechnung der Priorität anhand einer Gewichtung:
(Anmerkung: In der folgenden Matrix gelten die Gewichtungen H = 5, M = 3 und L = 1. Eine Gesamtgewichtung von mehr als
30 kennzeichnet einen Test mit hoher Priorität, Werte von 20 bis einschließlich 30 einen Test mit mittlerer Priorität
und Werte unter 20 einen Test mit niedriger Priorität.)
Punkt
|
Risiko (x 3)
|
Nutzungsprofil (x 2)
|
Akteur (x 1)
|
Vertrag (x 3)
|
Gewichtung
|
Priorität
|
Installation neuer Software
|
5 (15)
|
5 (10)
|
1 (1)
|
5 (15)
|
41
|
H (2)
|
Bestellung von Artikeln aus dem Katalog
|
5 (15)
|
5 (10)
|
5 (5)
|
5 (15)
|
45
|
H (1)
|
Kundenrückfragen
|
1 (3)
|
1 (2)
|
1 (1)
|
1 (3)
|
9
|
L (4)
|
Dialog für Produktauswahl
|
1 (3)
|
5 (10)
|
1 (1)
|
1 (3)
|
17
|
L (3)
|
Die Teststrategie beschreibt den allgemeinen Ansatz und die allgemeinen Zielsetzungen für einen bestimmten Test.
In einer guten Teststrategie darf Folgendes nicht fehlen:
Formulieren Sie klar die Art des zu implementierenden Tests und dessen Zielsetzung. Je genauer Sie diese Informationen
angeben, desto weniger Unklarheiten und Missverständnisse sind möglich. (Dies gilt insbesondere, wenn es mehrere sehr
ähnliche Tests gibt.) Aus der Zielsetzung sollte klar hervorgehen, warum der Test ausgeführt wird.
Beispiele:
"Funktionstest. Der Funktionstest konzentriert sich auf die Ausführung der folgenden, im Testobjekt implementierten
Anwendungsfälle auf der Benutzerschnittstelle."
"Leistungstest. Schwerpunkt des Leistungstests für das System wird die Messung der Reaktionszeit für die
Anwendungsfälle 2, 4 und 8-10 sein. Für diesen Test wird das System nur von einem Akteur genutzt, der diese
Testfälle ausführt. Das System unterliegt keinen weiteren Belastungen."
"Konfigurationstest. Der Konfigurationstest wird implementiert, um das Verhalten des Testobjekts in drei
verschiedenen Konfigurationen festzustellen und zu bewerten. Die Leistungskenndaten werden mit unserer
Benchmark-Konfiguration verglichen."
Geben Sie klar die Phase an, in der der Test ausgeführt werden soll. Nachfolgend sind die Phasen angegeben, in denen
Tests allgemein durchgeführt werden:
|
Phase für Testausführung
|
Art der Tests
|
Einheit
|
Integration
|
System
|
Abnahme
|
Funktionstest
(Konfiguration, Funktion, Installation, Sicherheit, Volumen)
|
X
|
X
|
X
|
X
|
Leistungstests
(Leistungsprofile einzelner Komponenten)
|
X
|
X
|
(X)
Optional oder bei Feststellung von Mängeln bei Systemtests
|
|
Leistungstests
(Auslastung, Belastung, Konflikte)
|
|
|
X
|
X
|
Zuverlässigkeit
(Integrität, Struktur)
|
X
|
X
|
(X)
Optional oder bei Feststellung von Mängeln bei anderen Tests
|
|
Das Verfahren sollte beschreiben, wie die Tests implementiert und ausgeführt werden. Geben Sie auch an, was getestet
werden soll, welche wichtigen Maßnahmen während der Testausführung zu ergreifen sind und welche Methoden für die
Evaluierung der Tests angewendet werden sollen.
Beispiel:
Funktionstest:
-
Für jeden Ereignisablauf im Anwendungsfall wird eine repräsentative Gruppe von Transaktionen angegeben, die die
Aufgaben des Akteurs bei Ausführung des Anwendungsfalls widerspiegeln.
-
Für jede Transaktion werden mindestens zwei Testfälle entwickelt. Ein Testfall repräsentiert den positiven
Zustand und der andere den negativen (inakzeptablen) Zustand.
-
In der ersten Iteration werden die Anwendungsfälle 1-4 und 12 wie folgt getestet:
-
Anwendungsfall 1:
-
Der Anwendungsfall 1 beginnt, wenn sich der Akteur bei der Anwendung angemeldet hat und das
Hauptfenster angezeigt wird. Er endet, wenn der Benutzer 'Speichern' ausgewählt hat.
-
Alle Testfälle werden mit Rational Robot implementiert und ausgeführt.
-
Zur Überprüfung und Einschätzung der Ausführung aller Testfälle werden die folgenden Methoden
angewendet:
-
Ausführung der Test-Scripts (Konnte jedes Test-Script fehlerfrei und wie vorgesehen
ausgeführt werden?)
-
Mit (in den Test-Scripts implementierten) Methoden zur Überprüfung des Vorhandenseins
von Fenstern oder von Daten wird festgestellt, ob die wichtigsten Fenster angezeigt
werden und die angegebenen Daten während der Testausführung vom Testobjekt
erfasst/angezeigt werden.
-
Die Datenbank des Testobjekts wird vor und nach dem Test (mit Microsoft Access)
untersucht,um festzustellen, ob die Daten die während des Tests vorgenommenen
Änderungen exakt widerspiegeln.
Leistungstest:
-
Für jeden Anwendungsfall wird wie im Dokument zur Auslastungsanalyse angegeben eine repräsentative Gruppe von
Transaktionen implementiert und mit Rational Suite PerformanceStudio (vu-Scripts) und Rational Robot
(GUI-Scripts) ausgeführt.
-
Die Test-Scripts und Testausführungspläne beziehen sich auf mindestens drei Auslastungen, einschließlich der
folgenden:
-
Extreme Dauerbelastung: 750 Benutzer (15 % Management, 50 % Verkauf, 35 % Marketing)
-
Auslastungsspitze: 350 Benutzer (10 % Management, 60 % Verkauf, 30 % Marketing)
-
Nominale Auslastung: 150 Benutzer (2 % Management, 75 % Verkauf, 23 % Marketing)
-
Die Test-Scripts für die Ausführung der einzelnen Transaktionen enthalten die erforderlichen Zeitgeber zur
Erfassung der Antwortzeiten, z. B. der gesamten Transaktionszeit (gemäß Dokument zur Auslastungsanalyse) und
der Zeit für wichtige Transaktionsaufgaben oder -prozesse.
-
Die Test-Scripts halten die Auslastungen für eine Stunde aufrecht (sofern im Dokument zur Auslastungsanalyse
nichts anderes angegeben ist).
-
Zur Überprüfung und Einschätzung der Ausführung aller Auslastungstests gehört Folgendes:
-
Die Testausführung wird mit Statushistogrammen überwacht (um sicherzustellen, dass Test und
Auslastungen der Planung und den Erwartungen entsprechen).
-
Ausführung der Test-Scripts (Konnte jedes Test-Script fehlerfrei und wie vorgesehen ausgeführt werden?)
-
Erfassung und Bewertung der ermittelten Antwortzeiten in folgenden Berichten:
-
Leistungsperzentil
-
Antwortzeit
Erfüllungskriterien werden aus zwei Gründen angegeben:
-
Sie helfen festzustellen, ob die Produktqualität annehmbar ist.
-
Sie helfen festzustellen, ob die Tests erfolgreich implementiert wurden.
Klar angegebene Erfüllungskriterien sollte unter anderem Folgendes umfassen:
-
zu messende Funktion, zu messendes Verhalten oder zu messender Zustand
-
Messmethode
-
Konformität(skriterien) der Messungen
Beispiel 1
-
Alle geplanten Testfälle wurden ausgeführt.
-
Alle bekannten Mängel wurden bearbeitet und einer einvernehmlichen Lösung zugeführt.
-
Alle geplanten Testfälle wurden erneut ausgeführt und alle bekannten Mängel wurden einvernehmlich behoben. Es
wurden keine neuen Mängel entdeckt.
Beispiel 2
-
Es wurden alle Testfälle mit hoher Priorität ausgeführt.
-
Alle bekannten Mängel wurden bearbeitet und einer einvernehmlichen Lösung zugeführt.
-
Alle Mängel mit Schweregrad 1 oder 2 wurden beseitigt (Status = beseitigt oder zurückgestellt).
-
Alle Testfälle mit hoher Priorität wurden erneut ausgeführt und alle bekannten Mängel wurden einvernehmlich
behoben. Es wurden keine neuen Mängel entdeckt.
Beispiel 3
-
Alle geplanten Testfälle wurden ausgeführt.
-
Alle bekannten Mängel wurden bearbeitet und einer einvernehmlichen Lösung zugeführt.
-
Alle Mängel mit Schweregrad 1 oder 2 wurden beseitigt (Status = überprüft oder zurückgestellt).
-
Alle Testfälle mit hoher Priorität wurden erneut ausgeführt und alle bekannten Mängel wurden einvernehmlich
behoben. Es wurden keine neuen Mängel entdeckt.
In diesem Abschnitt sollten alle Einflüsse und Abhängigkeiten aufgelistet werden, die sich auf die in der Teststrategie
beschriebenen Testverfahren auswirken könnten. Hierzu gehören unter anderem:
-
Personal (Ressourcenverfügbarkeit/-bedarf zur Unterstützung von Tests bzw. zur Teilnahme an Tests)
-
Einschränkungen (Ausrüstungs- oder Verfügbarkeitsgrenzen, der Bedarf an Sonderausrüstungen oder das Fehlen von
Sonderausrüstungen)
-
spezielle Anforderungen, z. B. Zeitplanung für Tests oder Zugriff auf Systeme
Beispiele:
-
Testdatenbanken erfordern die Unterstützung durch einen Datenbankdesigner/-administrator, der Testdaten erstellen
und aktualisieren muss.
-
Für Systemleistungstests werden die Server des vorhandenen Netzes verwendet (die auch für testunabhängigen
Datenverkehr genutzt werden). Die Tests müssen für die Zeit nach Geschäftsschluss geplant werden, um
sicherzustellen, dass außerhalb der Tests kein Datenverkehr im Netz stattfindet.
-
Das Testobjekt muss mit dem herkömmlichen System synchronisiert werden (ggf. simulierte Synchronisation), um einen
vollständigen Funktionstest implementieren und ausführen zu können.
|