Software Projekt 2009/10 VAK Testplan Version 1.0

Transkript

1 Software Projekt 2009/10 VAK Testplan Version 1.0 xxxxxx xxxxxxx xxxx xxxxxxxx xxxx xxxxx xxxxxxxx xxxxxxxxxx xxxxxx xxx Abgabe: 1. April 2010

2 Inhaltsverzeichnis 0 Version und Änderungsgeschichte 3 1 Einführung Zweck Umfang Beziehungen zu anderen Dokumenten Aufbau der Testbezeichner Definitionen und Akronyme Referenzen. 5 2 Systemüberblick Module der Anwendungsschicht und deren Funktionen. 6 3 Merkmale Zu testende Merkmale Funktionale Anforderungen Nicht zu testende Merkmale 7 4 Abnahme- und Testendkriterien 8 5 Vorgehensweise Komponenten- und Integrationstest Funktionstest Aufhebung und Wiederaufnahme 10 7 Hardware- und Softwareanforderungen Hardware Software Testfälle Komponententest Integrationstest Funktionstest Leistungstest Härtetest Volumentest Sicherheitstest Erholungstest. 16 2

3 0 Version und Änderungsgeschichte

4 1 Einführung Wozu dient das Dokument, und an wen richtet es sich? Bei dem vorliegenden Dokument handelt es sich um den Testplan für das System BiBi, das von der Gruppe Bauhaus Software Technologies im Rahmen des Softwareprojekts 2009/2010 an der Universität Bremen erstellt wird. 1.1 Zweck Zweck des Testplans ist es, ein organisiertes und systematisches Testen des Systems BiBi zu ermöglichen. Es werden die zu testenden Komponenten des Systems benannt und zu diesen adäquate Testfälle entworfen. Auch werden Kriterien gesetzt, wann der Test als erfolgreich durchgeführt gilt und wann er abgebrochen werden muß. Desweiteren werden Anforderungen an Hardware, Software und andere Betriebsmittel, die für die Tests benötigt werden, definiert. Der Testplan richtet sich an den Kunden, an das Entwicklungsteam sowie insbesondere die Tester. 1.2 Umfang Inhalt und Aufbau dieses Testplanes entsprechen der im Rahmen des Softwareprojekts vorgestellten vereinfachten Form des IEEE Standard ??. Schwerpunkt der Testfälle sollen hier Integrations- und Leistungstests sein. In diesem Dokument sind die Spezifikationen der Komponententests nicht enthalten; diese werden als JUnit-Testfälle erstellt, und deren Spezifikation ist daraus direkt ersichtlich. 1.3 Beziehungen zu anderen Dokumenten Im Testplan wird dargelegt, wie die Erfüllung der Anforderungsspezifikation und Einhaltung der Architektur sichergestellt wird. Insofern ist ein direkter Bezug zu beiden Dokumenten gegeben. Die Anwendungsfälle werden direkt als Testfälle für Abnahmetests dienen. 4

5 1.4 Aufbau der Testbezeichner Die Testbezeichner sind nach folgendem Prinzip aufgebaut: Die ersten beiden Buchstaben stehen für die Art des Tests (vgl. Tabelle 1). Dann folgt eine Testfallnummer der vorne angegebenen Testart. Die Variationen oder untergeordnete Testfälle des Testfalls werden in alphabetischer Reihenfolge bezeichnet. Dieser Teil ist optional. Beispiel: FT 1 C steht für Funktionstest Nummer 1, Variante 3. IT FT LT Integrationstest Funktionstest Leistungstest Tabelle 1: Kürzelzuordung der Testbereiche 1.5 Definitionen und Akronyme KLOC: Kilo Lines Of Code, ein Größenmaß für Software. 1.6 Referenzen 5

6 2 Systemüberblick Dieser Abschnitt soll einen Überblick über das System geben, und zwar insbesondere hinsichtlich jener Komponenten, die durch Komponententests geprüft werden sollen. Dazu ist die richtige Granularität der Komponenten wichtig (einzelne Klassen, ganze Pakete oder Systeme, etc.). Für den Integrationstest sind die Abhängigkeiten der Komponenten voneinander von besonderer Wichtigkeit. Der Überblick sollte leicht verständlich sein und sich auf die wesentlichen benötigten Informationen konzentrieren. Hier sind evtl. auch Referenzen auf die Architekturbeschreibung angebracht. Es sollten die Hofmeister-Konzepte verwendet werden. Benutzt am besten Diagramme aus der Architekturbeschreibung. Das System BiBi setzt sich aus dem Client und dem Server zusammen Hier folgen die Diagramme, weitere Beschreibungen, etc. 2.1 Module der Anwendungsschicht und deren Funktionen Hier solltet ihr dann die einzelnen Module aus Sicht des Tests weiter verfeinern. Auch wäre noch eine Grafik angebracht, die die Abhängigkeiten der Subsysteme/Module zeigt, sowie eine kurze Beschreibung dazu. 6

7 3 Merkmale Hier sollen die zu testenden Merkmale, aber auch die nicht zu testenden Merkmale (mit Begründung) aufgelistet werden. Welche Kombinationen von Merkmalen sind relevant? 3.1 Zu testende Merkmale Die implementierten Klassen müssen korrekt funktionieren. Das Zusammenspiel zwischen einzelnen Klassen bzw. Komponenten muss korrekt vonstatten gehen. Ebenso müssen externe Komponenten wie Datenbank- und SMTP- Server korrekt angebunden werden. Die Module sind auf Einhaltung ihrer Spezifikation zu testen. Das System muss angemessen auf auftretende Fehler und unerwartete Eingaben reagieren Funktionale Anforderungen Die Anforderungen aus der Anforderungsspezifikation müssen erfüllt werden. Welche sind besonders wichtig? 3.2 Nicht zu testende Merkmale Verwendete Java-Bibliotheken von Drittanbietern (z. B. JDBC, JPA, ) müssen nicht getestet werden, da diese von den Anbietern selbst getestet wurden. Selbiges gilt für Server-Software von Drittanbietern (z. B. MySQL-Datenbank- Server, Mail-Server, ). Getestet wird nur das Zusammenspiel mit diesen Bibliotheken. Methoden von Java-Klassen, wie z.b. set- und get-methoden, die lediglich auf die Attribute eines Objektes zugreifen, brauchen nicht getestet zu werden. 7

8 4 Abnahme- und Testendkriterien Wann wird das Testen beendet? Die angegebenen Kriterien müssen objektiv prüfbar sein. Die wahre Fehlerzahl einer Software ist unbekannt. Daher müssen im Vorfeld Kriterien bestimmt werden, die festlegen, in welchem Umfang das Testen stattfindet und wann die Tests beendet werden können. Anweisungsabdeckung: Bei den White-Box-Tests wird die Anweisungsabdeckung gemessen. Wir streben eine Anweisungsabdeckung von 90 Prozent an. Mit Hilfe des Tools xyz kann diese bestimmt werden. Ebenfalls kann damit festgestellt werden, welche Zeilen des Codes vom Testfall durchlaufen wurden und welche nicht. Die Tests müssen die angegebene Anweisungsabdeckung erreichen, vorher darf nicht abgebrochen werden. Testergebnisse: Erfolgreiche Tests (d.h. Tests, die einen Fehler gefunden haben), werden in Fehlerklassen entsprechend Tabelle 2 kategorisiert. Pro 1000 Zeilen Code dürfen nur Fehler mit einer Wertigkeitssumme von x auftreten. Das Testen darf nicht beendet werden, solange noch Fehler der Klassen 3 oder 4 auftreten. Fehlerklasse Beschreibung Wertigkeit 1 unwesentlich: Fehler, der keine sichtbaren Schäden 1 verursacht, aber trotzdem korrigiert werden muss 2 gering: Fehler, der das System in seiner Leistung 10 einschränken oder dessen Verfügbarkeit reduzieren könnte 3 kritisch: Fehler, der schwere Schäden am System 20 verursachen kann 4 katastrophal: Fehler, der die Unterbrechung des Systems verursachen kann bzw. das System unbrauchbar macht 100 Tabelle 2: Fehlerklassen 8

9 5 Vorgehensweise 5.1 Komponenten- und Integrationstest Klassen werden mit JUnit-Testfällen geprüft. Vor Beginn der Implementierung werden bereits Blackbox-Testfälle erstellt, die dann begleitend zur Implementierung genutzt werden ( Test first ). Nach Abschluss der Implementierung einer Komponente wird diese dann durch Whitebox- Tests geprüft. Der Integrationstest der Klassen und Komponenten erfolgt nach dem Bottom-Up-Prinzip [vgl.?]. Anfangs muss die Integration von JPA und den entsprechenden Data- Access-Objects (DAO) geprüft werden, da das Mapping der Datenbank auf Objekte die unterste Schicht von BiBi bildet. Dieser Testabschnitt wird durch die Schnittstellentests abgedeckt. Diesem Testabschnitt schließen sich die Tests der in Abschnitt 2.1 dargestellten Module an, wobei der Schwerpunkt erst auf dem Zugriff auf die tiefer liegenden Abstraktionsschichten liegen soll. Erst dann erfolgt der Test auf vertikaler Ebene, also der Interaktion zwischen den Modulen. Die Komponenten werden damit unter Berücksichtigung ihrer Abhängigkeiten konkret in folgender Reihenfolge integriert: Hier kommt das konkrete Vorgehen bei der Integration: Welche Klassen werden zusammen getestet, welche kommen dann dazu, etc. Das kann man z.b. auch schön in Form eines Baumes aufzeigen. 5.2 Funktionstest Die Anwendungsfälle aus der Anforderungsspezifikation werden über das graphische Interface geprüft. Mindestanforderung hierfür ist es, jeden Fall einmal auf seine korrekte Funktionalität zu testen. 9

10 6 Aufhebung und Wiederaufnahme Wenn sich während des Testverlaufs zeigt, dass die Anzahl der fehlschlagenden Tests einen Schwellwert übersteigt, ist es sinnvoll, die Tests abzubrechen und zur Implementierungsphase zurückzukehren. Dieser Schwellwert ist abhängig von der jeweiligen Testphase, der Testart sowie der Schwere des Fehlers. Fehler in den unteren Schichten haben eine starke Auswirkung auf die Funktionsweise des Systems, da sie zu fehlerhaften Übergaben von Daten an Methoden einer höheren Schicht führen. Die abhängigen Komponenten können dann nicht mehr sinnvoll getestet werden. Bei Testfällen in tiefer liegenden Schichten muß deshalb ein niedrigerer Schwellwert angesetzt werden als bei Tests in oberen Schichten (z.b. Tests der Controller-Schicht oder Funktionstests). Hier folgt die konkrete Festlegung des Schwellwerts für die verschiedenen Szenarien. Bei der Wiederaufnahme der Testphase muß beachtet werden, daß Veränderungen an Komponenten dazu führen, dass alle davon abhängigen Komponenten neu getestet werden müssen. 7 Hardware- und Softwareanforderungen Hier soll das zu prüfende Material spezifiziert werden. Auf welchen Rechnern werden die Tests durchgeführt? Welche anderen Hilfsmittel oder Ressourcen sind dafür nötig? 7.1 Hardware Für die Durchführung der Tests wird folgende Hardware benötigt: Server: Ein Server entsprechend den spezifizierten Mindestanforderungen (siehe Anforderungsspezifikation). Rechner: Für die Integrations- und Funktionstests wird ein Rechner mit mindestens 256 MB Hauptspeicher benötigt. Für die Leistungstests werden 20 Rechner mit mind. 256 MB Hauptspeicher und bestehender Internetanbindung benötigt. Weiterhin werden entsprechend viele Helfer benötigt, die die Software bedienen. Arbeitsraum: Die Tests werden in MZH Ebene 0 durchgeführt. 10

11 7.2 Software Neben dem eigentlichen System werden folgende Hilfsprogramme eingesetzt: JUnit 3.8 für Unit-Tests Tool xyz für Testabdeckungsmessung HTML Tidy zur Validierung von HTML 11

12 8 Testfälle Dies ist der wichtigste (und vermutlich umfangreichste) Teil des Testplans. Hier wird genau aufgelistet, was wie und von wem getestet wird. Das spätere Testen besteht dann einfach aus einer Durchführung dieser Tests. Zu jedem Testfall muss es eine Testfallspezifikation geben (außer Komponententests, siehe unten). Schwerpunkt sollen hier Integrations- und Leistungstests sein. Welche Arten von Integrationstests und Leistungstests seht Ihr vor, und wie wollt Ihr diese genau ausgestalten? 8.1 Komponententest Auf die genaue Spezifikation der Komponententests könnt Ihr verzichten diese werden durch die JUnit-Testfälle gegeben. Uns genügt hierzu eine Beschreibung, welche Komponenten/Klassen wie, wann und durch wen getestet werden sollen. Die zugehörigen JUnit-Tests werden separat abgegeben (Black-Box jetzt, White-Box später) und müssen im Testplan nicht als Code aufgeführt werden. Es werden JUnit-Testfälle entsprechend Tabelle 3 erstellt. Die Black-Box-Tests sind bei Abgabe des Testplans bereits fertiggestellt und liegen dem Dokument bei, die White-Box-Tests werden nach Abschluss der Implementierung der entsprechenden Komponente durchgeführt (siehe Zeitplanung im Projektplan Kapitel 5). Klasse Implementierer Tester Testart ReferenceManagement Klaus Hans Blackbox UserManagement Anna Klaus Blackbox ReferenceTable Heinz Bert Whitebox Tabelle 3: Komponententests Achtet darauf, dass der Tester ein anderer ist als der Implementierer. Jeder soll mind. 1 Klasse Black-Box und 1 Klasse White-Box testen! Hier könnten später noch die Kontrollflussdiagramme für die Whiteboxtests eingefügt werden. 12

13 8.2 Integrationstest Die Integrationstests werden hier genauer beschrieben: Welche Klassen sind beteiligt? Wie ist der Zustand des Systems vor Beginn? Welche Eingaben werden getätigt? Welche Ergebnisse/welches Verhalten wird erwartet? Aufbau einer Testfallspezifikation: 1. eindeutiger Testfallbezeichner (entspr. Namenskonvention) 2. Testobjekte: welche Komponenten werden getestet? 3. Eingabespezifikationen (erwartete Eingaben) 4. Ausgabespezifikationen (erwartete Ausgaben) 5. Umgebungserfordernisse (notwendige Software- und Hardwareplattform sowie Testrümpfe und -stümpfe) 6. besondere prozedurale Anforderungen (Einschränkungen wie Zeitvorgaben, Belastung oder Eingreifen durch den Operator) 7. Abhängigkeiten zwischen Testfällen Die folgenden Beispiele halten sich nicht vollständig daran Ihr solltet das aber tun. IT 1 Integration User/Entleihung IT 1 A Testziel Erhalt der Relation zwischen User und Entleihung nach Löschen des Users Voraussetzung Referenz gehört User Eingabe User löschen erwartete Ausgabe User ist gelöscht; Referenz führt eine anonymisierte Variante des Users als Besitzer Abhängigkeiten 13

14 8.3 Funktionstest Die Funktionstests basieren auf den Anwendungsfällen. Diese müssen hier nun konkretisiert werden, um einen Testfall zu erhalten. Auch das Verhalten im Fehlerfall sollte getestet werden. In Eurem Testplan ist dieser Teil nicht explizit verlangt. Im Ernstfall würde der Teil aber wichtiger Bestandteil des Testplans sein, da er häufig auch für die Abnahme durch den Kunden genutzt wird. Für Euer Dokument reicht hier ein Verweis auf die Anwendungsfälle. Trotzdem hier ein Beispiel, wie das aussehen könnte. Für alle Tests der Anwendungsfälle gelten folgende allgemeine Voraussetzungen: ein betriebsbereiter Arbeitsplatzrechner mit einer Java 1.6 Installation eine aktive Internetverbindung ein betriebsbereiter BiBi-Server Erläuterungen zur Tabelle: Die Bezeichnung der Anwendungsfälle bezieht sich auf unsere Anforderungsspezifikation. Die angegebenen Abhängigkeiten beziehen sich auf die Tests der Anwendungsfälle, nicht auf sonstige Tests. Die Notation Home/Search beschreibt, wie man auf dem Interface navigieren muß, um zu der gerade beschriebenen Seite zu gelangen. Die Startseite wird mit Home betzeichnet. In der Regel wird jeder Anwendungsfall einmal auf korrekte Funktionalität geprüft und einmal auf korrektes Verhalten im Fehlerfall. FT 1 Anwendungsfall Referenzen auffinden über reguläre Ausdrücke FT 1 A Testziel Überprüfung des Normalfalls Voraussetzung Testperson befindet sich auf der Startseite des Systems; das System enthält eingestellte Referenzen mit Autoren namens Koschke oder Kosilke. Eingabe Eintrag von Kos*ke in das Suchfeld und klicken des search -Buttons. erwartete Ausgabe Liste aller Datensätze, deren AutorInnen dem regulären Ausdruck Kos*ke entsprechen. Abhängigkeiten FT 1 B Testziel Überprüfung des Fehlerfalls Voraussetzung Testperson befindet sich auf der Startseite des Systems; das System enthält eingestellte Referenzen. 14

15 Eingabe erwartete Ausgabe Abhängigkeiten FT 2 Klicken des search -Buttons ohne vorherige Eingabe Es erscheint die Aufforderung die Eingabe zu überprüfen und den Vorgang zu wiederholen. 8.4 Leistungstest Die Leistungstests prüfen die Leistungsanforderungen, wie z. B. Reaktionszeiten, das Verhalten unter extremen Bedingungen, bei großen Datenmengen, etc Härtetest LT 1 Referenzen auffinden über reguläre Ausdrücke Testziel Überprüfung der korrekten Funktionalität bei 20 zeitnahen Anwendungen. Voraussetzung 20 Testpersonen befinden sich auf der Startseite des Systems. Eingabe User geben einen Suchstring ein und klicken fast gleichzeitig den search -Button erwartete Ausgabe Abhängigkeiten LT 2 Liste aller Datensätze, deren AutorInnen den jeweiligen Suchstrings entsprechen. Die Antwort muss innerhalb von 5 Sekunden erfolgen Volumentest LT 3 Viele Referenzen Testziel Vorbedingung Überprüfung der korrekten Funktionalität bei Einträgen. Das System wurde mit zufällig generierten BibTex-Einträgen gefüllt. Testperson befindet sich auf der Startseite. 15

16 Eingabe erwartete Ausgabe Abhängigkeiten LT 4 Eintrag von * in das Suchfeld und klicken des search -Buttons. Alle Referenzen werden gefunden, die ersten 50 werden auf einer Seite angezeigt, die weiteren sind über Blättern erreichbar. Die Anwort muss innerhalb von 5 Sekunden erfolgen Sicherheitstest LT 5 LT 6 Login Testziel Vorbedingung Eingabe erwartete Ausgabe Abhängigkeiten SQL Injection Überprüfung der korrekten Funktionalität beim Versuch eines unbefugten Zugriffs. Testpersonen befinden sich jeweils auf der Seite login. Das Feld loginname wird mit einem gültigen Login ausgefüllt, das Feld password wird mit einem beliebigen String ausgefüllt. Anschließend wird der Login Button betätigt. Es erscheint eine Seite mit einer erneuten Aufforderung zur Eingabe der Logindaten Erholungstest Hier wird geprüft, ob sich das System von Fehlerzuständen auch wieder erholt. Es werden also gezielt Fehler provoziert, um die Korrektheit der Systemreaktion herauszufinden. 16