Automated Software Testing Sebastian Heil
Automated Software Testing - Sebastian Heil Motivation Agile Software Development Manuelle Tests aufwändig Alles „Auf einen Klick“ Manuelle Tests > Aufwändig, nicht für komplexe Systeme Ständiges Testen zur Qualitätssicherung Automated Software Testing - Sebastian Heil
Was ist automatisierbar? Testfallerstellung Testausführung Testauswertung und – dokumentation Oft zu hohe Ansprüche / Erwartungen Erstellung != Finden, Höhere Sprache/Abstraktion z.B. tabelle, skriptsprache, imperative / objektorientierte sprachen > internes Repräsentation Ausf: Sammeln aller Tests und Ausführen – Exceptions behandeln A/D: Ist-Soll-Vergleich, Übersichtliche Darstellung Automated Software Testing - Sebastian Heil
Ziele (der Automatisierung) Verbesserung der Qualität Tests als Spezifikation Fehlervermeidung Fehlerlokalisation Minderung des Risikos Tests als Sicherungsnetz Einfache Ausführung Hohe Coverage Ziele: Test im allgemeinen, speziell automatisierte Spez: erwartetes Verhalten d. SUT noch vor Implementierung> Ausführbare Spezifikation Verm: Tests vor Check-In Lok: Nutzertests: Unerwartetes Verhalten Unit Tests: Warum/Wo Netz: Legacy-Code, Regression-Tests, Experimentelles Ändern > „dafür ist dieser Parameter“ AW 82 (19) Automated Software Testing - Sebastian Heil
Automated Software Testing - Sebastian Heil Ansätze Code-driven Testing GUI Testing Direkt Quellcode Indirekt über GUI public class TestClassToTest { … @Test public void testMethodToTest() { ClassToTest sut = new ClassToTest() int val = sut.methodToTest(0); assertEquals(42, val); } … site = 'http://www.google.com‘ b = Watir::Browser.new browser b.goto(site) b.text_field(:name, "q").set(“gaedke") b.button(:name, "btnG").click if b.text.include?(“TU Chemnitz") puts "Test Passed. Found the test string” else puts "Test Failed! Couldn’t find test string” end Interaktion des Tests mit Software CDT: Test als Quellcode, direkt, tendenziell höhere Coverage, genauer, aufwändiger Automated Software Testing - Sebastian Heil
Automated Software Testing - Sebastian Heil Ansätze Code-driven Testing GUI Testing Direkt Quellcode Indirekt über GUI public class TestClassToTest { … @Test public void testMethodToTest() { ClassToTest sut = new ClassToTest() int val = sut.methodToTest(0); assertEquals(42, val); } … site = 'http://www.google.com‘ b = Watir::Browser.new browser b.goto(site) b.text_field(:name, "q").set(“gaedke") b.button(:name, "btnG").click if b.text.include?(“TU Chemnitz") puts "Test Passed. Found the test string” else puts "Test Failed! Couldn’t find test string” end Interaktion des Tests mit Software CDT: Test als Quellcode, direkt, tendenziell höhere Coverage, genauer, aufwändiger GT: Test als Skript welches GUI-Interaktion nutzt, indirekt, wartungsintensiver, fehleranfälliger, einfacher, Regressionstests für fertige Software, „Automatisierung von Nutzertests“ Watir, Ruby-Basiert Automated Software Testing - Sebastian Heil
Prinzipien der Automatisierung Front Door First Aussagekräftige Tests Keine Veränderungen am SUT Testabdeckung maximieren, Testüberdeckung minimieren Separate, spezifische Tests FDF: tests über public interface, keine Backdoor-Manipulation der SUT – hoher Wartungsaufwand für Tests AT: keine extrem langen Tests, Lesbarkeit, Wartungsaufwand gering wie möglich SUT: Gefahr: Tests verlieren Aussagekraft, manchmal nötig für indirekte Eingaben: Testspezifische Subklassen SEP: Fehlerlokalisierung AW 102ff Automated Software Testing - Sebastian Heil
Automated Software Testing - Sebastian Heil Unit Testing Unit: kleines Stück isolierter Quellcode, meist Klasse Unit Test: Quellcode, ruft zu testende Unit auf Überprüfung von Annahmen Vergleich von Ist- und Sollergebnis Getestet wird logischer Code Logischer Code: (IF, LOOP, SWITCH, Berechnungen) Nicht default Getter/Setter Keine DB-Interaktion/ Netzwerk Automated Software Testing - Sebastian Heil
Unit vs. System/Integration Testing Unit Testing System/Integration Testing Test einer einzelnen Unit in Isolation Testet Programmlogik Automatisiert Schnell Von Anfang an Test von mehreren voneinander abhängigen Modulen als Gruppe Testet Zusammenspiel Schwerer automatisierbar Aufwändiger erst nach vorangeschrittener Entwicklung Automated Software Testing - Sebastian Heil
Automatisierungsstrategien Recorded Tests Data-Driven Tests Scripted Tests AW 341 (278) Rec: Benutzerinteraktion aufnehmen und abspielen, schnell zu erstellen Data: gleiche Aktionen, unterschiedliche Daten, Test-Datei + Interpreter, gut für Nichtinformatiker Script: explizit als Code, f. fast alle Unit, Programier- u. Testerfahrung Automated Software Testing - Sebastian Heil
Test Automation Frameworks Robot User xUnit GUI Testing Recorded Tests Test Recorder Test Runner Code-driven Testing Scripted Tests Test Runner Library Assertion Methods 4-Phasen Test Beispiel: JUnit Separation Ausführungslogik/Testlogik Robo: Runner spielt aufgenommene Interaktion ab xUnit: JUnit, CppUnit, NUnit, PyUnit, … Runner sucht alle Testcases, ruft Testmethoden auf; Assertion Methods: Erwartetes Erbenis - assertTrue() Gleichheit - Equal() Erw. Excep. - Raises() Fuzzy – Equal() mit Toleranz Testmethoden: nutzen Assertion Methoden, 1 Methode 1 Test 4Phase: für jede Methode Setup Ausführung Verifikation Aufräumen AW 410 (347) Beispiel: Selenium Automated Software Testing - Sebastian Heil
Automated Software Testing - Sebastian Heil xUnit Automated Software Testing - Sebastian Heil
Automated Software Testing - Sebastian Heil xUnit Automated Software Testing - Sebastian Heil
Automated Software Testing - Sebastian Heil Beispiel: Selenium Automated Software Testing - Sebastian Heil
Automated Software Testing - Sebastian Heil Beispiel: JUnit Automated Software Testing - Sebastian Heil
Automated Software Testing - Sebastian Heil Quellen The Art of Unit Testing: With Examples in .NET TU Darmstadt: JUnit 4 Tutorial Software Test Automation: Myths and Facts xUnit Test Patterns: Refactoring Test Code Selenium Automated Software Testing Automated Software Testing - Sebastian Heil