Haben wir das richtige gebaut?

Transkript

1 1 Inhalt des points 2 Review plan debugging HOM/FHTeL SEN1 Software Engineering Februar /32 Haben wir das richtige gebaut? Inhalt des points Abbildung : Kommunikation zwischen Fachabteilung und Entwicklung Bei der Kommunikation zwischen Fachabteilung und Entwicklung findet ein Transfer aus einer Fachsprache in eine andere statt. HOM/FHTeL SEN1 Software Engineering Februar /32 Was ist ein Akzeptanztest? Inhalt des points Bei der Auflieferung von maßgeschniederter Software findet immer einen Akzeptanztest statt. Ziel des : Genügt die Software den Bedingungen und Wünsche des Auftragsgeber? Ist die Software geeignet für die produktive Inbetriebnahme? HOM/FHTeL SEN1 Software Engineering Februar /32 1

2 des Auftragsgebers Inhalt des points Gewährleistungsbedingungen Der Lieferant kann die Kosten der Korrektur berechnen, wenn ein Fehler bei der Ausführung eines Akzeptanztest auftritt. Nach Akzeptanz ist der Lieferant auf Grund dieser Vereinbarung nicht gehalten die Fehler in der Software zu korrigieren. HOM/FHTeL SEN1 Software Engineering Februar /32 des Softwareentwicklers Inhalt des points Qualität und Effizienz Mittels eines gründlich ausgeführten, werden mögliche Kosten für Ausbesserungsarbeiten gespart. Die Testperiode bietet eine gute Gelegenheit um die Qualität und Zuverlässigkeit der Software zu verbesseren. HOM/FHTeL SEN1 Software Engineering Februar /32 Die Verhandlung Inhalt des points Unvolkommentheiten sind Fehler und Mangel oder das in irgendeiner Art und Wiese Abweichen von der Spezifikation. Je genauer die Spezifikationen sind, desto größer wird die Chance das der Auftragsgeber Mängel finden kann. Der Auftragsgeber wird seine Anforderungen so genau wie möglich beschreiben wollen. HOM/FHTeL SEN1 Software Engineering Februar /32 2

3 Inhalt des 1 Inhalt des points Die Funktionalität: Alle Aspekte des Verhalten und die Ergebnisse nach der vereinbarten Spezifikationen. Robustheit. Sinnvolles reagieren auf Fehleingabe, technische Fehlsituationen und Benutzerfehler. Die Konversionsprozedur für das Übertragen der Daten auf die neue Software. Bindung mit anderen Informationssysteme. HOM/FHTeL SEN1 Software Engineering Februar /32 Inhalt des Akzeptanztest 2 Inhalt des points Die Leistung Die Benutzerfreundlichkeit Die Qualitätsgarantien, wie Vereinbart In der Informatik allgemein gängige Ausgangspunkte der Qualität und Tauglichkeit. Die Dokumentation für Verwalter und Benutzer. Die Prozeduren für manuelle Tätigkeiten. HOM/FHTeL SEN1 Software Engineering Februar /32 Wie führt man den Test aus? Inhalt des points Richtet rechtzeitig den Testumgebung ein (Hardware, Software, Dokumentation, Lizenzen und Arbeitsplatz). Bestimme wer die Tests ausführen wird. Schreibe die konkreten Testszenarien, sobald die funktionelle Spezifikationen vorhanden sind kann damit angefangen werden. Stelle sicher das es eine (temporäre) Verwaltung zur Sammlung und Festlegung der Testergebnisse vorhanden ist. HOM/FHTeL SEN1 Software Engineering Februar /32 3

4 Arten von V & V Inhalt des points Software Inspections Requirements specification High level design Formal specification Detailed design Program Prototype Program testing Abbildung : Static and dynamic verification and ation. HOM/FHTeL SEN1 Software Engineering Februar /32 Review plan debugging Validierung: Machen wird das richtige Produkt? Ist ein allgemeinerer Teil Machen wir was der Auftragsgeber möchte? Verifikation: Machen wird das Produkt richtig? Dynamisch testen heißt das Ausführen der Software mit Testdaten. V&V sind statisch: Inspektionen und Reviews während aller Phasen des Entwicklungsprozesses. Validierungstests: Zeigen das die Software macht was der Kunde möchte. In punkto Leistung als auch Zuverlässigkeit. Eine scharfe Grenze zwischen diese Bereiche ist nicht fest zu legen. HOM/FHTeL SEN1 Software Engineering Februar /32 Review plan debugging Inspektion und review sind beides statische Verifikationstechniken, deshalb muss das System nicht ausgeführt werden. Inspektion ist die präzisere Variante. Die sogenannte Fagan Inspektion folgt einem strikten Protokoll, mit unterschiedlichen Rollen für die Teilnehmer während der Inspektion. Reviewen ist eine weniger strickte Methode. Trotzdem sollte es nach einem Plan mit einem Ziel ausgeführt werden. HOM/FHTeL SEN1 Software Engineering Februar /32 4

5 Ziel eines Reviews Review plan debugging Genau wie andere Testtechniken, kann reviewen höchstens Fehler aufdecken. Die Arten der inhaltlichen Fehler, wonach gesucht werden soll sind: 1 Unvolständige oder fehlende Information. 2 Inkonsitenz oder Wiedersprüche 3 Unklarheiten oder Vagheit. Durch diese Mangel gibt es Wahlmöglichkeiten in die nächsten Schritte, wodurch die Unsicherheit steigt. HOM/FHTeL SEN1 Software Engineering Februar /32 Review plan debugging Test results Specification Test cases Locate error Design error repair Repair error Retest Program Abbildung : Debugging process. HOM/FHTeL SEN1 Software Engineering Februar /32 V-Modell Abbildung : Selbstverständig erwarten wir das Kodieren und Testen Hand in Hand gehen. HOM/FHTeL SEN1 Software Engineering Februar /32 5

6 V-Modell als Test und Entwicklungszyklus In modernen Entwicklungsmethoden wird das V-Model oft bevorzugt. Das V-Modell fordert eine Abgleichung zwischen Spezifikation auf der linken Seite und Verifikation/Validation auf der rechten Seite, auf allen Ebenen der Entwicklung. Bemerke das alle Schritte zu beide Beine des Vs Dokumente erzeugen. HOM/FHTeL SEN1 Software Engineering Februar /32 Inhalt Testplan Organisation: Beschreibung wie der Test organisiert ist, wo die Verantwortlichkeiten liegen und was die benutzten Mittel sind. Kommunikation und Prozeduren: u.a. Prozeduren für das Beheben von Fehler, Versions-Verwaltung. Teststrategie: Überblick der Teststragtegie, Kriterien für die Akzeptanz der Tests und auf welcher Ebene getestet wird. HOM/FHTeL SEN1 Software Engineering Februar /32 Inhalt Testplan 2 Test Items: Überblick der Funktionen die getestet werden und deren Priorität. Test Ergebnisse: Beschreibung der verwendete Produkte: Eingaben, Testberichte, Infrastrukur und Fortschrittsberichte. Testaktivitäten: Installation der Infrastruktur, schreiben von Testskripte, die Ausführung des Tests, das Fortschrittsmonitoring und das Erstellen der Testberichte. Planung: Die tatsächliche Planung der Softwaretestaktivitäten und die benutzte Mittel. HOM/FHTeL SEN1 Software Engineering Februar /32 6

7 Test Szenarien Die konkreten Szenarien gehören zu einem Use-case. Manchmal meint man mit Testszenario ein Testprogramm, d.h.: welche Tests und in welcher Reihenfolge werden sie ausgeführt. Mann benutzt auch die sogenannte Testskripte, wenn bei einer Testprozedur mit einem Softwaretool automatisch eine Reihe von Tests ausgeführt werden soll. HOM/FHTeL SEN1 Software Engineering Februar /32 Es gibt kommerzielle Produkte zum automatischen Testen, aber es gibt auch ant in Kombination mit Junit. Eins von den Frameworks ist Castor. Es gibt mehr:.. ( JUnit, Cactus, Abbot (waar is Costello?), JUnitPerf, Jamelon, DbUnit, Mockrunner, dbmonster, The Grinder, XMLUnit, jfcunit, JTestCase, StrutsTestCase, jmock, EasyMock, MockEJB, MockCreator, SQLUnit, Marathon, TestNG, Surrogate Test framework, JTR Java Test Runner, TESTARE, MockLib, TagUnit, TestGen4J, UISpec4J, Jacareto, Jemmy, DDTUnit, Mocquer,Mockito sind alle Framworks zum oder zur Untersstützung des Testen. Und die Liste ist noch nicht volständig. HOM/FHTeL SEN1 Software Engineering Februar /32 Wie findet man Testdaten? Man will selbstverständlich alles testen! Man kann nicht alle Werte testen! Es gibt Methoden mit dem man eine beschränkte doch komplette Menge von Testdaten finden kan. Grenzwerte und Extremwerten. Bestimmen von Equivalenzklassen. HOM/FHTeL SEN1 Software Engineering Februar /32 7

8 Ein- und Ausgabe Partitionen in in in in system Abbildung : Eingabe und Ausgabe kann mann verteilen in verschiedene HOM/FHTeL Klassen. SEN1 Software Engineering Februar /32 Beispiel equivalente Partitionierung a b c Mann sieht hier 4 Partitionen: 1 x < a 2 a x < b 3 b x < c 4 x c Partitionsequivalenz nimmt an, daß jeder Wert in der Partition auf gleicher Weise behandelt wird. Aber auch die Grenzen verdienen Aufmerksamkeit: Teste ob die Grenzwerte nach den Regeln behandelt werden gehörend zur richtigen Partition. Im Beispiel gehört a zu Partition 2. HOM/FHTeL SEN1 Software Engineering Februar /32 Clock12 interface public interface Clock12 { void tick (); void settime ( boolean pm, int hrs, int min, int sec ); int gethour (); int getminutes (); int getseconds (); void sethour ( int hour ); void setminutes ( int minutes ); void setseconds ( int seconds ); boolean ispm (); void setpm ( boolean pm ); String gettime (); } HOM/FHTeL SEN1 Software Engineering Februar /32 8

9 Equivalence classes Equivalenc classes : sethour : 1 hour < 0 in data 2 0 <= hour <12 data 3 12 <= hour <= 24 data 4 hour > 24 in data input : hour =16 -> hour =4 && PM = true -7 -> exception " hour not negative " 5 -> hour =5 && PM = false 57 -> exception " hour not greater than 24" etc. HOM/FHTeL SEN1 Software Engineering Februar /32 Mit der können wir systematisch blackbox Tests entwerfen. Diese Testdesignmethode enthält vier Schritte: 1 Identifiziere die Aspekte des Testobjekts. 2 Verteile oder partitioniere den Eingabebereich analog zu den identifizierte Aspekte. 3 Spezifiziere logische Testfälle. 4 Setze das Test(skript/scenario/plan) zusammen. HOM/FHTeL SEN1 Software Engineering Februar /32 CTM Schritt 1 1 Identifiziere die Aspekte des Testobjekts. Aspekte sind die Einflüsse auf das Systeem. Das umfasst die normale Eingabe aber auch den Zustand in dem sich das System befindet, reihenfolge der Bedienung usqw. HOM/FHTeL SEN1 Software Engineering Februar /32 9

10 CTM Schritt 2 2 Verteile oder partitioniere den Eingabebereich analog zu den identifizierte Aspekte. Teile die Eingaben in Partitionen oder Klassen auf, bezogen auf die unterschiedliche Einflüsse. Für jede Eingabe aus einer Partition verhält das System sich auf gleicher Weise. HOM/FHTeL SEN1 Software Engineering Februar /32 CTM Schritt 3 3 Spezifiziere logische Testfälle. Wähle ein Element aus einer Partition für jeden Aspekt. Kombiniere diese Elemente und berücksichtige dabei auch die nicht mögliche Kombinationen. HOM/FHTeL SEN1 Software Engineering Februar /32 CTM Schritt 4 4 Setze das Test(skript/scenario/plan) zusammen. Konstruiere reale Testfälle. Definiere de Aktionen innehalb des Tests. Definiere die Prüfpunkte. Bestimme die Ausgangssituationen der Tests. Stelle das vollständige Testskript auf. HOM/FHTeL SEN1 Software Engineering Februar /32 10

11 Beispiel Tempomat Die Aspekte HOM/FHTeL SEN1 Software Engineering Februar /32 Beispiel Tempomat Die kombinierte tests HOM/FHTeL SEN1 Software Engineering Februar /32 11