Lade Inhalt...

Ansatz zur Testfallerstellung bei der Test Automatisierung für Abnahmetestfälle in der Automobileindustrie

Ausarbeitung 2012 10 Seiten

Informatik - Angewandte Informatik

Leseprobe

Inhaltsverzeichnis

1. Einleitung

2. Softwaretest

3. Der Ansatz für die Erstellung der Abnahmetestfälle

4. Quellen

1. Einleitung

Eine komplette Eigenentwicklung von Fahrzeugssoftware durch einen Hersteller (OEM) ist heute zu tage aufgrund hohe Anforderungen fast unmöglich. Bei der Entwicklung werden verschiedene Know-how-Träger benötigt, das erschwert die Aufgabe der Koordination und Integration der Software-Module auf dem Steuergerät im Fahrzeug. Darüber hinaus sind die hohen Anforderungen an die Korrektheit der Software zu beachten.

Dies wird in der Studie HAWK (Herausforderung Automobile Wertschöpfungskette) bestätigt. In der Studie werden weitreichende Änderungen in der Wertschöpfungsarchitektur im Automobilbau prognostiziert. Zulieferer als Know-how-Träger weiten ihren Anteil aus. Der Hersteller-Anteil soll bis 2015 um fast ein Drittel auf dann noch 25 Prozent sinken1.

Die Abhängigkeit der OEMs von mehreren Zulieferern erhöht die Testkomplexität. Bevor die OEMs die SW-Module verschiedener Zulieferern auf Software in the Loop Ebene (SiL- Ebene) integrieren oder auf Hardware in the Loop Prüfstände (HiL- Prüfstände) testen, müssen die einzelne Module abgenommen werden. Die OEMs konzentrieren sich dann zum einen auf die Abnahme- und Systemtest der Software-Module verschiedener Zulieferer und deren Integration und zum anderen auf die Integration des gelieferten Steuergerätes im Gesamtfahrzeug. Eingebettete Systeme werden verstärkt zum integralen Bestandteil sicherheitskritischer Anwendungen. Sie übernehmen die Steuerung und Regelung komplexer interner Abläufe und/oder interagieren mit der Umgebung. Zudem übernehmen diese Geräte die Aufgabe der Vernetzung verteilter und gleichzeitig ablaufender Prozesse zwischen Sender und Empfänger, was neue Fehlerarten mit sich bringen kann. Der Fehleranteil der Software im Medizinbereich oder im Automobilbereich liegt heute bei ca. 20 Prozent, so dass Qualitätssicherung eine hohe Bedeutung erhält. Das Testen ist eine der wichtigsten Säulen der Qualitätssicherung. Mit einem Test wird geprüft, ob das System entsprechend den Anforderungen implementiert wurde. Verschiedene Teststrategien und Konzepte sind notwendig, um eine akzeptable Testabdeckung bzgl. der Kundenanforderungen, der Normen und gesetzlichen Anforderungen zu erreichen.

2. Softwaretest

Voraussetzung des Softwaretestbegriffs ist der Begriff des Fehlers in Softwaresystemen. Ein Fehler ist die Nichterfüllung einer festgelegten Anforderung an das Softwaresystem. Es liegt eine Abweichung zwischen dem Ist-Verhalten und dem Soll-Verhalten vor. Das Ist-Verhalten wird während des Betriebs des Softwaresystems festgestellt. Das Soll-Verhalten wird in der Spezifikation der Testaufgaben fest verankert. Fehler in Softwaresystemen entstehen im Gegensatz zu jenen in physikalischen Systemen nicht durch Verschleiß oder Alterung, sondern während der Entwicklung der Software. Die Fehler bleiben erhalten und kommen bei der Ausführung des Systems zum Tragen. Das Testen hat die Aufgabe, Risiken beim Einsatz der Software zu verringern. Das geschieht dadurch, dass beim Testen möglichst alle Fehler aufgedeckt werden.2

Das Ziel des Testens ist die Qualitätsverbesserung durch Beheben eines Fehlerzustands. Testen erfolgt durch das Ausführen eines Programms im Steuergerät. Man braucht dafür einen Testfall und einen Testplan. Ein Testfall hat die Aufgabe festzulegen, welche Eingaben in das Programm gemacht werden und was das Ergebnis sein soll. Man braucht viele Testfälle, um das gesamte Programm im Steuergerät abzudecken.3 Testplan oder auch Testkonzept werden meistens nach der Norm IEEE 829 aufgestellt.4 Der Inhalt eines Testkonzepts nach IEEE 829 besteht aus folgenden Punkten:5

Testkonzeptbezeichnung

Das Testkonzept muss gekennzeichnet werden, um sicherzustellen, dass das Dokument gegenüber anderen Dokumenten klar erkennbar ist. Die Benennung der Dokumente ist in jeder Firma archiviert und gemäß Maßgaben und Regeln festgelegt. Das Dokument muss im Dokumentmanagementsystem abgelegt sein und mindestens Dokumentname, Version und Freigabestatus enthalten.

Einführung

In der Einführung sind Projekt und Hintergründe kurz beschrieben. Die Projektbeteiligten (Kunde, Tester, Testmanager und weitere Rollen) sind dargestellt. Referenzen auf weitere Dokumente, Normen, Standards und Unternehmensregeln müssen enthalten sein.

Testobjekte

Hier sollten die zu testenden Softwarekomponenten und Teile des Systems, die nicht getestet werden, kurz dargestellt sein.

Zu testende Leistungsmerkmale:

Dieses Unterkapitel des Testkonzepts berücksichtigt Funktionen und Eigenschaften, die getestet werden soll. Der Verweis auf die Testspezifikation und die Teststufen muss enthalten sein.

Leistungsmerkmale, die nicht getestet werden:

Die Aspekte in der Software, die nicht getestet werden sollen, müssen hier aufgeführt werden, um unberechtigten Erwartungen vorzubeugen.

Teststrategie

Die Testziele werden auf Basis einer Risikoanalyse definiert. Testmethoden und notwendige Automatisierungen der Testaufgaben werden festgelegt, die ausgewählten Strategien auf vorhandene Ressourcen geprüft und identifizierte Risiken abgewogen.

Abnahmekriterien

Das Entwicklungsteam muss anhand der durchgeführten Tests entscheiden, ob die implementierte Software an den Kunden geliefert werden soll oder nicht. Eine kurze Ansage, dass die Software fehlerfrei ist, reicht hierbei nicht aus. Kriterien wie „Anzahl der gefundenen Fehler“, „Schweregrad der gefundenen Fehler“ und „Entstandene Kosten“ werden hier herangezogen.

Kriterien für Testabbruch und Testfortsetzung

Es kann vorkommen, dass die Software bei den ersten Tests so schlecht abschneidet, dass weitere Tests sinnlos erscheinen. An dieser Stelle muss überlegt werden, welche Kriterien ausgewählt werden, um Testabläufe zum Abbruch zu bringen.

Testdokumentation

Hier wird entschieden, wann und welche Testdokumente und Ergebnisse an wen kommuniziert werden müssen.

Testaufgaben

Die Zuordnung der Verantwortlichkeiten sowie die Planung und Durchführung der Testaktivitäten werden festgelegt.

Testinfrastruktur

Testwerkzeuge, Arbeitsmittel und Testinfrastruktur müssen aufgelistet werden. Wenn für die Testautomatisierung besondere Werkzeuge und Mittel benötigt werden, müssen diese aufgelistet sein.

Verantwortlichkeiten/Zust ä ndigkeiten

Die organisatorische Einbindung des Testpersonals in das Projekt und die Aufteilung in verschiedene Testgruppen und Teststufen muss geplant werden.

Personal, Einarbeitung, Ausbildung

Die Ressourcen werden geplant. Die Personalausstattung und die Qualifikation werden bestimmt und das Administrationspersonal wird eingewiesen.

Zeitplan/Arbeitsplan

Die Testaktivitäten werden mit Meilensteinen geplant und an den Projektmanager kommuniziert.

Genehmigung/Freigabe

Die Organisationseinheiten, die das Testkonzept genehmigen müssen, werden aufgelistet. Die Zustimmung erfolgt durch die Unterschrift der Führungsebene einer Organisationseinheit.

Glossar

Im Testbereich werden viele verschiedene Begriffe genutzt. Diese sollten in einem Glossar erfasst sein. Im Projekt sollten immer die Test-Fachbegriffe verwendet werden, um unterschiedliche Interpretationen für einen Fachbegriff zu vermeiden.

Die Einordnung der Testaktivitäten in Softwareentwicklungsprozesse wird anhand des V-Modells des Bundes dargestellt (siehe Abbildung 1). Die Grundidee des V- Modells ist, dass Testaktivitäten und Entwicklungsaktivitäten zueinander korrespondierende, gleichberechtigte Tätigkeiten sind.6 Der linke Ast veranschaulicht die Entwicklungsschritte. Über die Kundenwünsche werden die Anforderungen entworfen, spezifiziert und dann implementiert. Der rechte Ast steht für Integrationsund Testarbeiten. Der Verlauf beschreibt die Integration und den Test der Bausteine sukzessiv zum Wachsen des Gesamtsystems. Der linke Ast erfasst die Verifikationen nach jedem fertigen Schritt. Parallel dazu validiert der Tester, ob ein Teilprodukt eine festgelegte spezifizierte Aufgabe tatsächlich löst.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: V-Modell des Bundes und Testaktivitäten7

Die Kernaufgabe der Abnahme-Testfälle für die SW-Module verschiedener Zulieferer ist zu prüfen, ob sie für die nächsten Teststufen im linken Ast des V-Modells also Sil-Integration und HiL-Tests ausgereift sind oder nicht. Da SiL-Integration. HiL Tests oder sogar Systemtest viel Aufwand und Kosten mit sich bringen, ist die Reife der SW-Module von großer Bedeutung. Es ist an der Stelle Notwendig die SW-Module abzunehmen, um ihre Eignung für die weiteren Teststufen im rechten Ast des V-Modells zu überprüfen. Um diesem Problem entgegen zu wirken, werden Ansätze benötigt, die die speziellen Anforderungen von Steuergerätesoftware in der Automobileindustrie berücksichtigen und zum anderen die Abnahme der Softwaremodule erleichtert. In diesem Beitrag wird einen Ansatz zur Abnahme von Software-Module dargestellt. Der Ansatz betrachtet die manuelle Testfallerstellung, um Abnahmetestfälle für OEMs aus den Anforderungen abzuleiten.

3. Der Ansatz für die Erstellung der Abnahmetestfälle

Der Ansatz beruht auf die Integration der Testfallerstellungsmethode „Klassifikationsbaummethode“ und das „Design by Contract“ Konzept (DBC). Das DBC basiert auf die Definition von Annahmen (Assumptions) und Versprechungen (Promises) für jedes Softwaremodul. Das bedeutet, dass jedes Software-Modul einen Vertrag mit anderen Modulen abschließt. In diesem Vertrag nimmt das Modul etwas an und verspricht anderen Modulen etwas zur Verfügung zustellen, wenn seine Annahme erfüllt wird8. Im Gegensatz dazu startet die Klassifikationsbaummethode mit der Analyse der funktionalen Spezifikation. Das Ziel ist dabei, die so genannten testrelevanten Aspekte der Anforderungen zu erkennen. Durch sinnvolle Auswahl der Werte, die diese Aspekte annehmen können, verspricht man sich unterschiedlich relevante Testfälle. Diese Aufteilung in verschiedene Aspekte, die im Folgenden separat verfeinert werden können, reduziert die Komplexität des ursprünglichen Testproblems erheblich9.

In dem Ansatz wird DBC zur Auswahl der testrelevanten Aspekte und Kategorien in der Klassifikationsbaummethode herangezogen. Es werden im Klassifikationsbaum keine funktionalen Kategorien, sondern die durch das DBC definierte Verträge betrachtet. Die Zerteilung des Klassifikationsbaumes in Aspekte wird durch DBC- Verträge ersetzt. Die Verträge werden in Assumptions (Annahmen) und Promises (Versprechungen) unterteilt. Dabei muss der Testfallersteller immer an den Vertrag denken, der ein Software-Module mit den anderen Modulen im gesamten Architektur des Steuergerätesoftware abschließen kann.

Diese Aufteilung des Baumes in verschiedene Verträge, die separat in Äquivalenzklassen verfeinert werden können, reduziert die Komplexität des ursprünglichen Testproblems beachtlich. Ein Vertrag bietet durch die Annahmen die benötigten Testdaten, die Versprechung auf der anderen Seite stellt das Sollverhalten dar. Dennoch bietet diese Denkart und Weise eine Vereinfachung im Vergleich des ursprünglichen Ansatz der Klassifikationsbaummethode, da die Methode eine Zerteilung des Baumes in Aspekte vorschreibt, ohne dabei konkrete Herangehensweise bei der Auswahl und Ableitung der Aspekte vorzuschlagen.

Dieser Ansatz ermöglicht die Erstellung aller notwendigen Testfälle, die zur Abnahme eines korrekten, integrierbaren und funktionierenden Software-Moduls benötigt werden, wenn alle Annahmen und ihre Versprechungen des Software-Moduls betrachtet werden. Er ist unabhängig von den eingesetzten Teststufen und kann beispielsweise für Abnahmetests auf SiL-(Software in the Loop), HiL-(Hardware in the Loop) oder Gesamtsystemebene angewendet werden. Für die Evaluierung des Ansatzes kann der Klassifikationsbaum-Editor CTE/XL verwendet werden10 und im Rahmen eines Projektes angewendet werden.

Der vorgestellte Ansatz gehört zur Kategorie des funktionsorientierten Testens. Durch die Verwendung des formalen Ansatz „DBC“ und die Klassifikationsbaummethode erfüllt der Ansatz die Anforderungen von den Qualitätssicherungsnormen und Standards, die im Rahmen des Testens von Software in sicherheitskritischen Anwendungen wie die Automobilindustrie, existieren. Der eingesetzte funktionsorientierte Ansatz ist für die Erstellung der Abnahmetestfälle geeignet. Der Ansatz lässt sich reibungslos in der Abnahmephase von Software-Module im Entwicklungsprozess einfügen.

Der Ansatz unterstützt nicht nur OEM bei der Abnahme von Software-Module, sondern bietet eine einfache Vorgehensweise für den Tester bei seiner Aufgabe, aus Lastenhefte Abnahmetestfälle zu erstellen. Die Vorteile, die dem Ansatz gegenüber andere in der Industrie herrschende Testverfahren und Ansätze unterscheidet, sind folgende:

- Einfache Methode und intuitive Testfallerstellungsansatz
- Konzentration auf die Abnahmetestfälle
- Frühe Erkennung von konsistente und widerspruchsfreie Anforderungen
- Reduzierung des Testproblems
- Verwendung von formalen Methoden bei der Testfallerstellung
- Vereinfachung der Ableitung von Testfällen aus dem Lastenheft
- Verwendung von schon auf dem Markt etablierte Testwerkzeuge
- Frühe Erkennung von Architektur und Spezifikationsfehler
- Wiederverwendung von erstellten Testfälle

4. Quellen

[1]: http://www.automobil-produktion.de/themen/02430/index.php

[2]: http://de.wikipedia.org/wiki/Design_by_contract

[3]: Schneider, Kurt (2007): Abenteuer Software Qualität, dpunkt-Verlag, Heidelberg

[4]: http://www.systematic-testing.com

[5]: Spillner, Andreas; Linz, Tilo (2006): Basiswissen Softwaretest, dpunkt.verlag.

[...]


1 Vgl. http://www.automobil-produktion.de/themen/02430/index.php

2 Vgl. Andreas/Tilo (2006), S. 7.

3 Vgl. Kurt (2007), S. 83.

4 Vgl. Andreas/Tilo (2006), S. 223.

5 Vgl. Andreas/Tilo (2006), S. 223.

6 Vgl. Andreas/Tilo (2006), S. 39.

7 Vgl. Andreas/Tilo (2006), S. 40.

8 Vgl. http://de.wikipedia.org/wiki/Design_by_contract

9 Vgl. Schneider, Kurt (2007)

10 Vgl. http://www.systematic-testing.com

Details

Seiten
10
Jahr
2012
ISBN (Buch)
9783656820420
Dateigröße
444 KB
Sprache
Deutsch
Katalognummer
v202909
Institution / Hochschule
Hochschule für Wirtschaft und Recht Berlin – IMB
Note
Schlagworte
Softwaretest Testspezifikation Abhängigkeit der OEMs von Zulieferer Testmethoden und Konzepte

Autor

Teilen

Zurück

Titel: Ansatz zur Testfallerstellung bei der Test Automatisierung für Abnahmetestfälle in der Automobileindustrie