-
GEBIET DER TECHNIK
-
Hierin beschriebene Ausführungsformen betreffen allgemein die Generierung eines Testfalls zur Validierung von Software und genauer die Verwendung von zustandsbasierten Bestimmungen zur Generierung der Testfälle.
-
TECHNISCHER HINTERGRUND
-
Als Stand der Technik weisen viele Fahrzeuge integrierte Software auf, um bestimmte Funktionen bereitzustellen. Bevor das Fahrzeug an den Kunden verkauft wird, wird die Software validiert, um sicherzustellen, dass die Software ihre Funktionen ohne ein unerwünschtes Maß an Fehlern ausführt. Die Software-Validierung kann das Testen von Software mit einer Reihe von Testfällen in einer kontrollierten Umgebung beinhalten, wo der Gebrauch des Fahrzeugs simuliert werden soll. Heutige Werkzeuge zur Erzeugung von Testfällen nutzen zwei Hauptklassen von Verfahren zur Erzeugung von Testfällen, um Normen/Empfehlungen der internationalen Normungsorganisation (international standards organization, ISO) gerecht zu werden.
-
Die erste Klasse kann als formales Verfahren beschrieben werden, das Mathematik nutzt, um nachzuweisen, ob die Software korrekt funktioniert. Allerdings hat diese erste Klasse zahlreiche Beschränkungen aufgrund der Tatsache, dass in komplexer Software nicht-lineare Mathematik, Nachschlagtabellen, Zustandraum-Explosion, rechnerische Beschränkungen und dergleichen vorkommen. Somit ist diese erste Klasse häufig auf weniger umfangreiche, weniger komplizierte Software beschränkt. Die zweite Klasse kann als Generierung von zufälligen Testfällen beschrieben werden, die durch gezielte zufällige Testfälle für eine Modified Condition/Decision Coverage (MC/DC) sorgt. Allerdings ist es wahrscheinlich, dass die Generierung eines zufälligen Testfalls eine ungenügende Vielfältigkeit von Testfällen liefert, mit der keine akzeptable MC/DC für komplexe oder umfangreichere Software erreicht werden kann.
-
KURZFASSUNG DER ERFINDUNG
-
Es werden Systeme und Verfahren für die zustandsbasierte Testfallgenerierung zur Software-Validierung offenbart. Eine Ausführungsform des Verfahrens beinhaltet die Bestimmung einer ersten Eingabe und einer ersten Eingabeart für einen Programmblock einer Fahrzeug-Software zur Erzeugung eines ersten Testfalls, die Bestimmung von Permutationen von Werten für die erste Eingabe auf Basis der ersten Eingabeart und das Durchspielen des Testfalls mit der zustandsbasierten Eingabe, wobei das Durchspielen des Testfalls das Anwenden der Permutationen von Werten für die erste Eingabe auf den Programmblock beinhaltet. Manche Ausführungsformen beinhalten eine Bestimmung, ob der Testfall einen vorgegebenen Grad der Modified Condition/Decision Coverage (MC/DC) erreicht, und die Bereitstellung eines Hinweises darauf, ob der Testfall den vorgegebenen Grad an MC/DC erreicht.
-
In einer anderen Ausführungsform beinhaltet ein System eine Test-Rechenvorrichtung mit einem Speicher, der Logik speichert, die, wenn sie durch die Test-Rechenvorrichtung ausgeführt wird, bewirkt, dass die Test-Rechenvorrichtung eine erste Eingabe und eine erste Eingabeart für einen Programmblock der Fahrzeug-Software zur Erzeugung eines Testfalls bestimmt, eine zweite Eingabe und eine zweite Eingabeart für den Programmblock bestimmt und Permutationen von Werten für die erste Eingabe auf Basis der ersten Eingabeart bestimmt. In manchen Ausführungsformen bewirkt die Logik, dass die Test-Rechenvorrichtung einen Mechanismus bestimmt, um der zweiten Eingabe Werte zuzuweisen, den Testfall mit der zustandsbasierten Eingabe und der nicht-zustandsbasierten Eingabe durchzuspielen und zu bestimmen, ob der Testfall eine vorgegebenen Höhe der Modified Condition/Decision Coverage (MC/DC) erreicht.
-
In einer noch anderen Ausführungsform bewirkt ein nicht-transitorisches, computerlesbares Medium, dass eine Test-Rechenvorrichtung einen Programmblock aus Fahrzeug-Software eines Fahrzeugs, das getestet werden soll, auswählt, eine erste Eingabe und eine erste Eingabeart für den Programmblock bestimmt, um einen Testfall zu erzeugen, und eine zweite Eingabe und eine zweite Eingabeart für den Programmblock bestimmt. Im manchen Ausführungsformen bewirkt das nicht-transitorische, computerlesbare Medium, dass die Test-Rechenvorrichtung Permutationen von Werten für die erste Eingabe auf Basis der ersten Eingabeart bestimmt, einen Mechanismus zum Zuweisen von Werten für die zweite Eingabe auf Basis der zweiten Eingabeart bestimmt und den Testfall mit der zustandsbasierten Eingabe und der nicht-zustandsbasierten Eingabe durchspielt, wobei das Durchspielen des Testfalls das Anwenden der Permutationen von Werten für die erste Eingabe auf den Programmblock mit den Werten für die zweite Eingabe beinhaltet.
-
Diese und zusätzliche Merkmale, die von den Ausführungsformen der vorliegenden Offenbarung geschaffen werden, werden aus der folgenden ausführlichen Beschreibung in Zusammenschau mit den Zeichnungen besser verständlich werden.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Die in den Zeichnungen dargestellten Ausführungsformen dienen als Erläuterung und als Beispiele und sollen die Offenbarung nicht beschränken. Die folgende ausführliche Beschreibung der erläuternden Ausführungsformen wird verständlich, wenn sie in Verbindung mit den folgenden Zeichnungen gelesen wird, wo ein gleicher Aufbau mit gleichen Bezugszahlen bezeichnet ist, und worin:
-
1 schematisch eine Test-Rechenvorrichtung, wie sie zum Testen von Software in einem Fahrzeug verwendet werden kann, gemäß hierin offenbarten Ausführungformen darstellt;
-
2A–2C schematisch eine Steuerungsspezifikationsstruktur, die eine Mehrzahl von logischen Schichten zeigt, gemäß hierin offenbarten Ausführungsformen darstellt;
-
3A eine logische Schaltung zur Implementierung einer Funktion in einem Fahrzeug gemäß hierin offenbarten Ausführungsformen darstellt;
-
3B Eingaben, die aus der logischen Schaltung von 3A bestimmt werden können und die verwendet werden können, um einen Testfall zu erzeugen, gemäß hierin offenbarten Ausführungsformen darstellt;
-
4 eine Anwenderschnittstelle, die zur Erzeugung des zustandsbasierten Testfalls verwendet werden kann, gemäß hierin offenbarten Ausführungsformen darstellt; und
-
5 ein Ablaufschema zur Generierung eines zustandsbasierten Testfalls gemäß hierin offenbarten Ausführungsformen darstellt.
-
BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
-
Hierin offenbarte Ausführungsformen beinhalten Systeme und Verfahren zur Generierung eines Testfalls zur Software-Validierung. Dementsprechend betreffen diese Ausführungsformen computerimplementierte Verfahren zur Generierung von Testfällen auf Basis von Modelleingabekennwerten für MC/DC. Die Ausführungsformen können zur Software-Validierung genutzt werden, um ISO-Normen/-Empfehlungen gerecht zu werden (z. B. ISO 26262). Im Allgemeinen können die Eingaben für die getestete Software in Zustandsvariable und Nicht-Zustandsvariable eingeteilt werden. Zustandsvariable in der Software können als Flag- oder Modusvariable beschrieben werden, die den Zustand eines Systems oder das Ergebnis einer Operation bezeichnen. Zustandsvariable werden in Software verwendet, um Konditionen und Entscheidungen auszudrücken. Konditionen können beispielsweise Ausdrücke sein für ein/aus, 0/1 oder dergleichen. Entscheidungen bestehen im Allgemeinen aus Konditionen, mit denen einer oder mehrere boolesche Operatoren arbeiten, beispielsweise wenn a und b „EIN” sind, und dann eine Funktion ausführen.
-
Die hierin offenbarten Testfälle können so generiert werden, dass bestimmte Konditionen zumindest einmal während des Validierungsprozesses des Testfalls zutreffen. Die Konditionen, die während der Validierung zutreffen, können die Folgenden beinhalten: jede Entscheidung versucht jedes mögliche Ergebnis zu bewirken; jede Kondition in einer Entscheidung nimmt den Wert jedes möglichen Ergebnisses an; jeder Eintritts- und Austrittspunkt wird aufgerufen; und es wird gezeigt, dass jede Kondition in einer Entscheidung das Ergebnis der Entscheidung unabhängig beeinflusst.
-
Nicht-Zustandsvariable beinhalten Rechenwerte, Regelwerte und Sensorwerte. Für Nicht-Zustandsvariable können hierin offenbarte Ausführungsformen Mechanismen nutzen wie Konstante, Zufall, zufällige ganze Zahl, Rampe, Sequenz, Transition und Permutation und dergleichen, um Testfallwerte zum Testen von Software bereitzustellen.
-
In manchen Ausführungsformen können Pseudo-Zustandsvariable als Zustandsvariable behandelt werden. Eine Pseudo-Zustandsvariable ist eine Nicht-Zustandsvariable, die in einer Entscheidung auf eine Weise verwendet wird, die einer Zustandsvariablen analog ist. Zum Beispiel kann eine Funktion ausgeführt werden, wenn eine Nicht-Zustandsvariable größer ist als ein Schwellenwert (z. B. kann eine Nicht-Zustandsvariable einen Bereich von 0–200 aufweisen, und eine Entscheidung kann getroffen werden, wenn die Nicht-Zustandsvariable größer ist als 50). Eine Pseudo-Zustandsvariable kann aus der Nicht-Zustandsvariable durch Zuweisen diskreter Werte erstellt werden, so dass sie sich wie eine Zustandsvariable verhält. Zum Beispiel kann die Variable in manchen Ausführungsformen auf 2 Zustände gesetzt werden: 50 = Ein und 51 = Aus.
-
Infolgedessen bestimmen hierin offenbarte Ausführungsformen, welche Eingaben als zustandsbasierte Eingaben und als nicht-zustandsbasierte Eingaben erkannt werden können. Die zustandsbasierten Eingaben können für jede Permutation eines Eingabewerts, die für diese zustandsbasierte Eingabe möglich ist, getestet werden. Außerdem können die nicht-zustandsbasierten Eingaben unter Verwendung einer Zufallszahl, einer Reihe von Zahlen und/oder anderer Werte getestet werden. Auf Basis dieser Eingabebestimmungen und Eingabewertauswahlen kann Fahrzeug-Software mit voller MC/DC effizienter getestet werden.
-
Nun wird auf die Zeichnungen Bezug genommen, von denen 1 schematisch eine Test-Rechenvorrichtung 112 darstellt, die gemäß hierin offenbarten Ausführungsformen zum Testen von Fahrzeug-Software 114c verwendet werden kann. In der dargestellten Ausführungsform beinhaltet die Test-Rechenvorrichtung 112 einen Prozessor 130, Eingabe-/Ausgabe-Hardware 132, Netzschnittstellen-Hardware 134, eine Datenspeicherungskomponente 136 und die Speicherkomponente 140. Die Speicherkomponente 140 kann als flüchtiger und/oder als nicht-flüchtiger Speicher konfiguriert sein und kann als solcher einen Speicher mit wahlfreiem Zugriff (einschließlich SRAM, DRAM und/oder anderer Arten von RAM), Flash-Speicher, einen sicheren digitalen (SD) Speicher, Register, Compact Disks (CD), Digital Versatile Disks (DVD) und/oder andere Arten von nicht-transitorischen, computerlesbaren Medien beinhalten. Abhängig von der jeweiligen Ausführungsform kann ein nicht-transitorisches, computerlesbares Medium in der Test-Rechenvorrichtung 112 und/oder außerhalb der Test-Rechenvorrichtung 112 angesiedelt sein.
-
Außerdem kann die Speicherkomponente 140 Betriebslogik 142, die Fahrzeug-Softwaretestlogik 144a, die Testfalllogik 144b und die Fahrzeug-Software 144c speichern. Die Fahrzeug-Software 144c kann die Software sein, die getestet wird. Ebenso können die Fahrzeug-Softwaretestlogik 144a und die Testfalllogik 144b jeweils eine Mehrzahl von verschiedenen Logiken beinhalten, von denen jede beispielsweise als Computerprogramm, Firmware und/oder Hardware ausgeführt sein kann. Eine lokale Schnittstelle 146 ist ebenfalls in 1 enthalten und kann als Bus oder andere Schnittstelle implementiert sein, um eine Kommunikation zwischen den Komponenten der Test-Rechenvorrichtung 112 zu erleichtern.
-
Der Prozessor 130 kann jede Verarbeitungskomponente beinhalten, die dazu dient, Befehle zu empfangen und auszuführen (beispielsweise von der Datenspeicherungskomponente 136 und/oder der Speicherkomponente 140). Die Eingabe-/Ausgabe-Hardware 132 kann einen Monitor, ein Positionierungssystem, eine Tastatur, eine Maus, einen Drucker, eine Bildaufnahmevorrichtung, ein Mikrofon, einen Lautsprecher, ein Gyroskop, einen Kompass und/oder eine andere Vorrichtung zum Empfangen, Senden und/oder Darstellen von Daten beinhalten und/oder so gestaltet sein, dass sie damit über eine Schnittstelle verbunden ist. Die Netzschnittstellen-Hardware 134 kann eine beliebige kabelgebundene oer drahtlose Netz-Hardware, einschließlich einer Antenne, eines Modems, eines LAN-Ports, einer Wireless Fidelity (Wi-Fi)-Karte, einer WiMax-Karte, einer Mobilkommunikations-Hardware und/oder anderer Hardware zum Kommunizieren mit anderen Netzen und/oder Vorrichtungen beinhalten und/oder so gestaltet sein, dass sie damit kommunizieren kann. Aufgrund dieser Verbindung kann eine Kommunikation zwischen der Test-Rechenvorrichtung 112 und anderen Rechenvorrichtungen erleichtert sein.
-
Die Betriebslogik 142 kann ein Betriebssystem und/oder andere Software beinhalten, um Komponenten der Test-Rechenvorrichtung 112 zu verwalten. Ebenso kann die Fahrzeug-Softwaretestlogik 144a in der Speicherkomponente 140 angesiedelt sein und kann so konfiguriert sein, dass sie den Prozessor 130 veranlasst, einen Test der Fahrzeug-Software 144c zu implementieren. Wie nachstehend ausführlicher erörtert wird, kann der Test, der von der Fahrzeug-Softwaretestlogik 144a implementiert wird, dafür da sein, zu bestimmen, dass die Fahrzeug-Software 144c fehlerfrei programmiert worden ist. Außerdem kann die Testfalllogik 144b so gestaltet sein, dass sie den Prozessor 130 veranlasst, einen Testfall zum Testen der Fahrzeug-Software 144c zu generieren. Andere Funktionen sind ebenfalls enthalten und werden nachstehend ausführlicher beschrieben.
-
Man beachte, dass die in 1 dargestellten Komponenten lediglich Beispiele sind und den Bereich der Offenbarung nicht beschränken sollen. Obwohl die in 1 dargestellten Komponenten in der Test-Rechenvorrichtung 112 angesiedelt sind, ist dies lediglich ein Beispiel. In manchen Ausführungsformen kann eine oder können mehrere von den Komponenten außerhalb der Test-Rechenvorrichtung 112 angesiedelt sein. Man beachte, dass die Test-Rechenvorrichtung 112 in 1 zwar als einzelne Vorrichtung dargestellt ist, dies aber ebenfalls lediglich ein Beispiel ist. In manchen Ausführungsformen können die Fahrzeug-Softwaretestlogik 144a und die Testfalllogik 144b in verschiedenen Vorrichtungen angesiedelt sein.
-
Außerdem sind zwar die Test-Rechenvorrichtung 112 so dargestellt, dass die Fahrzeug-Softwaretestlogik 144a und die Testfalllogik 144b separate logische Komponenten sind, aber dies ist ebenfalls ein Beispiel. In manchen Ausführungsformen kann eine einzige Logik die Test-Rechenvorrichtung 112 veranlassen, die beschriebenen Funktionen auszuführen.
-
2A–2C stellen schematisch eine Steuerungsspezifikationsstruktur, die eine Mehrzahl von logischen Schichten in der Fahrzeug-Software 144c zeigt, gemäß hierin offenbarten Ausführungsformen dar. Genauer zeigt 2A eine Anwendungsebene der Fahrzeug-Software 144c. Die Fahrzeug-Software 144c kann eine Mehrzahl von Anfangseingaben 210 beinhalten, die an einen Zustandsblock 212 geschickt werden. Die Zustandsblöcke 212 können diese Eingaben verarbeiten und Daten an einen Funktionsblock 214 schicken. Der Funktionsblock 214 kann die Daten weiterverarbeiten. Dies kann fortgesetzt werden, bis das gewünschte Ergebnis erhalten wird und an einen oder mehrere von den Ausgaben 216 geschickt wird. Obwohl in 2A nur zwei Verarbeitungsebenen (Blöcke 212 und 214) dargestellt sind, sei demgemäß klargestellt, dass mehr oder weniger Ebenen verwendet werden können, um die gewünschte Funktion im Fahrzeug 102 und/oder einer Fahrzeugrechenvorrichtung 104 zu implementieren.
-
2B stellt den Funktionsblock 214 von 2A (z. B. die Funktionsschicht) dar. Genauer weist der dargestellte Funktionsblock 214 eine von den Anfangseingaben 210 von 2A ebenso wie die beiden Ausgaben aus den Zustandsblöcken 212 auf. Der Funktionsblock 214 beinhaltet eine Mehrzahl von Modulblöcken für die Weiterverarbeitung von Daten gemäß der Fahrzeug-Software 144c. Die Funktionsblockausgaben 226 sind ebenfalls dargestellt und können zum nächsten Block in 2A geschickt werden.
-
2C zeigt den Modulblock 224 von 2B. Genauer können Eingaben 232 an einen Block 234 ausgegeben werden, der die Daten weiterverarbeiten kann. Diese Daten können dann von anderen Blöcken erneut verarbeitet werden und an eine Ausgabe 236 geschickt werden. Diese Ausgabe 236 kann dann weiter zu anderen Blöcken einer Anwendungsschicht, Blöcken einer Funktionsschicht geschickt und/oder an eine Ausgabe geschickt werden.
-
2A stellt eine Mehrzahl von Blöcken in der Anwendungsschicht dar, von denen jede Verarbeitungskomponenten innerhalb dieser Blöcke beinhalten kann. Die Verarbeitungskomponenten in der Anwendungsschicht sind in der Funktionsschicht in 2B detailliert dargestellt. Ebenso kann jeder von den Funktionsblöcken in 2B zusätzliche Verarbeitungskomponenten beinhalten, die in der Modulschicht von 2C dargestellt sind. Um die Fahrzeug-Software 144c (1) zu implementieren, führt die Fahrzeugrechenvorrichtung 104 (ebenfalls 1) daher die Logik in jeder dieser Schichten aus. Beim Testen der Fahrzeug-Software 144c testet die Test-Rechenvorrichtung 112 somit jeden von den Blöcken in jeder von den Schichten, um sicherzustellen, dass die Fahrzeug-Software 144c fehlerfrei programmiert ist.
-
Man beachte, dass die Begriffe Eingabe, erste Eingabe, zweite Eingabe usw. hierin verwendet werden können, um Eingaben in die Fahrzeug-Software 144c oder andere Werte zu bezeichnen, die an einen logischen Block der Fahrzeug-Software 144c geschickt werden können. Somit kann der Begriff Eingabe verwendet werden, um irgendeinen Wert zu bezeichnen, der an eine logische Komponente gesendet wird.
-
3A stellt eine logische Schaltung 300 zur Implementierung einer Funktion in einem Fahrzeug gemäß hierin offenbarten Ausführungsformen dar. Genauer kann die logische Schaltung 300 eine Logik innerhalb eines der Blöcke in der Anwendungsschicht, der Funktionsschicht und/oder der Modulschicht darstellen, die jeweils in 3A, 3B und 3C abgebildet sind. Wie dargestellt, beinhaltet die logische Schaltung 300 Eingaben 302a, 302b (gemeinsam als „Eingaben 302” bezeichnet). Die Eingaben 302 können die Form von binären Eingaben (als „Flags” erkannt), wo der Eingabewert eine von zwei Möglichkeiten darstellt (wie 0/1, ein/aus, usw.), Moduseingaben, wo die Eingabe eine von einer begrenzten Anzahl von Möglichkeiten ist, und/oder einer variablen Eingabe haben, wo die Eingabe eine von einer unendlichen Anzahl von Möglichkeiten (oder von einer sehr großen Zahl von Möglichkeiten) ist. Demgemäß kann bestimmt werden, dass die Flags und die Moduseingaben zustandsbasierte Eingaben sind, und sie können somit entsprechend getestet werden. Im aktuellen Beispiel wurde bestimmt, dass die Eingaben 302a beides Flags (binäre Eingaben) sind, während bestimmt wurde, dass die Eingabe 304 eine variable Eingabe ist. Es wurde bestimmt, dass die Eingabe 306 eine Moduseingabe ist.
-
Man beachte, dass die Bestimmung einer Eingabeart, wie einer ersten Eingabeart, einer zweiten Eingabeart usw., für jeden von den Blöcken in sowohl der Anwendungsschicht, der Funktionsschicht als auch der Modulschicht, die in 3A–3C dargestellt sind, getroffen werden kann. Zusätzlich zur Bestimmung der Eingabeart können die möglichen Eingabewerte auch für jede von den Eingaben bestimmt werden.
-
Sobald die Eingabearten und Eingabewerte bestimmt worden sind, kann die Test-Rechenvorrichtung 112 einen Testfall für jeden von den Blöcken in 3A–3C erzeugen. Genauer können die Testfälle als Logik erzeugt werden, die Permutationen von Werten (beispielsweise jede Permutation von zustandsbasierten Eingaben in der Fahrzeug-Software 144c) implementiert. Abhängig von der jeweiligen Ausführungsform kann das Testen der variablen Eingaben das Implementieren eines Mechanismus zum Testen eines Untersatzes möglicher Werte beinhalten. Als Beispiel kann ein Zufallswert für jede Permutation der zustandsbasierten Eingabewerte verwendet werden. Andere Mechanismen können verwendet werden, wie oben beschrieben.
-
Im vorliegenden Beispiel beinhaltet die logische Schaltung 300 einen logischen „und”-Operator 310, der die Eingaben 302 empfängt. Die Ausgabe des logischen „und”-Operators 310 wird zusammen mit den Werten 0 und 100 an einen ersten Schalter 312 geschickt. Der erste Schalter 312 macht eine Ausgabe an einen Multiport-Schalter 314. Ebenso werden die Eingaben 302 an einen logischen „oder”-Operator 316 geschickt. Die Ausgabe an den logischen „oder”-Operators 316 wird an einen zweiten Schalter 318 geschickt, der die Eingabe 304 empfängt, ebenso wie „0”. Der zweite Schalter 318 macht eine Ausgabe an den Multiport-Schalter 314. Der Multiport-Schalter 314 empfängt die Ausgaben vom ersten Schalter 312 und vom zweiten Schalter 318, ebenso wie den Wert „0” und die Eingabe 306. Der Multiport-Schalter 314 wählt eine gewünschte Ausgabe 320 aus.
-
3B stellt Eingaben dar, die aus der logischen Schaltung 300 von 3A bestimmt werden können und die gemäß hierin offenbarten Ausführungsformen verwendet werden können, um einen Testfall zu erzeugen. Wie für die logische Schaltung 300 von 3A dargestellt ist, kann die Tabelle 340 bereitgestellt werden, um zu zeigen, dass jede von den Eingaben in dem Testfall implementiert wird, wenn die Fahrzeug-Software 144c getestet wird. Wie dargestellt, beinhalten die Eingaben in diesem Beispiel eine Moduseingabe, zwei Flag-Eingaben und eine variable Eingabe. Demgemäß werden die drei zustandsbasierten Eingaben in allen Permutationen von eingegebenen Werten implementiert. Außerdem wird die variable Eingabe als Zufallswert für jede von den Zustandspermutationen der zustandsbasierten Eingaben implementiert.
-
Sobald der Testfall entwickelt worden ist, kann die Test-Rechenvorrichtung 112 bestimmen, ob der Testfall eine MC/DC jenseits eines vorgegebenen Schwellenwerts erreicht (z. B. 95%, 100% usw.). Falls der Testfall eine vorgegebene MC/DC erreicht, kann der Testfall in der Fahrzeug-Software 144c implementiert werden, um zu bestimmen, ob die Fahrzeug-Software 144c ordnungsgemäß programmiert worden ist.
-
4 stellt eine Anwenderschnittstelle 430 dar, die gemäß hierin offenbarten Ausführungsformen zur Erzeugung des zustandsbasierten Testfalls verwendet werden kann. Wie dargestellt kann die Test-Rechenvorrichtung 112 die Anwenderschnittstelle 430 zur Erzeugung eines neuen Testfalls bereitstellen. Der Anwender kann die Eingaben für jeden von den Blöcken in 2A–2C bestimmen und einen Eingabenamen in der Eingabespalte 432 identifizieren. In der Sequenzspalte 434 kann der Anwender die verwendete Eingabeart identifizieren, ebenso wie die möglichen Werte für diese Eingabeart.
-
Zum Beispiel hat der Anwender in der ersten Zeile eine Eingabe mit dem Namen „flag1” eingegeben, die als zustandsbasierte Eingabe mit den möglichen Werten 0 und 1 verwendet wird. In der zweiten Zeile wird eine Eingabe mit dem Namen „mode1” als zustandsbasierte Eingabe mit den möglichen Werten 0, 2 und 4 verwendet. In der dritten Zeile wird eine Eingabe mit dem Namen „var1” als zufällige Eingabe mit möglichen Werten von 0 bis 100 verwendet. Andere Eingaben können abhängig von der jeweils getesteten Fahrzeug-Software implementiert und vorgesehen werden.
-
Man beachte, dass die Sequenzbezeichnungen, die in 4 abgebildet sind, nur Beispiele sind. Genauer können Bezeichnungen wie Konstante, Zufall, zufällige ganze Zahl, Rampe (z. B. eskalierende Werte), Sequenz (z. B. ein Muster), Transition (z. B. eine Transitionsdatensequenz über einer vorgegebenen Zeit), Permutation (z. B. die Erzeugung eindeutiger Permutationen für mehrere Eingaben) und/oder andere verwendet werden. Man beachte außerdem, dass in 4 zwar nur eine einzige Sequenz dargestellt ist, dass manche Ausführungsformen aber eine Mehrzahl von Sequenzen verwenden können, um unterschiedlichen Werten der Eingaben gerecht zu werden.
-
Ebenfalls in 4 enthalten ist eine Sequenz-Hinzufügungsoption 436, eine Sequenz-Weglassungsoption 438, eine Eingabe-Hinzufügungsoption 440, eine Eingabe-Weglassungsoption 442 und eine Testfall-Zeichnungsoption 444. Die Sequenz-Hinzufügungsoption 436 kann verwendet werden, um dem aktuellen Testfall eine Sequenz hinzuzufügen. Ebenso kann die Sequenz-Weglassungsoption 438 verwendet werden, um eine aktuelle Sequenz wegzulassen. Die Eingabe-Hinzufügungsoption 440 kann verwendet werden, um zusätzliche Eingaben zu dem Testfall hinzuzufügen, während die Eingabe-Weglassungsoption 442 verwendet werden kann, um eine bereits vorhandene Eingabe in dem Testfall wegzulassen. Die Testfall-Zeichnungsoption 444 kann verwendet werden, um eine grafische Darstellung des Testfalls bereitzustellen, um zu bestimmen, ob der Testfall eine angemessene MC/DC aufweist.
-
Ebenfalls in 4 enthalten ist eine Testfalldatei-Ladeoption 446, eine Option 448 zum Laden eines neuen Testfalls, eine Testfalldatei-Speicheroption 450, eine Testfall-Generierungs- und -Speicherungsoption 452 und eine Option 454 zum Hinzufügen eines Testfalls zu einem Modell-Signal-Builder. Genauer kann die Testfalldatei-Ladeoption 446 ausgewählt werden, um einen bereits vorhanden Testfall für den aktuellen Test zu verwenden. Die Option 448 zum Laden eines neuen Testfalls kann ausgewählt werden, um einen neuen Testfall zu beginnen. Die Testfalldatei-Speicheroption 450 kann ausgewählt werden, um den aktuellen Testfall zu speichern. Die Testfall-Generierungs- und -Speicherungsoption 452 kann ausgewählt werden, um den vollständigen Testfall für die Implementierung zu generieren und um den Testfall zu speichern. Die Option 454 zum Hinzufügen eines Testfalls zu einem Modell-Signal-Builder kann ausgewählt werden, um den Testfall zum Modell-Signal-Builder hinzuzufügen.
-
5 stellt ein Ablaufschema zur Generierung eines zustandsbasierten Testfalls gemäß hierin offenbarten Ausführungsformen dar. Wie in Bock 550 dargestellt ist, können ein Programmblock, beispielsweise ein Anwendungsschichtblock, ein Funktionsschichtblock und/oder ein Mudulschichtblock in der Fahrzeug-Software 144 zum Testen ausgewählt werden. Wie oben erörtert, kann der Anwender mit der Anwenderschnittstelle 430 interagieren, um den Programmblock zu identifizieren. Im Block 552 können Eingaben und eine Eingabeart für das Modul bestimmt werden. Als Beispiel kann diese Bestimmung durch die Test-Rechenvorrichtung 112 durchgeführt werden, die mögliche Eingabewerte für die Eingabe identifiziert und dann die Eingabeart bestimmt. Ebenso kann die Bestimmung von der Test-Rechenvorrichtung 112 durchgeführt werden, welche die Eingabeart von einem Anwender empfangt. Unabhängig davon können die Eingaben eine zustandsbasierte Eingabe und eine nicht-zustandsbasierte Eingabe beinhalten. Im Block 554 können eindeutige Permutationen von Eingabewerten für die zustandsbasierten Eingaben bestimmt werden. Im Block 556 kann ein Mechanismus zum Zuweisen von nicht-zustandsbasierten Eingabewerten für die nicht-zustandsbasierten Eingaben bestimmt werden. Als Beispiel kann der Anwender in der Anwenderschnittstelle 430 angeben, ob die nicht-zustandsbasierten Eingabe Zufallswerte, Reihen und/oder andere Mechanismen sein werden. Im Block 558 kann der Testfall erzeugt und mit jedem von den zustandsbasierten Eingabewerten und den nicht-zustandsbasierten Eingabewerten durchgespielt werden. Im Block 560 können die Ergebnisse aus dem Testfall analysiert werden. Im Block 562 kann eine Bestimmung dahingehend getroffen werden, ob die Ziel-MC/DC erreicht worden ist. Falls nicht, kann das Ablaufschema zu Block 552 zurückkehren. Falls MC/DC erreicht wird, kann der Testfall in Block 564 validiert werden und verwendet werden, um die Fahrzeug-Software 144c zu testen.
-
Es sei klargestellt, dass hierin zwar eine Fahrzeug-Software 144c erörtert wird, dass der Bereich der vorliegenden Offenbarung aber nicht bloß auf eine Fahrzeug-Software beschränkt ist. Genauer können hierin offenbarte Ausführungsformen zum Testen jeder Art von Software verwendet werden, wo zumindest ein Teil der Eingaben in Programmblöcke als zustandsbasierte Eingaben identifiziert werden kann.
-
Wie oben dargestellt werden verschiedene Ausführungsformen für die zustandsbasierte Testfallgenerierung zur Software-Validierung offenbart. Genauer können die hierin offenbarten Ausführungsformen Anwendern die Fähigkeit verleihen, einen vorgegebenen Grad an MC/DC für einen Testfall zu erreichen, ohne Gefahr zu laufen, Mathematik hoher Ordnung anwenden zu müssen. Demgemäß kann der vorgegebene Grad an MC/DC leichter und effizienter erreicht werden als in heutigen Systemen.
-
Obwohl hierin bestimmte Ausführungsformen und Aspekte der vorliegenden Offenbarung dargestellt und beschrieben worden sind, können andere Änderungen und Modifikationen durchgeführt werden, ohne vom Gedanken und Bereich der Offenbarung abzuweichen. Darüber hinaus wurden hierin zwar verschiedene Aspekte beschrieben, aber diese Aspekte müssen in der Permutation nicht verwendet werden. Demgemäß sollen somit die beigefügten Ansprüche all diese Änderungen und Modifikationen, die im Bereich der hierin gezeigten und beschriebenen Ausführungsformen liegen, abdecken.
-
Es sollte nunmehr klar sein, dass hierin offenbarte Ausführungsformen Systeme, Verfahren und nicht-transitorische, computerlesbare Medien zum Bestimmen einer Temperaturkalibrierung beinhalten. Wie oben beschrieben sind diese Ausführungsformen so konfiguriert, dass sie einen dynamischen Glättungswert bestimmen, der auf Fahrzeuggeschwindigkeit, Kühlmitteltemperatur und/oder anderen Kriterien basiert. Es sei außerdem klargestellt, dass diese Ausführungsformen nur Beispiele sind und den Bereich der Offenbarung nicht beschränken sollen.
