Testautomatisierung für die Absicherung der … · With the development of software technology in recent years the use of a computer control ... Testautomatisierung in asiatische

Hochschule München

Fakultät Für Feinwerk- und Mikrotechnik, Physikalische Technik

BACHELORARBEIT

Testautomatisierung für die Absicherung der

Integration von externen Multimediaplayern in

asiatische Fahrzeug-Varianten

von

Yang LU

in Zusammenarbeit mit

der Berner & Mattner Systemtechnik GmbH, München

Bearbeitungsbeginn: 19.05.2012

Abgabetermin: 17.08.2012

Hochschule München

Fakultät Für Feinwerk- Und Mikrotechnik, Physikalische Technik

Bachelorarbeit

Zum Erlangen des akademischen Grades Bachelor of Engineering

Testautomatisierung für die Absicherung der

Integration von externen Multimediaplayern in

asiatische Fahrzeug-Varianten

Test automation for the hedge to the integration of

external multimedia players in Asian vehicle-types

Vorgelegt von

Yang LU

Matrikelnummer: 05479211

Betreuender Hochschulprofessor: Prof. Dr.-Ing. Michael Hermann

Betreuerin (Berner & Mattner): Dipl.-Math. Viola Maier

Bearbeitungsbeginn: 19.05.2012

Abgabetermin: 17.08.2012

Selbständigkeitserklärung

Ich erkläre hiermit, dass ich die vorliegende Bachelorarbeit selbständig verfasst und noch

nicht anderweitig zu Prüfungszwecken vorgelegt habe.

Sämtliche benutzte Quellen und Hilfsmittel sind angegeben, wörtliche und sinngemäße Zitate

als solche gekennzeichnet.

München, den 07. August 2012

Yang LU

Bachelorarbeit-Hochschule München-2012 Yang LU

i

Kurzfassung

Mit der Weiterentwicklung von Softwaretechnik ist heutzutage der Einsatz eines Computer-

Kontrollsystems mit mehreren Funktionen im Fahrzeug immer sinnvoller. Diese

angeforderten Funktionen sollen in der Entwicklungsphase des Fahrzeugs integriert und

abgesichert werden. In dieser Arbeit werden die besonderen Multimedia-Funktionen in

asiatischen BMW-Fahrzeug-Varianten vorgestellt und die spezifizierten Anforderungen an

diese Softwarefunktionen dargestellt und analysiert. Aufbauend auf dieser Analyse werden

automatisierte Testfälle zur Verifikation des spezifizierten Systemverhaltens entwickelt.

Abstract

With the development of software technology in recent years the use of a computer control

system with multiple functions in the vehicle is more and more important. These requested

functions should be integrated and tested in the development phase of vehicle. In this thesis

the special multimedia features in the Asian BMW vehicle variant were introduced and the

specified requirements for these software functions were shown and analyzed. On base of this

analysis, the automated test cases were developed for the verification of the specified system

behavior.

Inhaltsverzeichnis


ii

Inhaltsverzeichnis

1. Einleitung ........................................................................................................................................ 1

1.1. Die Berner & Mattner Systemtechnik GmbH ......................................................................... 2

1.2. Motivation ............................................................................................................................... 3

1.3. Aufgabenstellung ..................................................................................................................... 4

1.4. Aufbau und Gliederung der Arbeit .......................................................................................... 5

2. Testumgebung für die Testautomatisierung .................................................................................... 6

2.1. Technische Grundlage ............................................................................................................. 6

2.1.1. MOST-Bus ...................................................................................................................... 6

2.1.2. CAN-Bus ......................................................................................................................... 7

2.2. Hardware ................................................................................................................................. 8

2.2.1. Steuergeräte im Testaufbau ............................................................................................. 8

2.2.2. Multimedia ...................................................................................................................... 8

2.3. Software................................................................................................................................... 9

2.3.1. TAF – Testautomatisierungsframework .......................................................................... 9

2.3.2. TAQT (Testautomatisierung – QTInterface) ................................................................. 10

2.3.3. Zusammenarbeit von TAF und TAQT .......................................................................... 11

3. Testmethode der Testautomatisierung ........................................................................................... 12

3.1. Simulation des ZBEs ............................................................................................................. 12

3.2. Screenshot und Bildvergleich ................................................................................................ 13

3.3. Bildbearbeitung ..................................................................................................................... 14

3.4. Zeichenerkennung (OCR) ..................................................................................................... 15

4. Anforderung der Funktionen ......................................................................................................... 16

4.1. Hintergrund ........................................................................................................................... 16

4.1.1. Zeichenkodierungsstandard ........................................................................................... 16

4.1.2. Umschrift ....................................................................................................................... 17

4.1.3. Sortierung ...................................................................................................................... 17

4.2. Anforderungen für Asienabsicherung ................................................................................... 19

5. Testfälle ......................................................................................................................................... 20

5.1. Voraussetzung der Testfälle .................................................................................................. 20

5.2. Testfallaufbau ........................................................................................................................ 20

5.2.1. Precondition ................................................................................................................... 21

5.2.2. Testrun ........................................................................................................................... 22

Inhaltsverzeichnis


iii

5.2.3. Postcondition ................................................................................................................. 22

5.3. Erstellung der Testfälle.......................................................................................................... 23

5.3.1. Coverart ......................................................................................................................... 23

5.3.2. Richtige Anzeige eines chinesischen Zeichens ............................................................. 27

5.3.3. Sortierung ...................................................................................................................... 31

5.3.4. Speller und Suche .......................................................................................................... 35

5.4. Auswertung ........................................................................................................................... 39

6. Zusammenfassung ......................................................................................................................... 40

6.1. Problem und mögliche Lösungsvarianten ............................................................................. 41

6.1.1. Problem ......................................................................................................................... 41

6.1.2. Lösungsvarianten ........................................................................................................... 42

6.2. Ausblick................................................................................................................................. 42

6.2.1. Mögliche Verbesserung und Erweiterungen ................................................................. 42

6.3. Fazit ....................................................................................................................................... 43

7. Glossar ........................................................................................................................................... 44

8. Abbildungsverzeichnis .................................................................................................................. 46

9. Tabellenverzeichnis ....................................................................................................................... 47

10. Literaturverzeichnis ................................................................................................................... 48

1. Einleitung


1

1. Einleitung

Wegen der Entwicklung der Softwaretechnik spielt Embedded System in Steuergeräte

eine immer wichtigere Rolle im Bereich der Automobilindustrie. In der Vergangenheit hat

jeder Hebel, Knopf, Schalter oder Pedal bei der Steuerung eines Geräts ohne die

Unterstützung eines Embedded Computers meistens eine einzige Bedeutung. Wird ein

Computer eingesetzt, kann man einem Knopf oder Schalter mehrere Bedeutungen geben,

je nachdem in welchem Kontext oder Modus dieser Knopf oder Schalter betätigt wird [1].

Mit Hilfe dieser Technik können viele innovative Funktionen im Automobil realisiert

werden. In den Fahrzeugen der letzten Jahre befinden sich immer mehr Steuergeräten mit

Embedded Software. In der Gegenwart haben moderne Fahrzeuge zum Teil mehr als 70

Steuergeräte eingebaut.

Die Software wird wegen steigender Anforderung von Kunden oder Konkurrenz immer

komplexer. Autos sind momentan rollende Computer – bis zu rund 1 Gigabyte Software

steuern in modernen Fahrzeugen sämtliche Komponenten und technischen Extras [2]. Die

Zusammenfassung vieler verschiedener Funktionen in einem einzigen Steuergerät hat

jedoch für den Hersteller den Vorteil, dass er nur noch ein einziges Interaktionselement

anbieten muss, das an verschiedene Modelle des Fahrzeuges nur durch Änderungen in der

Software angepasst werden kann. Für den Kunden ist diese Zentrierung vieler Funktionen

in einem einzigen Gerät auch vorteilhaft, da sie damit leicht die Funktionen betätigen

können [1].

In der Regel liefert der Automobilhersteller die Spezifikationen und Anforderungen an die

gewünschten Funktionen, deren Entwicklungen und Implementierungen sich auf mehrere

Lieferanten verteilen. Die entwickelten Funktionen werden dann beim Fahrzeughersteller

und teilweise auch beim Zulieferer integriert.

Obwohl die Funktion allein ohne Fehler laufen kann, können tatsächlich mehrere Fehler

im Zusammenspiel aller Funktionen entstehen. Um diese Fehler zu vermeiden, soll die

Software in der Entwicklungsphase beim Fahrzeughersteller überprüft werden und dann

beim Lieferanten die überprüften Fehler bewertet und zum Schluss die Software

verbessert werden. Somit ist die Überprüfung eine sehr wichtige Stufe in der

Entwicklungsphase der Software.

1. Einleitung


2

1.1. Die Berner & Mattner Systemtechnik GmbH

Das Unternehmen Berner & Mattner ist spezialisiert auf Systems Engineering,

Entwicklung und Test leistungsfähiger elektronischer und mechanischer Systeme. Das

branchenübergreifende Leistungsspektrum reicht von der Beratung, Konzeption,

Software- und Systementwicklung bis hin zum Aufbau und Betrieb kompletter Test-

und Integrationssysteme [3].

Als strategischer Partner für die Entwicklungsbereiche der Kunden aus den Branchen

Automobil, Energie, Maschinenbau, Raumfahrt, Transportation und Verteidigung

liefern sie maßgeschneiderte Software- und Engineering-Lösungen auf Basis ihrer

Produkte und Dienstleistungen. Dabei tragen sie maßgeblich zur Optimierung von

Effizienz und Qualität in der Software- und Systementwicklung ihrer Kunden bei.

Daher vertrauen namhafte Unternehmen wie AUDI, BMW, Bombardier, Daimler,

Deutsche Bahn, Siemens u.v.m. der Kompetenz von Berner & Mattner [3].

Berner & Mattner ist Pionier modellbasierter Technologien und agiert seit über 30

Jahren als wichtiger Entwicklungspartner weltweit führender Konzerne. Dies zeugt

von einem hohen Innovationsgeist und einer starken Mitarbeitermotivation. Heute

arbeiten 370 Spitzenkräfte der Elektronik- und Softwareentwicklung an sieben

Standorten in Deutschland und Österreich [3].

Seit 2011 ist Berner & Mattner Mitglied der Assystem Group. Das Netzwerk

innovativer Engineering-Dienstleister beschäftigt weltweit mehr als 10.200

Mitarbeiterinnen und Mitarbeiter [3].

http://www.berner-mattner.com/de/berner-mattner-home/unternehmen/berner-mattner-mitglied-der-assystem-group.html

1. Einleitung


3

1.2. Motivation

Ein wichtiger Grund dafür, dass ich das Thema „Testautomatisierung für die

Absicherung der Integration von externen Multimediaplayern in asiatische Fahrzeug-

Varianten― als meine Bachelorarbeit bei Berner & Mattner ausgewählt habe, lag darin,

dass ich großes Interesse für die Programmierung habe. Dass ich bereits einige

Sprachen wie C und JAVA gelernt habe, war vorteilhaft für mich, um die

Testautomatisierung durchzuführen. Da das bereits bestehende Testframework auf der

Programmiersprache „Python― basiert, sollte ich während meiner Bachelorarbeit die

Testskripts mit „Python― schreiben, damit ich nicht nur eine neue Sprache kennen

lernen, sondern auch meine Kenntnisse der Informatik wegen der Ähnlichkeit

unterschiedlicher Programmiersprachen verbessern konnte.

Außerdem sammelte ich schon Vorkenntnisse davon im Verlauf meines Praktikums.

Im Rahmen meines Praktikums hatte ich die Gelegenheit mich in die

Fahrzeugfunktionen, die verwendeten Technologien sowie die verwendeten

Werkzeuge zur Testautomatisierung einzuarbeiten. Dabei lernte ich die manuellen

Testfälle für die Asienabsicherung kennen. Mit den besonderen Anforderungen

bestimmter Länder machte ich mich bereits vertraut. Diese Erfahrungen waren nötig

und nützlich für mich, um die Testfälle für die Testautomatisierung aufzubauen.

Darüber hinaus bin ich Chinese. Daher beherrsche ich die chinesischen Schriftzeichen

und die Buchstabierung dieser. Diese Kenntnisse waren hilfreich für die

Testautomatisierung in asiatische Fahrzeug-Varianten.

1. Einleitung


4

1.3. Aufgabenstellung

Die Bachelorarbeit wurde in Zusammenarbeit mit der Berner & Mattner

Systemtechnik GmbH im Rahmen des Projekts „Entertainment und mobile Endgerät―

bei der BMW AG in München angefertigt. Meine Bachelorarbeit umfasste folgende

Aufgaben, die ich eigenverantwortlich umsetzen sollte.

In die bereits bestehende Testumgebung habe ich weitere Testskripts integriert, die ich

auch selbst entwickelte und überprüfte. Diese Skripts sollten für die Ländervarianten

China, Hongkong und Taiwan folgende Use Case absichern,

1. ob Coverart vom Lied im Bildschirm richtig angezeigt wird. (Besonderheit:

Coverart ist in Hongkong immer verboten)

2. ob die Zeichen der Titelnamen bei verschieden Zeichenkodierungsstandards

richtig angezeigt werden. (China: GB18030 und Hongkong/Taiwan: Big5)

3. ob die Lieder nach der Anforderung richtig sortieren werden.

4. ob das erwartete Zeichen in der Suchmaske ausgewählt und in der Ergebnisliste

die erwarteten Lieder angezeigt werden.

Besondere Herausforderung hierbei war die automatische Überprüfung der

chinesischen Zeichen über eine OCR oder einen Bildvergleich. Für die entwickelten,

integrierten und getesteten Testskripts erstellte ich eine Dokumentation. Des Weiteren

gebe ich einem Ausblick auf den Test die Verbesserungsvorschläge für Robustheit und

Sicherheit.

1. Einleitung


5

1.4. Aufbau und Gliederung der Arbeit Alle notwendigen Grundlagen und Detailinformationen zum Aufbau der

Testumgebung für die Testautomatisierung werden im zweiten Kapitel beschrieben.

Dabei wird ein Überblick über die technischen Grundlagen der verwendeten

Bussystems gegeben. Im anschließenden Teil wird auf die Hardware der einzelnen

Steuergeräte sowie Multimediafunktionen eingegangen. Zum Schluss dieses Kapitels

wird die Software für die Testautomatisierung präsentiert.

Das dritte Kapitel beschreibt Methoden wie die Simulation des ZBEs und

Zeichenerkennung mit einigen Code-Beispielen im Rahmen der vorhandenen Services

im TAF (Testautomatisierungsframework). Dabei wird hauptsächlich auf die bei den

umgesetzten Testfällen genutzten Methoden eingegangen.

Anschließend wird der Hintergrund der chinesischen Zeichenkodierungsstandards,

Umschreibungen und Sortierungen im vierten Kapitel präsentiert. Dann werden die

speziellen BMW-Anforderungen für asiatische Fahrzeug-Varianten mit drei Tabellen

dargestellt.

Das darauf folgende Kapitel beschreibt zuerst den Testfallaufbau und Ablauf der

implementieren Testfälle. Mit Hilfe von Ablaufdiagrammen, Screenshots und Code-

Beispielen soll der Leser mit diesem Kapitel die genaue Umsetzung der einzelnen

Testfälle nachvollziehen können. Darin ist mein Gedankengang für die Analyse des

Problems, die damit erworbene Lösung und Verbesserung entstanden. Zum Schluss

dieses Kapitels wird die Auswertung des Testergebnisses dargestellt.

Im letzten Kapitel wird eine Zusammenfassung dieser Arbeit gegeben, einen Ausblick

auf die Verbesserung und Erweiterung der aktuellen Testfälle.

2. Testumgebung für die Testautomatisierung


6

2. Testumgebung für die Testautomatisierung Die nachfolgende Abbildung 2.1 zeigt den Aufbau der Testumgebung mit relevanten

Komponenten. Der Aufbau teilt sich in zwei Bereiche, zum einen die Steuergeräte am

MOST-Bus und zum anderen die am CAN-Bus. Mit dem ZGW (Zentrales Gateway) sind

die zwei Bussystems verbunden. Via USB war der Rechner mit CAN-Case und Verctor-

Box für MOST, die beide für die Bearbeitung der Nachrichten benutzt werden,

angeschlossen. Auf dem Rechner liefen die Skripts für die Testautomatisierung. Die

Befehle des Rechners können per CAN-Bus oder Vector-Box für MOST an die

Steuergeräte gesandt werden.

Im Testrack befinden sich die Infotainment-Steuergeräte (hier-zu gehören unter anderem:

Head Unit, Verstärker, Multimediasteuergeräte) und die zum Testen nötigen Tools

(Framegrabber, VectorBox usw.). Nachfolgend werden die technische Grundlage,

Hardware und Software der Testumgebung vorgestellt.

Abbildung 2.1: Aufbau der Testumgebung

2.1. Technische Grundlage

2.1.1. MOST-Bus

In den letzten Jahren sind vor allem in den Fahrzeugen der Premiumklasse mehr

und mehr Multimedia- und Telematikapplikationen integriert worden. Dies hat zu

einer raschen Zunahme der Komplexität geführt [4].

Alle diese Funktionen und der große Bandbreitenbedarf haben zur Entwicklung

eines speziellen Infotainment-Kommunikationssystems geführt, dem MOST

(Media Oriented Systems Transport). Die MOST Technologie bietet nicht nur eine

synchrone Übertragung für Audio- und Videodaten, sondern stellt für die

Beherrschung der Komplexität ein sogenanntes Application-Framework zur

Verfügung, das Schnittstellen und Funktionen für Infotainment-Systeme auf einem

Zentrales Gateway

Vector Box für MOST

Fahrzeug-komponenten

Head Unit MOST

CAN-Case

Rechner

Endgerät

CAN

USB

USB



7

hohen Abstraktionsniveau definiert- MOST verbindet die verschieden

Multimediakomponenten in einem Ring [4]. In der Ringtopologie1 werden

Lichtwellenleiter eingesetzt. Dabei nimmt ein Busteilnehmer die Rolle des Masters

an, welcher das Timing des synchronen Busses vorgibt. Zusätzlich sendet er

kontinuierlich Frames, welche von den Teilnehmern für ihre Datenübertragung

verwendet werden können.

Eine weitaus höhere Performance in Bezug auf den Datenaustausch bietet MOST

gegenüber CAN. MOST ermöglicht einen schnellen Informationsaustausch

zwischen Infotainment-Steuergeräten, er erfüllt aber nicht die Anforderungen

bezüglich Echtzeitfähigkeit und Sicherheit, die z.B. Fahrdynamikregelsystem an

die Kommunikation stellen [6].

2.1.2. CAN-Bus

Der CAN-Bus (Controller Area Network) ist ein asynchrones, serielles Bussystem

und gehört zu den Feldbussen. Der derzeit eingesetzte CAN-Bus vernetzt durch

eine High- oder Low-Speed-Übertragung die Antriebs- und Komfortkomponenten

miteinander, welche im Motor- und Innenraum des Fahrzeugs verbaut sind. Der

High Speed CAN ist bis zu einer Baudrate von 1 Mbit/s und der Low Speed CAN

ist bis 125 Kbit/s spezifiziert [5].

Der CAN-Bus dient dazu, elektronische Fahrzeugsysteme miteinander über eine

Kommunikationsleitung zu vernetzen. Beim CAN-Bus kann eine Vielzahl

elektronischer Systeme miteinander kommunizieren und Daten austauschen [6].

Das CAN-Protokoll wurde ursprünglich für die Echtzeitanwendungen im

Antriebsstrang und der Fahrzeugbewegung entwickelt und wird seit 1991 mit

wachsender Marktdurchdringung eingesetzt. Das Protokoll hat sich durch

dominantes Design weltweit durchgesetzt, als Standard etabliert und wird heute in

nahezu jedem Fahrzeug mit unterschiedlicher Anzahl von Busteilnehmern genutzt.

Beim Einsatz eines Bussystems entfällt im Steuergeräteverbund eine Vielzahl von

schwer diagnostizierbaren Kabeln und Verbindungsstellen. Der mit Bussystem

aufgebaute Netzwerkverbund verringert daher die Ausfallrate im Vergleich zu den

Punkt-zu-Punkt-Verbindungen und bedeutet damit eine in der Systementwicklung

planbare Qualitätsverbesserung [7].

1Ringtopologie: Eine Vernetzung, bei der in einem Ring jeweils zwei Teilnehmer über Zweipunktverbindungen miteinander

verbunden sind, so dass ein geschlossener Ring entsteht.

http://de.wikipedia.org/wiki/Feldbus



8

2.2. Hardware

2.2.1. Steuergeräte im Testaufbau

- Zentrales Infotainmentssteuergerät / Head Unit

Die HU (Head Unit) stellt das zentrale Steuergerät, also den Master, auf

dem MOST-Ring (siehe Kapitel 2.1.1.) dar. Für die Entwicklung der

Testfälle wurde die Serien HU „NBT― verwendet. Diese HU ist anders als

die anderer Serien davor, weil sie alle Funktionen der Infotainment-

Software des Fahrzeugs, wie z.B. die Navigation, Radio, CD und

Multimedia-Wiedergabe, Fahrzeuginformation und Einstellungen integriert.

Andere HUs benötigten im Ring zusätzliche Steuergeräte, auf denen

Funktionen verteilt waren. Die Ausgabe erfolgt auf einem CID (Central

Information Display). Die Auflösung vom CID ist 1280*480.

- Zentrales Gateway – ZGW

Das MOST-CAN-Gateway ist im zentralen Gateway implementiert. Für

den CAN-Bus und das MOST Interface existieren unterschiedliche

Abstraktionslevel. Während auf der CAN-Seite Signale, die an einer

bestimmten Position im CAN-Frame transportiert werden, vorhanden sind,

besteht die MOST Schnittstelle aus einem Funktionsblock, d.h., die Signale

werden auf der MOST Seite als Properties des Funktionsblocks behandelt

[6]. Ein zentrales Gateway stellt eine Schnittstelle zwischen den

verschiedenen Bussystemen dar. Seine Aufgabe ist die Nachrichten von

einem Bus auf einen anderen Bus zu senden und die dafür nötige

Umwandlung der Nachrichten vorzunehmen.

- Zentrales Bedienelement – ZBE

Das Zentrale Bedienelement, auch „iDrive― genannt, ist das Eingabegerät

des Fahrers zur Bedienung der Funktionen der Head Unit. Die

Kommunikation des ZBEs mit der HU erfolgt mittels CAN-Bus.

2.2.2. Multimedia

Die Multimediafunktionen, wie Musik und Video, in der HU „NBT― bestehen aus

CD/DVD, Musiksammlung und externen Geräte. In der Asienabsicherung sollte

die Überprüfung mit externen Geräten, wie USB-Stick und iPhone/iPod,

durchgeführt werden. Im Folgenden sind diese zwei Arten der Endgeräte

beschrieben.

- USB-Storage/USB-Stick

Über den KuZu (Kunden-Zugang) wird ein USB-Stick mit der HU

verbunden. Der Verbindungsmodus von USB ist in der Regel MSC (mass

storage class). Die Daten vom USB-Stick können in der HU ausgelesen

werden. Nach dem Auslesen werden diese Daten in der HU bearbeitet.



9

Beispielsweise entscheidet die HU, wie die ausgelesenen Lieder sortiert

werden und welche Ergebnisse eine Suche liefert.

Über USB kann Audio und im Stand auch Video in BMW-Fahrzeugen

abgespielt werden.

- iPhone/iPod

Ebenfalls am KuZu kann über ein spezielles Kabel oder den SIA (Snap in

Adapter)1 ein iPhone oder iPod mit der HU verbunden werden. Der

Verbindungsmodus von iPhone/iPod ist iAP (iPod accessory protocol).

Anderes als bei USB-Sticks sendet die HU an das iPhone oder den iPod die

Nachrichten zur Datenbearbeitung wie zum Beispiel Sortierung oder Suche,

die dann im iPhone/iPod durchgeführt wird. D.h. die Sortierung oder Suche

ist nicht abhängig von der HU sondern von iPhone oder iPod selbst.

Im Vergleich mit USB-Sticks kann nur Audio von iPhone/iPod abgespielt

werden, wenn dieser über den KuZu mit Kabel angeschlossen ist. Über den

SIA ist nicht nur Audio sondern auch Video (wenn die Geschwindigkeit

des Fahrzeugs gleich 0 ist) möglich.

- Relaiskarte

Mit Hilfe einer Relaiskarte ist es möglich gleichzeitig bis zu fünf Endgeräte

an den USB-Eingang des Steuergerätes anzuschließen und diese einzeln

durchzuschalten. Dies ermöglicht die automatisierte Simulation des

manuellen An- und Absteckens eines Endgerätes sowie sequentielle Tests

von mehreren Geräten. Die Relaiskarte wird nur zum Test eingesetzt und

ist kein offizielles BMW Zubehör.

2.3. Software

2.3.1. TAF – Testautomatisierungsframework

Das Testautomatisierungsframework (TAF) ist eine Eigenentwicklung der BMW

AG, das im E-Resort entwickelt wird. Das Framework unterstützt die

Spezifikation, Durchführung und Auswertung von Testfällen. Die Testfälle werden

in Excel spezifiziert, über einen Parser in eine Python-Testsequenz umgewandelt

und diese ausgeführt. Testergebnisse können danach über Reporterfunktionen

aufbereitet werden [8].

Neben Elementen zur Ablaufsteuerung wie Schleifen stellt das Framework dem

Testspezifikateur eine Reihe von Funktionen bereit, um das „System under

Test― (SUT) zu steuern bzw. zu testen. Diese Funktionen sind in sogenannten

Services gekapselt. Beispiele für Services sind MOST, CAN, Ediabas, etc. [8].

1SiA (Snap in Adapter): er ist von BMW entwickelt und hergestellt, um das Telefon an das Fahrzeug anzuschließen. Bisher

ist er vielen Marken der Mobiltelefone angepasst, wie Apple, Nokia, BlackBerry und so weiter.



10

2.3.2. TAQT (Testautomatisierung – QTInterface)

TAQT Interface ist eine von BMW geschriebene Applikation und bietet

verschiedene Funktionen an, um Testfälle automatisiert ablaufen zu lassen. Es

bietet weiterhin die Möglichkeit, Testreports zu generieren [9].

In der Abbildung 2.2 ist die Startansicht des TAQT dargestellt. Im linken oberen

Bereich lässt sich ein Modell, das die Überprüfungen der Funktionen von

Multimedia unterstützt, auswählen und über die Schaltflächen Init und Stop starten

und anhalten. Außerdem findet man dort den Network Status zum MOST-Ring

(Licht an/aus).

Im linken Bereich des Tab TA sind die Testfälle, die in bestimmte Ordnern des

Rechners abgelegt sind, zu finden. Nachdem ein Modell initialisiert wurde, wird

im rechten Bereich ein neuer Ordner erstellt, in dem die nun in der Mitte stehenden

Testfälle aufgerufen werden können.

Das TestcaseLog1-Fenster unten zeigt Info- und Fehlermeldungen der

Testergebnissen selbst und der Verbindung zum Modell; die Ausgaben des

Modells befinden sich in einer Windowskonsole, die zusammen mit der TAQT

gestartet wird.

Abbildung 2.2: TAQT-Interface

1Log: in dem die Kommentare des Tests stehen, wie Informationen oder Fehler des Testlaufs, im Kapitel 5.1.1. ist ein

Beispielbild zu finden.

http://teco.muc/sites/e/proj-MMP/Wiki/Testfälle.aspx



11

2.3.3. Zusammenarbeit von TAF und TAQT

Wie im Kapitel 2.3.1. beschrieben kann TAF als eine Bibliothek betrachtet werden,

in der viele Services mit bestimmten Methoden vorhanden sind. Im Vergleich dazu

ist TAQT ein GUI (Graphical User Interface) für Testorganisation, wie zum

Beispiel Konfiguration und Testablauf.

TAQT kann auf die Ordnerstruktur der Testskripte zugreifen. Damit kann eine

Auswahl der Skripte, sowie deren Reihenfolge für einen Testablauf festgelegt

werden. Außerdem kann hier die Iteration, d.h. die Anzahl der Durchläufe, für

jedes Skript definiert werden. Während die Testskripts ablaufen, müssen die von

TAF angebotenen Services aktiviert werden. So können die Methoden, die von

diesen Services angeboten werden, in den Testskripts erfolgreich aufgerufen und

genutzt werden. Mit der Zusammenarbeit von TAF und TAQT kann die

Testautomatisierung durchgeführt werden.

3. Testmethode der Testautomatisierung


12

3. Testmethode der Testautomatisierung Die Testautomatisierung der Multimediatests wird am Testracks entwickelt. Mit TAF, in

dem sich viele Services mit unterschiedlichen Methoden befinden, kann die TA besser

und einfacher umgesetzt werden. Im Folgenden wird auf die für die Multimedia-TA

relevanten Methoden des TAF eingegangen.

3.1. Simulation des ZBEs Man kann mit der vom ZBE gesendeten Nachricht direkt zu dem benötigen Menü

(Media, Radio, Navigation, Telefon und Hauptmenü) springen. Da ZBE nur

physikalische Knöpfe beinhaltet, soll die Simulation des ZBEs für TA genutzt werden.

ZBEL6Service

Der ZBEL6Service ist die auf dem CANService basierende Umsetzung von

Nutzeraktionen der zentralen Bedieneinheit in der Baureihe L6 [8].

Dieser Service besitzt die Funktionen für die verschiedenen ZBE-Aktionen. Die

nachfolgend aufgelisteten Methoden habe ich im Programm gebraucht:

Drehen:

- Left ( sleepTime, repeat )

- Right ( sleepTime, repeat )

Shift:

- East ( sleepTime, repeat )

- West ( sleepTime, repeat )

Tasten am ZBE:

- CD ( sleepTime )

- Mainmenü ( sleepTime )

Funktionsparameter der oberen verschiedenen Methoden

repeat (integer): Anzahl der Wiederholungen des Befehls

sleepTime (float): die nach Ausführen des Befehls gewartete Zeit. Bei mehreren

Wiederholungen, wie ZBE mehrere Male nach links drehen, wird diese Zeit nach jeder

Wiederholung gewartet.



13

Code – Beispiel:

3.2. Screenshot und Bildvergleich Eine der einfachsten Methoden um die Ausgabe auf dem Bildschirm zu überprüfen ist

der Vergleich des Bildes im Bildschirm mit einem Referenzbild. Vor dem Vergleich

muss das Bild im Bildschirm abgegriffen werden. Dann muss das Bild bearbeitet

werden, damit die Dimension des Bildes gleich ist wie die des Referenzbildes.

FrameGrabberL6Service:

Dieser Service bietet verschiedene Methoden zur Aufnahme von Screenshots sowie

dem Vergleich dieser Screenshots untereinander.

Im Folgenden stehen die Methoden, die ich im Programm brauchte:

GetImage()

Macht einen Screenshot und gibt das Bild als PIL-Image Objekt zurück.

SaveImage(Pfad+filename)

Macht einen Screenshot und speichert ihn unter dem gegebenem Pfad +

Bildname.

CompareImages2(Pfad+filename, Pfad+filename)

Macht einen Vergleich zwischen zwei Bilder und gibt ein „bool― zurück.

Code – Beispiel:



14

3.3. Bildbearbeitung MMIService

Der Service bietet die Funktionen, das Bild vom Screenshot zu verarbeiten.

Im Folgenden steht die Methode, die ich im Programm brauchte:

ExtractCursorRegion(img)

Erkennung von Cursor im Bild und Rückgabe der Koordinate des Cursors.

Code – Beispiel:



15

3.4. Zeichenerkennung (OCR) Beim Bildvergleich sollen die Referenzbilder zunächst gespeichert werden. Um die

Überprüfung effizienter zu machen, bietet TAF die Zeichenerkennung an. Damit kann

die Überprüfung ohne Referenzbild automatisch durchgeführt werden. Diese optische

Zeichenerkennung ist eine wesentlich bessere Alternative zum Bildvergleich. Sie heißt

im Englisch OCR (Optical Character Recognition). Mit dieser Funktion können die in

einem vom FrameGrabber geschossenem Screenshot dargestellten Zeichen erkannt

werden. Diese lassen sich dann sehr komfortabel im Testskript durch einen einfachen

String-Vergleich mit der erwarteten Referenz abgleichen.

OCR2Service

OCR2Service bietet die Funktion der Zeichenerkennung. Das heißt, dass mit Hilfe des

Services die Zeichen oder die lateinischen Buchstaben im Bild erkannt werden können.

Recognize(img)

Zeichenerkennung aller Zeichen oder lateinischen Buchstaben im Bild und Rückgabe

einer Liste mit diesen.

Momentan unterstützt der Service die chinesischen Zeichen, und zwar vereinfachtes

Chinesisch und traditionelles Chinesisch. Die Rückgabe erfolgt in Hexadezimalcode,

der nach Unicode kodiert ist.

Obwohl es funktioniert, ist die Erkennungsrate ca. 60%, z.B. chinesische Zeichen „一,

二 , 三― sind nicht erkennbar. Deswegen ist die OCR für chinesische Zeichen zu

schlecht für die Testautomatisierung. Daher benutzte ich im Programm kein OCR für

die Erkennung der chinesischen Zeichen, diese Funktion habe ich mit Bildvergleich

ersetzt.

Code – Beispiel:

4. Anforderung der Funktionen


16


4.1. Hintergrund Gegenwärtig besteht Chinesisch aus vereinfachtem Chinesisch und traditionellem

Chinesisch. Der Unterschied ist, dass die Zeichen im vereinfachten Chinesisch mit

weniger Striche als im traditionellen Chinesisch geschrieben werden. In der Regel

wird vereinfachtes Chinesisch auf dem Festland genutzt, während traditionelles

Chinesisch in Hongkong und Taiwan genutzt wird. Im nachfolgenden Kapitel werden

die Unterschiede im Bereich Zeichenkodierungsstandard, Umschreibung und

Sortierung erklärt.

4.1.1. Zeichenkodierungsstandard

Um die Zeichen im Computer anzeigen zu können, werden die eignen

Zeichenkodierungsstandards von den Ländern erstellt. Obwohl Unicode

(international Zeichenkodierungsstandard) bereits erstellt worden ist, wird

gewöhnlich der eigene Standard genutzt. Da unterschiedlich es Chinesisch auf dem

Festland und in Hongkong/Taiwan genutzt wird, werden zwei verschiedenen

Standards erstellt. Im Folgenden werden kurz die Standards GB18030 vom

Festland und Big5_HKSCS von Hongkong und Taiwan beschrieben.

4.1.1.1. GB18030 in China – Festland

Der chinesische Zeichenkodierungsstandard GB18030 beschreibt 27.484

Zeichen der chinesischen Schrift. Seit dem 1. September 2001 ist er

verbindlich für alle in der Volksrepublik verkauften Betriebssysteme und

Programme; es ist der Nachfolgestandard für die Kodierungen GBK und

GB2312 und deckt traditionelle und vereinfachte Zeichen ab[10].

4.1.1.2. Big5_HKSCS in China – Hongkong und Taiwan

Big5 ist eine Zeichenkodierung für traditionelle chinesische Schriftzeichen. Sie

kodiert 13.062 chinesische Schriftzeichen und ist bei weitem der am meisten

benutzte Zeichensatz in Taiwan [11].

Das HKSCS (Hong Kong Supplementary Character Set) ist eine Erweiterung

der Big5-Kodierung, die 4.941 zusätzliche Zeichen für Kantonesisch enthält.

Es ist eine Weiterentwicklung des Government Chinese Character Set und

wurde zunächst nur in Behörden, später auch in der Öffentlichkeit benutzt [12].

http://de.wikipedia.org/wiki/Chinesische_Zeichenkodierung

http://de.wikipedia.org/wiki/1._September

http://de.wikipedia.org/wiki/2001

http://de.wikipedia.org/wiki/Betriebssystem

http://de.wikipedia.org/wiki/Computerprogramm

http://de.wikipedia.org/wiki/Kodierung

http://de.wikipedia.org/wiki/GBK

http://de.wikipedia.org/wiki/GB2312

http://de.wikipedia.org/wiki/Langzeichen

http://de.wikipedia.org/wiki/Kurzzeichen

http://de.wikipedia.org/wiki/Langzeichen

http://de.wikipedia.org/wiki/Chinesische_Schriftzeichen

http://de.wikipedia.org/wiki/Big5

http://de.wikipedia.org/wiki/Kantonesisch



17

4.1.2. Umschrift

In diesem Kapitel werden drei Umschreibungen, die in China heutzutage

üblicherweise genutzt werden, je mit einem Beispiel beschrieben.

4.1.2.1. Pinyin

Pinyin ist die offizielle chinesische Romanisierung des Hochchinesischen in

der Volksrepublik China [13]. Damit kann jedes chinesische Zeichen durch

einen Pinyin-String ersetzt werden. Eine Besonderheit ist, dass die Buchstaben

„i―, „u― und „v― im Pinyin-String als erste Buchstaben nicht erlaubt sind, um

chinesischen Zeichen umzuschreiben. Pinyin wird auf dem Festland überall

und in Hongkong teilweise genutzt.

Beispiel:

木 : die Umschreibung in Pinyin ist „mu―.

4.1.2.2. Strich/Strokes

Weil chinesische Zeichen aus Strichen bestehen und alle Zeichen mit 5

unterschiedlichen Basisstrichen in bestimmter Reihenfolge gezeichnet werden

können, wird die Buchstabierung durch fünf Striche, sogenanntes 5 Strokes,

erstellt. In der Gegenwart wird 5 Strokes üblicherweise in Hongkong und auf

dem Festland genutzt.

Beispiel:

木 : die Umschreibung durch 5 Strokes ist „一丨丿丶―.

4.1.2.3. Bopomofo

Bopomofo ist eine nichtlateinische, phonetische Transkription für die

chinesischen Schriftzeichen. Von 1921 bis 1956 war sie in ganz China als

Umschrift in Gebrauch, in Taiwan (seit 1949) ist sie es bis heute. Auf dem

Festland wurde sie durch das lateinschriftliche Pinyin abgelöst [14].

Beispiel:

木 : die Umschreibung von Bopomofo ist „ㄇㄨ―.

4.1.3. Sortierung

Weil auf dem Festland vereinfachtes Chinesisch und die Umschreibung durch

Pinyin überall genutzt wird, ist die Sortierung der chinesischen Zeichen auf dem

Festland abhängig vom Pinyin-String. Obwohl in Hongkong und Taiwan

traditionelles Chinesisch genutzt wird, ist die Sortierung von chinesischen Zeichen

unterschiedlich. In Hongkong ist die Sortierung wegen der Umschrift durch 5

Strokes abhängig von der Anzahl der Striche, während in Taiwan laut der

Reihenfolge von Bopomofo sortiert wird.

http://de.wikipedia.org/wiki/Umschrift

http://de.wikipedia.org/wiki/Hochchinesisch

http://de.wikipedia.org/wiki/Volksrepublik_China

http://de.wikipedia.org/wiki/Phonem

http://de.wikipedia.org/wiki/Transkription_%28Schreibung%29


http://de.wikipedia.org/wiki/China

http://de.wikipedia.org/wiki/Umschrift

http://de.wikipedia.org/wiki/Taiwan_%28Insel%29

http://de.wikipedia.org/wiki/Lateinisches_Alphabet

http://de.wikipedia.org/wiki/Pinyin



18

Als Beispiel zeigt das untenstehende Bild die richtige Sortierung auf dem Festland:

Abbildung 4.1: Beispiel der Sortierung nach der Anforderung auf dem Festland

Die Anforderung der Sortierung auf dem Festland ist eine sogenannte Mischung-

Sortierung, die abhängig von der Reihenfolge der lateinischen Buchstaben (von A

bis Z) ist. In jeder Gruppe, beispielweise A, sollen zuerst die Chinesischen Zeichen,

deren Pinyin-String mit A oder a beginnt, einsortiert werden. Dann folgen die Titel,

deren Namen mit lateinischen Buchstaben geschrieben sind.

Entsprechend der Anforderung werden die chinesischen Zeichen in der HU, die für

China-Festland codiert ist, zuerst in Pinyin-Strings umgewandelt. D.h. die HU

betrachtet die chinesischen Zeichen als Pinyin-Strings. Die folgende Tabelle zeigt

die Umwandelung, die der Sortierungsliste mit den Gruppen A und B des oberen

Bildes entspricht.

Sortierungsliste lateinische Buchstaben oder Pinyin-String von

chinesischen Zeichen

爱是怀疑 Ai Shi Huai Yi

Angels angels

半梦半醒 Ban Meng Ban Xing

别怕我伤心 Bie Pa Wo Shang Xin

不让我的眼泪陪我过夜 Bu Rang Wo De Yan Lei Pei Wo Guo Ye

Baby Be Mine baby be mine

Bed Of Roses bed Of Roses

Tabelle 4.1: Beispiel der Umwandelung der chinesischen Zeichen in der HU



19

4.2. Anforderungen für Asienabsicherung Nach dem Lastenheft von BMW sind die Anforderung für das Festland, Hongkong

und Taiwan unterschiedlich. Im Folgenden werden die jeweiligen Anforderungen in

einer Tabelle dargestellt.

China-Festland

Coverart erlaubt

Zeichenkodierungsstandard GB18030 wird unterstützt

Sortierung der Lieder mit


abhängig von Pinyin-String (erster Buchstabe von A bis

Z)

Ergebnis

der Suche

Mit

chinesischem

Zeichen

Die Titel, die das Zeichen beinhalten

Mit

lateinischem

Buchstaben

Alle chinesischen Titel, die den Buchstaben als ersten

Buchstaben im Pinyin-String haben, ebenso wie

lateinische Titel, die mit diesem Buchstaben beginnen

Tabelle 4.2: Anforderung für das Festland

Hongkong

Coverart Nicht erlaubt

Zeichenkodierungsstandard Big5_HKSCS wird unterstützt



abhängig von der Anzahl der Striche des Zeichens

Ergebnis

der Suche

Mit

chinesischem

Zeichen

Die Titel, die das Zeichen beinhalten

Mit

lateinischer

Buchstabe

Alle lateinischen Titel, die mit diesem Buchstaben

beginnen

Tabelle 4.3: Anforderung für Hongkong

Taiwan

Coverart erlaubt

Zeichenkodierungsstandard Big5_HKSCS wird unterstützt



abhängig von der Bopomofo-Tabelle

Ergebnis

der Suche

Mit

chinesischem

Zeichen

Die Titel, deren erstes Zeichen gleich wie das Zeichen

ist

Mit

lateinischer

Buchstabe

Alle lateinischen Titel, die mit dieser Buchstaben

beginnen

Tabelle 4.4: Anforderung für Taiwan

5. Testfälle


20

5. Testfälle

5.1. Voraussetzung der Testfälle In der Implementierung der Testfälle wird die Methode Bildvergleich verwendet.

Somit müssen zuerst bestimmte Lieder auf dem USB-Stick gespeichert werden. Dann

können die Referenzbilder manuell angefertigt werden. Mit diesen Bildern wird

danach der Ordner im Computer erstellt. Die auf dem USB-Stick vorhandenen Lieder

dürfen nicht verändert werden, weil die Referenzbilder, die abhängig von den auf dem

Stick gespeicherten Lieder sind, bereits erstellt sind.

Auf meinem Test-USB-Stick sind alle Testlieder. Außerdem wurden die Ordner mit

bestimmten Namen im USB-Stick erstellt (Abb.: 5.11 zeigte die vorhanden Ordner im

USB-Stick). Alle Überprüfungen in dieser Arbeit konnten mit diesem USB-Stick

durchgeführt werden.

5.2. Testfallaufbau Die Testfälle, die für die Ausführung im TAQT geschrieben werden, sollen nach der

definierten Vorlage aufgebaut werden. Jeder Testfall soll mit einer Vorbedingung

(precondition) beginnen, in der z.B. die Aktivität des Bussystems, die Verbindung

eines externen Gerätes usw. überprüft werden soll. Danach folgt der Programmcode

des eigentlichen Tests. Der Testfall endet mit der Schlussbedingung (postcondition).

Damit wird das Programm beendet. Das Bussystem wird heruntergefahren und die

Verbindung der externen Geräte getrennt.

Im Folgenden wird der vollständige Testfallaufbau graphisch dargestellt:

Abbildung 5.1: Diagramm des Testfallaufbaus

1 • Start

2 • Vorbedingung

3 • Test laufen

4 • Schlussbedingung

5 • Ende

5. Testfälle


21

5.2.1. Precondition

In der Precondition werden alle notwendigen Schritte für die Testdurchführung

vorbereitet. Dies sind folgenden Punkte:

Einstellung der Relaiskarte

Start des MOST-Ring und starten der TAF-Services

Einlesen der Konfigurationsvariablen

Warten auf die Verbindung des Endgerätes

Die unten stehende Abbildung zeigte die ganzen Log-Informationen in der

Precondition:

Abbildung 5.2: Log-Informationen in der Vorbedingung

5. Testfälle


22

5.2.2. Testrun

In diesem Abschnitt wird der Test durchgeführt. Treten Fehler auf, werden diese

am Ende des Testprotokolls/Testlogs aufgeführt. Dies wird ausführlich in Kapitel

5.3. vorgestellt.

5.2.3. Postcondition

In der Postcondition wird der MOST-Ring nach einer kurzen Wartezeit

ausgeschaltet. In den folgenden Testfällen müssen die Steuergeräte und Testtools

neu gestartet werden.

Dieses Vorgehen beugt aus Erfahrung vielen Fehlern vor. Es zeigte sich, dass z.B.

die Vector-Box für MOST durch einen Neustart zuverlässiger arbeitete. Ein

Nachteil ist jedoch der Zeitaufwand, der daraus entsteht. Aber der Anspruch an die

Stabilität des Systems überwiegt.

Die unten stehende Abbildung stellt die ganzen Log-Informationen in der

Postcondition dar:

Abbildung 5.3: Log-Informationen in der Nachbedingung

5. Testfälle


23

5.3. Erstellung der Testfälle Wie oben genannt gibt es vier spezielle Anforderungen für Multimedia in Fahrzeugen,

die auf dem Festland, in Hongkong und Taiwan eingesetzt werden. Aus diesem Grund

sollen vier Testfälle für jeweils eine Funktion aufgebaut werden. Damit kann man

einfach erkennen, welche Funktionen richtig oder falsch umgesetzt sind.

Im folgenden Kapitel werden die vier Testfälle beschreiben. Zuerst werden in diesem

Kapitel die wichtigen Probleme, die Lösung dazu, die mögliche Variante und

Verbesserungsvorschläge präsentiert. Dann werden die Tests mit Schritten, Ablaufbild,

Diagrammdarstellung und Code-Beispiel erklärt.

5.3.1. Coverart

5.3.1.1. Problem, Lösung und Verbesserung

Problem 1: wie wird ein

bestimmter Titel, der Coverart

enthält, gefunden.

Lösung 1: die Position des

Titels in der Titelliste muss

bestimmt werden. Mit der

genauen Position kann der

Titel einfach und schnell

gefunden werden.

Problem 2: Die Position hat mit

der Sortierung zu tun. Die

Sortierung, deren Änderung die

Position beeinflusst, soll auch

überprüft werden.

Lösung 2: TAF

OCR2.Service bietet die

Methode der

Zeichenerkennung an. Damit

kann der erwartete Titel

gefunden werden.

Problem 3: Die Koordinate

des Cursors muss bestimmt

werden. Die Methode wird im

MMI.Service angeboten. Diese

Methode funktioniert nicht

zuverlässig, somit wird das

Zeichen falsch erkannt.

Verbesserung 1: Basierend

auf Lösung 2 muss das

Programm verbessert werden,

um die Zeichenerkennung zu

verbessern.

5. Testfälle


24

In meinem Programm wird der Titel „Baby be Mine― gesucht. Wegen der vier

mögliche unterschiedlichen Erkennungen des OCR mit „Baby be

Mine― musste ich dies im Programm wie folgt abfangen.

Abbildung 5.4: Verbesserung des Programms im ersten Testfall

5.3.1.2. Testablauf

Der Testablauf ist gemäß des Ablaufplan (Abb.: 5.6) implementiert. In diesem

Testfall basiert die komplette Überprüfung nicht nur auf der grafischen

Darstellung sondern auch auf der Zeichenerkennung in der HMI.

Der erste Schritt in diesem Testfall ist die Simulation der Navigation mit dem

ZBE zur Kategorie „Alle Titel― (Abb.: 5.5 zeigt die Titellistenansicht eines

Beispiel-Titel). Danach wird mit dem TAF MMI.Service die Koordinate des

Cursor ausgelesen und zurückgegeben und dann mit dem OCR2.Service das

Zeichen in der Cursor-Region erkannt, um den bestimmten Titel zu finden.

Nachdem der Titel gefunden und ausgewählt ist, wird zunächst der Screenshot

mit dem FrameGrabberL6.Service erzeugt und mit bestimmten Koordinaten

ausgeschnitten. Die Überprüfung von Coverart wird anschließend durchgeführt.

Abbildung 5.5: Titellistenansicht im Bildschirm

Dazu muss bekannt sein, für welches Land die Head Unit vorab codiert wurde.

Der Grund dafür ist, dass Coverart in Hongkong, wie in Kapitel 4.2.

beschrieben, verboten ist. Deswegen ist das Referenzbild anders als das für das

Festland oder Taiwan. Der Unterschied kann mit zwei Bilder (Abb.: 5.7

Festland und Taiwan, Abb.: 5.8 Hongkong) erkannt werden.

5. Testfälle


25

Abbildung 5.6: Testablaufdiagramm des ersten Testfalls auf dem Festland

Test Start

Navigieren zu

„Alle Titel―

Titelname mit OCR

erkennen

„Baby be Mine―? ZBE einmal nach

rechts drehen bis

zum nächsten Titel

Nein

Ja

Auswahl von

„Baby be Mine―

Ausschneiden des

Coverarts und als

Bild speichern

Vergleich des gespeicherten

Bildes mit dem

entsprechenden Referenzbild

entsprechen? Test mit Fehler

beenden

Nein

Ja

Test ohne Fehler

beenden

5. Testfälle


26

Abbildung 5.7: Anzeige von Coverart auf dem Festland und in Taiwan

Abbildung 5.8: keine Anzeige von Coverart in Hongkong

5. Testfälle


27

5.3.2. Richtige Anzeige eines chinesischen Zeichens


Mit der Lösung 2 und Verbesserung 2 konnte im Programm eine For-Schleife

verwendet werden. Das unten stehende Bild zeigte ein Code-Beispiel, bei dem der

Code mit Schleife den älteren ersetzt.

1„GB―-Ordner: Test-Ordner im TestUSB-Stick, in dem die Lieder, die mit dem Zeichenkodierungsstandart GB18030 (in

Kapitel 4.1.1.1) codiert sind, abgelegt werden. Im TestUSB-Stick befinden sich außerdem die „HKBig5―-Ordner und

„TWBig5―-Ordner.

Problem 1: wie viele Titel sind

im „GB―-Ordner1.

Lösung 1: Da die Inhalte in

USB-Stick immer gleich sein

müssen, kann die Anzahl der

Titel direkt im Programm

verwendet werden.

Verbesserung 1: Um das

Programm flexibel zu machen,

sollte es selbst die Anzahl

auswerten. Problem 2: Wie in Abb.: 5.9

gezeigt, kann mit dem unteren

linken Knopf, der mit Rot

hinterlegt ist, der nächste Titel

ausgewählt werden.

Lösung 2: Das Bild eines

Titels kann sukzessive

gespeichert werden, bis das

aktuelle Bild gleich wie das

zuletzt aufgenommene ist.

D.h., die Bilder aller Titel

werden gespeichert. Problem 3: Mit dem im

Problem 2 genannten Knopf

kann der Titel unendlich

zyklisch ausgewählt werden.

Z.B. im oberen Bild, der

nächste Titel nach dem

dreizehnten Titel ist der erste

Titel.

Verbesserung 2: Basierend

auf der Lösung 2 soll das

aktuelle Bild sukzessive mit

den schon gespeicherten

Bildern verglichen werden.

5. Testfälle


28

Abb. 5.9: Anzeige des von GB kordierten Liedes

Abbildung 5.10: Verbesserung des Programms im zweiten Testfall

5.3.2.2. Testablauf

Im zweiten Testfall wird die Anzeige des chinesischen Zeichens überprüft. Der

Test läuft gemäß des Ablaufdiagramms (Abb.: 5.12) ab.

Als erster Schritt in diesem Testfall wird mit dem TAF ZBEL6.Service zur

Kategorie „Verzeichnis― navigiert (Abb.: 5.11 zeigt die Ordnerlistenansicht der

Referenz-USB-Stick). Dann wird der Ordner „GB― in der Verzeichnisliste mit

der Zeichenerkennung, wie im Kapitel 5.3.1 beschrieben, gesucht. Nachdem

der Ordner „GB― gefunden wurde, wird er anschließend geöffnet. Dann wird

das erste Lied in diesem Ordner ausgewählt. Danach wird der Screenshot, wie

Abb.: 5.9 zeigt, mit der Informationsregion (Mittelfeld in der Abb.: 5.9, rechts

von Coverartregion) ausgeschnitten und gespeichert.

Erst dann kann die Überprüfung der Sortierung mit der Methode Bildvergleich

beginnen. Um sicher zu sein, sollen alle Lieder im Ordner „GB― überprüft

werden. Deswegen ist der Prozess der Überprüfung komplexer als der erste

Testfall. In der Überprüfung muss zuerst das aktuelle, gespeicherte Bild mit

dem entsprechenden Referenzbild verglichen werden. Damit kann die Anzeige

getestet werden. Dadurch, dass das aktuelle, gespeicherte Bild dann mit den

bereits gespeicherten Bildern verglichen wird, kann erkannt werden, ob alle in

dem Ordner vorhandenen Lieder bereits überprüft sind. Für diesen Fall werden

zwei verschachtelte Schleifen verwendet, die eine für den Vergleich mit den

gespeicherten Bildern und die andere für den mit den Referenzbildern.

5. Testfälle


29

Abbildung 5.11: Anzeige des Ordnerverzeichnisses im USB-Stick

Abb.: 5.11 zeigt, dass es insgesamt 5 Ordner im USB-Stick gibt. Die drei in

diesem Testfall genutzten Ordner, „GB―, „HKBIG5― und „TWBIG5―, sind im

Mittelfeld. Der Grund dafür ist, dass die Koordinate der Region des Cursors

wegen des TAF-Services nicht richtig erkannt werden kann, wenn der Cursor

auf dem ersten Eintrag steht. Z.B. kann im oberen Bild, die Koordinate der

Cursor-Region falsch zurückgegeben werden. Dies führt dann zur falschen

Zeichenerkennung von „Englisch―.

Außerdem sind die Namen der drei Test-Ordner alle mit großen Buchstaben.

Im ersten Testfall habe ich beschrieben, dass der Name des Liedes „Baby Be

Mine― manchmal falsch erkannt wird. Nach meiner Analyse ist der Grund

dafür, dass die Koordinate der Cursor-Region nicht immer genau richtig

bestimmt wird. Es gibt immer eine kleine Abweichung. Deswegen können die

Buchstaben, wie „y―, „g―, „j―, mit der Methode Zeichenerkennung jeweils als

„v―, „o―, „i― erkannt werden. Mit großen Buchstaben kann dieser Fehler

vermieden werden. Wegen der Länder-Varianten und der unterschiedlichen

Zeichenkodierungsstandards müssen die Lieder mit entsprechenden Standards

aufgebaut werden. Deswegen werden die drei Ordner „GB―, „HKBIG5― und

„TWBIG5― jeweils für Festland, Hongkong und Taiwan im USB-Stick erstellt.

Damit kann die TA einfach mit nur einem USB-Stick implementiert werden.

Das obere Code-Beispiel und folgende Abbildung sind Beispiele für den Test

mit der Länder-Variante Festland. Für die Tests für Hongkong oder Taiwan

kann man einfach mit dem entsprechenden Ordner-Namen den Name

„GB― ersetzen.

5. Testfälle


30

Abbildung 5.12: Testablaufdiagramm des zweiten Testfalls auf dem Festland

Test Start

Eintritt in das

Verzeichnis des

USB-Stick

Ordnername mit

OCR erkennen

Ja

ZBE einmal nach

rechts drehten bis

zum nächsten

Ordner

Nein

Eintritt in den

„GB― Ordner und

erstes Lied

auswählen

Die Information

des ersten Lieds als

Bild speichern

Vergleich des

gespeicherten Bildes

mit dem

entsprechenden

Referenzbild

Nein Test mit Fehler

beenden

Ja

Die Information

des nächsten Lieds

als Bild speichern

Vergleich des gerade


mit dem

entsprechenden

Referenzbild

Nein

Ja

Vergleich des aktuellen


mit allen gespeicherten

Bildern

Ja

Test ohne Fehler

beenden

Nein

„GB―?

entsprechen?

entsprechend?

Einmal

entsprechen?

5. Testfälle


31

5.3.3. Sortierung

5.3.3.1.Problem, Lösung und Verbesserung

Die folgende Tabelle zeigt jeweils ein Beispiel und die Analyse jeder Lösung:

Tabelle 5.1: Analyse und Konsequenz des Vergleiches drei Lösungen

Lösungsva

rianten

Lösung1 Lösung2 Lösung3

Beispiel

Analyse Damit ist es effizienter

und die Zeit der

Überprüfung kürzer.

Aber das Problem ist,

dass der Bildvergleich

falsch sein kann, obwohl

die Sortierung ganz

richtig ist. Der Grund

dafür ist, dass die Farbe

des Cursors das Ergebnis

des Bildvergleich

beeinflussen kann.

Von Vorteil ist, dass

man Speicher für

Referenzbilder

sparen kann. Wegen

dem Problem, das im

Kapitel 3.4.

beschrieben ist, ist

die Erkennung nicht

immer richtig. Somit

gibt es ein Risiko,

bei der Überprüfung

nicht sicher zu sein.

Mit dieser Methode

ist es zeitaufwändig

und die

Referenzbilder

müssen zuerst

erstellt werden. Das

Überprüfungsergeb

nis ist jedoch

sicherer als das mit

Lösung 1 und

Lösung 2.

Zusammen

-fassung

Anhand der oberen Analyse wird klar, dass Lösung 1 und Lösung 2

jeweils Zeit und Speicher sparen, während Lösung 3 jeweils viel Zeit

und Speicher verbraucht. Die Richtigkeit der Überprüfung ist jedoch

auf jeden Fall wichtiger. Deshalb ist die Lösung 3 auszuwählen.

Problem 1: wie die Überprüfung der

Sortierung implementiert werden kann.

Lösung 1:

Bildvergleich mit

mehreren Titel

Lösung 2:

Zeichenerkennung

Lösung 3:

Bildvergleich mit

einem Titel

5. Testfälle


32

Zur Lösung 3 sind zwei Varianten verfügbar.

- Erste Variante: zuerst werden die Namen aller Titel gespeichert. Dann

wird der gespeicherte Name mit dem entsprechenden Referenzbild

verglichen.

- Zweite Variante: nachdem ein Name des Titels gespeichert wird, wird

der gespeicherte Name sofort mit dem entsprechenden Referenzbild

verglichen.

Mit der ersten Variante ist das Programm, in dem nur zwei separaten For-

Schleifen benutzt werden, ganz einfach. Aber es ist nachteilig, dass es

zeitaufwändig ist. Im Vergleich dazu ist es effizienter mit der zweiten Variante.

Wenn der Name eines Titels nicht entspricht, wird das Programm sofort

beendet. Das Programm der zweiten Variante ist jedoch komplex. Es braucht

zwei verschachtelte For-Schleifen.

Verbesserung:

Um Fehler leichter zu analysieren wird noch eine Funktion eingesetzt:

Nachdem ein Fehler gefunden ist, wird das Programm nicht sofort beendet.

Zuerst wird noch geprüft, in welcher Position der Titel sein sollte oder ob es

kein entsprechendes Referenzbild von dem Titel gibt, was beides zur falschen

Anzeigen des Namens führen könnte. Damit muss man nicht manuell die falsch

gelegenen Titel suchen, sondern kann direkt den Grund für den Fehler

analysieren. Die Analysearbeit wird dadurch erleichtert.

Variante auswählen:

Um diese Funktion zu erfüllen ist noch eine For-Schleife nötig. Nicht nur mit

der ersten Variante sondern auch mit der zweiten braucht man bereits zwei

Schleifen. Deswegen wird die erste Variante ausgewählt. Der Grund dafür ist,

dass mit der zweiten Variante drei Schleifen verschachtelt werden müssten,

was zu einem komplexen Programm führen würde. Außerdem entfällt die

Verbesserung in der Zeit der zweiten Variante, weil das Programm mit der

Verbesserung nicht sofort beendet wird, sondern weiter läuft, um die

zusätzliche Funktion zu erfüllen, wenn ein Fehler gefunden ist.

5. Testfälle


33

5.3.3.2. Testablauf

In diesem Testfall wird die Sortierung der Namen der im USB-Stick

gespeicherten Lieder überprüft. Der Test läuft gemäß des Ablaufdiagramms

(Abb.: 5.13) ab.

Als ersten Schritt in diesem Testfall wird mit dem ZBEL6.Service zu Kategorie

„Alle Titel― navigiert. Dann werden die Namen aller Titel mit dem

MMI.Service (CursorRegion erkennen) und dem FrameGrabberL6.Service

(Screenshot und Bild speichern) sukzessiv als Bilder gespeichert. Nachdem die

Speicherung fertig ist, beginnt die Sortierungsüberprüfung mit der Methode

Bildvergleich.

Wegen der unterschiedlichen Sortierungsregeln vom Festland, Hongkong und

Taiwan werden drei verschiedene Ordner mit Referenzbildern vorbereitet.

Obwohl das Prinzip der Überprüfung leicht ist, nur die gespeicherten Bilder

mit den Referenzbildern zu vergleichen, ist der Prozess komplexer. Im

Vergleich zu den ersten zwei Testfällen ist die Überprüfung unterschiedlich.

Wie oben genannt wird das Programm nicht sofort gestoppt, wenn ein

Sortierungsfehler gefunden wurde. Die zusätzliche Funktion, deren Ergebnis

als Kommentar in der Log-Information steht, kann als Analyse betrachtet

werden.

5. Testfälle


34

Nein

Abbildung 5.13: Testablaufdiagramm des dritten Testfalls auf dem Festland

Test Start

Eintritt in das

Verzeichnis „Alle

Titel―

ZBE einmal nach

rechts drehen bis

zum ersten Titel in

der Titelsliste

Das Bild mit erstem

Titelname durch

FrameGrabber

speichern

Das Bild mit

Titelname durch

FrameGrabber

speichern



mit dem letzten

gespeicherten Bild

entsprechen?

ZBE einmal

nach rechts

drehen bis zum

nächsten Titel

Ja

Nein

Vergleich der

gespeicherten Bilder

mit den entsprechenden

Referenzbildern

entsprechen?

FehlerFlag ersetzen

Nein

Titel-Nummer plus

1

Ja

Vergleich der

Titel-Nummer mit

der Anzahl der

Lieder im USB-

Stick

>=

Ja

Nein

Test ohne Fehler

beenden

Das gerade

verglichene Bild mit

Referenzbild

sukzessiv vergleichen

entsprechen?

Ja

Nein

Kommentar: In welcher

Position der

Sortierungsliste soll der

Titel gelegt werden.

Nummer

plus 1

Nummer>=

Anzahl der Titeln?

Kommentar: Der

Name des Titels ist

nicht richtig gezeigt.

Ja

5. Testfälle


35

5.3.4. Speller und Suche

Zuerst werden die verschiedenen Arten von Speller der drei unterschiedlichen

Fahrzeug-Varianten beschrieben. Auf dem Festland und in Hongkong gibt es drei

verschiedenen Speller, sogenannt „Pinyin with conversion―, „Stroke with

conversion― und „Latin― (der dritte Speller auf dem Festland wird wegen der

besonderen Anforderung, die in Tabelle 4.2 im Kapitel 4.2 beschrieben ist,

„Pinyin/Latin― genannt), während es in Taiwan die Speller „BPMF with

conversion― und „Latin― gibt.

Diese unterschiedlichen Speller werden mit Bildern in folgender Tabelle gezeigt:

Speller

benutzt

Festland,

Hongkong

Festland,

Hongkong

Festland,

Hongkong,

Taiwan

Taiwan

Anzeige

von

Speller

Name

von

Speller

Pinyin with

conversion

Stroke with

conversion

Latin (auf dem

Festland

„Pinyin/Latin―)

BPMF with

conversion

Tabelle 5.2: Anzeige unterschiedlicher Speller

In diesem Kapitel beschreibe ich nur die Testautomatisierung vom Speller „Pinyin

with conversion―. Der Grund dafür ist, dass das Prinzip der TA von allen Speller

ähnlich ist.


Problem 1: wie wird Pinyin-String eingegeben

Lösung 1: Die Anzahl der Drehungen des ZBE nach rechts werden gezählt

und diese Zahl dann einfach im Programm verwendet. Damit wird ein

bestimmter Buchstabe eingegeben.

Vorteile:

- Das Programm ist sehr einfach zu schreiben

- Zeit wird gespart

- Funktioniert und hat bisher kein Fehler erzeugt

5. Testfälle


36

Nachteil:

- Das Programm ist nicht robust. Z.B. wird ein Fehler auftreten, wenn

das Symbol von Delete mit weißem Highlight erschienen ist (ohne

Highlight kann das Symbol nicht ausgewählt werden und die

Drehungsanzahl bleibt korrekt. D.h. mit Highlight ist die

Drehungsanzahl falsch und führt dann zu einem Fehler.).

Um den oberen genannten Nachteil zu vermeiden wird die folgende

Verbesserung benutzt.

Verbesserung: der Buchstabe wird jeweils mit OCR (Zeichenerkennung)

erkannt, wenn ZBE einmal nach rechts gedreht wurde.

Mit der Verbesserung ist das Programm robust, jedoch zeitaufwändig, weil

mehr als zwanzig Mal Screenshots und Zeichenerkennungen gemacht werden,

wenn der Buchstabe „Z― einzugeben ist.

Problem 2: wie kann man die Zeit sparen

Analyse: Aus dem Bild (erstes Bild in der Tabelle 5.2) kann man sehen, dass

die Drehungsanzahl mit der Reihenfolge von a bis z zu tun hat.

Reihenfolge 1 2 3 4 5 6 7 8 9 10 11 12 13

Buchstabe auszuwählen a b c d e f g h i j k l m

Drehungsanzahl 2 3 4 5 6 7 8 9 * 10 11 12 13

Reihenfolge 14 15 16 17 18 19 20 21 22 23 24 25 26

Buchstabe auszuwählen n o p q r s t u v w x y z

Drehungsanzahl 14 15 16 17 18 19 20 * * 21 22 23 24

Tabelle 5.3: Analyse der Beziehung zwischen Reihenfolge und Drehungsanzahl

(Mit Stern * bedeutet, dass diese Buchstaben nicht ausgewählt werden kann. Der Grund dafür

ist im Kapitel 4.1.2.1 erklärt.)

Aus der oberen Tabelle und dem Nachteil der ersten Lösung ist die

Konsequenz:

Drehungsanzahl ∈ [Reihenfolge minus drei, Reihenfolge plus drei]

Lösung 2:

In der zweiten Lösung sind zwei Varianten verfügbar.

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0060

a b c d e f g h i j k l m n o

0070 p q r s t u v w x y z

Tabelle 5.5: die Buchstaben a bis z in Unicode-Tabelle

5. Testfälle


37

Variante 1 Variante 2

Inhalt Die Buchstaben a bis z

werden sukzessiv in

einer Liste abgelegt.

Die Position des

Buchstabens in der

Liste steht für die

Reihenfolge. (Im

Programm beginnen die

Positionen der Liste bei

0. Deshalb darf man im

Programm nicht

vergessen, die Position

plus eins zu rechnen.)

In der Programmiersprache

Python gibt es eine Funktion

„ord―, mit der der Buchstabe

oder das Zeichen nach

Unicode umgewandelt werden

kann. (In der Tabelle 5.5

stehen die Entsprechung von

lateinischen Buchstaben und

Unicode, die Zahlen sind

hexadezimal.)

Beispiel: das Ergebnis der

Funktion ord(‚n‘) ist die ganze

Zahl 110.

ord(‚n‘)-961 = 14, es ist die

Position des Buchstabes „n― in

der Gruppe „A bis Z―.

Analyse Im Vergleich der ersten Variante mit der zweiten

Variante ist das Programm mit Variante 2 viel einfacher

zu erfüllen. Beispielweise kann man das Programm so

schreiben:

ZBEL6.Right(0.1, (ord(‚n‘)-96))

Man muss damit keine Liste erstellen und kann so

Speicher sparen.

Zusammenfassung Nach der Analyse ist die zweite Variante auszuwählen.

Tabelle 5.4: zwei Varianten der zweiten Lösung

5.3.4.2.Testablauf

In diesem Testfall ist das Suchergebnis zu überprüfen. Der Test läuft gemäß

des Ablaufdiagramms (Abb.: 5.14) ab.

Als ersten Schritt in diesem Testfall wird mit dem ZBEL6.Service zur

Kategorie „A – Z Suche― navigiert. Dann ist die Umschrift (z.B. Pinyin with

conversion) auszuwählen. Nachdem die Umschrift eingestellt wurde, wird der

Pinyin-String (z.B. „ni―) mit der Funktion „ord― und Zeichenerkennung

eingegeben. Danach ist das chinesische Zeichen mit der Methode Bildvergleich

zu finden und auszuwählen. Zum Schluss ist mit dem Bildvergleich das

aktuelle Ergebnis mit dem Referenzbild zu vergleichen.

196: (0060)16 = (96)10. Z.B. der Unicode des Buchstabes a ist (0061)16, wenn die Zahl minus (0060)16 oder (96)10

rechnet wird, entspricht die erworbene Zahl die Position des Buchstabes a in der Gruppe „A bis Z―.

5. Testfälle


38

Nein

Nein

Ja

Nein

Abbildung 5.14: Testablaufdiagramm des vierten Testfalls auf dem Festland

Test Start Eintritt in das

Verzeichnis „A-Z

Suche―

ZBE einmal nach rechts

schieben und Eintritt in

das Verzeichnis

„Umschrift Auswahl―

Umschrift „Pinyin with

Conversion― auswählen

„n― mit ord-Funktion

im Python nach

Unicode umwandeln

ZBE viermal nach

links drehen

ZBE (ord(‚n‘)-96) mal

nach rechts drehen

Den ausgewählten

Buchstaben mit OCR

erkennen

„n―?

ZBE einmal nach

rechts drehen

Nr1 >=2?

Nr1 += 1

Nr2 ==0?

Nr2 += 1

ZBE einmal nach

links drehen

Nein

Ja

Nr2 += 1

Nr2 >3?

Ja

Ja

FehlerFlag ersetzen und

Kommentar: der

Buchstabe „n― kann nicht

gefunden werden

Press-Funktion von

ZBE simulieren, um

die Buchstabe

„i― einzugeben

Nochmal Press-Funktion

von ZBE simulieren, um

den Pinyin-String

„ni― auszuwählen

Das Bild mit ausgewählten

chinesischen Zeichen durch

FrameGrabber speichern


gespeicherten Bildes mit

dem Referenzbild

entsprechen? ZBE einmal nach

rechts drehen

Nein

Ja

Das chinesische Zeichen

auswählen und ZBE nach

links schieben

Das Bild mit Suchergebnis

durch FrameGrabber

speichern


gespeicherten Bildes mit

dem Referenzbild

entsprechen?

Ja

Test ohne Fehler beenden

Test mit Fehler beenden

Nein

5. Testfälle


39

5.4. Auswertung Zur Auswertung des Testfalls kann bei aufgetretenen Fehlern das Logfile analysiert

werden. Die Logfiles liegen im Unterordner „logs― auf der Ebene der Testfälle. Für

jeden Testfall wird ein separates Logfile angelegt. Im Gutfall hat der Dateiname den

Zusatz „OK―, im Fehlerfall „FAILED―.

Im Folgenden sind zwei Ausschnitte als Beispiele für Logfiles: das erste ist, dass

Testfall (China_Festland_Sortierung) mit Fehler beendet wurde und der andere

(China_Festland_Pinyin) beendet ohne Fehler.

15:52:17.885 msc Begin: Testcase

15:52:26.338 info ZBEControl is gone

15:52:28.541 info, seq FBBluetoothS: did not receive status for

function ManualConnectRequired

15:58:25.582 error The 19th title should be in 20th position

sorted

15:58:26.457 error The 20th title should be in 19th position

sorted

15:58:27.573 msc, error Testcase failed, test stopped Error flag

set.

Aus dem oberen Ausschnitt des Logfile ist deutlich, dass es zwei Fehler in diesem

Testfall gibt. Nach den Error-Informationen kann man einfach die fehlende Bilder

nachschauen und damit den Grund dieser Fehler analysieren.

16:20:43.195 msc Begin: Testcase

16:20:43.351 info Select the speller with 'Pinyin with

conversion'

16:20:43.523 info A-ZSearch

16:21:00.148 info Set the speller with 'Pinyin with conversion'

16:21:00.148 info Input a pinyin-string 'ni'

16:21:01.085 info Input_Letter1 =[u'I1']

16:21:03.491 info select the pinyin-string 'ni'

16:21:05.960 info select the chinese character 'ni'

16:21:08.882 info the result of search are stored

16:21:11.100 info save the image China_Mainland_Pinyin

16:21:11.475 info Pinyin Search in China_Mainland is correct

16:21:11.475 msc Testcase passed

In dieser Log-Information steht der Satz „Testcase passed―, d.h. der Testfall beendet

ohne Fehler. Deshalb ist es unnötig, diesen Testfall nochmal zu überprüfen.

6. Zusammenfassung


40

6. Zusammenfassung

Ziel dieser Arbeit ist es die speziellen Anforderungen der Multimediafunktionen in den

aktuellen Serien Head Units von BMW in asiatischen Fahrzeug-Varianten zu analysieren

und daraus ableitend automatisierte Testfälle zur Überprüfung der korrekten

Implementierung zu erstellen.

Als gemeinsame Datengrundlage für den Test-USB-Stick sind die Testlieder mit

bestimmten Ordner-Namen für die entwickelten Testfälle entstanden. Außerdem sind die

Referenzbilder mit bestimmter Ordner-Struktur für die Testskripts erstellt.

Resultierend aus dieser Arbeit liegen nun siebzehn Testfälle (sechs für Festland, sechs für

Hongkong und fünf für Taiwan) vor, die die speziellen asiatischen Multimediafunktionen

des aktuellen Serienstands überprüfen. Die Vorteile des automatisierten Testens der

Multimediafunktion sind klar erkennbar. Mit der Testautomatisierung wird ohne

manuellen Eingriff Coverart, die Anzeige der mit bestimmtem Zeichenkodierungsstandard

kordierten Lieder sowie die Sortierung aller Titel und die Suchergebnisse überprüft. Mit

gleicher Genauigkeit könnte dies manuell nicht getestet werden. Bei einer großen Anzahl

von Liedern treten beim manuellen Testen unweigerlich Fehler auf, die bei einer TA nicht

auftreten. Außerdem kann die TA über Nacht oder am Wochenende durchgeführt werden,

damit kann die Zeit der Mitarbeiter gespart werden.

Bei dem Umfang der Lieder auf dem USB-Stick ist es egal, ob dieser nur ein paar wenige

Lieder enthält oder mehrere tausend. Selbstverständlich muss man die Referenzbilder

erneuern, wenn sich die Lieder auf dem USB-Stick verändern.

Die Ausführungszeit des Testfalls bei Coverart Überprüfung beträgt wegen

unterschiedlicher Sortierung ca. zwei Minuten auf dem Festland, während etwa fünf

Minuten in Hongkong bzw. Taiwan benötigt werden. Mit der Zunahme der auf dem USB-

Stick gespeicherten Lieder kann die Ausführungszeit sich absolut erhöhen aber nicht

proportional. Deswegen könnte man die Ordner-Struktur auf dem USB-Stick ändern und

einen neuen Ordner mit dem Name Coverart erstellen, in dem das Lied „Baby Be

Mine― abgelegt wird. Damit kann die Ausführungszeit abnehmen und die Zeit ist nicht

mehr abhängig von der Anzahl der Lieder, die für die anderen Tests benötigt werden.

Die Ausführungszeit bei Anzeige der nach bestimmtem Zeichenkodierungsstandard

kodierten Lieder ist ca. zwei Minuten in allen drei Länder-Varianten. Die Zeit ist abhängig

von den oberen gerade genannten Liedern.

Beim Testfall „Suchergebnis überprüfen― beträgt die Ausführungszeit aller Länder-

Varianten etwa ein Minute und zehn Sekunden. Die Zeit hat keine Beziehung zu der

Anzahl der auf dem USB-Stick gespeicherten Lieder.

6. Zusammenfassung


41

Bei der Überprüfung der Sortierung liegt die Ausführungszeit deutlich höher. Aufgrund

der zahlreichen Screenshots, Erkennung der Cursor-Region und Ausschnitten sowie der

Wartezeiten dazwischen und Überprüfung aller Titel, dauert der Testfall bis zu ungefähr

sieben Minuten für alle Varianten. Selbstverständlich ist diese Ausführungszeit abhängig

von der Anzahl der Lieder. Daraus ergibt sich eine Ausführungszeit bei tausend Liedern

von etwa zwei Stunden.

Die Reportfunktion erweist sich als ein ausgezeichnetes Mittel, um zum Schluss eines

größeren Testfalls, schnell Aufschluss über das Testergebnis zu erhalten.

6.1. Problem und mögliche Lösungsvarianten Im Verlauf der Bachelorarbeit bin ich auf viele Probleme und Hindernisse gestoßen

und meistens habe ich gelöst. Noch ein Problem wird nicht gelöst, aber ich habe mir

dazu zwei Variantenvorschläge überlegt. Das Problem und die Lösungsvarianten, die

ich dazu erdacht habe, sind in folgenden Unterkapiteln beschrieben.

6.1.1. Problem

In der Überprüfung der Sortierung gibt es ein Problem, weil die Methode

Bildvergleich für die Überprüfung benutzt wird. Zuerst ist die folgende Bildgruppe

entstanden. Diese Bilder sind von fünf Positionen, in der der Cursor auftreten kann,

im Bildschirm mit der Cursor-Region ausgeschnitten.

Position Bild

1

2

3

4

5

Tabelle 6.1: Bilder von unterschiedlichen Cursor-Positionen

Aus den oberen Bildern kann man sehen, dass der schwarze Teil in der Mitte des

Bildes vom ersten Bild bis zum fünften Bild immer nach oben wandert. Dies führt

zu einer Beeinflussung der Methode Bildvergleich. Um die Beeinflussung zu

bestätigen, werden diese Bilder jeweils mit andere verglichen. Das Ergebnis ist in

der folgenden Tabelle ergänzt:

6. Zusammenfassung


42

1 2 3 4 5

1 - In 3369 Pixel In 7863 Pixel In 10087 Pixel In 12200 Pixel

2 - - In 3558 Pixel In 7383 Pixel In 10076 Pixel

3 - - - In 3350 Pixel In 8133 Pixel

4 - - - - In 3266 Pixel

5 - - - - -

Tabelle 6.2: Vergleichsergebnisse der Bilder in der Tabelle 6.1

Aus der oberen Tabelle ist es deutlich, dass das Ergebnis des Vergleiches falsch

zurückgegeben wird, obwohl gleiche Zeichen in dieser Cursor-Region stehen.

Glücklicherweise ist dieser Fehler in der Testautomatisierung selten aufgetreten.

Es ist jedoch nötig ihn zu lösen, damit das Programm sicher und robust ist.

6.1.2. Lösungsvarianten

In der Testautomatisierung gibt es momentan zwei Methoden, um die Testfälle

durchzuführen, Zeichenvergleich mit der Zeichenerkennung und Bildvergleich.

Deshalb habe ich mir zwei Varianten überlegt.

Erste Variante: für die Titel mit lateinischen Buchstaben wird die

Zeichenerkennung benutzt, während der Bildvergleich weiterhin für die Titel mit

chinesischen Zeichen verwendet wird.

Obwohl es das Problem nicht vollständig lösen kann, reduziert es die

Auftrittswahrscheinlichkeit des oben beschriebenen Fehlers.

Zweite Variante: die Bilder werden zuerst gefiltert, d.h. der Rot- und Schwarz-

Teil wird in die gleiche Farbe (vollständig rot) umgewandelt. Dann wird die

Methode Bildvergleich verwendet.

Damit kann das Problem vollständig gelöst werden.

6.2. Ausblick

6.2.1. Mögliche Verbesserung und Erweiterungen

In diesen Testfällen sind viele Referenzbilder nötig und man muss die

Referenzbilder verändern, wenn die auf dem USB-Stick gespeicherten

Lieder gewechselt werden oder die Anforderungen an die Funktionen sich

ändern. Deswegen ist ein Programm, das Referenzbilder erstellen kann,

nützlich und sinnvoll. Damit muss man nicht manuell diese Bilder

anfertigen. Außerdem ist die Erzeugung der Bilder durch ein Programm

genauer als durch manuelle Erstellung.

6. Zusammenfassung


43

Im meinen Programm gibt es eine Beschränkung, dass die Titelnamen der

benutzten Lieder verschieden sein müssen, weil eine Bedingung im

Programm verwendet wird, um zu erkennen, ob alle nötigen Bilder bereits

gespeichert sind, z.B. in der Abb. 5.13 mit blauem Rahmen gekennzeichnet.

Um diese Beschränkung aufzuheben, muss man die Referenz ändern und

nicht das Bild sonder die Koordinate vergleichen.

Wenn es weniger als fünf Test-Lieder gibt, sind die Koordinaten dieser mit

Cursor ausgewählten Titelnamen unterschiedlich. Aber die Koordinaten

der nach dem fünften Titelnamen stehenden Titelnamen sind immer gleich

wie die vom fünften Titelname. D.h. dies kommt daher das beim

Weiterdrehen des ZBE das nächste Lied immer an der fünften Stelle im

Bildschirm erscheint. Die Veränderung der Koordinate ist nur aufgetreten,

wenn der Cursor von vorletztem Titelname bis letztem Titelname wandert.

Deshalb kann die Veränderung verwendet werden, um das Programm zu

verbessern. Selbstverständlich gibt es eine Bedingung, dass die

Koordinaten der ersten fünf Titelnamen gefiltert werden müssen.

Im Folgenden beschreibe ich, eine mögliche Verbesserung ist für den

Testfall Suchergebnis mit der Umschrift „BPMF with conversion―. Weil

der Buchstabe von BPMF nicht lateinisch sondern ähnlich wie ein Zeichen

ist, kann man nicht die oben genannte Methode benutzen, die für „Pinyin

with conversion― (sehe Kapitel 5.3.4.1) benutzt wird. Deswegen muss eine

neue Methode gesucht werden und bisher habe ich noch keine Idee dafür

gefunden.

Eine zusätzliche mögliche Erweiterung ist, dass diese Testfälle für alle

Ländervarianten einmal automatisch überprüft werden können. D.h. man

muss nicht zwischen den Testfällen die Ländervariante manuell kodieren.

Die Voraussetzung dafür ist allerdings, dass der TAF-Service die Funktion,

mit der die HU automatisch nach anderen Ländervariante kodiert werden

kann, vollständig unterstützt.

6.3. Fazit Im Rahmen dieser Arbeit konnten erfolgreich Testfälle entwickelt werden, die die

Anforderungen der speziellen asiatischen Multimediafunktionen automatisch testen.

Die daraus resultierende Zeitersparnis, gegenüber dem manuellen Testen ist vorteilig

für die Abteilung. Im Vergleich zum manuellen Testen ist die Testautomatisierung

auch wesentlich genauer. Dadurch ist die Fehlerrate, die vom Benutzer verursacht

werden und nicht Softwarefehler sind, geringer. Nach der Analyse können die

Verbesserungsideen und Erweiterungsideen im nächsten Schritt umgesetzt werden.

7. Glossar


44

7. Glossar

BPMF Bopomofo: Es ist eine nichtlateinische, phonetische

Transkription für die chinesischen Schriftzeichen. Momentan ist

diese Umschrift in Taiwan üblich benutzt.

CAN Controller Area Network

CID Central Information Display

CJK China Japan Korea

Cursor Bezeichnet in dieser Arbeit den roten Auswahlrahmen für

Menüpunkte in der BMW-HMI.

GB Guojia Biaozhun: das Kürzel für nationale Normen in China

GSIM Gerätesimulation

HMI Human Machine Interface

HU Head Unit: Zentrales Infotainmentsteuergerät zur Darstellung

und Verarbeitung der Informationen. Der Großteil der

Infotainment Software, wie z.B. Navigation, Radio, Multimedia

und so weiter laufen auf diesem Steuergerät.

KuZu Kunden Zugang

MOST Media Oriented Systems Transport

MSC Mass Storage Class

OCR Optical Character Recognition (Optische Zeichenerkennung)

Softwarefunktion zur Erkennung von Zeichen aus

Bildinformationen

PIL Python Imaging Library

Pinyin Romanisierung von chinesischen Schriftzeichen. D.h. die

Aussprache der chinesischen Zeichen wird durch lateinische

Buchstaben dargestellt.

QC Quality Center

SIA Snap in Adapter

TA Testautomatisierung

http://de.wikipedia.org/wiki/Phonem

http://de.wikipedia.org/wiki/Transkription_%28Schreibung%29


http://de.wikipedia.org/w/index.php?title=Guojia_Biaozhun&action=edit&redlink=1

7. Glossar


45

TAF Testautomatisierungsframework

TAQT Testautomatisierung – QTInterface

ZBE Zentrales Bedienelement

ZGW Zentrale Gateway

5 Strokes Eine Art der Umschrift von chinesischen Zeichen. Mit

unterschiedlichen grundlegenden Strichen und verschiedener

Reihenfolge der Eingaben dieser Striche können

unterschiedliche chinesische Zeichen zusammengebaut werden.

8. Abbildungsverzeichnis


46

8. Abbildungsverzeichnis

Abbildung 2.1: Aufbau der Testumgebung .................................................................. 6

Abbildung 2.2: TAQT-Interface ................................................................................... 10

Abbildung 4.1: Beispiel der Sortierung nach der Anforderung auf dem Festland ....... 18

Abbildung 5.1: Diagramm des Testfallaufbaus ............................................................ 20

Abbildung 5.2: Log-Informationen in der Vorbedingung ............................................ 21

Abbildung 5.3: Log-Informationen in der Nachbedingung .......................................... 22

Abbildung 5.4: Verbesserung des Programms im ersten Testfall ................................ 24

Abbildung 5.5: Titellistenansicht im Bildschirm ......................................................... 24

Abbildung 5.6: Testablaufdiagramm des ersten Testfalls auf dem Festland ................ 25

Abbildung 5.7: Anzeige von Coverart auf dem Festland und in Taiwan ..................... 26

Abbildung 5.8: keine Anzeige von Coverart in Hongkong .......................................... 26

Abbildung 5.9: Anzeige des von GB kordierten Liedes ............................................... 28

Abbildung 5.10: Verbesserung des Programms im zweiten Testfall ........................... 28

Abbildung 5.11: Anzeige des Ordnerverzeichnisses im USB-Stick ........................... 29

Abbildung 5.12: Testablaufdiagramm des zweiten Testfalls auf dem Festland............ 30

Abbildung 5.13: Testablaufdiagramm des dritten Testfalls auf dem Festland.............. 34

Abbildung 5.14: Testablaufdiagramm des vierten Testfalls auf dem Festland............. 38

9. Tabellenverzeichnis


47

9. Tabellenverzeichnis Tabelle 4.1: Beispiel der Umwandelung der chinesischen Zeichen in der HU………. 18

Tabelle 4.2: Anforderung für das Festland …………………………………………... 19

Tabelle 4.3: Anforderung für Hongkong …………………………………………….. 19

Tabelle 4.4: Anforderung für Taiwan ………………………………………………... 19

Tabelle 5.1: Analyse und Konsequenz des Vergleiches drei Lösungen ……………... 31

Tabelle 5.2: Anzeige unterschiedlicher Speller …………………………………….... 35

Tabelle 5.3: Analyse der Beziehung zwischen Reihenfolge und Drehungsanzahl…... 36

Tabelle 5.5: die Buchstaben a bis z in Unicode-Tabelle …………………………….. 36

Tabelle 5.4: zwei Varianten der zweiten Lösung ……………………………………. 37

Tabelle 6.1: Bilder von unterschiedlichen Cursor-Positionen ……………………….. 41

Tabelle 6.2: Vergleichsergebnisse der Bilder in der Tabelle 6.1…………………….. 42

10. Literaturverzeichnis


48

10. Literaturverzeichnis [1] Markus Dahm. Grundlagen der Mensch-Computer-Interaktion: Fallbeispiel

Infotainment-Center im Auto. 2006.

[2] Fraunhofer, Software im Auto – Variantenvielfalt im Griff.

http://www.fraunhofer.de/de/presse/presseinformationen/2010/02/embedded-world-

software-im-auto.html , 2010.

[3] Berner & Mattner Systemtechnik GmbH. Unternehmenspräsentation. www.berner-

mattner.com , 2012.

[4] Andreas Grzemba. MOST: Das Multimedia-Bussystem für den Einsatz im Automobil.

2007.

[5] Lorena Diaz Ortega. Physical Layer Modellierung der Bussysteme CAN und FlexRay

im Kraftfahrzeug. 2005

[6] Manfred Krüger. Grundlagen der Kraftfahrzeugelektronik. 2004

[7] Hans-Jürgen Gevatter, Ulrich Grünhaupt. Handbuch der Mess- und

Automatisierungstechnik im Automobil. 2006

[8] Alexander Wolf. TAF Tutorial. BMW AG. 2010.

[9] Thomas Rudolph. MMP-Wiki-TAQT Interface. BMW AG, 2012

[10] Wikipedia. GB18030 — wikipedia, die freie enzyklopädie.

http://de.wikipedia.org/wiki/GB18030 , 2010.

[11] Wikipedia. Big5 — wikipedia, die freie enzyklopädie.

http://de.wikipedia.org/wiki/Big5 , 2012.

[12] Wikipedia. HKSCS — wikipedia, die freie enzyklopädie.

http://de.wikipedia.org/wiki/HKSCS , 2011.

[13] Wikipedia. Pinyin — wikipedia, die freie enzyklopädie.

http://de.wikipedia.org/wiki/Pinyin , 2012.

[14] Wikipedia. Bopomofo — wikipedia, die freie enzyklopädie.

http://de.wikipedia.org/wiki/Bopomofo , 2012.

http://www.fraunhofer.de/de/presse/presseinformationen/2010/02/embedded-world-software-im-auto.html

http://www.fraunhofer.de/de/presse/presseinformationen/2010/02/embedded-world-software-im-auto.html

http://www.berner-mattner.com/

http://www.berner-mattner.com/

http://de.wikipedia.org/wiki/GB18030

http://de.wikipedia.org/wiki/Big5

http://de.wikipedia.org/wiki/HKSCS

http://de.wikipedia.org/wiki/Pinyin

http://de.wikipedia.org/wiki/Bopomofo

Documents

Testautomatisierung für die Absicherung der … · With the development of software technology in recent years the use of a computer control ... Testautomatisierung in asiatische