TESTAUTOMATISIERUNG LEICHT GEMACHT

Transkript

1 die autorin TESTAUTOMATISIERUNG LEICHT GEMACHT ist in vieler Munde: Mit steht der Testgemeinschaft eine generische, bei ETSI und ITU standardisierte Testtechnologie zur Verfügung, die die Entwicklung und Ausführung systematischer Tests und deren Wiederverwendung über Technologien, Produktlinien und Hersteller hinweg ermöglicht. ist eine lebendige, in steter Anwendung befindliche und kontinuierlich gewartete Testtechnologie, die seit August 2008 in der Version v3.4.1 vorliegt. Prof. Dr.-Ing. Ina Schieferdecker hat einen Lehrstuhl für Entwurf und Testen kommunikationsbasierter Systeme an der Technischen Universität Berlin inne und leitet das Kompetenzzentrum Modellieren und Testen bei Fraunhofer FOKUS. Sie ist u.a. aktives Mitglied der -Standardisierung bei ETSI und Mitglied im German Testing Board. Jedoch ist der Zugang zu dieser Testtechnologie nicht immer leicht, paaren sich durchaus die Vorurteile der Testautomatisierung mit Einstiegshürden einer neuen Testtechnologie. Dabei zeigen einerseits Untersuchungen von Motorola [Rao05], dass der Einsatz dieser Technologie nicht nur die Güte der Tests, sondern ebenso die Effizienz ihrer Entwicklung und den Grad der Wiederverwendung entscheidend erhöhen. Zudem zeigen Studien in China [Ji06], dass diese Technologie von Testern unmittelbar anwendbar ist und bereits nach ein bis zwei Tagen Ausbildung in produktive Tests umgesetzt werden kann, wenn die Tester ein Grundverständnis über Testmodellierung und spezifikation besitzen. Dennoch: ist eine mächtige Testtechnologie, mächtig genug, um eine Vielzahl von Testaufgaben zu lösen, damit auf den ersten Blick aber auch komplex. Lassen Sie mich dazu auf ein Gedankenspiel aus einer Diskussion mit Mark Harman, Brunel University, verweisen: Stellen Sie sich vor, Ihnen steht entweder ein Totalverlust Ihres Systems oder des dazugehörigen Testsystems bevor. Sie können den Schaden nur insofern mindern, als dass Sie sich entweder für den Erhalt des Systems oder des Testsystems entscheiden. Während noch vor einigen Jahren in einer solchen Situation mehrheitlich das System gerettet worden wäre (denn darum geht es schlussendlich), so mehren sich heutzutage die Stimmen, die eine Rettung des Testsystems bevorzugen (da das Testsystem nicht nur das Wissen über das zu entwickelnde System, sondern auch das Wissen über dessen Absicherung umfasst). Das Testsystem erlaubt uns, das System jederzeit zu rekonstruieren und gleichzeitig, das System in seiner Evolution abzusichern. Dieses Mehr an Wissen korreliert mit den Aufwänden für die Entwicklung des jeweiligen Systems: Es gibt in zunehmendem Maße Produkte, bei denen ebenso viel, wenn nicht mehr, Aufwände in das Testsystem wie in das System investiert werden. Diese Verlagerung der Aufwände auf das Testsystem konnte man bspw. bei Microsoft seit der Entwicklung von Windows XP beobachten, was sich in unser aller Sinne u. a. auf die Stabilität des Betriebssystems positiv auswirkte. Gleichzeitig kommen diese Mehraufwände in den Technologien, die für die Entwicklung eines Testsystems genutzt werden, zum Ausdruck. Wer kennt nicht den Wald an Testwerkzeugen, wo bereits jedes Werkzeug für sich genommen komplex ist, aber erst die Kombination eine hinreichende Analyse und Bewertung eines Systems auf seine Qualitätsanforderungen zulässt. Da angetreten ist, diesen Wald an Werkzeugen wenn nicht aufzuheben, so doch zumindest zu lichten, verwundert es nicht, dass diese Testtechnologie in ihrer Mächtigkeit entsprechend ausgelegt wurde, um über eine Konsolidierung der Testkonzepte schlussendlich eine Vereinfachung zu erreichen. Und hierbei ist kein Ende abzusehen: regelmäßig erreichen uns Wünsche, weitere Konzepte in aufzunehmen. Doch dazu später. Im Folgenden gebe ich einen Abriss zur Geschichte, zum Stand und zur möglichen Zukunft von und möchte Sie neugierig auf diese Testtechnologie machen. gestern: Ein kurzer Rückblick auf die Geschichte wurde als Neuauflage der TTCN (Tree and Tabular Combined Notation), Abkürzungen ASN.1 ETSI IDL ITU OMA SUT XML Abstract Syntax Notation One European Telecommunication Standards Institute Interface Definition Language International Telecommunication Union Open Mobile Alliance System under Test Testing and Test Control Notation Extended Markup Language die für Konformitätstests von Kommunikationsprotokollen entwickelt wurde, durch ETSI erarbeitet. ist als moderne Testspezifikations- und -implementierungssprache ausgelegt, mit deren Hilfe Tests textuell oder grafisch entwickelt und automatisiert zur Ausführung gebracht werden können. wurde erstmals im September 2000 der Öffentlichkeit vorgestellt und hat mit Version v2.2.1 eine für die Werkzeugentwicklung und industrielle Anwendung notwendige Stabilität erreicht. Nachfolgende Versionen wurden um neue Konzepte erweitert, aber rückwärts-kompatibel zu den Vorgängerversionen gestaltet. So umfassen bspw. die Neuerungen in v3.1.1 verschachtelte Typen, wie sie in XML genutzt werden, dynamische Templates und ein Logging-Interface. In Version v3.2.1 wurden die Adressierung innerhalb des Testsystems verbessert, in Version v3.3.2 Template-Restriktionen ermöglicht und in 1

2 // erwartete, richtige Antwort [] b.receive {setverdict(fail); // unerwartete, falsche Antwort [] keineantwort.timeout {setverdict(fail); // keine Antwort Abb. 1: Die TTCN- 3 Testspezifikationssprache v3.4.1 nutzerdefinierbare Attribute für Testurteile (Verdicts) eingeführt. Diese Änderungen können seit 2005 entlang des Change-Request(CR)-Prozesses durch jedermann transparent verfolgt werden. Im Gegensatz zu vielen (Test-)Modellierungssprachen umfasst nicht nur eine Sprache für die Spezifikation von Tests (siehe Abb. 1), sondern ebenso eine Architektur und Ausführungsschnittstellen für basierte Testsysteme (siehe Abb. 2). Im Folgenden ein kleines Beispiel zu (siehe auch Abb. 3), das Ihnen einen Einblick in diese Technologie vermittelt. In dem bekannten Testbeispiel von G.J. Myers [Mye01] zur Klassifikation von Dreiecken (ein Dreieck ist über die Seitenlängen definiert und muss klassifiziert werden) steht bspw. immer wieder die Frage nach der Typisierung. In legen Sie diese explizit fest: type integer Dreieck[3] (0..infinity); // ganzzahlige Charakterisierung eines Dreiecks type enumerated Klassifikation { // Dreieckseigenschaften syntaktischfehlerhaft, keindreieck, gleichschenkligesdreieck, gleichseitigesdreieck, rechtwinkligesdreieck, rechtwinkligesgleichseitigesdreieck type port BestimmeDreieck message { out Dreieck; in Klassifikation // Zugang zur SUT type component DreiecksTester { port BestimmeDreieck b // die Testkomponente testcase Einfach() runs on DreiecksTester { // ein einfacher Test b.send(dreieck: {2,2,2); // das Dreieck b.receive(klassifikation: gleichseitigesdreieck); // die erwartete Antwort setverdict(pass); // ein erfolgreicher Test Diese Testspezifikation verdrahtet die Testdaten fest mit dem Testablauf, was nicht gut wartbar ist. Eine andere Methode ist es, die Testdaten vom Testverhalten zu separieren: type record TestVector { // Kombination von Eingaben mit Soll-Werten Dreieck input, Klassifikation output template TestVector gueltig1:= {{2,2,2,gleichseitigesDreieck; // gültige Dreiecke template TestVector gueltig2:= {{2,2,1,gleichschenkligesDreieck; // usw. template TestVector ungueltig1:= {{1,0,3,keinDreieck; // ungültige Dreiecke template TestVector ungueltig2:= {{1,2,3,keinDreieck; // usw. testcase Erweitert(TestVector tv) runs on DreiecksTester { // ein parametrisierter Test timer keineantwort:= 1.0; b.send(tv.input);keineantwort.start; alt { [] b.receive(tv.output) {setverdict(pass); Hier definieren wir zudem, dass die SUT auch fehlerhaft oder gar nicht antworten kann. Das können Sie nun weiter ausbauen, indem Sie bspw. über parallele Testkomponenten gleichzeitig Anfragen an das SUT starten oder aber Testsequenzen festlegen, die erst auf alle gültigen, danach in Abhängigkeit positiver Testergebnisse auch auf ungültige Dreiecke prüfen. Viele weitere Varianten sind möglich, die aber nicht in diesem Artikel dargestellt werden können. heute: 10 gute Gründe, einzusetzen Dies führt uns zu einer Beschreibung der jetzigen Situation mit, die in Form von guten Gründen für zusammengefasst wird. 1. Sie können relativ leicht erlernen und direkt anwenden: ist eine testspezifische Sprache, die von Testern für Tester entwickelt wurde. Eine Handvoll an Kernkonzepten wie Testfälle, Testurteile oder aber Testdaten (Templates genannt) erlaubt es Ihnen, einfache Tests, wie Sie sie in einer Mehrzahl von Testaufgaben zu entwickeln haben, direkt umzusetzen. Dabei bleibt aber nicht stehen: eine Vielzahl zusätzlicher Kon- TE: Test Engine Abb. 2: Die TTCN- 3 Testsystem-Architektur online-ausgabe Testing 2008

3 fachartikel Abb. 3 Beispiel für eine integrierte Entwicklungsumgebung für 2. 3 zepte erlaubt es Ihnen, Tests auch für komplexe Testaufgaben wie Tests über heterogene Schnittstellen, verteilte Tests, sich dynamisch adaptierende Tests, etc. umzusetzen. Wenn Ihnen das nicht genügt, so können Sie weitere Konzepte integrieren oder aber direkt in die Weiterentwicklung des Standards einbringen. An dieser Stelle sei die Vielzahl an Veröffentlichungen zum Thema in Form von Büchern, Zeitschriften und Artikeln zu nennen, mit deren Hilfe Sie sich aktuell und im Detail über die Technologie, ihre Anwendung und zugehörige Werkzeuge informieren können (siehe Quellen). Sie können Ihr Testwissen prüfen und sich bei erfolgreichem Abschluss durch ein Zertifikat bestätigen lassen. In Anlehnung an das Certified Tester Schema des International Software Testing Qualification Boards (ISTQB) wurde durch das German Testing Board (GTB) ein Ausbildungsschema entwickelt (siehe Quellen). Durch akkreditierte Trainingsanbieter werden Schulungen angeboten, mit denen Sie in der 3. Anwendung von ausgebildet werden. Die Aufnahme des Zertifikats in das Certified Tester Expert Level beim ISTQB ist in Vorbereitung. Sie können selber zur Weiterentwicklung von beitragen. Bei ETSI wird ein Change-Request(CR)Prozess für gepflegt, über den Korrekturen, Ergänzungen und Vorschläge für Erweiterungen eingebracht werden können (siehe Quellen). Wann immer Sie in ihrer praktischen Anwendung von den Bedarf der Weiterentwicklung 4. sehen, so können Sie dies als CR beschreiben und in einem transparenten Verfahren den Weg zur Lösung des CRs verfolgen. CRs können zu Korrekturen, Erläuterungen oder Ergänzungen führen. Sie können aber auch als Duplikate eines bereits eingereichten CRs erkannt oder aber begründet ohne Änderung am Standard geschlossen werden. Sie können eine Vielzahl von Werkzeugen nutzen. Da ein Standard ist, ermöglicht dies die Entwicklung von Off-the-Shelf-Werkzeugen. Sie können die aufwendige Wartung und Weiterentwicklung Ihrer Quellen ETSI Standardserie: ITU Standardserie: Home Page Bibliographie: Mailing List: Change Requests: Zertifikat: User Conferences Werkzeuge ES Z.140 Z ttcn3@list.etsi.org > Events -> Tools w w w. o b j e k t s p e k t r u m. d e

4 proprietären Inhouse-Werkzeuge durch Lizenz- und Wartungsverträge für externe Werkzeuge ablösen und sich auf die Spezifikation und die Entwicklung von Testfällen konzentrieren. Die Entwicklung von Entwicklungs-, Ausführungs-, Reporting- oder Integrationskomponenten überlassen Sie Dritten. Die Verfügbarkeit einer Vielzahl von Werkzeugen erfordert Ihrerseits keine Sackgassen- Entscheidung für einen Anbieter Ihr Investment in bleibt über ein konkretes Werkzeug hinweg gesichert. Eine Liste kommerzieller, freier oder Open-Source-Werkzeuge finden Sie unter Quellen. 5. Derzeit wird in immer größerem Umfang genutzt. Es kommt in der Telekommunikation, für Internet- Technologien, für Steuergeräte im Automobil und in der Medizintechnik, für Software und Web Services von Business-Applikationen und in egovernment, usw. zum Einsatz. Verschiedene Gremien nicht nur ETSI oder ITU setzen auf : 3GPP nutzt es für UMTS und LTE Tests an der Luftschnittstelle und im Backbone, das WIMAX Forum für Zertifizierungen der Geräte, das AUTOSAR Konsortium für Basissoftware der Automotive Software Middleware und die OMA für Funktionstests von Enablern für mobile Dienste und stellen die Tests zur Verfügung. So können Sie für Ihre Testfälle oftmals auf bestehende Bibliotheken und Test Suiten zurückgreifen und müssen diese nicht von Null an selber entwikkeln. Weitere Nutzungen im Kontext von XÖV (XML-basierter Datenaustausch in der öffentlichen Verwaltung), HL7 (kommunizierende Geräte in der Medizintechnik [EU08]) oder MOST (Entertainment Applikationen und Komponenten im Automobil) zeichnen sich ab. Die weitere Verbreitung von geht Hand in Hand mit einer wachsenden Zahl von Werkzeuganbietern, so z.b. im deutschsprachigen Raum davinci Communications, Danet oder TestingTech. 6. Sie können Mitglied einer permanent wachsenden Community werden, die sich regelmäßig bei der User Conference (T3UC, siehe Quellen) trifft, um sich über Anwendungen, Fallstudien, Experimente, Werkzeuge und neue Entwicklungen von auszutauschen. Die fünfte T3UC fand 2008 in Madrid statt, die T3UC 2009 wird nahe Nizza an der Côte d Azur stattfinden. Dort können Sie neben Anwendern und Experten auch die Werkzeughersteller treffen und sich über neueste Entwicklungen in der Werkzeug- und Dienstlandschaft zu informieren. Zudem veranstalten eine Reihe anderer Konferenzen wie die Software Quality Conference (SQC), die EuroStar oder die Conquest Tracks und Tutorials zu. 7. Und natürlich können Sie vor allem mit Ihre anstehenden Testaufgaben effektiv und effizient lösen. Dabei erfordert keinen unmittelbaren und absoluten Wechsel Ihrer derzeitigen Testmethodik und -landschaft, sondern ermöglicht eine schrittweise Migration in die neue Testtechnologie. Sie können existierende Testlösungen mit neuen Testlösungen verknüpfen und so die aufgebaute Testbasis weiternutzen, bis sie nicht mehr benötigt wird, da bspw. die damit getesteten Systeme ausgelaufen sind. 8. Neben den verschiedenen Programmiersprachen wie C, C++, Java oder C#, die durch Werkzeuge unterstützt werden, erhalten Sie mit eine Vielzahl von Zugängen zu Schnittstellen-Technologien der zu testenden Systeme. Dazu gehören Zugänge für ASN.1, IDL und XML basierte Systeme, Schnittstellen oder Formate, die Bestandteil der Standardserie sind. Zudem wurden durch Werkzeughersteller Zugänge für Java, C/C++, Tcl, Python, WSDL, BPEL, etc. geschaffen, die zwar (noch) nicht standardisiert worden sind, Ihnen aber dennoch zur Verfügung stehen. 9. Sie können Ihre Testfälle in mittels der Dokumentationsannotationen (documentation tags) angemessen kommentieren und so die Lesbarkeit, Wiederverwendung und Wartbarkeit der Tests erhöhen. Zudem können Sie Metriken, Muster, Anti- Muster und Refactorings für nutzen, die Ihre Test Suiten analysieren und optimieren helfen. 10. Sie können für verschiedene Testarten und -phasen einsetzen. Die Stärken von liegen in der Spezifikation und Ausführung von Tests, bei denen Schnittstellen oder andere Kommunikationswege als Testzugänge zum SUT genutzt werden und man es ggfs. mit der Heterogenität des Systems oder des Testsystems bzgl. Schnittstellen, Programmiersprachen, Formaten, der Kombination von SWund HW-Komponenten, der verwendeten Programmiersprachen, etc. zu tun hat. Es bietet sich insbesondere für Integrations-, System- und Abnahmetests an. Darüber hinaus kann nicht nur zum funktionalen Testen, sondern auch zum nicht-funktionalen Testen wie z. B. für Leistungstests (siehe [Din08]) genutzt werden. Wenn Sie dabei die Wiederverwendungspotenziale der Testfälle in den verschiedenen Testphasen und Testarten ausnutzen, gewinnen Sie nicht nur durch eine breite Nutzung dieser Testtechnologien. Damit verbunden sind eine Reduktion an Aufwänden für die Schulung und Weiterbildung der Mitarbeiter als auch bei der Wartung der Testwerkzeuge. Ebenso können bestehende Test Suiten oder Bibliotheken häufig genutzt werden. Der Standard im Überblick Teil 1: Testkonzepte und textuelle Kernsprache (core language) Teil 2: Tabellarische Format (TFT) wenig genutzt Teil 3: Graphische Format (GFT) abgelöst durch das UML Testing Profile Teil 4: Operationale Semantik (OS) Teil 5: Anbindung an die SUT (Ausführungsschnittstellen TRI) Teil 6: Anbindung an das Testsystem (Ausführungsschnittstellen TCI) Teil 7: Nutzung von ASN.1 mit Teil 8: Nutzung von IDL mit Teil 9: Nutzung von XML Schemata mit Teil 10: Dokumentationstags für online-ausgabe Testing 2008

5 morgen: Ein Ausblick Derzeit wird die Version v4.1.1 von erarbeitet. Im Zentrum der Betrachtung stehen Konzepte für eine effizientere Handhabung von Testkonfigurationen, für eine bessere Unterstützung von Bibliotheken und für eine weitere Dynamisierung der Testspezifikationen bspw. durch Typ-Parametrisierungen. Im Anschluss werden Konzepte zum Testen von Echtzeitsystemen, von kontinuierlichen Systemen und/oder zum Leistungstesten betrachtet. Zwar können derartige Tests schon heute in formuliert und ausgeführt werden, doch erhofft man sich von einer direkteren Unterstützung durch dedizierte Konzepte eine effizientere Anwendung von für Echtzeit- und hybride Systeme, wie sie in der Automatisierung, Automobiltechnik, Luftfahrttechnik, Medizintechnik usw. genutzt werden. Aber eigentlich geht mein Blick dahin, dass wir mit eine Middleware für automatisierte Tests etablieren, so wie wir sie mit SQL für Datenbanken oder aber mit IDL für objektorientierte Systeme kennen. Auch wenn sich softwarebasierte Systeme in ihren Anwendungsgebieten und damit in ihren Tests unterscheiden, so kann man doch eine gemeinsame Menge an Grundfachartikel konzepten für die Entwicklung von Testlösungen identifizieren. Aufbauend auf dieser, in realisierten Menge an Grundkonzepten und einer Middleware können dedizierte Methoden und Werkzeuge für die jeweiligen Anwendungsgebiete effizient und effektiv entwikkelt werden. Wir sollten Testen immer mehr als Ingenieursdisziplin verstehen, bei der gemeinsame, automatisierte Methoden von geschultem Personal zum Einsatz kommen die Zeiten manueller Tests und proprietärer Testlösungen für spezielle Testfragen sollten über kurz oder lang vorbei sein. Dazu muss die Methodik in der Anwendung von stärker vermittelt werden und müssen die Werkzeuge noch stärker auf die Bedürfnissen der Tester ausgerichtet werden. Moderne Methoden der Softwareentwicklung müssen auch für die Entwicklung von Testsystemen angeboten werden dazu gehören u.a. Refactorings, Metriken, Verfikationen, Debugging und auch die Simulation der Tests. Eine wichtige Entwicklung stellen modellbasierte Testmethoden [IT08] dar, die in Kombination mit einer -Middleware ihr Potenzial voll ausschöpfen können. Referenzen [Rao05] G. G. Rao, T. Weigert: Network Element Testing using : Benefits and Comparison, SDL Forum 2005, Grimstadt, Norwegen, Juni [Ji06] W. Ji: test technique evaluation report, Technical Report, Joint Sino-German Institute, Beijing, China, Mai [Mye01] G.J. Myers: Methodisches Testen von Programmen. 7. Auflage, R. Oldenbourg Verlag, [EU08] EUREKA TestNGMed Projekt: Testautomatisierung für die nächste Generation medizinischer Systeme, verfügbar ab Okt [DIN08] ITEA D-MINT Projekt: Deployment of Model-Based Technologies to Industrial Testing, letzter Zugriff am 14. Sept [IT08] G. Din: A Workload Realization Methodology for Performance Testing of Telecommunication Services, Promotion, TU Berlin, Fakultät Elektrotechnik und Informatik, Sept