U2TP UML Testing Profile Specification

Transkript

1 U2TP UML Testing Profile Specification

2 UML Unified Modeling Language UML- Unified Modelling Language der OMG- Object Management Group Familie graphischer Modellierungssprachen für komplexe, objektorientierte Systeme Über ein gemeinsames Metamodell verbunden Entwicklung von U2TP 2001 angestoßen durch RFP (Request for Proposal) Apr Annahme der finalen U2TP- Spezifikation des U2TP Konsortiums Aktuell Klärung offener Prunkte und Probleme P A G E 2

3 Testen mit U2TP Was ist Testen? - Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden. G.J. Myers Die stichprobenhafte Überprüfung, dass ein System die spezifizierten Anforderungen erfüllt. Ziele Wozu Testen wir?: um Fehler zu finden und ein System zu erhalten, dass so fehlerfrei wie nötig ist um die Entwickler zu informieren, wie sie Fehler vermeiden können P A G E 3

4 Beschreibung U2TP I Testmodellierungssprache für das Entwerfen, Visualisieren, Spezifizieren, Analysieren, Konstruieren und Dokumentieren der Artefakte von Testsystemen P A G E 4

5 Beschreibung U2TP II Die UML Testing Profile ist in 4 Konzeptgruppen aufgeteilt: 3. Test Architektur (Test Architecture) 4. Testdaten (Test data) 5. Testverhalten (Test behaviour) 6. Testzeit (Test time) Da U2TP als UML- Profil definiert ist, ist es in UML integriert U2TP basiert auf dem UML2.0- Metamodell U2TP verwendet die UML2.0- Syntax wieder P A G E 5

6 Die U2TP-Konzepte sind strukturiert in Testarchitektur Definiert die Konzepte bezogen auf Teststruktur- und Testkonfiguration Testverhalten Adressieren die Konzepte für die dynamischen Aspekte der Testverfahren und definieren Stimuli, Beobachtungen und Aktivitäten während eines Tests Testdaten Definieren die Konzepte für die Testdaten, die während der Testprozeduren genutzt werden Testzeit Zur Definition von zeit- quantifizierten Testprozeduren, also für Zeitbeschränkungen und Zeitanalysen während der Testausführung P A G E 6

7 Testarchitektur Mit den Testarchitekturkonzepten werden die strukturellen Aspekte einer Test Suite festgelegt: Test Context Test Component Test Configuration SUT Arbiter Scheduler Utility Part P A G E 7

8 Test Context ist ein strukturierter Classifier, der 1) eine gruppierende Funktion für eine Menge von Testfällen (Test Case) darstellt und 2) eine TestConfiguration besitzt, auf dessen Grundlage die TestCases ausgeführt werden. Attribute: Arbiter: realisiert die Arbiter- Schnittstelle Scheduler: realisiert die Scheduler- Schnittstelle Constraints: Test Context muss genau ein Property enthalten, um die Arbiter- Schnittstelle und die Scheduler- Schnittstelle zu realisieren. P A G E 8

9 Test Configuration Objekte der Testkomponenten-Klassen bilden zusammen mit den SUT- Objekten Testkonfigurationen. Verbindungen zwischen den Schnittstellen der Testkomponenten und der SUT ermöglichen die Interaktion zwischen Testsystem und zu testendem System. P A G E 9

10 Test Configuration P A G E 10

11 Test Component Eine Testkomponente ist ein strukturierter Classifier und stellt eine Klasse von Testsystemen dar. Objekte des Testsystems werden über Testkomponenten-Klassen mit ihren Schnittstellen, Attributen und Operationen definiert. Attribute: zone: Timezone [0..1] Spezifiziert die Zeitzone, zu der eine Testkomponente gehört P A G E 11

12 SUT System Under Test System Under Test: das zu testende System Mit dem Stereotyp SUT werden ein oder mehrere Objekte als Bestandteil des zu testenden Systems und als wichtig für eine Testkonfiguration angesehen. In Abhängigkeit der Ebene beim Testen kann der SUT eine Systemkomponente, eine Menge von Systemkomponenten, ein Subsystem, ein System oder eine Komposition von Systemen. P A G E 12

13 Arbiter Vordefinierte Schnittstelle Definiert Operationen für die Arbitrage von Tests Zur Auswertung der individuellen Testergebnisse jeder Testkomponente wird der Arbiter genutzt. in U2TP aus technischen Gründen als vordefinierte Schnittstelle realisiert Berechnet aus Einzelergebnissen das Gesamtergebnis für einen Testfall Arbiter definiert für die Auswertung zwei Operationen: getverdict(): Verdict gibt den aktuellen Verdict aus setverdict (v: Verdict) setzt einen neuen Verdict- Wert P A G E 13

14 Scheduler Vordefinierte Schnittstelle definiert Operationen, um die Tests und die Testkomponenten zu kontrollieren. Der Scheduler ist eine Menge von TestContexts, um die Ausführung von verschiedenen Testkomponenten zu kontrollieren. Operationen: Scheduler(): Konstruktor des Schedulers. Es startet den SUT und den Arbiter starttestcase(): Der Scheduler wird den TestCase starten, in dem alle involvierten TestComponents benachrichtigt werden finishtestcase (t:testcomponent): Nimmt auf, dass die Testkomponente t die Ausführung von diesem Testfall beendet hat createtestcomponent (t:testcomponent): Nimmt auf, dass die Testkomponente t von vielen anderen Testkomponenten erzeugt wurde P A G E 14

15 Test Behavior I Test Control Spezifikation für den Aufruf von Testfällen innerhalb eines Test Context technische Spezifikation, wie der SUT mit dem gegebenen TestContext getestet werden sollte Test Case Ein TestCase enthält die Rahmenbedingungen, die zur Überprüfung eines Testlaufs benötigt werden. Zu den Rahmenbedingungen gehören: Die für die Ausführung notwendigen Vorbedingungen Die Menge der Eingabewerte Die Menge der erwarteten Sollwerte Die Prüfanweisung Die erwarteten Nachbedingungen P A G E 15

16 Test Behavior II Stimulus Testdaten, die an einen Testfall (SUT) gesendet werden Observation Reaktion des SUT, wenn der TestCase ausgeführt wird Coordination Coordination regelt die Ordnung der Testausführung und der Einsammlung von Urteilen, z.b. in einem verteilten System Default Voreinstellungen (Werte), die für den Test eigentlich nicht relevant sind P A G E 16

17 Test Behavior III Verdict Ermöglicht die Bewertung der Korrektheit eines SUT Vordefinierter Aufzählungs-Datentyp, der die Verdict- Werte pass, fail, inconclusive und error beinhaltet und andeutet, wie diese TestCase- Ausführung ausgeführt wird Pass: TestCase war erfolgreich und SUT reagierte wie erwartet Fail: SUT verhielt sich nicht gemäß der Spezifikation Inconclusive: Testausführung kann nicht bestimmen, ob sich der SUT gut oder nicht gut verhalten hat Error: Testsystem selber ist fehlgeschlagen und nicht der SUT P A G E 17

18 Test Behavior IV Validation Action Konkrete Auswertung eines TestCases der ausgeführt wird. Validierungsaktionen werden von einer Testkomponente ausgeführt, um an den Arbiter lokale Testdaten zu übertragen. Log- Aktionen Aktion eines TestCases zur Protokollierung zu veranlassen. Log- Aktionen zur Ablage von zusätzlichen Informationen über die Testausführung, die gegebenenfalls für eine spätere Analyse genutzt werden sollen. P A G E 18

19 Test Behavior V Test Log Ein TestLog repräsentiert das Verhalten, dass sich durch die Ausführung eines TestCase oder TestContext ergibt. TestlogApplication Eine Abhängigkeit zu einem TestCase oder TestContext. P A G E 19

20 Test Data Wildcard Erlauben dem Benutzer das explizite Spezifizieren, ob ein Wert vorhanden ist oder nicht. Spezielle Symbole, um Werte und Wertabgrenzungen herzustellen Es existieren drei Wildcards: Ein Wildcard für irgendeinen Wert Ein Wildcard für irgendeinen oder überhaupt keinen Wert Ein Wildcard für einen weggelassenen Wert DataPool Ein Datenpool ist eine Sammlung von Datenteilen oder expliziten Werten, die für einen TestContext oder Testcomponent während der Ausführung von TestContext und TestCases benutzt werden. P A G E 20

21 Time Concepts I Timezone Gruppierender Mechanismus für TestComponents Jede TestComponent gehört zu einer bestimmten Zeitzone TestComponents in der selben Zeitzone haben dieselbe Zeit Timer Mechanismus, der ein Timeout generieren kann, wenn ein bestimmter Zeitwert auftritt Timers gehören zu TestComponents GetTimeAction Aktion zur dynamischen Abfrage der aktuellen Timezone von einer Testkomponente GetTimzeone- Aktion kann zur Laufzeit von einer Testkomponente aufgerufen werden, um die aktuelle Timezone abzufragen. P A G E 21

22 Time Concepts II SetTimezone Aktion zum dynamischen Setzen der Timezone von einer Testkomponente SetTimezone- Aktion kann zur Laufzeit von einer Testkomponente aufgerufen werden, um die aktuelle Timezone zu setzen Duration Vordefinierter primitiver Typ zur Spezifikation der Bearbeitungsdauer Time Vordefinierter primitiver Datentyp zur Spezifikation konkreter Time- Werte Time- Werte werden benutzt, um Time- Bedingungen auszudrücken und Timers zu setzen P A G E 22

23 Time Concepts III TimeOut TimeOut wird durch einen ablaufenden Timer generiert TimeOutMEssage TimeOutMessage wird von einem ablaufenden Timer generiert. TimeOutMessage wird zur aktiven Klasse gesendet, die den Timer beinhaltet TimeOutAction TimeOut wird durch einen ablaufenden Timer aktiviert Eine Aktivität, die die TimeOutAction als eine Input- Bedingung beinhaltet, tritt auf, wenn das TimeOut abgelaufen ist P A G E 23

24 Time Concepts IV StartTimerAction Aktion, die zum Starten eines Timers gebraucht wird StartTimerAction auf einem laufenden Timer startet den Timer neu StopTimerAction Aktion, die den Timer stoppt StopTimerAction auf einem nicht laufenden Timer hat keinen Effekt ReadTimerAction Aktion zum Lesen einer Timers, um die Ablaufszeit des Timers einzuholen P A G E 24

25 Time Concepts V TimerRunningAction Aktion, die prüft, ob ein Timer aktuell läuft oder nicht Aktion liefert einen booleschen Wert Behavior Repräsentiert das dynamische Verhalten von einem TestContext, TestCase oder TestComponent in einem zu testenden System P A G E 25

26 Beispiel: Tempomat mit Abstandregelung _ regelt Fahrzeuggeschwindigkeit abhängig von Sollgeschwindigkeit und evtl. vorausfahrenden Fahrzeugen _ Einhaltung eines vorgegeben sicheren Abstandes oder vorgegebener Geschwindigkeit _ Subsystem Pedalinterpretation interpretiert die Pedalwege von Fahrpedal und Bremspedal P A G E 26

27 Elements of the system to be tested P A G E 27

28 The PedalInterpretation Test package P A G E 28

29 Erkennung der Bremspedalbetätigung Phi_Brake Bremspedalweg Phi_Acc Fahrpedalweg BrakePedal Bremspedalflag AccPedal Fahrpedalflag P A G E 29

30 Erkennung der Fahrpedalbetätigung Phi_Brake Bremspedalweg Phi_Acc Fahrpedalweg BrakePedal Bremspedalflag AccPedal Fahrpedalflag P A G E 30

31 Bremspedalhysterese Phi_Brake Bremspedalweg Phi_Acc Fahrpedalweg BrakePedal Bremspedalflag AccPedal Fahrpedalflag P A G E 31

32 Fahrpedalhysterese Phi_Brake Bremspedalweg Phi_Acc Fahrpedalweg BrakePedal Bremspedalflag AccPedal Fahrpedalflag P A G E 32

33 Vielen Dank für Eure Aufmerksamkeit P A G E 33