Was testet der Tester morgen?

Transkript

1 class Wagen Was testet der Tester morgen? Wagen + geschlossen() : void + hindernis() : void + Wagen(tuere_1, tuere_2) Tuere - versuche + auf() : void + zu() : void 2 + ist_auf() : void + ist_zu() : void + hindernis() : void + Tuere(wagen, motor) 3 Sensor stm Simple Ruhe entry / Motor.stopp exit / Motor.start Motor Initial freigabe [! anf] freigabe [anf] /Vorgaenger.bereit Fahrt2 anforderung / Vorgaenger.warte, anf = true anforderung /Vorgaenger.bereit Fahrt1 entry / anf = false sensor_ein warte /Nachfolger.anforderung, bereit Vorgaenger.freigabe Warten bereit entry / Motor.stopp anforderung / Vorgaenger.warte, anf=true exit / Motor.start + vor() : void + rueck() : void + stopp() : void CTFL Qualitätssicherung in den Zeiten automatischer Codegenerierung joerg.robra@t-online.de Embedded Systems

2 Was ist eigentlich aus 50 Jahren Software-Engineering geworden? Softwareentwicklung in der Mitte des vorigen Jahrhunderts: Idee Programmieren Testen Debuggen Ausliefern Man kann Qualität nicht aus einem Produkt heraustesten, man muss sie hinein entwickeln! Embedded Systems Folie 2

3 Was ist eigentlich aus 50 Jahren Software-Engineering geworden? Weiterentwicklung des Software-Engineering: Ziele und Wege Idee Erhebungstechniken QS von Requirements Spezifikation von Requirements User Stories Requirements Tracing Change Management Funktionale Zerlegung (SA/SD) Modulare Zerlegung (Parnas) Objektorientierter Entwurf Komponentenarchitekturen, SOA Spezifikationstechniken u. -sprachen Analysieren Strukturierte Programmiersprachen Verständliche Programmiersprachen Typsichere Programmiersprachen Prozedurale Programmiersprachen Modulare Programmiersprachen Objektorientierte Programmiersprachen Entwerfen Phasenmodelle V-Modelle Iterativ-inkrementelle Modelle Agile Modelle Spezifizieren Programmieren Integrationstest Integrieren Unittest Systemtest Akzeptanztest Embedded Systems Folie 3

4 Was ist eigentlich aus 50 Jahren Software-Engineering geworden? Weiterentwicklung des Software-Engineering: Die Realität Idee Analysieren Systemtest Akzeptanztest Entwerfen Spezifizieren Programmieren Integrationstest Integrieren Unittest % von Konferenz- und Veranstaltungsprogrammen im Bereich SW-Qualität befassen sich mit Testen. 80 % aller erteilten Schulungszertifikate heißen "Tester". ISTQB-Zertifikate garantieren angeblich die Karriere Sitzen wir eigentlich im richtigen Zug? joerg.robra@t-online.de Embedded Systems Folie 4

5 Ein paar Thesen... Testen ist ein gefährlicher Hype, da er den Zielen des Software- Engineering widerspricht. Demgemäß werden zu viele Tester und entsprechend zu wenige Experten auf anderen Gebieten ausgebildet. Ausbildung und Zertifizierung von Testern orientieren sich an althergebrachten Entwicklungsprozessen und berücksichtigen neue Techniken nicht, zu wenig oder zu spät. Durch agile Prozesse und automatische Generierung von Code und Testautomaten aus Modellen werden sich die Anforderungen an den Test(er) gewaltig ändern. Embedded Systems Folie 5

6 ... und die Begründungen dazu Die Verlagerung der QS in den rechten Zweig des V-Modells erzeugt hohe Kosten... Idee Analysieren Entwerfen Akzeptanztest...insbesondere in der Systemtest Integrationstest Wartungsphase... Spezifizieren Integrieren Programmieren Unittest...denn sie garantiert keine Systemqualität! Embedded Systems Folie 6

7 ... und die Begründungen dazu Warum es zu viele Tester gibt Es gibt derzeit weltweit ISTQB Certified Tester davon in Deutschland dazu CAT aber nur CPRE weltweit davon in Deutschland CPSA in Deutschland Certified Professional in Requirements Engineering Certified Agile Tester Certified Professional in Software Architecture Wo bleiben CPRS, CPDD, CPUE, CP...? Gefahr: Rückfall in die Zeit, in der Testen als wichtigster Bestandteil der QS angesehen wurde! joerg.robra@t-online.de Embedded Systems Folie 7

8 ... und die Begründungen dazu Die Karawane zieht weiter... seit 1995: Einzug agiler Methoden (Scrum, XP; "Agile Manifesto" 2001) Agiles Testen als CTFL-Add-on ab 2014 Seltsame Struktur des CAT-Syllabus seit 1998: Modellbasiertes Testen Modellbasiertes Testen als CTFL-Add-on ab 2015 Seit 1979: MDD (auch MDSD) im Sinne von Generierung ablauffähigen Codes aus Modellen (SDL bei PKI). Weitgehend in Vergessenheit geraten. Neuer Anlauf der OMG mit MDA seit 2003 Unit-Test in der bisherigen Form nicht sinnvoll Fehlerbeseitigung in der bisherigen Form nicht zulässig Beim ISTQB kein Trend sichtbar Embedded Systems Folie 8

9 Einfluss von MDSD / MDD / MDA auf das Testen MDSD / MDD / MDA: Generierung von lauffähigem Code aus Modellen MDA: Standard der OMG Modelle in UML Grundsätzlicher Weg: MDA setzt eine Plattform voraus, auf der der Code ablaufen soll. PIM = Platform Independent Model PSM = Platform Specific Model Rules: Transformationsregeln Abgekürzter Weg: Struktur der Plattform und Transformationsregeln sind in Tools und Design Rules integriert, das Modell enthält alle erforderlichen Informationen. Dann kann aus dem PIM direkt Code generiert werden. Beliebtes Verfahren für embedded Systeme, die aus kommunizierenden Zustandsautomaten bestehen. PSM Code Rules Rules joerg.robra@t-online.de Embedded Systems Folie 9

10 Einfluss von MDSD / MDD / MDA auf das Testen Voraussetzungen: Das Modell muss in einer offen zugänglichen und klar definierten textuellen Version vorliegen (bei UML: XMI = XML Metadata Interchange) Plattform und Codegenerator müssen (möglichst) fehlerfrei sein. Die Plattform muss alle Dienste zur Verfügung stellen, die nicht im Modell dargestellt werden; dazu gehören Kommunikationsdienst (Message Passing) Scheduling HW-Interface Zeit- und Timerdienste Applikationstyp-spezifische Bibliotheksfunktionen (z.b. Filter, Regler...); zu Gunsten der Mehrfachverwendbarkeit der Plattform möglichst als Plug-in Debugging-Schnittstelle (z.b. Message Tracing) Datendienst (nichtflüchtige Datenbank mit einfacher Zugriffssprache) "Erbauer" (Systemgenerierung, -konfiguration und -initialisierung auf Grund eines Initialisierungsskripts) joerg.robra@t-online.de Embedded Systems Folie 10

11 Einfluss von MDSD / MDD / MDA auf das Testen Folgen: Der generierte Code ist frei von Programmierfehlern und Regelverstößen. Er kann nur Fehler enthalten, die schon im Modell vorhanden waren, wie Logikfehler oder fehlerhafte Statements in Zustandsmodellen. Durch sprachunabhängige Makros und Funktionsbibliotheken können letztere minimiert werden. Außerdem können schwer testbare Konstrukte vermieden werden. Beispiel Bustüre Eine weitere Fehlerquelle ist das Initialisierungsskript. stm Tuere Initial Geschlossen entry / Wagen.ist_zu schli essen hindernis [versuche NE!= 0] Schliessen entry / Motor.rueck exit / Motor.stopp offen Hindernis zu entry / Motor.vor exit / Motor.stopp exit / DEC versuche-- (versuche) oeffnen oeffnen hindernis [versuche == EQ = 0] 0] /Wagen.hindernis schl iessen Oeffnen entry / Motor.vor exit / Motor.stopp schliessen / defer offen Offen entry / Wagen.ist_auf entry / versuche = 3 joerg.robra@t-online.de Embedded Systems Folie 11

12 Einfluss von MDSD / MDD / MDA auf das Testen Was bedeutet das für den Test? Variante 1: zunächst fast nichts. Der generierte Code wird getestet, als wäre er manuell erstellt. Nachteile für den Tester: Kann das der Tester? Er kann keine üblichen Programmierfehler finden. Die Ursache für gefundenes Fehlverhalten muss im Modell lokalisiert werden. Korrekturen sind nur im Modell zulässig. Folge: Den einzigen Testzyklus, der wirtschaftlich sinnvoll war, gibt es nicht mehr Idee Analysieren Systemtest Akzeptanztest Entwerfen Integrationstest Spezifizieren Generieren X Integrieren Unittest joerg.robra@t-online.de Embedded Systems Folie 12

13 Einfluss von MDSD / MDD / MDA auf das Testen Weitere Probleme: Wo kommen die Testfälle her? Normalerweise aus der Spezifikation. Was bleibt? MBT Die Spezifikation ist aber das Modell, und der Code repräsentiert das Modell 1:1, enthält keine Programmierfehler und erfüllt alle Coding Rules. Im Zustandsmodell werden Überdeckungstests konstruiert und am Code durchgeführt. Nutzen unklar. Testfälle werden aus übergeordneten Spezifikationen (Use Cases, User Stories) hergeleitet getestet wird das Modell. Testfälle werden (manuell oder automatisch) aus Modellen der Umgebung generiert (HW, Benutzer, Nachbar-Units). joerg.robra@t-online.de Embedded Systems Folie 13 stm Tuere Initial Geschlossen entry / Wagen.ist_zu schli essen Schliessen entry / Motor.rueck exit / Motor.stopp 6 hindernis [versuche!= 0] 5 offen Hindernis entry / Motor.vor exit / Motor.stopp exit / versuche-- zu 8 9 oeffnen oeffnen hindernis [versuche == 0] /Wagen.hindernis schliessen 4 7 Oeffnen entry / Motor.vor exit / Motor.stopp schliessen / defer offen Offen 3 entry / Wagen.ist_auf entry / versuche = 3 10

14 Einfluss von MDSD / MDD / MDA auf das Testen Andererseits ergeben sich daraus neue Möglichkeiten: Auch die Umgebung wird in Zustandsautomaten modelliert. Mögliches Fehlverhalten wird ins Modell aufgenommen. Diese werden mit dem vorhandenen Codegenerator in der vorhandenen Plattform installiert. Einer der Automaten steuert den automatischen Testablauf. Folge: Test- und Ablaufumgebung sind identisch, alle Tests sind automatisiert, keine besonderen Testwerkzeuge erforderlich. Testautomat Simulator Allgemeine Dienste joerg.robra@t-online.de Embedded Systems Folie 14

15 Einfluss von MDSD / MDD / MDA auf das Testen Beispiel: Modelle der Bustür-Umgebung (Wagen, Hardware, Fahrgast) Ausgaben der Tuere an ihren Motor werden an die Hardwaresim umgeleitet stm Wagen_Testautomat stm Hardwaresim Zu Oeffnen after(tb) Offen_1 /Tuere.offen vor /Fahrgastsim.oeffnet stopp Schliess4 after(tb/2) /Tuere.zu, Fahrgastsi m.zu Schliess3 vor after(td) Schliess5 frei Tb: Bewegungsdauer der Türe vor Alarm do / alarm after(td) after(td) block vor /Tuere.hindernis after(tb/2) Schliess2 /Fahrgastsim.wo rueck stopp Offen rueck Schliess1 stm Tuere Fahrt Tuer_oeffnen after(2 s) Geschlossen Oeffnen entry / Tuere.oeffnen oeffnen after(4 s) entry / Wagen.ist_zu entry / Motor.vor [zufall] exit / Motor.stopp ist_auf [zufall] oeffnen schliessen / defer schliessen zu Alarm Tuer_schliess ist_zu after(tz) hindernis [versuche == 0] Tuer_auf offen do / alarm Schliessen entry / Tuere.schliessen /Wagen.hindernis hindernis after(15s) entry / Motor.rueck schliessen Offen exit / Motor.stopp zufall: Zufallsvariable 10% true, 90% false entry / Wagen.ist_auf stm Fahrgastsim hindernis [versuche!= 0] tz : Zufallszeit s entry / versuche = 3 offen Hindernis Warten oeffnet after(tz) entry / Motor.vor exit / Motor.stopp Blockiert wo / Hardwaresim.block exit / versuche-- Frei zu wo / Hardwaresim.frei after(tz) Td: Maximal zulässige Reaktionszeit der Steuerung joerg.robra@t-online.de Embedded Systems Folie 15

16 Einfluss von MDSD / MDD / MDA auf das Testen Aber es geht auch anders: Direkter Test der Modelle durch Review oder automatisch bis zur automatischen Modellverifikation Korrektheit der einzelnen Modelle Klassendiagramm: Vollständigkeit von Attributen, Methoden und Parametern Typen von Attributen und Parametern Vollständigkeit der Kommunikationslinks Vollständigkeit der Initialisierungsparameter Objektdiagramm: Vollzähligkeit und Eindeutigkeit der Instanzen Korrektheit der Kommunikationslinks object Objects :Wagen 11 :Tuere class Klassen Wagen + ist_auf(name :char) : void + ist_zu(name :char) : void Platform 1..* Tuere - name: int - state: char schl i esse() : voi d + oeffne() : void + offen() : void + zu() : void + Tuere(name :char) joerg.robra@t-online.de Embedded Systems Folie 16

17 Einfluss von MDSD / MDD / MDA auf das Testen stm Fehler Zustandsdiagramm: Vollständigkeit Nachrichtenparameter Erreichbarkeit Deadlock-Freiheit Lifelock-Freiheit stm Bustuere Trigger oeffnen offen auf schliessen zu hindernis <None> State Geschlossen Oeffnen Offen Oeffnen ignorieren ignorieren Fehler Geschlossen Fehler??? Offen defer Fehler Fehler Fehler Schliessen Fehler Fehler Schl i essen Oeffnen Fehler ignorieren Geschl ossen Hindernis A Hindernis Oeffnen Schl i essen ignorieren Fehler Fehler Init Geschlossen B cb C D de E joerg.robra@t-online.de Embedded Systems Folie 17

18 Einfluss von MDSD / MDD / MDA auf das Testen Konsistenz zwischen Struktur- und Verhaltensmodell Übereinstimmung von Nachrichten- und Methodensignaturen Vorhandensein von Kommunikationslinks class Klassen Übereinstimmung von Adressaten- und Objektnamen sd Sequenz Wagen stm Tuere :Wagen A :Tuere :Platform + ist_auf(char) : void + ist_zu(char) : void Geschlossen oeffne() offen() Platform 1..* 2 1 Oeffnen oeffne zu /Wagen.ist_zu(this) Schliessen ist_auf('a') Tuere schl i esse() ist_zu('a') zu() - name: char - state: char + schliesse() : void + oeffne() : void + offen() : void + zu() : void offen /Wagen.ist_auf(this) Offen schl i esse Ein gutes UML-Tool verhindert syntaktisch falsche und inkonsistente Modelle. Weitere Überprüfungen kann der Codegenerator vornehmen. joerg.robra@t-online.de Embedded Systems Folie 18

19 sd MDD1 Einfluss von MDSD / MDD / MDA auf das Testen Anforderungsanalyse (Sub)Systemtest Anforderungen Build Änderungen im V-Modell: Verlagerung wesentlicher Testaktivitäten in den linken Zweig Strukturmodell Architektur Modelltest Interaktionsmodell Integrationstest UnitCode [getestet] kurze Zyklen, niedrigere Kosten Verifikation von Strukturund Interaktionsmodellen reduziert die Fehlerzahl auch im Integrations- und Systemtest Design Zustandsmodell Codegenerator UnitCode [ungetestet] UnitTest joerg.robra@t-online.de Embedded Systems Folie 19

20 sd MDD-MBT2 Einfluss von MDSD / MDD / MDA und MBT auf das Testen Änderungen im V-Modell: Verlagerung wesentlicher Testaktivitäten in den linken Zweig SystemTestModell Anforderungsanalyse IntegrationsTestModell Anforderungen Generator Architektur UnitTestModell Strukturmodell Modelltest Interaktionsmodell SystemTestAutomat IntegrationsTestAutomat (Sub)Systemtest Build Integrationstest UnitCode [getestet] kurze Zyklen, niedrigere Kosten Der "Generator" erzeugt Testautomaten wenig Testaufwand im rechten Zweig Design Zustandsmodell UnitTestAutomat UnitCode [ungetestet] UnitTest Codegenerator joerg.robra@t-online.de Embedded Systems Folie 20

21 Zu guter Letzt das Ganze auch noch agil mit Test Driven Development Continous Integration Collective Code Ownership und MDA / MDD und MBT sd AgilMDD-MBT UserStories EntwickleTestModell Testmodell Testautomat Frage: Wo ist der Tester? PlanningGame Analyse EntwickleModell UnitModell UnitCode Generiere Architektur UnitTest Implementierung Check_in Entw ickleintegrationsmodell IntegrationsTestModell «datastore» Repository IntegrationsTestAutomat Build [potentially shipable] Integriere Check-Out joerg.robra@t-online.de Embedded Systems Folie 21

22 Einfluss von MDSD / MDD / MDA und MBT auf das Testen Daraus ergeben sich neue Lernziele für "den Tester": Erkenntnis, dass er in Modell-generiertem Code keine Codierungsfehler oder Regelverstöße finden kann. Fähigkeit, Programmfehler im Modell zu lokalisieren und zu korrigieren. Einsicht, dass für die Kombination von MDD und MBT besondere Bedingungen gelten. Einsicht, dass "der Tester" in modernen Prozessen keine eigene Rolle ist, sondern eine Zusatzqualifikation für den Entwickler. Fähigkeit, für den MBT von Modell-generiertem Code geeignete Testmodelle zu erstellen. Spätestens hier wird der Tester zum Modellierer (oder umgekehrt?) Fähigkeit, Entwickler bei der Erstellung testbarer Modelle zu beraten. Fähigkeit, den Review von Modellen unter dem Aspekt durchzuführen, dass das Modell eigentlich schon der Code ist und keine weiteren Fehler auftreten. Fähigkeit, für die Verifikation von Modellen geeignete Tools einzusetzen. joerg.robra@t-online.de Embedded Systems Folie 22

23 Fazit Herkömmliches Testen hat derzeit einen zu hohen Stellenwert. Durch MDD/MDA hat der herkömmlich ausgebildete Tester nur Nachteile: Er muss die Ursache von im Code gefundenem Fehlverhalten im Modell lokalisieren und beseitigen. Durch den Umweg über das Modell verlängert sich der Debugzyklus. Die Spezifikation eines Moduls eignet sich nicht zur Testfallgenerierung. Die Zukunft gehört demjenigen, der einerseits Modelle in Reviews oder formal verifizieren (MDD), andererseits Testmodelle entwickeln kann (MBT). Da offenbar sowohl der Entwickler als auch der Tester der Zukunft weniger programmieren und mehr modellieren müssen, unterscheiden sich beide in Zukunft nicht mehr in ihren Fähigkeiten, sondern nur noch in der Intention. Embedded Systems Folie 23

24 Requirements Architektur UML / SysML MDA / MDD Simulation / Test Danke für f Ihre Aufmerksamkeit! Noch Fragen? joerg.robra@t-online.de Embedded Systems Folie 24

25 Literatur: ISTQB Syllabi CTFL, CTAL (TA, TTA, TM), CTEL (ITP, TA, TM, ST), Portfolio Websites von ISTQB, CAT, CPRE, CPSA Ken Schwaber and Jeff Sutherland: Scrum Development Process. OOPSLA 1995 Extreme Programming. Agile Manifesto S. R. Dalal, A. Jain, N. Karunanithi, J. M. Leaton, C. M. Lott: Model-based testing of a highly programmable system. 9th International Symposium on Software Reliability Engineering (ISSRE 98, 1998) Jeff Offutt and Aynur Abdurazik: Generating Tests from UML Specifications. Second International Conference on the Unified Modeling Language (UML 99), October B. Ludwig, C. Krechel: Kommunikationsmechanismen in einer multiprozessorfaehigen SDL- Laufzeitumgebung. Informatik-Fachberichte Volume 205, 1989; Springer-Verlag OMG: MDA Guide Version Juni 2003 OMG: XMI Specification 2013 Horst Kargl: Flexibilität beim modellbasierten Testen. Objekt Spektrum Online-Ausgabe Testing 2009 joerg.robra@t-online.de Embedded Systems Folie 25