Drei Methoden, ein Ziel: Testautomatisierung mit BDD, MBT und KDT im Vergleich

Transkript

1 Drei Methoden, ein Ziel: Testautomatisierung mit BDD, MBT und KDT im Vergleich C. Brandes, B. Eberhardinger, D. Faragó, M. Friske, B. Güldali, A. Pietschker 15. Oktober 2015 Zukunftsmeile Fürstenallee, Paderborn

2 Kurze Vorstellung des TAV- Arbeitskreises TOOP/MBT Besteht seit 1997 Die letzten Publikationen Starthilfe für modellbasiertes Testen: Entscheidungsunter- stützung für Projekt- und Testmanager. OS, 2010 Modellbasiertes Testen: Hype oder Realität? OS, 2011 Wirtschaftlichkeitsberechnung für MBT: Wann sich modellbasiertes Testen lohnt. OS, 2013 Folie 2 TAV- 38, 1 5. Oktober / P aderborn Copyright TOOP/MBT

3 Agenda Auf der Suche nach Bugs Laufendes Beispiel: Bankautomat Drei Methoden, ein Ziel: Testautomatisierung Modellbasiertes Testen Behaviour-driven Development Keyword-driven Testing Vergleich der drei Methoden Fazit & Ausblick MBT? BDD KDT Folie 3

4 Warum ist Softwaretesten wichtig? jährliche Kosten durch Softwarefehler aktuell über 300 Mrd. US$ pro Jahr [Cambridge, 2013] Jahr Folie 4

5 Warum ist Softwaretesten wichtig? Folie 5

6 Softwareentwicklung Requirements Deliverable System specification Integrated system Subsystem specification Subsystems Verfeinerung Codegenerierung Implementation/ Integration Component specification Components Folie 6 [L. Baresi, M. Pezzè, 2006]

7 Qualitätssicherung Requirements Acceptance tests Haben wir das Richtige entwickelt? Deliverable System specification System tests Integrated system Haben wir richtig entwickelt? Subsystem specification Integration tests Subsystems Verifikation Validation Debugging Component specification Unit tests Components Folie 7 [L. Baresi, M. Pezzè, 2006]

8 Auf der Suche nach Bugs! MBT Verifikation: Haben wir richtig entwickelt? Folie 8 Bagdanov: Working together - Formal Methods and Testing, 2003 Validation: Haben wir das Richtige entwickelt?

9 World Quality Report 2015 Folie 9

10 Agile Softwareentwicklung TDD Continuous Delivery KDT BDD Folie 10

11 Laufendes Beispiel: Bankautomat Funktionale Anforderung: Nachdem der Kunde die Karte eingeschoben und die PIN und den Betrag eingegeben hat, wird der Betrag vom Konto abgebucht und die Karte und das Geld ausgegeben. Falls die PIN das 1. oder 2. Mal falsch eingegeben wurde, wird der Kunde benachrichtigt und die PIN wird erneut eingegeben. Falls die PIN ein 3. Mal falsch eingegeben wurde, protokolliert das System den Versuch, zieht die Karte ein und bricht die Kommunikation ab. Falls die Karte nicht gültig ist, wird dies dem Kunden mitgeteilt und die Karte wieder ausgegeben. (Quelle: Wincor Nixdorf) Folie 11

12 Modell-basiertest Testen Anforderungen Spezifikation Modell Kriterien zur Testauswahl Testfälle Testobjekt Testergebnisse Folie 12 [Pretschner et.al.]

13 Modell-basiertest Testen Testfall 3 Testfall 2 Testfall 1 Folie 13

14 Behavior-driven Development BDD = Shared understanding by discussing examples User Story As a role I want to use a function so that I achieve a goal tests Scenario Scenario Scenario Given Given Given When some initial context, When When Then an event occurs, Then Then ensure some outcomes. Product owner Developer Business analyst Tester Folie 14

15 Behavior-driven Development readable User Story: Bankkunde hebt Geld ab Als Bankkunde, ich möchte vom Bankautomaten Geld abheben damit ich außerhalb der Filial-Öffnungszeiten Geld abheben kann. executable Scenario 2: Gewünschter Geldbetrag ist auf dem Konto vorhanden Scenario 1: Gewünschter Geldbetrag ist auf dem Konto vorhanden Given the account is in credit And Gegeben the card is das valid Konto verfügt über den gewünschten Betrag When the customer requests cash Then Und ensure die the Bankkarte account ist is gültig debited And Und ensure der cash Bankautomat is dispensed enthält das Geld in erwünschter Betrag And ensure the card is returned Wenn der Kunde den gewünschten Betrag abhebt Dann der Betrag ist ausgezahlt Und das Konto ist mit dem Betrag belastet Und die Bankkarte ist das Konto verfügt über den gewünschten Betrag ) public bool kontoverfügtbetrag(){... Bankkarte ist gültig ) public bool bankkartegueltig(){... der Kunde den gewünschten Betrag abhebt ) public void kundebetragabheben() {... } Folie 15

16 Keyword-driven Testing Technik fokussiert auf automatisierten Softwaretest, ist prinzipiell aber auch zum manuellen Test geeignet Basiert auf parametrierten Schlüsselwörtern (Keywords / Action Words) Nutzung von Keywords als Abstraktionsschicht ermöglicht verbesserte Wiederverwendbarkeit & Wartbarkeit automatischer Testfälle ISO/IEC-Standard Software and systems engineering - Software testing - Part 5: Keyword-driven testing in Entwicklung Umsetzung mit vielen Werkzeugen möglich: Klassische Capture/Replay-Tools, z.b. HP QTP und Nachfolger FIT Selenium Folie 16

17 Keyword-driven Testing Keyword Katalog: Führe Karte ein (mit Parameter gültig/ungültig ) Entnehme Karte Gib PIN ein (mit Parameter <PIN> als Repräsentant der Äquivalenzklassen gültige/ungültige PIN ) Wähle Transaktion (mögliche Werte: Abheben, Kontostand,...) Gib Betrag ein (<Betrag>) Entnehme Geld (<Betrag>) Breche Vorgang ab. Testfall: Testfall: Testfall: Führe Karte ein ( gültig ) Führe Gib PIN Karte ein ein ( 0815 ) ( gültig ) Führe Gib Wähle PIN Karte ein ein Transaktion ( 0815 ) ( gültig ) Gib ( Abheben ) Wähle PIN ein Gib Betrag Transaktion ( 0815 ) ein ( 500 ) ( Abheben ) Wähle Gib Entnehme Betrag Transaktion ein Karte ( 500 ) ( Abheben ) Gib Entnehme Betrag ein Karte ( 500 ) Entnehme Entnehme Karte Geld ( 500 ). Entnehme Geld ( 500 ). Entnehme Geld ( 500 ). Folie 17

18 Vergleich der drei Methoden MBT Keyword Katalog: Führe Karte ein (mit Parameter gültig/ungültig ) Entnehme Karte Gib PIN ein (mit Parameter <PIN> als Repräsentant der Äquivalenzklassen gültige/ungültige PIN ) Wähle Transaktion (mögliche Werte: Abheben, Kontostand,...) Gib Betrag ein (<Betrag>)... Alternativ-Notation zu Szenario 1... Wenn der Kunde die Karte einführt Und der Kunde PIN eingibt Und die Geld abheben -Transkation wählt Und den Betrag eingibt... KDT BDD Folie 18

19 Vergleich der drei Methoden formal MBT unterstützt KDT unterstützt BDD informell Testdesign Testrealisierung Folie 19

20 Fazit leichtgewichtig: einfach, aber weniger mächtig schwergewichtig: aufwendig, aber mächtig gute Basis zur Automatisierung, auch für BDD und MBT Folie 20

21 Danksagung & Ausblick Danke an die AK-Teilnehmer Einladung zum Arbeitskreis Nächster Termin in Bremen Mögliche zukünftige Themen: Coverage Fallstudien Werkzeuge & Werkzeugintegration Folie 21

22 Vielen Dank für Ihre Aufmerksamkeit leichtgewichtig: einfach, aber weniger mächtig schwergewichtig: aufwendig, aber mächtig gute Basis zur Automatisierung, auch für BDD und MBT Folie 22

23 Kontakt Webseite: Mailverteiler: Treffen/Protokolle Publikationen Mitarbeiter Doktoranden Ressourcen Folie 23