vteststudio - konzepthandbuch · dateien, c#-dateien, testtabellen, testdiagramme und...

Konzepthandbuch

vTESTstudio

Version 4.0

Deutsch

Impressum Vector Informatik GmbH Ingersheimer Straße 24

D-70499 Stuttgart Die in diesen Unterlagen enthaltenen Angaben und Daten können ohne vorherige Ankündigung geändert werden. Ohne ausdrückliche schriftliche Genehmigung der Vector Informatik GmbH darf kein Teil dieser Unterlagen für irgendwelche Zwecke vervielfältigt oder übertragen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln, elektronisch oder mechanisch, dies geschieht. Alle technischen Angaben, Zeichnungen usw. unterliegen dem Gesetz zum Schutz des Urheberrechts.

Copyright 2017, Vector Informatik GmbH. Printed in Germany. Alle Rechte vorbehalten.

Konzepthandbuch vTESTstudio Inhaltsverzeichnis

© Vector Informatik GmbH Version 4.0 - I -

Inhaltsverzeichnis

1 Einführung 3

1.1 Zu diesem Handbuch 4 1.1.1 Zugriffshilfen und Konventionen 4 1.1.2 Zertifizierung 5 1.1.3 Gewährleistung 5 1.1.4 Support 5 1.1.5 Warenzeichen 6

2 Überblick 7

2.1 Allgemeines 8

2.2 vTESTstudio und CANoe 10

2.3 Funktionsüberblick 10

2.4 Aufbau eines Projektes 12 2.4.1 Projektbaum 12 2.4.2 Dateibasierte Ablage 12 2.4.3 Wiederverwendung von Dateien 13 2.4.4 Stammverzeichnis und Bibliotheken 13 2.4.5 Ablageort von Dateien auf dem Dateisystem 13 2.4.6 Strukturierung über (wiederverwendbare) Ordner 14

2.5 Konzepte für eine hohe Testabdeckung 14

2.6 Traceability durch die Anbindung von REQM/TDM-Systemen 18

2.7 Testdesign-Dokumentation 21

3 Testdesign-Editoren 23

3.1 CAPL-Editor 24

3.2 C#-Editor 25

3.3 Testtabelleneditor 26

3.4 Testdiagrammeditor 27

3.5 Zustandsdiagrammeditor 28

4 Interaktion mit CANoe 29

4.1 CANoe Systemumgebung 30

4.2 Ausführung in CANoe 32

4.3 Reporting 34

5 Sprachinteraktion 35

5.1 Schnittstellenfunktionen 36

6 Parameter, Kurven und Varianten 39

6.1 Parameter 40 6.1.1 Konzept 40 6.1.2 Testfalldatenfindung mit der Klassifikationsbaum-Methode 41

6.2 Kurven 42

6.3 Varianten 44

Konzepthandbuch vTESTstudio Inhaltsverzeichnis

© Vector Informatik GmbH Version 4.0 - II -

7 Anwendungsbeispiele 47

7.1 Erzeugen zweier ähnlicher Test Units für unterschiedliche OEMs 48

Konzepthandbuch vTESTstudio Einführung

© Vector Informatik GmbH Version 4.0 - 3 -

1 Einführung

In diesem Kapitel finden Sie die folgenden Informationen:

1.1 Zu diesem Handbuch Seite 4

Zugriffshilfen und Konventionen

Zertifizierung

Gewährleistung

Support

Warenzeichen



1.1 Zu diesem Handbuch

1.1.1 Zugriffshilfen und Konventionen

Informationen schnell finden

Diese Zugriffshilfen bietet Ihnen das Handbuch:

> zu Beginn eines Kapitels finden Sie eine Zusammenfassung der Inhalte,

> in der Kopfzeile sehen Sie, das aktuelle Kapitel und den aktuellen Abschnitt,

> in der Fußzeile sehen Sie, auf welche Version sich das Handbuch bezieht,

> am Ende des Handbuchs finden Sie ein Stichwortverzeichnis.

Verweis: In der Online-Hilfe finden Sie ausführliche Informationen zu allen Themen.

Konventionen In den beiden folgenden Tabellen finden Sie die durchgängig im ganzen Handbuch verwendeten Konventionen in Bezug auf verwendete Schreibweisen und Symbole.

Stil Verwendung

fett Felder, Oberflächenelemente, Fenster- und Dialognamen der Software. Hervorhebung von Warnungen und Hinweisen.

[OK] Schaltflächen in eckigen Klammern

File|Save Notation für Menüs und Menüeinträge

vTESTstudio Rechtlich geschützte Eigennamen und Randbemerkungen.

Quellcode Dateinamen und Quellcode.

Hyperlink Hyperlinks und Verweise.

<Strg>+<S> Notation für Tastaturkürzel.

Symbol Verwendung

Dieses Symbol gibt Ihnen Hinweise und Tipps, die Ihnen die Arbeit mit vTESTstudio erleichtern.

Dieses Symbol warnt Sie vor Gefahren, die zu Sachschäden führen können.

Dieses Symbol weist Sie auf Stellen im Handbuch hin, an denen Sie weiterführende Informationen finden.

Dieses Symbol weist Sie auf Stellen im Handbuch hin, an denen Sie Beispiele finden.

Dieses Symbol weist Sie auf Stellen im Handbuch hin, an denen Sie Schritt-für-Schritt Anleitungen finden.

Dieses Symbol finden Sie an Stellen, an denen Änderungs-möglichkeiten der aktuell beschriebenen Datei erlaubt sind.

Dieses Symbol weist Sie auf Dateien hin, die Sie nicht ändern dürfen.

Dieses Symbol weist Sie auf Multimedia-Dateien hin.



Symbol Verwendung

Dieses Symbol weist Sie auf Stellen im Handbuch hin, an denen Sie einführende Informationen finden.

Dieses Symbol weist Sie auf Stellen im Handbuch hin, an denen Sie Grundwissen finden.

Dieses Symbol weist Sie auf Stellen im Handbuch hin, an denen Sie Expertenwissen finden.

Dieses Symbol weist Sie auf Stellen im Handbuch hin, an denen sich Änderungen ergeben haben.

1.1.2 Zertifizierung

Qualitäts-managementsystem

Die Vector Informatik GmbH ist gemäß ISO 9001:2008 zertifiziert. Der ISO-Standard ist ein weltweit anerkannter Qualitätsstandard.

1.1.3 Gewährleistung

Einschränkung der Gewährleistung

Wir behalten uns inhaltliche Änderungen der Dokumentation und der Software ohne Ankündigung vor. Die Vector Informatik GmbH übernimmt keine Haftung für die Richtigkeit des Inhalts oder für Schäden, die sich aus dem Gebrauch des Handbuchs ergeben. Wir sind jederzeit dankbar für Hinweise auf Fehler oder für Verbesserungsvorschläge, um Ihnen in Zukunft noch leistungsfähigere Produkte anbieten zu können.

1.1.4 Support

Sie benötigen Hilfe? Sie können unsere Hotline telefonisch unter der Rufnummer

+49 (711) 80670-200

oder per Web-Formular unter Vector Support erreichen.

http://vector.de/support/



1.1.5 Warenzeichen

Geschützte Warenzeichen

Alle innerhalb des Handbuchs genannten und ggf. durch Dritte geschützten Marken- und Warenzeichen unterliegen uneingeschränkt den Bestimmungen des jeweils gültigen Kennzeichenrechts und den Besitzrechten der jeweiligen eingetragenen Eigentümer. Alle hier bezeichneten Warenzeichen, Handelsnamen oder Firmennamen sind oder können Warenzeichen oder eingetragene Warenzeichen ihrer jeweiligen Eigentümer sein. Alle Rechte, die hier nicht ausdrücklich gewährt werden sind vorbehalten. Aus dem Fehlen einer expliziten Kennzeichnung der in diesem Handbuch verwendeten Warenzeichen kann nicht geschlossen werden, dass ein Name von den Rechten Dritter frei ist.

> Windows, Windows Vista, Windows 7 und Windows 8 sind Warenzeichen der Microsoft Corporation.

> vTESTstudio ist ein Warenzeichen der Vector Informatik GmbH.

Konzepthandbuch vTESTstudio Überblick


2 Überblick


2.1 Allgemeines Seite 8

2.2 vTESTstudio und CANoe Seite 10

2.3 Funktionsüberblick Seite 10

2.4 Aufbau eines Projektes Seite 12

Projektbaum

Dateibasierte Ablage

Wiederverwendung von Dateien

Stammverzeichnis und Bibliotheken

Ablageort von Dateien auf dem Dateisystem

Strukturierung über (wiederverwendbare) Ordner

2.5 Konzepte für eine hohe Testabdeckung Seite 14

2.6 Traceability durch die Anbindung von REQM/TDM-Systemen Seite 18

2.7 Testdesign-Dokumentation Seite 21



2.1 Allgemeines

Überblick Das Werkzeug vTESTstudio ist eine vielfältige und integrierte Arbeitsumgebung für die Entwicklung von Tests von eingebetteten Systemen.

Tests in vTESTstudio können Sie mit unterschiedlichen Testdesign-Sprachen beschreiben. Folgende Editoren werden unterstützt:

Testdesign-Editoren > CAPL-Editor: CAPL ist eine ereignisorientierte Programmiersprache von CANoe, welche ebenso für die Programmierung von Testabläufen, Testfällen und Funktionen genutzt werden kann.

> C#-Editor: C# ist eine .NET Programmiersprache, die von CANoe durch Bibliotheken erweitert wird, die speziell für Tests und für Zugriffe auf Steuergeräte konzipiert sind.

> Testtabelleneditor: Editor zur Beschreibung von Tests in tabellenartiger Form. Dieser Editor kann ohne Programmierkenntnisse genutzt werden.

> Testdiagrammeditor: Editor für die Modellierung von Testabläufen in einer grafischen Notation. Dieser Editor ist in der Produktoption Graphical Test Design enthalten.

> Zustandsdiagrammeditor: Editor für die Modellierung des erwarteten Verhaltens des SUT als Zustandsmodell für die automatische Generierung von Testfällen. Dieser Editor ist in der Produktoption Graphical Test Design enthalten.

Wiederverwendung Durch die Möglichkeit von Bibliotheken und ein einfach verständliches Wiederverwendungskonzept können sowohl ganze Dateien als auch einzelne Testfälle bequem in verschiedenen Tests wiederverwendet werden.

Strukturierte Testerstellung

Für eine strukturierte Testerstellung werden Tests unterstützt, die aus mehreren Dateien bestehen können.

Parametrierung Durch ein integriertes Parameterkonzept können ECU-Konfigurationsparameter und Testvektoren komfortabel in separaten Dateien gepflegt werden. Von dort können sie einfach in verschiedenen Tests wiederverwendet werden.

Stimulationskurven Mit Hilfe des Waveform-Editors können Kurven definiert werden, die während des Tests zur Stimulation des „System under Test“ genutzt werden.

Varianten Eine durchgängige Variantenunterstützung für Testlogik, Testimplementierung und Parameterwerte ermöglicht die Umsetzung von variantenabhängigen Tests.



Bedienoberfläche

Abbildung 1: vTESTstudio Bedienoberfläche

Abbildung 2: vTESTstudio Bedienoberfläche – Testdiagrammeditor



2.2 vTESTstudio und CANoe

Hand in Hand Die Interaktion mit CANoe ermöglicht in allen Sprachen einen einfachen Zugriff auf das “System under Test”. Die Verwendung von Datenbanksymbolen, Systemvariablen und Diagnosebeschreibungen ist in allen Sprachen komfortabel möglich. Unterstützt werden die Bussysteme und Protokolle CAN, LIN, FlexRay, Ethernet, WLAN und J1939.

Die Tests werden unabhängig von ihrer Notation in CANoe geladen, in Echtzeit ausgeführt und in einem ausführlichen Testreport dokumentiert.

Schema

Abbildung 3: Schematische Übersicht – vTESTstudio und CANoe

2.3 Funktionsüberblick

Wichtige Funktionen Für eine erfolgreiche Testentwicklung bietet vTESTstudio u.a.:

> Integration grafischer Testdesign-Editoren, Programmiereditoren, Parametereditoren und Kurveneditoren in einem Tool

> Komfortable Möglichkeiten für Reviews durch die übersichtliche Modellierung der Testlogik im Testdiagrammeditor oder des erwarteten Verhaltens des SUT im Zustandsdiagrammeditor

> Einfache Wiederverwendbarkeit durch die mögliche Aufteilung von Testlogik, Implementierung, Parameterwerten und Testvektoren

> Mögliche Vorverarbeitung von Events in CAPL und C# für den Zugriff und die Auswertung in Testsequenzen

> Durchgängige Variantenunterstützung für Teststruktur, Implementierung und Parameter

> Konzepte für eine hohe Testabdeckung

> Durchgängige Traceability von extern definierten Anforderungen und Testbeschreibungen in der Testimplementierung und im Testreport

> Automatisch erzeugte Testdesign-Dokumentation für Dokumentationszwecke sowie interne und externe Reviews



2.4 Aufbau eines Projektes

2.4.1 Projektbaum

Begriffe Projekt und Test Unit

Ein vTESTstudio Projekt besteht aus beliebig vielen sogenannten Test Units. Eine Test Unit stellt die in CANoe konfigurier- und ausführbare Einheit dar. Sie besteht aus einer Menge an Dateien, welche die Testimplementierung beinhalten (z.B. CAPL-Dateien, C#-Dateien, Testtabellen, Testdiagramme und Parameterdateien).

Während ein vTESTstudio Projekt zum Beispiel die Tests für ein zu testendes Steuergerät abdeckt, können innerhalb einer Test Unit beispielsweise die Tests für eine bestimmte Funktionalität des Steuergeräts implementiert sein.

Beispiele Beispiel 1

> Projekt für die Tests der Gesamtfunktionalität eines Steuergeräts

> Test Units für Hauptfunktionalität, Fehlererkennung, Diagnose, …

Beispiel 2

> Projekt für die Tests der gesamten Produktlinie eines Steuergeräts

> Test Units für die Tests einer Variante des Steuergeräts

Abbildung 4: Projektansicht

2.4.2 Dateibasierte Ablage

Ablage von Projektbestandteilen

Die Ablage sämtlicher vTESTstudio Projektbestandteile erfolgt dateibasiert. Ein vTESTstudio Projekt besteht aus einer Projektdatei und beliebig vielen Quellcode- und Parameterdateien, welche in der Projektdatei referenziert werden.

Für den Test relevante Dateien (CAPL-Dateien, C#-Dateien, Testtabellendateien, Parameterdateien,…) werden im Kontext einer Test Unit angelegt. Innerhalb einer Test Unit kann zum Beispiel über Datei- bzw. Sprachgrenzen hinweg auf Testfälle und Testfunktionen in anderen Sprachen (Schnittstellenfunktionen) zugegriffen werden. Analog sind Parameter einer Parameterdatei (nur) im Kontext der entsprechenden Test Unit bekannt.



2.4.3 Wiederverwendung von Dateien

Verlinken von Dateien

Dateien können einfach wiederverwendet werden, indem sie in weitere Test Units verlinkt werden. Dies geschieht per Drag & Drop-Aktion von der Quelle zum Ziel. So kann zum Beispiel derselbe Testablauf auf einfache Art und Weise in mehreren Test Units wiederverwendet werden und lediglich eine zugehörige Parameterdatei ausgetauscht werden, d.h. in den Test Units unterschiedlich sein.

Abbildung 5: Projektansicht mit wiederverwendbarer Datei Main.vtt

2.4.4 Stammverzeichnis und Bibliotheken

Stammverzeichnis Das Verzeichnis, in dem sich die Projektdatei befindet, wird als Stammverzeichnis bezeichnet. Im Projekt verwendbar sind die Dateien aus dem Stammverzeichnis und Dateien aus speziell definierten Bibliotheken.

Bibliotheken Die Bibliotheksansicht bietet eine gefilterte Sicht auf das Dateisystem. Eine Bibliothek stellt lediglich einen Ordner auf dem Dateisystem dar, der im vTESTstudio Projekt bekannt gemacht wird. Dateien aus Bibliotheken können ebenfalls über Drag & Drop in Test Units verlinkt werden.

Verschiebt sich ein Bibliotheksordner auf dem Dateisystem, muss in vTESTstudio lediglich der Verweis zur Bibliothek aktualisiert werden. Die Pfade der verlinkten Dateien in den Test Units werden automatisch aktualisiert.

2.4.5 Ablageort von Dateien auf dem Dateisystem

Ablage von Dateien Wird eine Datei im Kontext einer Test Unit angelegt, so wird sie auf dem Dateisystem automatisch unter dem Pfad <Stammverzeichnis>\<Test Unit Name>

angelegt.

Sollen die Dateien auf dem Dateisystem anders organisiert werden, kann dies über die Stammverzeichnisansicht geschehen. Diese Ansicht bietet den Blick auf das Dateisystem unterhalb des Projektverzeichnisses. Wird eine Datei in dieser Ansicht verschoben, werden mögliche Verlinkungen auf diese Datei in den Test Units automatisch aktualisiert.



2.4.6 Strukturierung über (wiederverwendbare) Ordner

Wiederverwendung von Ordnern

Um die Inhalte von Test Units übersichtlicher zu strukturieren, können innerhalb einer Test Unit (beliebig viele und geschachtelte) Ordner angelegt werden. Diese haben keinerlei Einfluss auf den Inhalt des Tests, sie dienen lediglich der Organisation von Dateien.

Neben der Wiederverwendung einzelner Dateien ist auch die Wiederverwendung ganzer Ordner möglich. Befinden sich zum Beispiel in einem Ordner eine Testablaufbeschreibung und eine zugehörige Parameterdatei, können diese beiden Dateien gemeinsam wiederverwendet werden, indem der gesamte Ordner in einer anderen Test Unit verlinkt wird.

Wird ein Ordner mit Dateien unterhalb einer Test Unit angelegt und dann in eine andere Test Unit verlinkt, befindet sich der Ordner mit den Originaldateien auf dem Dateisystem unterhalb der ersten Test Unit. Ist solch eine „Master-Test Unit“ nicht erwünscht, kann der Ordner stattdessen auch als wiederverwendbarer Ordner angelegt werden. Dies geschieht über den Kontextmenü-Eintrag Neuer wiederverwendbarer Ordner am Projekt. So angelegte Ordner und Dateien werden auf dem Dateisystem unter dem Pfad <Stammverzeichnis>\<Shareable

Folders> angelegt. Von dort können sie ebenfalls über Drag & Drop in die Test

Units verlinkt werden.

2.5 Konzepte für eine hohe Testabdeckung

Parametrierte Testfalllisten

Für eine hohe Testabdeckung ohne großen Programmieraufwand werden sogenannte parametrierte Testfall- und Testsequenzlisten unterstützt.

Um eine Testfallliste zu definieren, muss ein Testfall mit Eingangsparametern definiert werden, z.B. in C#:

[Export][TestCase]

public static void CheckMotor(int temperature, double voltage)

{

// ...

}

Die Testfallliste dazu kann z.B. im Testtabelleneditor definiert werden. In der Kommando-Auswahl gibt es dazu einen Eintrag CheckMotor [list]. Wird dieser ausgewählt, erscheint ein Editor, über den mehrere Werte pro Testfall-Parameter vorgegeben werden können:



Abbildung 6: Parametrierte Testfallliste im Testtabelleneditor

Neben der Eingabe von Einzelwerten oder einem Bereich wird auch die Verwendung von skalaren Listenparametern und Struct-Listenparametern aus Parameterdateien unterstützt (siehe dazu auch Abschnitt Parameter):

Abbildung 7: Verwendung von Listenparametern in Testfalllisten

Indem die Parameterwerte sequentiell kombiniert werden, werden nun automatisch so viele Testfallaufrufe generiert, dass jeder Parameterwert mindestens einmal verwendet wird:



Abbildung 8: Generierte Testfallliste mit Kombinatorik Sequential

Soll eine höhere Testabdeckung erreicht werden, indem paarweise oder jede Kombination von Parameterwerten getestet wird, so muss die Eigenschaft Combinatorics von Sequential auf Pairwise bzw. Combinatorial geändert werden:



Abbildung 9: Generierte Testfallliste mit Kombinatorik Combinatorial

Für die Definition einer Testfallliste im Testtabelleneditor werden alle Sprachkombinationen bzw. –übergänge unterstützt, die unter Sprachinteraktion aufgeführt sind.



2.6 Traceability durch die Anbindung von REQM/TDM-Systemen

Konzept Mit vTESTstudio können Sie extern definierte Anforderungen und Testbeschreibungen in der Testimplementierung und im Testreport nachverfolgen (Traceability). Dies geschieht über Austauschdateien in offengelegtem XML-Format. Damit können beliebige REQM/TDM-Systeme mit vTESTstudio gekoppelt eingesetzt werden.

Schema

Abbildung 10: Traceability Workflow



Trace Item Explorer Alle in ein vTESTstudio Projekt importierten Trace Items stehen über den Trace Item Explorer zur Verfügung. Von dort können sie bequem per Drag & Drop mit Testfällen verlinkt werden.

Im REQM/TDM-System können Anforderungen und Testbeschreibungen in hierarchischen Ordnern oder vergleichbaren Elementen strukturiert sein. Diese Ordner werden im Trace Item Explorer in gleicher hierarchischer Darstellung angezeigt. Ordner können jedoch nicht direkt mit Testfällen verknüpft werden.

Traceability Matrix Die Traceability Matrix in vTESTstudio gibt einen Überblick über alle im Projekt verfügbaren Trace Items und deren Testfall-Verlinkungen. Mit Hilfe dieser Übersicht zur Testdesign-Abdeckung ist z.B. einfach erkennbar, für welche Trace Items noch keine Testfallimplementierung existiert. Aus der Traceability Matrix kann außerdem bequem von einem Trace Item zu den verlinkten Testfällen navigiert werden. Für Dokumentationszwecken kann die Traceability Matrix nach Excel exportiert werden.

Abbildung 11: Traceability Matrix

Import der Design-Traceability ins REQM/TDM-System

Zur Synchronisation mit dem REQM/TDM-System ist ein Export der Traceability Matrix nach XML möglich. Damit können Informationen über implementierte Testfälle und verlinkte Requirements oder Testbeschreibungen ins REQM/TDM-System importiert werden.

Planung der Testausführung

Basierend auf diesen Informationen kann eine Testausführungsplanung stattfinden, d.h. welche Testfälle sollen ausgeführt werden. Mithilfe eines sogenannten Testausführungsplans kann die Auswahl und Ausführung der Testfälle in CANoe automatisiert werden.

Testreport Für jedes Trace Item, das mit einem Testfall verlinkt ist, enthält der Testreport eine

Import von Requirements oder Testbeschreibungen in vTESTstudio

Die aus dem REQM/TDM-System exportierten Informationen werden in vTESTstudio importiert und können dort mit Testfällen verlinkt werden. Die verknüpften Elemente können Anforderungen oder Testbeschreibungen sein. Da diese Elemente der Traceability dienen, werden sie als Trace Items bezeichnet.



entsprechende Referenz am Testfall. Somit ist Traceability möglich vom Testfallergebnis zurück zur Anforderung bzw. Testbeschreibung.

Import der Testergebnisse ins REQM/TDM-System

Der Testreport kann ins REQM/TDM-System zurückgespielt werden, um die Testergebnisse dort für Auswertungen verfügbar zu haben.

Unterstützte REQM/TDM-Systeme

Eine out-of-the-box Anbindung existiert für IBM DOORS (classic), IBM DOOR NG und Rational Quality Manager, Siemens Polarion ALM sowie PTC Integrity. Dafür sind sogenannte „Connection Utilities“ kostenfrei erhältlich. Durch eine Kommandozeilen-API können diese auch für „Continuous Integration“ und „Continuous Testing“ genutzt werden (z.B. mittels Jenkins).

Weitere REQM/TDM Systeme können über die offenen Schnittstellen angebunden werden.



2.7 Testdesign-Dokumentation

Konzept Aus einem vTESTstudio Projekt kann automatisch eine Testdesign-Dokumentation in PDF-Format erstellt werden. Diese enthält eine Übersicht über alle implementierten Testfälle und Testschritte. Neben der Dokumentation dient sie internen und externen Reviews des Testdesigns.

Abbildung 12: Automatisch erstellte Testdesign-Dokumentation

Konzepthandbuch vTESTstudio Testdesign-Editoren


3 Testdesign-Editoren


3.1 CAPL-Editor Seite 24

3.2 C#-Editor Seite 25

3.3 Testtabelleneditor Seite 26

3.4 Testdiagrammeditor Seite 27

3.5 Zustandsdiagrammeditor Seite 28



3.1 CAPL-Editor

Funktionen Der im vTESTstudio integrierte CAPL-Editor bietet die Funktionen einer modernen Entwicklungsumgebung, wie

> Code-Ergänzung und Syntaxprüfung während des Schreibens

> Konfigurierbares Syntax-Highlighting

> Syntaxsensitive Einrückung

> Einklappbare Funktionsblöcke und Funktionsreferenz in einer Baumstruktur zur schnelleren Navigation

> Hierarchische Funktionsliste mit Suchfunktion zur direkten Übernahme in den Quelltext

> Direkte Übernahme von Netzwerksymbolen, Umgebungsdaten, Diagnosesymbolen und Parametern aus dem Symbol Explorer

Oberfläche

Abbildung 13: CAPL-Editor

Zugriff auf Symbole Der Zugriff auf Signale, Botschaften und Umgebungsdaten ist direkt über die CAPL API möglich. Damit können z.B. Signalwerte in der CANoe Laufzeitumgebung gelesen und geschrieben werden. Beispiel:

$Velocity = 100;

Ereignisprozeduren Neben der Programmierung von sequentiellen Testabläufen, Testfällen und Funktionen ist auch die Programmierung von Ereignisprozeduren möglich. Um auf Ereignisse in CANoe zu reagieren (z.B. eine Signaländerung), können entsprechende Event-Handler definiert werden. Die Methoden werden dann aufgerufen, wenn das Ereignis während des Tests eintritt.



3.2 C#-Editor

Funktionen Der im vTESTstudio integrierte C#-Editor bietet – analog zum CAPL-Editor – die Funktionen einer modernen Entwicklungsumgebung, wie

> Code-Ergänzung und Syntaxprüfung während des Schreibens

> Konfigurierbares Syntax-Highlighting

> Syntaxsensitive Einrückung

> Einklappbare Funktionsblöcke


Oberfläche

Abbildung 14: C#-Editor

Zugriff auf Symbole Für den Zugriff auf Signale und Umgebungsdaten sowie CAN-Frames stehen automatisch generierte .NET Klassen zur Verfügung, mit denen auf die Werte in der CANoe Laufzeitumgebung zugegriffen werden kann. Beispiel:

Velocity.Value = 100;

Ereignisprozeduren Neben der Programmierung von sequentiellen Testabläufen, Testfällen und Funktionen ist auch mit dem C#-Editor die Programmierung von Ereignisprozeduren möglich. Um auf Ereignisse in CANoe zu reagieren (z.B. eine Signaländerung), werden Methoden mit einem speziellen Attribut versehen. Die Methoden werden dann aufgerufen, wenn das Ereignis während des Tests eintritt (genau wie in CAPL).

Anbindung an MS Visual Studio

Alternativ zum C#-Editor in vTESTstudio kann über eine integrierte Anbindung auch Microsoft Visual Studio zur Entwicklung von Tests in C# verwendet werden.



3.3 Testtabelleneditor

Überblick Mit dem Testtabelleneditor können Testabläufe einfach in tabellarischer Form definiert werden, ohne dass Programmierkenntnisse benötigt werden. Es stehen dafür spezielle Kommandos für die Stimulation und Prüfung des „System under Test“ zur Verfügung.

Funktionen Für ein komfortables Arbeiten stehen u.a. folgende Funktionen zur Verfügung:

> Kommando- und Symbol-Ergänzung während des Schreibens


> Symbol und Wertetyp-Prüfungen während des Editierens

> Zugriff auf benutzerdefinierte Funktionen und Testfälle in anderen Sprachen

> Einfache Bedienung sowohl mit der Tastatur als auch mit der Maus möglich

Oberfläche

Abbildung 15: Testtabelleneditor



3.4 Testdiagrammeditor

Einsatzbereich Mit dem Testdiagrammeditor können Tests in grafischer Form notiert werden. Die grafische Notation eignet sich insbesondere auch gut für Reviews. Hinter den grafischen Elementen befindet sich jeweils Test-Code in tabellarischer Notation. Standardmäßig wird für jeden Pfad im Diagramm ein Testfall generiert, feiner granulare Testfalldefinitionen sind ebenfalls möglich.

Funktionen Ein komfortables Arbeiten mit dem Testdiagramm ist u.a. durch folgende Funktionen gegeben:

> Einfacher Aufbau des Diagramms per Drag & Drop von grafischen Elementen in die Grafikoberfläche





> Nutzung und Wiederverwendung von Sub-Diagrammen möglich

> Tabellarische Darstellung bzw. Vorschau der generierten Testfälle und ihrer Inhalte

Oberfläche

Abbildung 16: Testdiagrammeditor

Hinweis: Der Testdiagrammeditor ist nur mit der Option Graphical Test Design verfügbar.



3.5 Zustandsdiagrammeditor

Einsatzbereich Mit dem Zustandsdiagrammeditor kann das erwartete Verhalten des zu testenden Systems als Zustandsmodell beschrieben werden. Hinter den grafischen Elementen befindet sich jeweils Test-Code in tabellarischer Notation. Basierend auf Transitions-Abdeckung werden aus dem Zustandsmodell automatisch Testfälle generiert. Dabei kann zwischen verschiedenen Algorithmen wie dem „Chinese Postman“-Algorithmus und einem auf Breitensuche basierenden Algorithmus gewählt werden.

Funktionen Ein komfortables Arbeiten mit dem Zustandsdiagramm ist u.a. durch folgende Funktionen gegeben:

> Einfacher Aufbau des Diagramms per Drag & Drop von grafischen Elementen in die Grafikoberfläche





> Tabellarische Darstellung bzw. Vorschau der generierten Testfälle und ihrer Inhalte

Oberfläche

Abbildung 17: Zustandsdiagrammeditor

Hinweis: Der Zustandsdiagrammeditor ist nur mit der Option Graphical Test Design verfügbar.

Konzepthandbuch vTESTstudio Interaktion mit CANoe


4 Interaktion mit CANoe


4.1 CANoe Systemumgebung Seite 30

4.2 Ausführung in CANoe Seite 32

4.3 Reporting Seite 34



4.1 CANoe Systemumgebung

Zugriffsmöglichkeiten Die Integration der Beschreibungsdateien für die Systemumgebung (Datenbanken, Diagnosebeschreibungen, …) ermöglicht einen direkten und einfachen Zugriff auf Symbole der CANoe Systemumgebung. Die in der Systemumgebung enthaltenen Datenbanksymbole, Systemvariablen usw. stehen für eine Nutzung in der Testcodierung zur Verfügung. Es gibt zwei verschiedene Verfahren, um die Symbole in die Testabläufe einzufügen: Entweder per Text-Ergänzung in den einzelnen Editoren oder per Drag & Drop aus dem Symbol Explorer.

Abbildung 18: Symbol-Ergänzung in den Programmiereditoren

Abbildung 19: Symbol-Ergänzung im Testtabelleneditor



Abbildung 20: Symbol Explorer für Drag & Drop von Symbolen



4.2 Ausführung in CANoe

Test Unit erstellen In vTESTstudio kann eine ausführbare Test Unit erstellt werden. Eine ausführbare Test Unit hat die Dateiendung *.VTUEXE und beinhaltet alle Daten, die für den Test notwendig sind (Quelldateien, Parameterdateien,…).

Konfiguration und Ausführung in CANoe

Die ausführbare Test Unit kann in CANoe konfiguriert und ausgeführt werden.

Für die Ausführung in CANoe können in der CANoe Konfiguration beliebig viele Testkonfigurationen angelegt werden. Eine Testkonfiguration wiederum kann beliebig viele ausführbare Test Units beinhalten, die sequentiell hintereinander ablaufen.

Abbildung 21: Testausführung in CANoe



Test-Trace-Fenster Details zum Testablauf sind bereits während der Testausführung im Test-Trace-Fenster sichtbar.

Abbildung 22: Test-Trace-Fenster in CANoe

Debugging CANoe unterstützt zudem das Debuggen von in Test Units enthaltenem CAPL- und C#-Code.



4.3 Reporting

CANoe Test Report Viewer

Während der Testausführung einer Test Unit in CANoe wird automatisch ein ausführliches Testprotokoll erstellt. Der CANoe Test Report Viewer ermöglicht mit diversen Filter- und Gruppierungsfunktionen sowie anwenderdefinierten Abfragen eine komfortable und umfassende Analyse dieses Testprotokolls.

Abbildung 23: CANoe Test Report Viewer

Konzepthandbuch vTESTstudio Sprachinteraktion


5 Sprachinteraktion


5.1 Schnittstellenfunktionen Seite 36



5.1 Schnittstellenfunktionen

Überblick Mit Hilfe sogenannter Schnittstellenfunktionen können Funktionen einer Sprache in einer anderen verwendet werden. Eine Schnittstellenfunktion kann ein Testfall, eine Testsequenz, eine Testfunktion oder auch eine einfache Funktion sein. Im Unterschied zu einer Testfunktion wird eine einfache Funktion im Report nicht als Block dargestellt.

Definition Eine Schnittstellenfunktion kann in den einzelnen Sprachen wie folgt definiert werden:

> C#: Attribut [Export] an Testfällen, Testsequenzen, Testfunktionen oder einfachen Funktionen.

> CAPL: Schlüsselwort export vor Testfällen, Testsequenzen, Testfunktionen oder Funktionen.

> Testtabelleneditor: Einstellung Export an Testfällen, Testsequenzen oder Funktionen, die in der Ansicht für Funktionen definiert sind.

Alle Schnittstellenfunktionen, die innerhalb einer Test Unit verfügbar sind, werden in einem Explorer dargestellt.

Explorer

Abbildung 24: Explorer für Schnittstellenfunktionen

Aus diesem Explorer können die Funktionen über Drag & Drop in die einzelnen Editoren eingefügt werden. Alternativ können sie mit Hilfe der Text-Ergänzung in den Editoren eingefügt werden.



Sprachenübergänge Folgende Sprachenübergänge werden unterstützt:

Aufrufende Sprache

Definierende Sprache

CAPL C# Testtabelle Testsequenz-

diagramm Zustands-diagramm

CAPL — — — — —

C# ● ● — — —

Testtabelle ● ● ● — —

Testsequenzdiagramm ● ● ● — —

Zustandsdiagramm ● ● ● — —

Konzepthandbuch vTESTstudio Parameter, Kurven und Varianten


6 Parameter, Kurven und Varianten


6.1 Parameter Seite 40

Konzept

Testfalldatenfindung mit der Klassifikationsbaum-Methode

6.2 Kurven Seite 42

6.3 Varianten Seite 44 Seite 44



6.1 Parameter

6.1.1 Konzept

Definition Unter dem Begriff „Parameter“ sind beliebige konstante Werte zu verstehen, auf die im Testablauf aus allen Implementierungssprachen zugegriffen werden kann. Beispiele für Parameter: Konfigurationsgrößen für ein Steuergerät, Testvektoren, Toleranzen, …

Parameter werden in separaten Dateien definiert und gepflegt. Verfügbare Parameter werden im Symbol Explorer unter Parameter angezeigt.

Arten Es gibt verschiedene Arten von Parametern:

> (Skalarer) Parameter: Ein skalarer Parameter stellt genau einen konstanten Wert da, auf den im Testablauf zugegriffen werden kann.

Beispiel:

Name Wert

CycleTimeTolerance 50

> (Skalarer) Listenparameter: Ein Listenparameter hat 1…n Werte für dieselbe Größe. Im Testablauf kann über alle Werte der Liste iteriert werden, zum Beispiel um einen Test unter verschiedenen Temperaturwerten durchzuführen.

Beispiel:

Name Wert

OutsideTemperature -40, -10, 0, 15, 30, 50

> Struct-Parameter: Ein Struct-Parameter stellt eine Menge von zusammengehörigen (skalaren) Werten dar. Im Testablauf kann auf die Einzelwerte eines Structs zugegriffen werden, zum Beispiel um einen Testvektor (stimulierende und erwartete Werte) auf das Testsystem aufzuprägen.

Beispiel:

Struct Member Wert

LockingTestVector Velocity

CrashDetected

Wait

LockState

60

0

500

1



> Struct-Listenparameter: Ein Struct-Listenparameter entspricht einer Liste von Werte-Tupeln für ein Struct. Im Testablauf kann über alle Listenelemente iteriert werden, um zum Beispiel verschiedene Ausprägungen eines Testvektors auf das System aufzuprägen.

Beispiel:

Struct Member / Wert

LockingTestVectorList Velocity CrashDetected Wait LockState

60 0 500 1

40 0 500 0

60 1 250 0

Hierarchische Struktur

Parameterdefinitionen können mit Hilfe von Namensräumen hierarchisch strukturiert werden.

6.1.2 Testfalldatenfindung mit der Klassifikationsbaum-Methode

Klassifikationsbaum-Methode

Durch einen integrierten Editor für die Klassifikationsbaum-Methode können Testfalldaten in Form von Testvektoren definiert werden. Die grafische Oberfläche unterstützt das Finden der relevanten Eingangsdaten für einen Test. Die automatische oder manuelle Kombination aller entscheidenden Eingangswerte ermöglicht es, effizient die minimale Anzahl an notwendigen Testvektoren zu definieren.

Grenzwert-Analyse Eine dedizierte Unterstützung von Grenzwerten ermöglicht das gezielte Testen in kritischen Bereichen der Eingangsdaten.

Oberfläche

Abbildung 25: Definition von Testvektoren mit dem Editor für die Klassifikationsbaum-Methode

Parametrierung von Testfalllisten mit Testvektoren

Die Testvektoren können in den implementierten Testfällen verwendet werden, z.B. zur Parametrierung von Testfalllisten im Testtabelleneditor (siehe Abschnitt Konzepte für eine hohe Testabdeckung).



Abbildung 26: Verwendung von Testvektoren zur Parametrierung einer Testfallliste im Testtabelleneditor

6.2 Kurven

Stimulationskurven Mit Hilfe des sogenannten Waveform-Editors können Kurven zur Stimulation des „System under Test“ definiert werden. Vordefinierte Segmenttypen (Sinus, Puls, …) ermöglichen dabei das einfache Erstellen von z.B. Spannungsverläufen, die in der Norm LV124 für Steuergerätetests definiert sind.

Mehrere Kurvenverläufe können im selben Editor komfortabel synchronisiert werden.

Abbildung 27: Definition von Stimulationskurven mit dem Waveform-Editor

Synchronisierte Prüfpunkte

Über die Definition von Prüfpunkten an einer Stimulationskurve können Reaktionen des „System under Test“ auf die Stimulation synchron geprüft werden.



6.3 Varianten

Varianten- eigenschaften

Mit Hilfe von sogenannten Varianteneigenschaften können sowohl Steuergeräte- als auch Testvarianten realisiert werden.

Beispiele:

Varianteneigenschaft Mögliche Werte

Region US, Europe, Asia

Coverage full, low, medium

Model OEM1, OEM2

Zugriffsmöglichkeiten Varianteneigenschaften können sowohl zur bedingten Testcodierung, als auch zum Zugriff auf variantenabhängige Parameterwerte und zur Definition variantenabhängiger Testfälle oder ganzer Testgruppen verwendet werden.

Zugriff auf Varianten- eigenschaften in CAPL

if (varprop::Region == varprop::Region::US)

{

// ...

}

Parameterwert abhängig von einer Varianteneigenschaft

Abbildung 28: Parameterwert abhängig von einer Varianteneigenschaft

Variantenabhängige Testfälle

Abbildung 29: Variantenabhängige Testfälle

Übernahme Über den Symbol Explorer und die Text-Vervollständigung können Varianteneigenschaften einfach in den Test-Code übernommen werden.



Varianten- eigenschaften im Symbol Explorer

Abbildung 30: Varianteneigenschaften im Symbol Explorer

Der Wert einer Varianteneigenschaft wird entweder bereits zur Designzeit in vTESTstudio festgelegt oder ist noch in CANoe bis unmittelbar vor Teststart einstellbar.

Varianteneigenschaften können voneinander abhängig sein, d.h. der Wert einer Varianteneigenschaft (z.B. Region) kann den Wert einer anderen

Varianteneigenschaft (z.B. Model) festlegen.

Konzepthandbuch vTESTstudio Anwendungsbeispiele


7 Anwendungsbeispiele


7.1 Erzeugen zweier ähnlicher Test Units für unterschiedliche OEMs Seite 48



7.1 Erzeugen zweier ähnlicher Test Units für unterschiedliche OEMs

Aufbau Für den Test des Steuergeräts DoorControlUnit gibt es ein vTESTstudio Projekt. Dieses besteht aus zwei Test Units – einer für OEM1 und einer für OEM2. Die eigentliche Ablauflogik ist für beide OEMs dieselbe. Sie ist umgesetzt in einer Testtabelle Main.vtt und wird in beiden Test Units verwendet, d.h. verlinkt. Zur Verlinkung von Dateien in Test Units, siehe auch Wiederverwendung von Dateien.

Abbildung 31: Verwendung von Testlogik in beiden Test Units

Im Test wird auf verschiedene Toleranzwerte zugegriffen. Diese sind abhängig vom OEM. Dafür wird eine Varianteneigenschaft OEM deklariert mit den möglichen Werten OEM1 und OEM2.

Abbildung 32: Definition der Varianteneigenschaft OEM



Die Toleranzen selbst werden in einer Parameterdatei definiert. Die konkreten Werte werden dabei abhängig von der Varianteneigenschaft OEM angegeben.

Abbildung 33: Parameter mit variantenabhängigen Werten

Die Parameterdatei wird ebenfalls in beiden Test Units verwendet.

Abbildung 34: Verwendung von Parameterdatei in beiden Test Units

Damit während der Testausführung der richtige Parameterwert verwendet wird, muss nun lediglich noch im Konfigurationsdialog der Test Units jeweils der korrekt der Wert der Varianteneigenschaft OEM gesetzt werden.

Abbildung 35: Definition des Wertes für die Varianteneigenschaft für die Test Unit LockingTests_OEM1

Neben den OEM-abhängigen Parameterwerten soll zusätzlich eine OEM-abhängige Testfunktion verwendet werden. Dafür wird in der Testtabelle eine C#-Funktion aufgerufen:

Abbildung 36: Aufruf einer C# Funktion in der Testtabelle



Die Implementierung der Funktion findet in zwei C#-Dateien statt: die eine enthält die Implementierung für OEM1, die andere die für OEM2:

Abbildung 37: C#-Datei mit OEM1-spezifischer Implementierung für TestLockByVelocity

Abbildung 38: C#-Datei mit OEM2-spezifischer Implementierung für TestLockByVelocity

Die Datei für OEM1 wird in die erste Test Unit eingehängt, die Datei für OEM2 in die zweite:

Abbildung 39: Verwendung unterschiedlicher C#-Dateien für variantenabhängigen Implementierungen

Mehr Informationen

> News

> Produkte

> Demo-Software

> Support

> Seminare und Workshops

> Adressen

www.vector.com

http://www.vector-worldwide.com/

vteststudio - konzepthandbuch · dateien, c#-dateien, testtabellen, testdiagramme und...

Documents