-
Die vorliegende Erfindung betrifft ein Verfahren zur automatisierten Fehleridentifikation und/oder Fehlerverifikation von Hardware/Software-Systemen (HW/SW-Systemen) mit Hilfe von Testvorrichtungen.
-
Testobjekte müssen vielfach im Hinblick auf Ihre erwartungsgemäße Funktionsweise getestet werden. Beispielsweise müssen derartige Tests vor der Inbetriebnahme, während entsprechend vorbestimmten Wartungsintervallen, im Fall von besonderen Wartungsmaßnahmen oder teilweise auch fortlaufend während des regulären Betriebs durchgeführt werden. Das umfasst sowohl einzelne Hardwarekomponenten des jeweiligen Testobjekts als auch die jeweils zugrundeliegenden Softwarekomponenten. Beispielsweise muss ein Testobjekt bei der Einführung einer neuen Firmware-Version dahingehend getestet werden, ob alle Funktionen auch nach Änderung der Firmware noch erwartungsgemäß ausgeführt werden. Derartige Tests werden beispielsweise auch durchgeführt, um schadhafte Komponenten (Hardware und/oder Software) zu identifizieren.
-
Bei bekannten Testverfahren werden durch ein Steuergerät vorbestimmte Testabfragen (Testroutinen) an das Testobjekt gesendet und die erhaltenen Antworten mit Erwartungswerten verglichen. Daraufhin erfolgt für die Abfrage eine jeweilige Auswertung im Hinblick darauf, ob der Test bestanden wurde oder fehlerhaft ist. Allerdings sind derartige Testobjekte gewöhnlicher Weise im Hinblick auf viele verschiedene Merkmale zu testen. Deshalb wird häufig eine Vielzahl verschiedener Testroutinen durchgeführt und diese einzeln geprüft. Dann muss der Nutzer fehlerhafte Tests oder erfüllte Tests einzeln abgleichen, was unkomfortabel ist.
-
Falls bei einem Test ein Fehler auftritt, ermöglichen es bekannte Testverfahren nicht ohne weiteres, den Fehler unmittelbar zu identifizieren. Unklar ist dann, bei welchem exakten Teilschritt des Tests genau der Fehler auftritt. Dies ist von umso größerer Bedeutung, wenn der gesamte Testprozess eine Vielzahl von einzelnen Testroutinen umfasst. Das erschwert es dem Nutzer festzustellen, ob eine bestimmte Hardwarekomponente oder eine Softwarekomponente des Testobjekts fehlerhaft ist.
-
Zudem kann auch die Testroutine, also die Abfrage oder der vorgegebene Erwartungswert selbst fehlerhaft sein. Insgesamt ist die Fehlersuche dadurch aufwendig und unkomfortabel. Auch bei der Fehlerverifikation zeigen bekannte Testverfahren Nachteile, da sie nicht die Möglichkeit bieten, einen vermuteten fehlerhaften Teilaspekt des Testverfahrens zuverlässig zu verifizieren.
-
Es besteht daher ein Bedürfnis dafür, ein Verfahren bereitzustellen, das bezüglich der Fehleridentifikation gegenüber bekannten Testverfahren verbessert ist. Bevorzugt ist das Verfahren auch im Hinblick auf den Bedienkomfort gegenüber bekannten Testverfahren verbessert.
-
Die objektive technische Aufgabe, die zu lösen ist, kann darin gesehen werden, ein Verfahren bereitzustellen, mittels dem die Nachteile des Stands der Technik ausgeräumt oder zumindest verringert werden können.
-
Die Aufgabe wird durch den Gegenstand des unabhängigen Patentanspruchs gelöst. Vorteilhafte Ausführungsformen und Aspekte sind in den abhängigen Ansprüchen und der folgenden Beschreibung angegeben, von denen jede/jeder für sich oder in (Sub-)Kombination Aspekte der Offenbarung darstellen kann. Sämtliche fakultativen Merkmale können auch tatsächliche Merkmale der Erfindung sein, sofern die jeweilige (Sub)-Kombination eine vorteilhafte Weiterbildung darstellt.
-
Gemäß einem ersten Aspekt wird ein Verfahren zur automatisierten Fehleridentifikation und/oder Fehlerverifikation von Hardware/Software-Systemen (im Folgenden: HW/SW-Systemen) bereitgestellt. Insbesondere werden die Fehler mit Hilfe von Testvorrichtungen identifiziert und/oder verifiziert. Das HW/SW-System stellt ein Testobjekt dar. Die Testvorrichtung ist eingerichtet, um zumindest eine Testroutine (Software-Modul) bezüglich des HW/SW-Systems anzuwenden und es basierend auf der Testroutine zu testen. Das HW/SW-System umfasst zumindest eine Kommunikationsschnittstelle und ist mittels der Kommunikationsschnittstelle über zumindest einen Feldbus mit einem Steuergerät gekoppelt. Das Steuergerät ist insbesondere Teil der Testvorrichtung.
-
Das Verfahren umfasst zumindest den Schritt des Initiierens einer Mehrzahl an Testroutinen durch das Steuergerät. Jede Testroutine umfasst zumindest eine Abfrage und eine zugeordnete erwartete Reaktionsantwort des Testobjekts als Folge der Abfrage. Für jede Abfrage werden Daten an das Testobjekt übermittelt.
-
Das Verfahren umfasst zudem den Schritt des Empfangens von Daten, die von dem Testobjekt als Resultat einer Testroutine bereitgestellt werden, also in Reaktion auf die Abfrage der jeweiligen Testroutine.
-
Ferner umfasst das Verfahren den Schritt des Erstellens eines einzelnen Gesamttestreports für alle durchgeführten Testroutinen. Der Gesamttestreport basiert auf allen in Bezug für jede der mehreren Testroutinen empfangenen Daten sowie auf allen in Bezug für jede der mehreren Testroutinen an das Testobjekt übermittelten Daten. Der Gesamttestreport ist eingerichtet, um zumindest eine Verweismarkierung auf zumindest eine fehlerhafte Reaktionsantwort des Testobjekts zu umfassen, sofern zumindest eine Reaktionsantwort des Testobjekts nicht mit einer entsprechenden zugeordneten erwarteten Reaktionsantwort übereinstimmt, wodurch eine fehlerhafte Reaktionsantwort des Testobjekts gegeben ist.
-
Außerdem umfasst das Verfahren den Schritt des Ausgebens des Gesamttestreports an einer Mensch-Maschine-Schnittstelle. Bei einem Aufruf einer Verweismarkierung an der Mensch-Maschine-Schnittstelle werden mindestens die fehlerhafte Reaktionsantwort des Testobjekts und die Abfrage, deren fehlerhafte Reaktionsantwort nicht mit der zugeordneten erwarteten Reaktionsantwort übereinstimmt, an der Mensch-Maschine-Schnittstelle ausgegeben.
-
Vorliegend umfasst das HW/SW-System als Testobjekt irgendeine zu testende Software-Anwendung oder irgendeine zu testende Hardware-Vorrichtung sowie ebenfalls eine mögliche Kombination von solchen Anwendungen und/oder Vorrichtungen. Insbesondere kann das HW/SW-System eine eingebettete (embedded) elektrische oder elektronische Vorrichtung sein.
-
Die Testvorrichtung kann eine Software-Anwendung umfassen, die einen Testprozess (Testroutine) für das HW/SW-System (Testobjekt) darstellt. Mittels der Software-Anwendung wird das HW/SW-System (Testobjekt) also im Hinblick auf irgendein Merkmal getestet. Dies kann ebenfalls die Prüfung der Software-Anwendung der Testvorrichtung selbst umfassen.
-
Die Kombination aus HW/SW-System (Testobjekt) und Testvorrichtung kann als Gesamtsystem angesehen werden, insbesondere als Gesamtsystem bezüglich dieser Testumgebung.
-
Unter einer Testroutine wird im vorliegenden Zusammenhang ein Datenaustausch (auch genannt Input/Output-Benutzereingaben; im Folgenden: I/O-Benutzereingaben) mit dem HW/SW-System (Testobjekt) verstanden, um das HW/SW-System (Testobjekt) dahingehend zu prüfen, ob es das erwartete Verhalten zeigt. Die Testroutine kann insbesondere eine zuvor erwähnte Software-Anwendung sein, die computerimplementiert ausgeführt wird. Die Testroutine kann auch in einer Programmiersprache verfasst sein, beispielsweise C++, Python, Ruby, .NET, Java, JavaScript, Scala oder ähnliche.
-
Unter einer Kommunikationsschnittstelle wird vorliegend irgendeine Vorrichtung des Testobjekts (HW/SW-Systems) verstanden, die eine Dateneingabe in einen Feldbus oder einen Datenempfang von einem Feldbus erlaubt. Beispielsweise kann ein GPIO dazu genutzt werden. Der Standard des Feldbusses kann beispielsweise TCP/IP oder ein anderer Kommunikationsstandard sein. Die Daten können analog oder digital sein. Die Daten können eine gerichtete Kommunikation (individuelle Adressen) umfassen oder als eine Broadcast-Nachricht übermittelt werden.
-
Als ein Steuergerät kann vorliegend eine die Testroutinen auslösende Teilkomponente der Testvorrichtung verstanden werden. Beispielsweise kann das Steuergerät eine speicherprogrammierbare Steuerung (SPS) umfassen. Das Steuergerät kann eingerichtet sein, um Testroutinen auch im Hinblick auf Echtzeitanforderungen auszuführen. Ferner kann das Steuergerät mit der Mensch-Maschine-Schnittstelle gekoppelt sein, um Eingaben entgegenzunehmen, beispielsweise das Aufrufen einer Verweismarkierung. Das Steuergerät kann zudem weitere Daten an das HW/SW-System (Testobjekt) übermitteln, beispielsweise um das Testobjekt entsprechend einer erforderlichen Konfiguration zu konfigurieren.
-
Die Mensch-Maschine-Schnittstelle kann beispielsweise ein Computer sein, aber auch ein Mobilgerät, das mit dem Steuergerät kommunizieren kann.
-
Das so eingerichtete Verfahren stellt einen verbesserten Nutzerkomfort bereit. Es ermöglicht die automatisierte und präzise Fehleridentifikation, und zwar nicht nur in Bezug auf das HW/SW-System (Testobjekt), sondern auch in Bezug auf die Testvorrichtung und die von ihr angewendeten Testroutinen. Dem Nutzer wird die Möglichkeit gegeben, den Fehler auch in Bezug auf die Einzelschritte einer Testroutine zu lokalisieren. Zudem können auftretende Fehler präzise bestimmt werden. Dazu werden Verweismarkierungen genutzt, mittels denen die zum Fehler zugehörigen Informationen aufgerufen und ausgegeben werden können. Dadurch kann eine aufwendige Fehlersuche entfallen, so dass der Fehler, verglichen mit bekannten Testverfahren, in kürzerer Zeit identifiziert und/oder verifiziert werden kann.
-
Optional kann das Verfahren auch den Schritt des Erstellens eines elektronischen Teiltestreports für jede Testroutine durch das Steuergerät umfassen. Jeder Teiltestreport wird dann basierend auf den in Bezug für die jeweilige Testroutine durch das Testobjekt bereitgestellten Daten sowie basierend auf den in Bezug für die jeweilige Testroutine an das Testobjekt übermittelten Daten erstellt. Die Teiltestreports ermöglichen eine bessere Unterteilung des Gesamttestreports. Dadurch kann die Fehleridentifikation und Fehlerverifikation noch präziser ermöglicht werden.
-
Weiterhin kann das Verfahren den Schritt des Aggregierens der in Bezug auf alle durchgeführten Testroutinen empfangenen Daten durch das Steuergerät umfassen, so dass der einzelne Gesamttestreport alle Teiltestreports umfasst. Bevorzugt können die Teiltestreports zusammen mit dem Gesamttestreport an der Mensch-Maschine-Schnittstelle ausgegeben werden. Somit wird dem Nutzer eine Gesamtübersicht für alle Teiltestreports zur Verfügung gestellt. Dadurch wird es dem Nutzer ermöglicht, vorhandene Fehler schon in der Übersicht auf bestimmte Abschnitte des Testverfahrens zu begrenzen. Schon auf den ersten Blick kann der Nutzer beispielsweise nur bestimmte Verweismarkierungen aufrufen, bezogen auf Teile des Gesamttestreports, die für den Nutzer von Interesse sind.
-
Gemäß einem weiteren Aspekt kann die zumindest eine Kommunikationsschnittstelle des HW/SW-Systems (Testobjekts) ausgebildet sein, um sowohl Dateneingaben als auch Datenausgaben zu verarbeiten. Dadurch wird eine vereinfachte Kommunikation zwischen Steuergerät und Testobjekt (HW/SW-System) ermöglicht. Somit für das Verfahren bezüglich der Komplexität der Kommunikation vereinfacht.
-
Bevorzugt kann der Gesamttestreport eingerichtet sein, um einer Verweismarkierung zumindest einen Zeitstempel und/oder eine eindeutige Identifikationsnummer des Testobjekts zuzuordnen. Die Zeitstempel und/oder Identifikationsnummern werden mit dem Gesamttestreport ebenfalls an der Mensch-Maschine-Schnittstelle ausgegeben. Dadurch lassen sich Verweismarkierungen besser identifizieren. Beispielsweise können somit bei Durchsicht von einer Mehrzahl von Gesamttestreports, die bezogen auf unterschiedliche Testobjekte oder zu unterschiedlichen Zeitpunkten an demselben Testobjekt erlangt wurden, Fehlerverläufe nachvollzogen werden. Insgesamt wird dadurch eine Kategorisierung der Gesamttestreports ermöglicht. Zudem ist dies von Vorteil, wenn gleichzeitig mehrere Testobjekte getestet werden, beispielsweise mehrere Testobjekte desselben Typs.
-
Optional kann für jede Testroutine ein Anforderungsprofil definiert sein. Dann wird an der Mensch-Maschine-Schnittstelle zusätzlich eine Aufstellung darüber ausgegeben, für welche Teile des Anforderungsprofils fehlerfreie Reaktionsantworten und/oder fehlerhafte Reaktionsantworten empfangen wurden. Die jeweiligen Reaktionsantworten werden durch das Steuergerät empfangen. Das Steuergerät gleicht die Reaktionsantworten des getesteten Testobjekts mit der jeweils erwarteten Reaktionsantwort ab. Das Anforderungsprofil gibt dann an, für welche Teile eine Übereinstimmung gefunden wurde und für welche das nicht der Fall ist. Dadurch ist die Fehleridentifikation vorteilhaft noch präziser möglich. Zudem kann das Testobjekt im Hinblick auf das Verhältnis von Abweichungen zu Übereinstimmungen beurteilt werden. Beispielsweise kann ein Testverfahren auch mehrfach durchgeführt werden. Wenn dann bei einer hohen Anzahl von Durchläufen ein einzelner Fehler auftritt, kann das als Sonderfall angesehen werden, der vernachlässigbar sein könnte. Das Anforderungsprofil ermöglicht die Beurteilung des HW/SW-Systems (Testobjekts) im Hinblick auf die Spezifikationen des Testverfahrens, die beispielsweise von einem Auftraggeber vorgegeben sein können. Auch kann das Anforderungsprofil bei Entwicklungsarbeiten hilfreich sein, um beurteilen zu können, ob die Entwicklung Fortschritte macht, beispielsweise dadurch, dass bei wiederholten Testverfahren ein jeweils steigender Anteil des Anforderungsprofils Übereinstimmungen zeigt.
-
In einer bevorzugten Ausgestaltung kann das Steuergerät eingerichtet sein, um eine Notifikation an eine Mensch-Maschine-Schnittstelle auszugeben, sofern eine Testroutine eine Interaktion an einer Mensch-Maschine-Schnittstelle erfordert. Die jeweilige Testroutine wird dann beim Ausgeben einer Notifikation an die Mensch-Maschine-Schnittstelle unterbrochen. In Reaktion auf eine Benutzereingabe an der Mensch-Maschine-Schnittstelle wird die jeweilige Testroutine fortgesetzt.
-
Beispielsweise kann so ein Bruch der Kommunikationsverbindung zwischen Steuergerät und HW/SW-System (Testobjekt) simuliert werden. Auch können somit Testroutinen absolviert werden, die beispielsweise die Betätigung eines Hardware-Schalters des Testobjekts erfordern.
-
Optional kann das Verfahren derart weitergebildet werden, dass ein Fehler ausgegeben wird, der als Verweismarkierung im Gesamttestreport aufgeführt wird, sofern keine Benutzereingabe an der Mensch-Maschine-Schnittstelle erfolgt, die aber gemäß der Testroutine erforderlich ist. Somit kann für den Nutzer aus dem Gesamttestreport der Fehler der fehlenden Benutzereingabe unmittelbar ersichtlich sein.
-
Zudem kann das Verfahren ferner den Schritt des wiederholten Initiierens der Testroutinen umfassen. An der Mensch-Maschine-Schnittstelle wird dann eine Historie aller initiierten Testroutinen und/oder der zugehörigen Gesamttestreports ausgegeben. Dadurch ist das Verfahren geeignet, kontinuierliche Testroutinen an Testobjekten durchzuführen. Beispielsweise können so auch im Betrieb befindliche HW/SW-Systeme (Testobjekte) kontinuierlich auf ihre erwartungsgemäße Funktionalität hin getestet werden. Dies kann beispielsweise über eine Internetverbindung ermöglicht werden. Insofern kann das Steuergerät auch entfernt vom Testobjekt angeordnet sein.
-
Beispielsweise kann das Verfahren auch eingerichtet sein, um verhaltensgetriebene Softwareentwicklung (Behaviour Driven Development; BDD) zu unterstützen. Diese Art der Softwareentwicklung kann als agile Softwareentwicklung angesehen werden. Zunächst wird eine Analyse der Anforderungen der Aufgaben, Ziele und erwarteten Ergebnisse des Testobjekts erstellt. Diese wird dann für das Verfahren bereitgestellt und in automatisierten, wiederholten Testverfahren getestet. Somit kann der Fortschritt bei der Entwicklung im Hinblick auf die erwartungsgemäße Funktionalität des Testobjekts beurteilt werden.
-
Die Wiederholfrequenz des wiederholten Ablaufs der Testroutinen kann durch eine Eingabe an einer Mensch-Maschine-Schnittstelle festgelegt sein. Dadurch kann der Nutzer in komfortabler Weise die Häufigkeit der wiederholten Testroutinen bestimmen.
-
Optional können das HW/SW-System, die Testvorrichtung mit dem Steuergerät und der Feldbus eingerichtet sein, um das HW/SW-System (Testobjekt) entsprechend einer Hardware-in-the-Loop Konfiguration und/oder einer Software-in-the-Loop Konfiguration zu testen. Das Testobjekt ist dann als eingebettete Vorrichtung über seine Ein- und Ausgänge an ein angepasstes Gegenstück, die Teilkomponente der Testvorrichtung ist, angeschlossen und kommuniziert über den Feldbus mit dem Steuergerät.
-
Alternativ oder kumulativ kann das Verfahren für kontinuierliche Integration geeignet sein, also für die fortlaufende Weiterentwicklung einer Software durch das Zusammenfügen weiterer Komponenten.
-
Gemäß einer vorteilhaften Ausgestaltung umfasst der Gesamttestreport ein in einer XML-Sprache (Extensible Markup Language) geschriebenes Dokument, bevorzugter Weise ein HTML-Dokument.
-
Bevorzugt werden alle an der Mensch-Maschine-Schnittstelle ausgegebenen Daten in einer einzelnen speicherbaren Datei für den Nutzer zur Verfügung gestellt. Das ermöglicht eine einfache Archivierung aller durchgeführten Testverfahren.
-
Der Gesamttestreport kann auch zumindest teilweise verschlüsselt sein. Dadurch wird ein unerlaubter Zugriff vermieden.
-
Alternativ oder kumulativ kann der Gesamttestreport auch signiert werden, also mit einer (fortgeschrittenen) elektronischen Signatur versehen werden. Dadurch kann der Gesamttestreport zusätzlich gegen Manipulationen gesichert sein. Außerdem kann der Gesamttestreport somit durch Zertifizierungsstellen auf seine Validität hin überprüft werden.
-
Optional kann das Steuergerät derart eingerichtet sein, dass Testroutinen mit Echtzeitanforderungen durchführbar sind. Insofern können die Testroutinen, insbesondere deren Zeitstempel, mit einem Zeitgeber gekoppelt werden.
-
Weiterhin kann der Gesamttestreport interaktive Übersichtsgrafiken und eine Suchfunktion umfassen, um spezifische Zeitstempel, Teiltestreports, Identifikationsnummern oder andere Suchbegriffe innerhalb des Gesamttestreports auffinden zu können.
-
Jeder der vorstehend genannten Aspekte kann mit jedem anderen Aspekt (unter-)kombiniert werden, sofern dem Fachmann entsprechend denkbare Entwicklungen zur Verfügung stehen.
-
Die vorstehenden Aspekte und weiteren Vorteile des beanspruchten Gegenstands werden leichter verständlich, wenn sie durch Bezugnahme auf die folgende detaillierte Beschreibung in Verbindung mit den beigefügten Zeichnungen besser verstanden werden. In den Zeichnungen ist
- - 1 eine vereinfachte schematische Darstellung des HW/SW-Systems mit einer Testvorrichtung,
- - 2 eine vereinfachte schematische Darstellung des Testverfahrens gemäß einer Ausführungsform,
- - 3 eine vereinfachte schematische Darstellung des Testverfahrens gemäß einer weiteren Ausführungsform, und
- - 4 eine vereinfachte schematische Darstellung des Testverfahrens gemäß einer zusätzlichen Ausführungsform.
-
Die nachstehende detaillierte Beschreibung in Verbindung mit den beigefügten Zeichnungen, in denen gleiche Ziffern auf gleiche Elemente verweisen, ist als Beschreibung verschiedener Ausführungsformen des offengelegten Gegenstands gedacht und soll nicht die einzigen Ausführungsformen darstellen. Jede in dieser Offenbarung beschriebene Ausführungsform dient lediglich als Beispiel oder Illustration und sollte nicht als bevorzugt oder vorteilhaft gegenüber anderen Ausführungsformen ausgelegt werden. Die hierin enthaltenen illustrativen Beispiele erheben keinen Anspruch auf Vollständigkeit und beschränken den beanspruchten Gegenstand nicht auf die genauen offengelegten Formen. Verschiedene Abwandlungen der beschriebenen Ausführungsformen sind für den Fachmann ohne weiteres erkennbar, und die hierin definierten allgemeinen Grundsätze können auf andere Ausführungsformen und Anwendungen angewandt werden, ohne vom Umfang der beschriebenen Ausführungsformen abzuweichen. Daher sind die beschriebenen Ausführungsformen nicht auf die gezeigten Ausführungsformen beschränkt, sondern haben den größtmöglichen Anwendungsbereich, der mit den hier offengelegten Grundsätzen und Merkmalen vereinbar ist.
-
Alle nachstehend in Bezug auf die Ausführungsbeispiele und/oder die begleitenden Figuren offengelegten Merkmale können allein oder in einer beliebigen Unterkombination mit Merkmalen der Aspekte der vorliegenden Offenbarung, einschließlich Merkmalen bevorzugter Ausführungsformen davon, kombiniert werden, sofern die sich ergebende Merkmalskombination für eine fachkundige Person sinnvoll ist.
-
Für die Zwecke der vorliegenden Offenbarung bedeutet die Formulierung „mindestens eines von A, B und C“ beispielsweise (A), (B), (C), (A und B), (A und C), (B und C) oder (A, B und C), einschließlich aller weiteren möglichen Kombinationen, wenn mehr als drei Elemente aufgeführt sind. Mit anderen Worten, der Begriff „mindestens eines von A und B“ bedeutet im Allgemeinen „A und/oder B“, nämlich „A“ allein, „B“ allein oder „A und B“.
-
1 ist eine vereinfachte schematische Darstellung eines Gesamtsystems 10 umfassend ein HW/SW-System (Testobjekt) 12 und eine Testvorrichtung 15. Das HW/SW-System (Testobjekt) 12 umfasst zumindest eine Kommunikationsschnittstelle 14. Mittels der Kommunikationsschnittstelle 14 kommuniziert das HW/SW-System (Testobjekt) 12 bidirektional mit der Testvorrichtung 15 und insbesondere dessen Steuergerät 16 über einen Feldbus 18. Der Feldbus 18 kann beispielsweise eine Kommunikation gemäß dem TCP/IP Protokoll ermöglichen. Die Kommunikation zwischen dem Testobjekt (HW/SW-System) 12 und dem Steuergerät 16 kann als gerichtete Kommunikation mit entsprechenden Adressen bezogen auf den Feldbus 18 erfolgen. Alternativ kann die Kommunikation aber beispielsweise zumindest teilweise auch als Broadcast-Nachricht erfolgen, also ohne individuelle Adressen der Kommunikationspartner.
-
Das Steuergerät 16 ist mit einer Mensch-Maschine-Schnittstelle 20 gekoppelt. An der Mensch-Maschine-Schnittstelle 20 kann das Steuergerät 16 Daten für einen Nutzer ausgeben, beispielsweise einen Gesamttestreport 22. Aber auch andere Daten können von dem Steuergerät 16 an der Mensch-Maschine-Schnittstelle 20 ausgegeben werden, beispielsweise Teiltestreports oder Notifikationen bezüglich erforderlicher Benutzereingaben. Insofern ist auch die Kommunikation zwischen der Mensch-Maschine-Schnittstelle 20 und dem Steuergerät bidirektional.
-
Das Testobjekt 12 kann insbesondere eine eingebettete elektrische oder elektronische Vorrichtung sein. Die Testvorrichtung 15 kann dann eine entsprechend komplementäre Vorrichtung für das Testobjekt 12 sein, insbesondere im Hinblick auf verwendete Kommunikationsschnittstellen. Das Gesamtsystem 10 bestehend aus HW/SW-System 12 und Testvorrichtung 15 kann als Hardware-in-the-Loop oder Software-in-the-Loop Konfiguration eingerichtet sein.
-
Das Steuergerät 16 ist derart eingerichtet, dass Testroutinen (Software-Module) mit Echtzeitanforderungen absolviert werden können.
-
2 zeigt eine vereinfachte schematische Darstellung des Testverfahrens 30 gemäß einer Ausführungsform. Das Testverfahren 30 ist zur automatisierten Fehleridentifikation und/oder Fehlerverifikation eingerichtet.
-
Das Testverfahren 30 umfasst den ersten Schritt 32 des Initiierens von mehreren Testroutinen (Software-Modulen). Jede Testroutine umfasst dabei eine Abfrage und eine der Abfrage zugeordnete erwartete Reaktionsantwort des Testobjekts 12. Für jede Testroutine übermittelt das Steuergerät 16 Daten an das Testobjekt 12. Beispielsweise kann eine Testroutine eine Abfrage eines internen Parameters des Testobjekts 12 umfassen.
-
Das Testverfahren 30 umfasst ferner den Schritt 34 des Empfangens von Daten von dem Testobjekt 12. Die Daten werden insbesondere von dem Steuergerät 16 empfangen. Die Daten werden von dem Testobjekt 12 als Folge der Abfrage ausgesendet. Die empfangenen Daten stellen insofern das Resultat der Abfrage einer jeweiligen Testroutine dar.
-
Außerdem kann das Testverfahren 30 optional den Schritt 36 des Erstellens eines Teiltestreports umfassen. Das bedeutet, dass das Steuergerät 16 für jede Testroutine einen Teiltestreport erstellen kann. Der Teiltestreport umfasst dann zumindest die jeweilige Abfrage, die an das Testobjekt 12 übermittelt worden ist, die erwartete Reaktionsantwort des Testobjekts 12 im Hinblick auf die jeweilige Testroutine und zumindest die tatsächliche Reaktionsantwort des Testobjekts 12, die vom Steuergerät 16 empfangen wurde. Zudem umfasst der Teiltestreport Verweismarkierungen, falls Abweichungen zwischen einer erwarteten Reaktionsantwort und einer tatsächlichen Reaktionsantwort bestehen. Die Verweismarkierungen stellen insofern präzise Bezüge dar, im Hinblick auf welche Abfrage oder auch auf welchen Teilschritt einer Testroutine eine fehlerhafte Reaktionsantwort (eine Abweichung) aufgetreten ist.
-
Optional kann das Testverfahren 30 auch den Schritt 38 des Aggregierens der Teiltestreports umfassen. Das bedeutet, dass sämtliche Teiltestreports zu einem Gesamttestreport 22 zusammengefügt werden können.
-
Zumindest umfasst das Testverfahren 30 ferner den Schritt 40 des Erstellens eines Gesamttestreports 22. Der Gesamttestreport 22 umfasst für alle durchgeführten Testroutinen die entsprechenden Abfragen, die erwarteten Reaktionsantworten und die tatsächlichen Reaktionsantworten. Zudem umfasst der Gesamttestreport 22 Verweismarkierungen, soweit fehlerhafte Reaktionsantworten auftreten, also Abweichungen zwischen den erwarteten Reaktionsantworten und den tatsächlichen Reaktionsantworten des Testobjekts.
-
Ferner umfasst das Testverfahren 30 den Schritt 42 des Ausgebens des Gesamttestreports 22 an einer Mensch-Maschine-Schnittstelle 20. Es werden auch die Verweismarkierungen an der Mensch-Maschine-Schnittstelle 20 ausgegeben, so dass der Nutzer die aufgetretenen Fehler unmittelbar identifizieren kann. Falls der Nutzer eine Verweismarkierung an der Mensch-Maschine-Schnittstelle 20 aufruft, werden durch das Steuergerät 16 an der Mensch-Maschine-Schnittstelle 20 mindestens die fehlerhafte Reaktionsantwort des Testobjekts 12 und die Abfrage, deren fehlerhafte Reaktionsantwort nicht mit der zugeordneten erwarteten Reaktionsantwort übereinstimmt, ausgegeben. Dadurch wird der Nutzer in die Lage versetzt, zu identifizieren, in Bezug auf welche Teilschritte des Testverfahrens 30 Fehler aufgetreten sind. Also wird dem Nutzer eine einzelne Übersicht des gesamten Testverfahrens 30 bereitgestellt, die es ermöglicht, Fehler automatisiert zu identifizieren. Eine aufwendige Fehlersuche kann entfallen.
-
Der Gesamttestreport 22 kann optional auch ein Anforderungsprofil für jede Testroutine umfassen. Dann wird an der Mensch-Maschine-Schnittstelle 20 eine Aufstellung darüber ausgegeben für welche Teile des Anforderungsprofils fehlerfreie Reaktionsantworten und/oder fehlerhafte Reaktionsantworten empfangen wurden. Das Anforderungsprofil gibt insofern einen Überblick über den Anteil der fehlerbehafteten Testroutinen bezogen auf die fehlerfreien Testroutinen oder die Gesamtanzahl der Testroutinen.
-
Der Gesamttestreport 22 kann zumindest teilweise verschlüsselt sein. Der Gesamttestreport 22 kann auch signiert sein. Der Gesamttestreport 22 kann zudem Zeitstempel und/oder eindeutige Identifikationsnummern des Testobjekts 12 umfassen, die einer jeweiligen Verweismarkierung zugeordnet sind. Somit können die Verweismarkierungen eindeutig bestimmt sein.
-
Der Gesamttestreport 22 kann als einzelne Datei an der Mensch-Maschine-Schnittstelle 20 zur Verfügung gestellt werden, insbesondere als speicherbare Datei. Beispielsweise kann der Gesamttestreport 22 ein HTML-Dokument sein.
-
3 ist eine vereinfachte schematische Darstellung des Testverfahrens 50 gemäß einer weiteren Ausführungsform. Eine Wiederholung von Aspekten, die schon in Bezug auf vorherige Figuren erläutert wurden, wird vermieden. Es wird vielmehr lediglich auf Unterschiede eingegangen.
-
Das Testverfahren 50 umfasst ebenfalls den Schritt 32 des Initiierens von mehreren Testroutinen. Manche Testroutinen erfordern aber eine Benutzereingabe. Beispielsweise kann eine Testroutine vorsehen, dass die Kommunikationsverbindung zwischen Testobjekt 12 und dem Steuergerät 16 absichtlich unterbrochen wird. Deshalb umfasst das Testverfahren 50 gemäß dieser Ausführungsform den optionalen Schritt 52 des Ausgebens einer Notifikation an einer Mensch-Maschine-Schnittstelle 20 über eine erforderliche Benutzereingabe. Dies kann beispielsweise durch das Steuergerät 16 erfolgen. Gemäß diesem Schritt wird die Testroutine beim Ausgeben der Notifikation unterbrochen.
-
Ferner umfasst das Testverfahren 50 gemäß dieser Ausführungsform den optionalen Schritt 54 des Empfangens einer Benutzereingabe an der Mensch-Maschine-Schnittstelle 20. Die Benutzereingabe kann insbesondere durch das Steuergerät 16 empfangen werden.
-
Dann wird das Testverfahren 50 gemäß dem optionalen Schritt 56 fortgesetzt, sofern die erforderliche Benutzereingabe erfolgt ist. Insbesondere wird die zuvor unterbrochene Testroutine fortgesetzt.
-
Erfolgt als Reaktion auf die Notifikation keine Benutzereingabe an der Mensch-Maschine-Schnittstelle 20 (oder keine sinnvolle Benutzereingabe), so wird durch das Steuergerät 16 im optionalen Schritt 58 eine entsprechende Verweismarkierung im Gesamttestreport 22 eingefügt, die auf diesen Fehler hinweist. In diesem Fall wird die zuvor unterbrochene Testroutine abgebrochen. Bis zum Abbruch der jeweiligen Testroutine kann das Steuergerät 16 eine vorbestimmte Zeitspanne auf eine Benutzereingabe warten.
-
4 zeigt eine vereinfachte schematische Darstellung des Testverfahrens 60 gemäß einer zusätzlichen Ausführungsform. Eine Wiederholung von Aspekten, die schon in Bezug auf vorherige Figuren erläutert wurden, wird vermieden. Es wird vielmehr lediglich auf Unterschiede eingegangen.
-
Das Testverfahren 60 umfasst gemäß dieser Ausführungsform die bekannten Schritte 32, 34, 40 und 42. Zusätzlich umfasst das Testverfahren 60 den optionalen Schritt 62 des wiederholten Initiierens der Testroutinen. Insofern kann das Testobjekt 12 mittels des Testverfahrens 60 kontinuierlich getestet werden. Eine Wiederholfrequenz des Schritts 62 kann beispielsweise auf einer entsprechenden Eingabe an der Mensch-Maschine-Schnittstelle 20 beruhen.
-
Weiterhin umfasst das Testverfahren 60 den Schritt 64 des Erstellens einer Historie der jeweiligen Testroutinen und/oder des jeweiligen Gesamttestreports 22. Insbesondere wird die Historie an der Mensch-Maschine-Schnittstelle 20 für den Nutzer ausgegeben. Somit wird dem Nutzer eine Aufstellung über sämtliche absolvierten Testroutinen einschließlich der jeweiligen Ergebnisse zur Verfügung gestellt.
-
In der vorliegenden Anmeldung kann auf Mengen und Zahlen Bezug genommen werden. Sofern nicht ausdrücklich angegeben, sind solche Mengen und Zahlen nicht als einschränkend zu betrachten, sondern als Beispiele für die möglichen Mengen oder Zahlen im Zusammenhang mit der vorliegenden Anmeldung. In diesem Zusammenhang kann in der vorliegenden Anmeldung auch der Begriff „Mehrzahl“ verwendet werden, um auf eine Menge oder Zahl zu verweisen. In diesem Zusammenhang ist mit dem Begriff „Mehrzahl“ jede Zahl gemeint, die größer als Eins ist, z. B. Zwei, Drei, Vier, Fünf, usw. Die Begriffe „etwa“, „ungefähr“, „nahe“ usw. bedeuten plus oder minus 5 % des angegebenen Wertes.
-
Obwohl die Offenbarung in Bezug auf eine oder mehrere Ausführungsformen dargestellt und beschrieben wurde, werden andere Fachleute beim Lesen und Verstehen dieser Beschreibung und der beigefügten Zeichnungen gleichwertige Änderungen und Modifikationen feststellen. Auch wenn ein bestimmtes Merkmal der Offenbarung nur in Bezug auf eine von mehreren Ausführungsformen offenbart wurde, kann dieses Merkmal mit einem oder mehreren anderen Merkmalen der anderen Ausführungsformen kombiniert werden, wie es für eine gegebene oder besondere Anwendung erwünscht und vorteilhaft sein kann.
