Post on 10-Sep-2020
transcript
1
Qualitätssicherung für Testspezifikationen am Beispiel
der standardisierten Testing and Test Control Notation (TTCN-3)
Prof. Dr. Jens Grabowski
Institut für InformatikGeorg-August-Universität Göttingen
grabowski@cs.uni-goettingen.de
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
2
InhaltEinführung
Wozu benötigt man eine standardisierte Testsprache?Was ist TTCN-3?Konzepte von TTCN-3
Qualitätssicherung für TTCN-3-SpezifikationenVorgehensweiseBewertung von TestreihenAuffinden und Beseitigen von QualitätsmängelnImplementierung
Zusammenfassung und Ausblick
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
3
Wozu benötigt man eine standardisierte Testsprache?
Entwickler
Heterogenitätnimmt zu
Testen imEntwicklungs-
prozessIntegrator
System-integrator
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
4
Wozu benötigt man eine standardisierte Testsprache?
ServicenahesTesten
TTCN-3
EntwicklungsnahesTesten
z.B. JUnit
Entwickler
Integrator
System-integrator
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
5
Wozu benötigt man eine standardisierte Testsprache?
Eine standardisierte Testspracheverbessert die Kommunikation
zwischen Entwicklern und Testernmit dem Kunden
verbessert die Transparenz des Testprozesses:eine Testsprache für alle Abteilungenvermeidet proprietäre Testsprachen
verringert die Testkosten:SchulungskostenVerwendung von kommerziellen Testlösungen (mehrerer Anbieter)
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
6
Was ist TTCN-3?Die standardisierte (Black-Box) Testspezifikations- und Testimplementierungssprache.
TTCN-3 (= Testing und Test Control Notation version 3)wurde beim European Telecommunications Standards Institute (ETSI) von 1999 – 2001 entwickelt.wird seit 2001 beim ETSI kontinuierlich gepflegt und weiterentwickelt.basiert auf Erfahrungen mit früheren TTCN Versionen.
Benutzbar für alle Arten des Black-Box Testens von reaktiven und verteilten Systemen
Mobile (Telecom) Systeme: ISDN, GSM, UMTS, WiMAXInternet: IPv6Automotive: AUTOSAR
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
7
Was ist TTCN-3?
TTCN-3 User
Graphical Format
Tabular Format
ASN.1 Types & Values
OtherTypes & Values
IDLTypes & Values
TTCN-3CoreNotation
OtherPresentation Formats
XMLTypes & Values
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
8
TTCN-3 User
Graphical Format
Tabular Format
ASN.1 Types & Values
OtherTypes & Values
IDLTypes & Values
TTCN-3CoreNotation
OtherPresentation Formats
XMLTypes & Values
Was ist TTCN-3?msc mi_synch1_conc1
mtc ISAP1 MSAP2
UML Testing Profile
:testcase myTestcase () runs on MTCType system TSIType{ mydefault := activate (OtherwiseFail);
verdict.set(pass);
:connect(PTC_ISAP1:CP_ISAP1,mtc:CP_ISAP1);:map(PTC_ISAP1:ISAP1, system:TSI_ISAP1);:PTC_ISAP1.start(func_PTC_ISAP1());PTC_MSAP2.start(func_PTC_MSAP2());Synchronization(); all component.done;log(”Correct Termination”);
}:
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
9
Was ist TTCN-3?Europäischer Standard (ES) in 10 Teilen
ES 201 873-1: TTCN-3 Core LanguageES 201 873-2: TTCN-3 Tabular Presentation Format (TFT)ES 201 873-3: TTCN-3 Graphical Presentation Format (GFT)
ES 201 873-4: TTCN-3 Operational SemanticsES 201 873-5: TTCN-3 Runtime Interface (TRI)ES 201 873-6: TTCN-3 Control Interface (TCI)
ES 201 873-7: Using ASN.1 with TTCN-3ES 201 873-8: Using IDL with TTCN-3ES 201 873-9: Using XML with TTCN-3
ES 201 873-10: Documentation Comment Specification
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
10
Konzepte von TTCN-3
Black-box Testen mit TTCN-3Verteilte TTCN-3 TestkonfigurationenTTCN-3 ImplementierungWeitere Konzepte
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
11
Black-box Testen mit TTCN-3TTCN-3 Test Case
Port.send(Stimulus) Port.receive(Response)
System Under Test
Port
• Assignmentof aTest Verdict
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
12
TTCN-3 Test Case
Verteilte TTCN-3 Testkonfigurationen
create
create
MTC
start
start
create
TCs
TC
TC
start
SUT
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
13
TTCN-3 Implementierung
SUT
Real Test System Interface
Test System
Abstract Test System Interface
TC2TC1
INOUT
OUT IN
Connected Ports
INOUTMapped Ports
INOUT
Real Test System Interface
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
14
Konzepte von TTCN-3Black-box Testen mit TTCN-3Verteilte TTCN-3 TestkonfigurationenTTCN-3 ImplementierungWeitere Konzepte
Umfangreiches DatentypsystemAusgefeiltes System zur Beschreibung von Testdaten (Templates mit Matchingmechanismen)Default-VerhaltenUnterstützt verschiedene Kommunikationsmechanismen
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
15
TTCN-3 KernspracheBeispiel: module exampleModule {
...type record IpAddressType { charstring ipAddress };template IpAddressType localhostTemplate := {
ipAddress := "127.0.0.1" } testcase exampleTestCase() runs on ExampleComponent {
portA.send(localhostTemplate); alt {
[] portB.receive(localhostTemplate) {setverdict(pass);
}[] portB.receive(IpAddressType:{*}) {
setverdict(fail);}
}}
}
„Look and feel“ einer typischen ProgrammierspracheQualitätsprobleme wie anderer Quellcode!
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
16
Umfang von TTCN-3 Testreihen
Motorola (interne) riesige „legacy“ TestreihenMigration zu TTCN-3Automatische Konvertierung einer UMTS Testreihe
60.000 Lines of Code (LOC)Schwer zu lesen, zu verstehen und zu pflegen
Standardisierte Testreihen (ETSI)SIP (ETSI TS 102 027-3 - v4.2.5): 61.990 LOCIPv6 Core Protocol (ETSI TS 102.516 - v3.1.1): 67.580 LOC3GPP Benchmark: 73.130 LOC
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
17
InhaltEinführung
Wozu benötigt man eine standardisierte Testsprache?Was ist TTCN-3?Konzepte von TTCN-3
Qualitätssicherung für TTCN-3-SpezifikationenVorgehensweiseBewertung von TestreihenAuffinden und Beseitigen von QualitätsmängelnImplementierung
Zusammenfassung und Ausblick
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
18
Vorgehensweise: Qualitätssicherung für TTCN-3 Spezifikationen
Bewertung vonTestreihen
Auffinden vonQualitätsmängeln
Beseitigen vonQualitätsmängeln
Qualitätsmodell
Metrik- und Code Smell-basiert
Refactoring
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
19
Objektive Beurteilung von Software-Qualität,Objektive Zielvorgaben für Software-Qualität.
ISO 9126-1: Software Engineering – Product Quality – Quality Model
Qualitätsmodelle fürInterne Qualität, Externe Qualität, Quality in Use.
Bewertung von Testreihen -Qualitätsmodelle
Qualität setzt sich aus einzelnen Merkmalen sowie ggf. weiteren Teilmerkmalen zusammen.
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
20
Teil-merkmale
Haupt-merkmale
Das ISO 9126 Modell für interne und externe Qualität
External and Internal Quality
Suitability
Accuracy
Interoperability
Security
FunctionalityCompliance
Maturity
Fault-Tolerance
Recoverability
ReliabilityCompliance
Understand-ability
Learnability
Operability
Attractiveness
UsabilityCompliance
Time Behaviour
Resource Utilisation
EfficiencyCompliance
Adaptability
Installability
Co-Existence
Replaceability
PortabilityCompliance
Functionality Reliability Usability Efficiency Portability
Analysability
Changeability
Stability
Testability
MaintainabilityCompliance
Maintainability
Analysability
Changeability
Stability
Testability
MaintainabilityCompliance
Maintainability
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
21
Ein Qualitätsmodell für Testspezifikationen
Test Specification Quality
Suitability
Accuracy
Interoperability
Security
FunctionalityCompliance
Maturity
Fault-Tolerance
Recoverability
ReliabilityCompliance
Understand-ability
Learnability
Operability
Attractiveness
UsabilityCompliance
Time Behaviour
Resource Utilisation
EfficiencyCompliance
Analysability
Changeability
Stability
Testability
MaintainabilityCompliance
Adaptability
Installability
Co-Existence
Replaceability
PortabilityCompliance
Functionality Reliability Usability Efficiency PortabilityMaintainabilityTest
Effectivity
Test Coverage
Test Correctness
SecurityFault-
RevealingCapability
Test Effectivity
Compliance
Test Repeatability
Reusability
Coupling
Flexibility
Comprehen-sibility
ReusabilityCompliance
Test Evaluability
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
22
Instantiierung von Qualitätsmodellen
Qualitätsmodell abstrahiert von Testspezifikationssprache,projekt-spezifischen Anforderungen.
⇒Instantiierung nötig!
ISO 14598: Software Engineering – Product Evaluation1. Qualitätsmodell erstellen,2. Metriken für Qualitätsmerkmale festlegen,3. Grenzwerte für Metriken festlegen,4. Gewichtung der Qualitätsmerkmale.
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
23
Maintainability:Analysability:
complexity violation := 1 -
Changeability:code duplication := 1 -
Stability:parameter reassignment := 1 -
Metrikintervalle:0,0 (= schlechteste Qualität) bis 1,0 (= beste Qualität).
Beispiel: TTCN-3 Metriken für Qualitätsmerkmal Maintainability
Σ Komplexe Verhaltenseinheiten
Σ Verhaltenseinheiten
Σ Duplizierte QuelltexteinheitenΣ Quelltexteinheiten
Σ out und inout Formalparameter
Σ Formalparameter
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
24
Anwendung des Qualitätsmodells
Metrik SIP v2.20
SIP v2.24
SIP v3.01
SIP v3.06
Testfälle 1068 1068 1412 1412Verhaltenseinheiten 1961 1971 2360 2369Verhaltenseinheiten mit zyklomatischer Komplexität > 10 27 30 51 51Zweige in alt-Anweisungen 1900 1958 2482 2534Duplizierte Zweige in alt-Anweisungen 1435 1471 1849 1879Formalparameter 3175 3224 5062 5084out und inout Formalparameter 1237 1244 1617 1628Analysability: complexity violation (zyklomatische Komplexität >10) 0.99 0.98 0.98 0.98
Changeability: code duplication (bzgl. Zweigen in alt-Anweisungen) 0.25 0.25 0.26 0.26
Stability: parameter reassignment 0.61 0.61 0.68 0.68
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
25
Vorgehensweise: Qualitätssicherung für TTCN-3 Spezifikationen
Bewertung vonTestreihen
Auffinden vonQualitätsmängeln
Beseitigen vonQualitätsmängeln
Qualitätsmodell
Metrik- und Code Smell-basiert
Refactoring
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
26
Definition:Code Smell & Refactoring
Code smell: “certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring”
Fowler: Refactoring – Improving the Design of Existing Code. Addison-Wesley, 1999
Refactoring: “A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.”
Fowler: Refactoring – Improving the Design of Existing Code. Addison-Wesley, 1999
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
27
TTCN-3 Code SmellsTTCN-3 Code Smells:
Muster für die unsachgemäße Benutzung von TTCN-3.
Code Smells lassen sich durch Refactoring verbessern. Zeiss, Neukirchen, Grabowski, Evans, Baker: Refactoring and Metrics for TTCN-3 Test Suites. SAM-Workshop, 2006.
Per Definition keine Code Smells: Syntax Fehler,Verstöße gegen die statische Semantik,Fehler in der Testfall Logik.
TTCN-3 Code Smells geben nur Hinweise auf QualitätsproblemeWas als TTCN-3 Code Smell angesehen werden soll, ist projektabhängig.
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
28
TTCN-3 Code Smell KatalogFür TTCN-3 Code Smells wurde ein strukturierter Katalog angelegt.Bisher wurden 38 TTCN-3 Code Smells identifiziert, die folgende Aspekte abdecken:
Duplicated Code, z.B. Duplicate Alt BranchesReferences, z.B. Singular Component Variable/Const./TimerParameters, z.B. Constant Actual Parameter ValueComplexity, z.B. Complex ConditionalDefault Anomalies, z.B. Activation AsymmetryTest Behaviour, z.B. Missing VerdictTest Configuration, z.B. Idle Parallel Test ComponentCoding Standards, z.B. Magic ValuesData Flow Anomalies, z.B. Unused Variable DefinitionMiscellaneous. z.B. Over-specific Runs On
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
29
Definition:Code Smell & Refactoring
Code smell: “certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring”
Fowler: Refactoring – Improving the Design of Existing Code. Addison-Wesley, 1999
Refactoring: “A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.”
Fowler: Refactoring – Improving the Design of Existing Code. Addison-Wesley, 1999
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
30
28 Refactorings von Fowler, die auf TTCN-3 anwendbar sind.20 TTCN-2 spezifische Refactorings.
Katalog Struktur: Refactorings zur Verbesserung vonTestverhalten (20 Refactorings):
Extract Altstep,…
der allg. Struktur der Testreihe (22 Refactorings):Extract Module,…
Datenbeschreibungen (6 Refactorings):Inline Template Parameter,…
TTCN-3 Refactoring Katalog
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
31
Vorgehensweise: Qualitätssicherung für TTCN-3 Spezifikationen
Bewertung vonTestreihen
Auffinden vonQualitätsmängeln
Beseitigen vonQualitätsmängeln
Qualitätsmodell
Metric- und Codesmell-basiert
Refactoring
?
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
32
Metrik-basiert:Anzahl der Referenzen auf ein Template = 0⇒ Lösche TemplateAnzahl der Referenzen auf ein Template = 1⇒ Definition des Templates bei dessen Benutzung
Code Smell-basiert:Verwendung von Templates mit identischen Parameterwerten⇒ Parameter in das Template integrierenMehrere Templates unterscheiden sich nur in einem Wert⇒ Parameterisiere Template
Auffinden und Beseitigen von Qualitätsmängeln
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
33
Implementierung: TRex TTCN-3 Refactoring and Metrics Tool (TRex):
Open Source Plug-In für die Eclipse-Plattform
Integrierte TTCN-3 Entwicklungsumgebung
Automatische Berechnung von Metriken
Automatische Detektion von TTCN-3 Code Smells
Regel- und Metrik-basierte Erkennen von Qualitätsproblemen
Werkzeug-basiertes Refactoring
Visualisierung von Kontrollfluss- und (Funktions-)Aufrufgraphen.
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
34
Visualisierung vonKontrollflussgraphen
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
35
Regel- und Metrik-basierte Erkennung von Qualtitätsproblemen
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
36
Anwendung von TRexSession Initiation Protocol (SIP) Testreihe (standardisiert von ETSI):
Größe:42397 lines of code (LOC),
528 Testfälle, 785 Funktionen,358 Templates (5619 LOC).
Auszug von gefundenen Qualitätsproblemen:10 unbenutzte Templates,22 Templates, die man parameterisieren und zusammengeführen könnte.
Automatische Anwendung der zugehörigen Refactorings führten zueiner Reduktion der Testreihe um 393 LOC (7% der Template LOC).
119 verschiedene mehrfach duplizierte alt-Verzweigungen.15 Verhalten, die gegen die McCabe-Komplexität verstoßen.
Refactorings zur Beseitigung dieser Qualitätsprobleme sind noch nicht implementiert.
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
37
InhaltEinführung
Wozu benötigt man eine standardisierte Testsprache?Was ist TTCN-3?Konzepte von TTCN-3
Qualitätssicherung für TTCN-3-SpezifikationenVorgehensweiseBewertung von TestreihenAuffinden und Beseitigen von QualitätsmängelnImplementierung
Zusammenfassung und Ausblick
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
38
ZusammenfassungÜbersicht über TTCN-3
Methodik zur Bewertung und Verbesserung der Qualität von TTCN-3. Die Methodik basiert auf:
einem Qualitätsmodell zur Bewertung von Testreihen,Metriken und TTCN-3 Code Smells zur Erkennung von Qualitätsproblemen undRefactoring zur Qualtitätsverbesserung.
Methodik wurde im TRex-Werkzeug implementiert.
An Beispielen wurde die Anwendbarkeit dieser Methodik gezeigt.
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
39
AusblickDetektion und Verbesserung von Qualtitätsproblemen, die sich nicht statisch entdecken lassen.
Qualität von Testreihen, die nicht-funktionale Anforderungen (u.a. Realzeitaspekte) messen (TEMEA-Projekt).
Enge Zusammenarbeit mit ETSI im Bereich der Qualitätssicherung für standardisierte TTCN-3-Testreihen.
06.0209 Softwareforen Leipzig, User Group Treffen:“Softwaretest und Qualitätsmanagement“
40
Vielen Dank für Ihre Aufmerksamkeit!
Haben Sie Fragen?
http://www.trex.informatik.uni-goettingen.de