Testautomatisierung im Projektalltag

Transkript

1 Testautomatisierung im Projektalltag 1

2 Agenda 1. Warum testen? 2. Grundlagen des Softwaretestens 3. Tools zur Unterstützung von Tests 4. Automatisiertes Testen - Erfahrungsbericht 2

3 : Erster Bug (Wikipedia) Eine Motte führt zum Ausfall eines Relais im Rechner Mark II. Frau Grace Murray Hopper notierte im Log-Buch:»First actual case of bug being found.offen«-sichtlicher Fehler! Lokalisierung und Beseitigung war einfach! [Spillner, HS Bremen, 2008] Logbuch-Seite des Mark II Aiken Relay Calculator mit dem ersten dokumentierten Bug (Wikipedia) 3

4 Fehler bei der Wiederverwendung von Software US Air Force, Programm zur Raketensteuerung Aus Speicherplatzmangel wurden beim Flug einer Rakete über den Äquator die Flugkoordinaten nicht neu berechnet, sondern nur das Vorzeichen geändert. Dadurch drehte sich die Rakete beim Überflug des Äquator zwar um die eigene Achse, was allerdings niemanden störte. Programm wurde unverändert in den Autopiloten des Jäger F-18 übernommen. Beim Überflug des Äquator drehte sich die Maschine auf den Kopf! [Spillner, HS Bremen, 2008] 4

5 Übersicht Fehlerhäufigkeiten in den USA Branche Anzahl Projekte Fellerrate [Fehler/KLOC] Mittlere Fehlerrate [Fehler/KLOC] Automatisierungstechnik 55 2,0-8,0 5,0 Finanzwirtschaft 30 3,0-10,0 6,0 Eingebettete Systeme 45 0,5-5,0 1,0 IT-Systeme (Datenbanken) 35 2,0-14,0 8,0 Entwicklungsumgebungen 75 5,0-12,0 8,0 Militär - gesamt 125 0,2-3,0 < 1,0 Militär - Luftfahrt 40 0,2-1,3 0,5 Militär - Boden 52 0,5-4,0 0,8 Militär - Raketentechnik 15 0,3-1,5 0,5 Militär - Raumfahrt 18 0,2-0,8 0,4 Wissenschaft 35 0,9-5,0 2,0 Telekommunikation (Switching) 50 3,0-12,0 6,0 Test 35 3,0-15,0 7,0 Trainer/Simulatoren 25 2,0-11,0 6,0 Webapplikationen 65 4,0-18,0 11,0 Sonstige 19 2,0-15,0 7,0 Quelle: Harry M. Sneed, Stefan Jungmayr: Mehr Testwirtschatlichkeit durch Value-Driven-Testing, Informatik Spektrum 34,

6 Und welche Anforderungen stellen unsere Kunden? Projekt mit 3 Releases Jedes Release ist in Produktion gegangen An jedem Release haben ca Entwickler ca. 1,5 Jahre gearbeitet Pro Release 3-5 Lieferungen an Kunden Späte Releases haben zum Teil funktionale Auswirkungen auf frühe Releases Kriterien Abnahmetest: Maximal 5 hohe Fehler durften gefunden werden vom Kunden! Maximal 15 mittlere Fehler durften gefunden werden vom Kunden! Ansonsten: Projektverzögerungen zu unseren Lasten Rahmenbedingungen eines meiner Projekte Inbetriebnahme nur ohne hohe Fehler und wenigen mittleren Fehlern Testen und Qualitätssicherung hilft diese Vorgaben zu erreichen. 6

7 Agenda 1. Warum testen? 2. Grundlagen des Softwaretestens 3. Tools zur Unterstützung von Tests 4. Automatisiertes Testen - Erfahrungsbericht 7

8 Zum Begriff des Testens Testen verfolgt mehrere Ziele: Identifizierung von Defekten Bestimmung der Qualität des Produkts Vertrauen in das Produkt erhöhen Analyse, um Fehlerwirkungen vorzubeugen Steigerung der Softwarequalität natürlich nur, wenn gefundene Fehler behoben werden ;) Aber: Test ist eine stichprobenartige Prüfung Fehlerfreiheit ist durch Testen nicht erreichbar Kein umfangreiches Softwaresystem ist fehlerfrei Test ist nur ein Bestandteil umfangreicher Qualitätsmaßnahmen 8

9 Konstruktives und analytisches Qualitätsmaßnahmen Konstruktive Maßnahmen Konstruktionstechniken und Richtlinien strukturiertes Vorgehen werkzeuggestützte Entwicklung höhere Programmiersprachen Vorgaben entstehen aus projektübergreifende Erfahrungen Planungsaktivitäten in frühen Phasen Einschränkung der Variabilität in der Systementwicklung, um gewisse Fehler nicht auftreten zu lassen und damit ein Maß an Qualität per se zu erreichen. Analytische QS Maßnahmen diagnostische Maßnahmen bringen keine Qualität per se Messung der Qualität der End- bzw. Zwischenprodukte Datenerhebung, um Ist- und Soll-Zustand zu vergleichen und so den Grad der erreichten Qualität im Nachhinein festzustellen. 9

10 Verfahren der konstruktiven Qualitätssicherung Konstruktive Qualitätssicherung Technische Maßnahmen Organisatorische Maßnahme Methoden Sprachen Werkzeuge Richtlinien Standards Checklisten Beispiel Methoden: Ziel: strukturierte Vorgehensweise Technik: Vorgabe von Zwischenprodukten Modelle Diagrammarten Beispiel Richtlinien: Ziel: Eigenschaften a priori festlegen Technik: Vorgabe von Richtlinien Checklisten, Schablonen Überprüfung Richtlinien 10

11 Verfahren der analytischen Qualitätssicherung Inspektion und Reviews Statische Prüfung (Dokument prüfen) Statische Codeanalyse Formale Verifikation Analytische Qualitätssicherung Symbolische Ausführung Tests Black-Box Äquivalenzklassen Grenzwertanalyse Zustandsbezogener Test Anweisungstest Dynamische Prüfung Dynamische Analyse White-Box Memory Leak Analyse Performancemessung Zweigtest 11

12 Testfallerstellung mit Äquivalenzklassen und Grenzwerten Äquivalenzklasse Sammlung von Ein/Ausgabewerten, für die ein System das gleiche Fehlerverhalten aufweist. Für die Testabdeckung muss nur ein Testfall aus der Äquivalenzklasse ausgeführt werden. Bei diesem Prinzip der Ableitung von Testfällen wird untersucht, welche Klassen von möglichen Eingabewerten zu einer ähnlichen Art der Verarbeitung führen. Mit Hilfe von Äquivalenzklassen kann man eine minimale Anzahl an Testfällen ermitteln, um die Anforderungen abzudecken. Grenzwertanalyse Die Grenzwertanalyse ist eine spezielle Form der Äquivalenzklassenanalyse. Die Werte, die sich auf und in der Umgebung der Grenzen der Äquivalenzklassen befinden, nennt man Grenzwerte. Methode wird oft zur Entwicklung von Stress oder Negativtests benutzt. 12

13 Beispiel für Äquivalenzklassen In der Spezifikation eines Online-Banking-Systems wird gefordert, dass nur Beträge von 0,01 bis 500 eingegeben werden dürfen. Für Tests sollte es daher ausreichen, drei Äquivalenzklassen zu bilden (eine gültige und zwei ungültige Äquivalenzklassen): Werte von 0,01 bis und mit 500,00 (gültig) Werte kleiner gleich null (ungültig) Werte größer als 500,00 (ungültig) Jede Überweisung im Online-Banking-System muss durch die Eingabe einer TAN autorisiert werden. Analog zur ersten Äquivalenzklasse können hier für die Eingabe der TAN vier Äquivalenzklassen gebildet werden: Eingabe einer korrekten TAN Eingabe einer falschen TAN Eingabe zu kurzer TAN Eingabe zu langer TAN Auf Basis der beiden Äquivalenzklassen werden die nachfolgenden Testfälle definiert: Gültiger Wert (z. B. 123,45 ) und korrekte TAN (ausgeführt, weil alles korrekt ist.) Gültiger Wert (z. B. 123,45 ) und falsche TAN (fehlgeschlagen, weil falsche TAN.) Ungültiger Wert (z. B. 600,00 ) und korrekte TAN (fehlgeschlagen, weil ungültiger Wert.) Gültiger Wert (z. B. 123,45 ) und zu kurze TAN (fehlgeschlagen, weil TAN zu kurz ist.) Gültiger Werts (z. B. 123,45 ) und zu lange TAN (fehlgeschlagen, weil TAN zu lang ist.) (/ 13

14 Beispiel für Grenzwerte Für die Prüfung der Grenzwerte werden nicht beliebige Werte getestet, sondern nur Randwerte oder Grenzwerte. Im Beispiel wären dies die Werte 0,00 (ungültige Eingabe) 0,01 (gültige Eingabe) 500,00 (gültige Eingabe) 500,01 (ungültige Eingabe) (/ 14

15 Softwarequalität umfasst mehr als nur die Beseitigung von Fehlern: Qualitätsmerkmale für Software Qualitätsziele Messbare Vorgaben für die verschiedenen Qualitätsmerkmale Funktionalität - Richtigkeit - Angemessenheit - Interoperabilität - Ordnungsmäßigkeit - Sicherheit Übertragbarkeit - Anpassbarkeit - Installierbarkeit - Konformität - Austauschbarkeit Zuverlässigkeit - Wiederherstellbarkeit - Fehlertoleranz - Reife ISO 9126 Benutzbarkeit - Verständlichkeit - Erlernbarkeit - Bedienbarkeit Änderbarkeit - Analysierbarkeit - Modifizierbarkeit - Stabilität - Prüfbarkeit Effizienz - Zeitverhalten - Verbrauchsverhalten Die Anforderungen an die Qualität hängen ab vom Anwendungsbereich der Software 15

16 Softwarequalität umfasst mehr als nur die Beseitigung von Fehlern Qualitätsmerkmale nach ISO 9126 (1/2) Funktionalität Umfasst Charakteristika, welche die geforderten Funktionalitäten des Systems beschreiben Oft durch Ein-/Ausgabeverhalten spezifiziert Mit Tests wird spezifiziertes Ein-/Ausgabeverhalten geprüft Teilmerkmale: Angemessenheit Richtigkeit Interoperabilität Ordnungsmäßigkeit Richtigkeit Zuverlässigkeit Fähigkeit eines Systems, sein Leistungsniveau unter festgelegten Bedingungen über einen definierten Zeitraum zu halten. Teilmerkmale: Reife Fehlertoleranz Wiederherstellbarkeit Benutzbarkeit Teilmerkmale: Verständlichkeit Erlernbarkeit Bedienbarkeit Wichtig für die Akzeptanz der Systeme Benutzbarkeit ist abhängig von Benutzergruppe Prüfung im Rahmen von nicht-funktionalen Tests 16

17 Softwarequalität umfasst mehr als nur die Beseitigung von Fehlern Qualitätsmerkmale nach ISO 9126 (2/2) Effizienz Teilmerkmale: Zeitverhalten Verbrauchverhalten Benötigte Zeit und Verbrauch an Betriebsmitteln für die Erfüllung einer Aufgabe Messbare Ergebnisse lassen sich mit Performancetest (nicht-funktionale Tests) ermitteln Änderbarkeit Wichtiges Kriterium, da Softwaresysteme oft über längeren Zeitraum eingesetzt werden. Änderbarkeit umfasst folgende Teilmerkmale: Analysierbarkeit Modifizierbarkeit Stabilität Prüfbarkeit Übertragbarkeit Übertragbarkeit umfasst folgende Teilmerkmale: Anpassbarkeit Installierbarkeit Konformität Austauschbarkeit Aspekte lassen sich häufig nur durch statische Analysen prüfen 17

18 Fundamentaler Testprozess (in Anlehnung an ISTQB) Allgemeine Softwareentwicklungsmodelle ordnen Test in Entwicklungsablauf ein und betrachten oft nur die Testdurchführung Fundamentaler Testprozess: Generischer Ablaufplan Anpassung an Gegebenheiten und Erfordernisse im Projekt notwendig. (Rollen und Dokumente sind nicht beschrieben.) Verfeinerter Ablaufplan für das Testen. Aufgaben im Prozess dürfen sich überschneiden und auch gleichzeitig durchgeführt werden. Beginn Planung und Analyse und Design Realisierung und Durchführung Auswertung und Bericht Abschluss Steuerung Ende Spillner, A., Linz, T.: Basiswissen Softwaretest - Aus- und Weiterbildung zum Certified Tester dpunkt, 4. Auflage 18

19 Testen im Softwarelebenszyklus Beispiel V-Modell Grundidee V-Modell Entwicklung und Test sind zueinander korrespondierende, gleichberechtigte Tätigkeiten. 19 Grundidee und daraus entstehende Prinzipien lassen sich auf andere Vorgehensmodelle übertragen.

20 Teststufen - Komponententest Komponententest soll die korrekte Funktionalität der einzelnen Systemkomponenten überprüfen. Schwerpunkt ist die isolierte Prüfung der einzelnen Komponenten. Komponententest wird meist durch den Entwickler durchgeführt vor der Integration Test der Komponenten 20

21 Teststufen - Integrationstest Integrationstest soll das fehlerfreie Zusammenwirken der Systemkomponenten überprüfen. Die einzeln getesteten Komponenten werden schrittweise integriert und das Zusammenwirken getestet. Schwerpunkt ist die Prüfung des Zusammenwirken der Komponenten. Dazu müssen die Schnittstellen in möglichst vielen Kombinationen ausgeführt werden. Test der Schnittstellen 21

22 Teststufen - Systemtest Systemtest ist der abschließende Test in einer realitätsnahen Umgebung (ohne den Auftraggeber), u.a. Funktionstest gegen die Spezifikation Massentest, Performancetest, Lasttest Usability Test Schwerpunkt der Prüfung ist das Verhalten des Gesamtsystems Test des Gesamtsystems 22

23 Teststufen - Abnahmetest Abnahmetest wird in der Einsatzumgebung des Auftraggebers mit realen Daten unter Mitwirkung des Auftraggebers durchgeführt Generierung und Installation des Systems Testfälle für reale Geschäftsvorfälle Zufällige Testfälle Prüfung Dokumentation Abnahmetest ist die Grundlage für die Abnahme durch den Auftraggeber. 23

24 Überblick Teststufen Komponententest Integrationstest Systemtest Abnahmetest Testbasis Komponentenspez. Systemdesign Schnittstellen- Dokumente auf Systemebene, Dokumente, die System aus Anforderungen übergreifende Spezifikation, Anwendersicht Softwaredesign Workflows, UCs Anforderungen... beschreiben Tester Entwickler Tester Tester Kunde Teststrategie White-Box Black-Box Black-Box Black-Box Testziele z.b. Funktionalität z.b. Schnittstellen- z.b. Erfüllt System die z.b. Vorgaben Vertrag Robustheit fehler Anforderungen Akzeptanz Effizienz Wechsel- (funktional vs. Nutzer u. wirkungen nicht-funktional) Systembetreiber 24 Komponententest und Integrationstest erfolgen nicht streng sequentiell Systemtest und Abnahmetest fallen typischerweise in die letzten Projektwochen

25 Frühes Testen ist wichtig für Projekterfolg Frühes Testen verringert die Projektrisiken Frühes Testen macht Entwicklung der Produktqualität transparent Implementierung Komponententest Stufenweise Integrationstest Systemtest Abnahmetest t Bereit zum Systemtest Bereit zur Abnahme 25

26 Grundsätze des Softwaretestens (nach ISTQB) 1. Testen zeigt die Anwesenheit von Fehlern. 2. Vollständiges Testen ist nicht möglich. 3. Mit dem Testen frühzeitig beginnen. 4. Häufung von Fehlern. 5. Zunehmende Testresistenz (Pesticide paradox). 6. Testen ist abhängig vom Umfeld. 7. Trugschluss: Keine Fehler bedeutet ein brauchbares System. Spillner, A., Linz, T.: Basiswissen Softwaretest - Aus- und Weiterbildung zum Certified Tester dpunkt, 4. Auflage 26

27 Agenda 1. Warum testen? 2. Grundlagen des Softwaretestens 3. Tools zur Unterstützung von Tests 4. Automatisiertes Testen - Erfahrungsbericht 27

28 Werkzeugtypen zur Unterstützung und Automatisierung von Tests (1/2) Werkzeuge für Management, Steuerung von Tests Erfassung, Verwaltung, Überwachung von Testfällen Verwaltung Problem-, Fehlermeldungen Verwaltung von Anforderungen (Requirements) Konfigurationsmanagement Werkzeuge zur Testspezifikation Verwaltung Vor-/Nachbedingungen von Testfällen Testdatengeneratoren (datenbankbasiert, spezifikationsbasiert, ) Werkzeuge für statische Tests Werkzeuge zur Reviewunterstützung Statische Analysen (z.b. zykomatische Anzahl) Model Checker 28

29 Werkzeugtypen zur Unterstützung und Automatisierung von Tests (2/2) Werkzeuge für dynamischen Tests Testtreiber, Testrahmen Simulatoren, Testroboter (z.b. Capture-and-Replay-Tools) Komparatoren Überdeckungsanalyse, Dynamische Analyse Werkzeuge für nicht-funktionale Tests Last-/Performancetests Monitore 29

30 Beispiel Testmanagement: HP Quality Center 30 HP ist führendes Tool im Kontext Testmanagement (Forrester Wave Studie) Browserbasiert Möglichkeit zur Automatisierung von Tests mit HP Quick Test

31 Werkzeuge für statische Tests Beispiele Checkstyle Prüfung von Coding Conventions in Java Projektkonfiguration notwendig Integration in Eclipse möglich FindBugs Durchsucht Java-Programmen nach Fehlermuster Fehlermuster deuten oft auf tatsächliche Fehler hin. Filterung bei größeren Projekten notwendig: Anzahl der angezeigten Warnungen sehr groß Sonograph for Java: Hinterlegung von Architekturmodellen für Projekt Identifikation von Architektur-oder Abhängigkeitsverletzungen Identifikation zyklischer Abhängigkeiten 31

32 Werkzeuge für die Testautomatisierung Beispiel JUnit Framework zum Testen von Java-Programmen Insbesondere zur Erstellung von Testtreibern für automatisierte Unit-Tests (Klassen oder Methode) Architekturüberblick aus JUnit A Cook's Tour 32

33 Einfacher JUnit-Testfall Test erben von Oberklasse TestCase public class StringTest extends TestCase { protected void setup( ) protected void teardown( ) Initialisierung des Testobjekts Zurücksetzen des Testobjekts nach Ausführung des Tests public void testsimpleadd() { String s1 = new String( abcd ); String s2 = new String( abcd ); Testobjekt wird geprüft mit assert-methoden von JUnit 33 } asserttrue( Strings not equal, s1.equals(s2)); } In Projekten wird Testframework aufgesetzt, das die Junit-TestCase-Klasse spezialisiert. Initialisierung der Datenbank, Komponenten, wird einheitlich für alle Tests gekapselt. Nur spezifische Initialisierungen in konkreten Tests enthalten.

34 JUnit: Integration in Eclipse 34

35 Vorteile, Nachteile JUnit Vorteile Einfache Erstellung von Testtreibern Tests können automatisiert werden Integration in IDEs Regelmäßig Durchführung der Tests möglich (nightly builds) Projektspezifische Anpassungen möglich Refactorings wirken sich auch auf Testtreiber aus Nachteile Keine Trennung von Testcode und Testdaten in Testtreibern Abhängige Komponenten müssen mit eingebunden werden in Test GUI-Tests nicht möglich 35

36 Werkzeuge für die Testautomatisierung Beispiel Selenium Testframework für Webanwendungen Aufzeichnung manuell durchgeführter Bedienschritte Bedienschritte werden als Testskript gespeichert. Beliebige Wiederholung der aufgezeichneten Skripte möglich Testskripte können als HTML-Tabellen abgelegt werden Selenium basiert rein auf HTML und JavaScript Selenium-IDE als Firefox-Addon verfügbar Capture-and-Replay-Tool 36

37 Vorteile, Nachteile Selenium Vorteile Einfache Erstellung von GUI- Testtreibern Gut geeignet für Regressionstests Vernünftiges Reporting durchgeführter Testfälle Generierung von Testskripten möglich Nachteile Keine Trennung von Testcode und Testdaten in Testtreibern Empfindlich ggü. Änderungen an GUI Kein Refactoring der Testfälle möglich Nachbearbeitung der Skripte notwendig Für langlebigen Einsatz ist angemessene Architektur notwendig (Modularisierung Testfälle, ) 37

38 Chancen und Risiken durch automatisiertes Testen Chancen Zeitdruck und Risiko vermindern sich in späten Projektphasen Kurzfristige Absicherung von Änderungen während des Produktivbetriebs Absicherung von Seiteneffekten Kostenersparnis Weniger stupider Test Risiken Zu wenig (Test-)Erfahrung im Team Ungeeignetes Werkzeug Sammlung von Testwerkzeugen passt nicht zusammen Testfälle sind nicht wartbar oder automatisierbar Pflegeaufwände für Testfälle ist hoch 38

39 Automating chaos gives faster chaos* Nicht als erstes über Werkzeuge zur Automatisierung der Testdurchführung nachdenken Nur wenn ein systematischer Testprozess definiert, eingeführt und gelebt wird, kann die Produktivität durch Tests zur Automatisierung erhöht werden. Reihenfolge zur Einführung von Werkzeugen 1. Fehlermanagement 2. Konfigurationsmanagement 3. Testplanung 4. Testdurchführung 5. Testspezifikation *Fewster, M., Graham, D.: Software Automation, Effective use of test execution tools 39

40 Abhängig von der Anzahl Wiederholungen der Testdurchführung lohnt sich eine Testautomatisierung Kosten Manuelle Tests Kosten Wartung TF Automatisierte Tests Kosten Implemen tierung TF Kosten Testspezifikation Anzahl Wiederholungen Testfälle Ab ca. 5 Wiederholungen lohnt sich eine Testautomatisierung Große Projekte laufen oft über mehrere Jahre mit mehreren Releases Früh über Testautomatisierung nachdenken 40

41 Agenda 1. Warum testen? 2. Grundlagen des Softwaretestens 3. Tools zur Unterstützung von Tests 4. Automatisiertes Testen - Erfahrungsbericht 41

42 Kernelemente des Testkonzepts in unserem Projekt Unittests auf Komponentenebene (Entwicklertests) Continuous Integration mit Nightly Builds und Reports Manuelle Integrationstests Testkonzept Erstellung von Testfallspezifikationen Zentrale Bereitstellung von Testdaten Automatisierte Integrationstests 42

43 Entwicklertests und Continuous Integration Entwicklertests Manuelle Entwicklertests (für Dialoge) JUnit-Tests Entwickler durfte erst einchecken, wenn die automatisierten Tests der Komponente lokal erfolgreich waren Vorgaben über Art und Umfang der Tests Refactoring der JUnit-Tests hat gut funktioniert Continuous Integration Einsatz von Hudson Sobald Entwickler eingecheckt hat, wurde Anwendung neu gebaut und getestet (auf Komponentenebene mit Junit) Reports wurden bereitgestellt und per Mail versandt an Verantwortliche Nightly-Build Nighly-Build wurde täglich ausgeführt Bauen und Deployen der Anwendung für manuelle Integrationstests am nächsten Tag Ausführung der automatisierten Entwicklertests und Integrationstests Historisierung der Reports über mehrere Wochen (Zur Identifikation eines Fehler, musste nachgestellt werden können, wann Fehler aufgetreten ist) 43

44 Testfallspezifikation: Testziele werden zu Testfällen gruppiert Ableiten von Testzielen/Testkriterien aus Spezifikation Gruppierung zu logischen Testfällen [Capgemini] 44

45 Verwendung der Testfallspezifikationen Konkrete Regeln/Vorgehensweisen zur Ableitung von Testzielen aus Spezifikationen Regeln sollen Testabdeckung sicherstellen Regeln stellen sicher, dass alle Themen ähnlich detailliert geprüft werden Beispiele: Vorbelegungen sind zu prüfen Vor-/Nachbedingungen sind zu prüfen Einfache Validierung (Zeichenanzahl, Umlaute, Datum, usw.) sind nicht explizit zu prüfen. Regeln haben sich sehr stark an gegebenen Strukturen der Spezifikation ausgerichtet Vergabe von Teststrategien auf Ebene der Testfallspezifikation Einfaches Dialogverhalten wurde manuell getestet, nicht wiederholt getestet Pflichtfelder Korrekte Generierung von Dokumenten Verhalten aus Anwendungsfällen wurde automatisiert getestet Vor-/Nachbedingungen Externe Schnittstellen. Entscheidung über Testwerkzeug (Proven! Oder JUnit) Testfallspezifikationen wurden einem Review unterzogen Frühe Qualitätssicherung darüber, was getestet werden soll Prüfung auf Vollständigkeit Testfallspezifikationen wurden dem Kunden übergeben Abgleich mit Testideen des Kunden war insbesondere auf der Ebene der Testziele möglich 45

46 Vorgehen automatisierte Dialogtests Testfallbeschreibung Testausführung Testergebnis Beschreibung basiert auf einer einfachen Sprache in HTML- Tabellen Organisation im Dateisystem Versionierung ist möglich Automatische Ausführung der Testfälle, dabei Anbinden verschiedener Testschnittstellen Verknüpfte Testfälle erlauben Wiederverwendung von Testsequenzen Report von Testergebnissen in der Testfallspezifikation Einfache und leicht verständliche Ergebnispräsentation im Ampel-Stil [Capgemini] 46

47 Proven! setzt keyword-basiertes Testen um Tool bei Capgemini entwickelt Schlüsselworte mit optionalen Parametern Für Schlüsselwörter ist im Testtreiber eine Implementierung hinterlegt, die vordefinierte Aktionen auslöst Testautomatisierer erstellt Tabellen, in denen die Schlüsselworte mit ihren Testdaten zu Testszenarien zusammengestellt sind Während automatisierter Testausführung liest Testframework Testfalltabellen ein und führt die dazugehörigen Operationen aus und protokolliert die Durchführung Vorteil: Testautomatisierer kann ohne Kenntnis der Testautomatisierungsdetails durch Kombination der Schlüsselwörter Testfälle erstellen Nachteil: Sprache ist nicht so leistungsfähig wie z.b. JUnit [Capgemini] 47

48 Regeln zur Implementierung von automatisierten Tests Problem im Projekt Proven!-Testfälle nicht robust gegen Änderungen der Anwendung Proven!-Testfälle nicht robust gegen Änderungen der Testdaten Hohe Kosten bei Anpassung der Testfälle Identifikation von Antipattern bei der Implementierung von Testfällen SQL-Antipattern Teilweise wurden in den Testfällen SQL-Anweisungen abgesetzt Bei einer Anpassung des Datenmodells funktionierten die Testfälle nicht mehr Falsche Annahmen bezüglich der Konstanz der Testdaten Teilweise wurden Ergebnismengen als statisch angenommen Bei einer Änderung der Testdaten können sich Ergebnismengen ändern, nur Konsistenz der Kerndaten konnte sichergestellt werden Programmierung in den Testfällen Programmierung mit den Hausmitteln der Testframeworks ist fehleranfällig und nicht wartbar Einsatz von fachlichen Konnektoren, die aus dem Skript heraus aufgerufen werden schafft Abhilfe 48

49 Erfahrung mit automatisierten Dialogtests Automatisierung von Dialogtests ist sinnvoll in einem Projekt über mehrere Jahre Vollautomatisierung ist nicht wirtschaftlich Aufwand zur Erstellung der automatisierten Tests ist sehr hoch Wartungsaufwand von automatisierten Testfällen kann hoch werden Abhängig von den Projektbedingungen muss geprüft werden, was wie oft getestet werden muss Modularisierung bei Dialogtests Modularisierung bei Dialogtests verschlechtert die Lesbarkeit Frameworks für die Unterstützung von Dialogtests erlauben einfache Implementierung von Testfällen Vorgaben für Implementierung sind unbedingt notwendig, da sonst Wartung nicht möglich ist Automatisierte Dialogtestfälle werden oft naiv implementiert Testfälle sind anfällig gegenüber Änderungen der Anwendung und den Testdaten Frameworks für die Unterstützung von Dialogtests unterstützen Refactoring nur unzureichend/gar nicht Kontinuierliche Überwachung und Wartung der Testfälle ist notwendig Anwendung darf den Testfällen nicht davon laufen 49

50 Vorgehen automatisierte Dialogtests Erstbefüllung Test-DB-Skripte Test-DB für Tests DB Skripte zur Ausführung von Anwendungsfällen Test- DB Befüllung über Schnittstellen zu Inputsytemen Initiale Daten von Kunden geliefert Skripte nutzen Testframework Skripte führen Anwendung aus Nach Ausführung der Skripte stehen Testdaten zur Verfügung Testdaten für Integrations und Entwicklertests Ziel: Zentrale Bereitstellung von konsistenten, korrekten Testdaten Gründe für Vorgehen Erstellung von konsistenten Testdaten erfordert detailliertes fachliches Wissen Einzelne Einzelne Testfallentwickler oftmals überfordert mit Erstellung Testdaten Anwendung und damit die Testdaten ändern sich Erstellung Testdaten muss wiederholbar sein Aufwand bei einzelnen Personen für die Erstellung von Testdaten reduziert sich. 50 Nicht alle Testdaten für alle Testfälle hinterlegen! Zentraler Testdatenpool Testdaten werden in Testfällen (über Anwendung) angepasst

51 Fazit: Testautomatisierung Testautomatisierung erlaubt gleichbleibend hohe Qualität über mehrere Releases Testautomatisierung sollte mit Beginn der Entwicklung hochgezogen werden Automatisiertes Testen erfordert strukturiertes Vorgehen Genau überlegen, was automatisiert getestet wird Testfälle müssen sorgfältig automatisiert werden Migrationsdaten sollten für den Test so früh wie möglich zur Verfügung stehen Testfälle müssen aktuell sein ansonsten bekommen Entwickler kein Feedback Tester und Entwickler sollten sich persönlich kennen Häufige Spezifikationsänderungen führen zu hohen Aufwänden bei automatisierten Tests Qualität zwischen einzelnen Testphasen messen/prüfen Gute Traceability zwischen Analysewelt und Test ist sehr hilfreich Neben funktionalen Tests auch früh genug mit nichtfunktionalen Tests beginnen 51

52 Literatur A. Spillner, T Linz: Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester - Foundation Level nach ISTQB-Standard) Guter Überblick über die Grundlagen des Softwaretestens. Vorstellung statischer und dynamischer Testverfahren, Testwerkzeuge Testen im Softwarelebenszyklus Aufgaben des Testmanagements Konform zum zum Certified Tester - Foundation Level F. Westphal: Testgetriebene Entwicklung mit JUnit & FIT: Wie Software änderbar bleibt Einführung in JUnit und FIT! Vorgehensweise beim Test Driven Development Webseiten - Open Source Tools for Software Testing Professionals - Üb erblick über Open-Source-Java-Testtools - Testwerkzeug (Ebene Testmanagement) - Review-Formulare, Test-Tool-Requirements, - Überblick über JUnit 52

53 Vielen Dank für Ihre Aufmerksamkeit msg systems ag Robert-Bürkle-Straße Ismaning/München Telefon: Fax: info@msg-systems.com 53