DE102020206621A1

DE102020206621A1 - Verfeinerung von Abdeckungsanalysen unter Verwendung von Kontextinformation

Info

Publication number: DE102020206621A1
Application number: DE102020206621.3A
Authority: DE
Inventors: William Potter; William Aldrich; Aaron Hughes; Anjali Joshi; Zsolt Kalmar; Ebrahim M. Mestchian
Original assignee: MathWorks Inc
Current assignee: MathWorks Inc
Priority date: 2019-05-31
Filing date: 2020-05-27
Publication date: 2020-12-03

Abstract

Es werden Systeme und Verfahren zur Abdeckungsanalyse unter Verwendung von Kontextinformation beschrieben. Die Systeme und Verfahren können verwendet werden, um Programmcode und Testinformation zum Testen des Programmcodes zu erhalten, wobei die Testinformation mit Kontextinformation zum Bereitstellen von Kontext zum Testen des Programmcodes assoziiert ist. Abdeckungsinformation kann generiert werden durch Testen des Programmcodes gemäß der Testinformation. Eine erste Assoziation kann generiert werden zwischen der Kontextinformation und der Testinformation. Eine zweite Assoziation kann generiert werden zwischen der Kontextinformation und dem Programmcode. Eine dritte Assoziation kann generiert werden zwischen der Abdeckungsinformation und der Testinformation. Eine Teilmenge der Abdeckungsinformation kann bestimmt werden basierend auf der dritten Assoziation und einer vierten Assoziation zwischen der Testinformation und dem Programmcode, die bestimmt wird basierend auf der ersten und der zweiten Assoziation. Eine Indikation der Teilmenge der Abdeckungsinformation kann angezeigt werden.

Description

Diese Anmeldung ist eine Nicht-Prov. von Prov. (35 USC 119(e)) der U.S. Anmeldung mit Anmeldenummer 62/855,802 , eingereicht am 31. Mai 2019, mit dem Titel „Refining Coverage Analyses Using Context Information“, deren gesamter Gehalt durch Bezugnahme hiermit hierin aufgenommen ist.
Zusammenfassung der Offenbarung
Gemäß verschiedenen Aspekten werden Systeme und Verfahren bereitgestellt zum Verfeinern von Abdeckungsanalysen unter Verwendung von Kontextinformation. Insbesondere können alle hierin offenbarten Verfahren als computerimplementierte Verfahren implementiert werden, und/oder jeder der Schritte der hierin offenbarten Verfahren kann implementiert werden durch eine oder mehrere Rechnereinheiten, wie etwa einem oder mehreren Prozessoren. In bestimmten Ausführungsformen wird ein System bereitgestellt, das zumindest einen Prozessor und zumindest einen Speicher beinhalten kann. Der zumindest eine Speicher kann Befehle beinhalten, welche, wenn sie durch den zumindest einen Prozessor ausgeführt werden, das System dazu veranlassen, Operationen auszuführen. Die Operationen können beinhalten Erhalten von Programminformation, welche Programmcode beinhaltet, und von Testinformation zum Testen des Programmcodes, wobei die Testinformation assoziiert ist mit Kontextinformation zum Bereitstellen von Kontext zum Testen des Programmcodes. Anders gesagt können die Operationen beinhalten Erhalten von Programminformation, welche Programmcode beinhaltet, und von Testinformation zum Testen des Programmcodes, wobei die Testinformation in Beziehung mit Kontextinformation zum Bereitstellen von Kontext zum Testen des Programmcodes stehen kann. Die Operationen kann weiter beinhalten Generieren von Abdeckungsinformation durch Testen des Programmcodes gemäß der Testinformation. Die Operationen können auch beinhalten Bestimmen einer ersten Assoziation zwischen der Kontextinformation und der Testinformation. Die Operationen können zusätzlich beinhalten Bestimmen einer zweiten Assoziation zwischen der Kontextinformation und dem Programmcode. Die Operationen können weiter beinhalten Bestimmen einer dritten Assoziation zwischen der Abdeckungsinformation und der Testinformation. T Die Operationen können auch beinhalten Bestimmen einer Teilmenge der Abdeckungsinformation basierend auf der dritten Assoziation und einer vierten Assoziation zwischen der Testinformation und dem Programmcode, wobei die vierte Assoziation bestimmt wird basierend auf der ersten und der zweiten Assoziation. Weiterhin können die Operationen beinhalten Bereitstellen von Befehle, um eine Indikation der Teilmenge der Abdeckungsinformation anzuzeigen.
In bestimmten Ausführungsformen wird ein Testsystem für zumindest ein Rechensystem bereitgestellt, das zumindest ein Rechensystem und ein Testmodul umfasst.
Das zumindest eine Rechensystem kann umfassen und/oder kann konfiguriert sein, auf eine Speichereinheit zuzugreifen, welche Befehle beinhaltet, wie beispielsweise Programmcode, welche, wenn sie durch das zumindest eine Rechensystem ausgeführt werden, das zumindest eine Rechensystem dazu veranlassen, eine Aktion auszuführen, wie beispielsweise eine Vorrichtung zu steuern und/oder zu regeln. Das zumindest eine Rechensystem kann zum Beispiel ein Steuer- und/oder Regelungssystem sein und/oder die Vorrichtung kann eine Maschine sein, wie beispielsweise ein Automobil, ein Schiff, ein Flugzeug oder ein anderes Gefährt, wobei das Steuer- und/oder Regelungssystem konfiguriert sein kann, die Maschine zu steuern und/oder zu regeln, um beispielsweise die Geschwindigkeit oder die Leistungsabgabe der Maschine zu steuern und/oder zu regeln. Die Befehle, die in der Speichereinheit enthalten sind, können zum Beispiel konfiguriert sein, um nach dem Testen durch das Testmodul in einem Steuer- und/oder Regelungssystem zum Steuern und/der Regeln einer Vorrichtung implementiert zu werden. Als ein spezifisches Beispiel kann die Steuer- und/oder Regelungssystem ein Tempomat eines Fahrzeugs sein. Weiter kann das zumindest eine Rechensystem ein Hardware- Rechensystem sein, welches weiter zumindest einen Prozessor umfasst, wobei die Befehle, wenn sie durch den zumindest einen Prozessor des zumindest einen Rechensystems ausgeführt werden, das zumindest eine Rechensystem dazu veranlassen, eine Aktion auszuführen, wie beispielsweise Steuern und/oder Regeln der Vorrichtung. Weiterhin kann das zumindest eine Rechensystem eine Rechenumgebung sein, wie etwa beispielsweise eine Programmierumgebung und/oder eine Simulationsumgebung, die auf einem Hardware Rechensystem implementiert sein kann, welches zumindest einen Prozessor umfasst, wobei die Befehle, wenn sie durch das zumindest eine Rechensystem, welches auf dem Hardware Rechensystem implementiert ist, ausgeführt werden, wie beispielsweise indem die Befehle durch den zumindest einen Prozessor des Hardware Rechensystems ausgeführt werden, das zumindest eine Rechensystem dazu veranlassen, eine Aktion auszuführen, wie beispielsweise Steuern und/oder Regeln der Vorrichtung.
Das Testmodul kann zumindest einen Prozessor beinhalten und/oder kann umfassen und/oder kann konfiguriert sein, auf zumindest einen Speicher zuzugreifen. Der zumindest ein Speicher kann Befehle beinhalten, welche, wenn sie von zumindest einem Prozessor ausgeführt werden, das Testmodul dazu veranlassen, Operationen auszuführen. Die Operationen können beinhalten Erhalten von Programminformation, welche Programmcode beinhalten, beispielsweise von dem Rechensystem, und von Testinformation zum Testen des Programmcodes, wobei die Testinformation assoziiert ist mit (und/oder sich bezieht auf) Kontextinformation zum Bereitstellen von Kontext zum Testen des Programmcodes. Die Testinformation kann erhalten werden, zumindest zum Teil, von dem zumindest einen Speicher, dem Rechensystem, einem Benutzer und/oder einer externen Quelle von Testinformation, wie beispielsweise einem Testinformationsserver. Die Operationen können weiter beinhalten Generieren von Abdeckungsinformation durch Testen des Programmcodes gemäß der Testinformation. Die Operationen können auch beinhalten Bestimmen einer ersten Assoziation zwischen der Kontextinformation und der Testinformation. Die Operationen können weiter beinhalten Bestimmen einer zweiten Assoziation zwischen der Kontextinformation und dem Programmcode. Die Operationen können weiter beinhalten Bestimmen einer dritten Assoziation zwischen der Abdeckungsinformation und der Testinformation. Die Operationen können auch beinhalten Bestimmen einer Teilmenge der Abdeckungsinformation basierend auf der dritten Assoziation und einer vierten Assoziation zwischen der Testinformation und dem Programmcode, wobei die vierte Assoziation bestimmt wird basierend auf der ersten und der zweiten Assoziation. Weiterhin können die Operationen beinhalten Bereitstellen von Befehle, um eine Indikation der Teilmenge der Abdeckungsinformation anzuzeigen.
Zudem kann das Testmodul implementiert werden als eine Komponente des zumindest einen Rechensystems. Anders gesagt kann das Testmodul implementiert werden als eine Rechenmodulkomponente des zumindest einen Rechensystems, wobei die Befehle des zumindest einen Speichers, wenn sie von dem zumindest einen Prozessor des zumindest einen Rechensystems ausgeführt werden, das Testmodul dazu veranlassen können, um die Operationen auszuführen. Auf eine solche Weise kann es möglich sein, das zumindest eine Rechensystem und das Testmodul als ein integriertes System bereitzustellen. Alternativ kann das Testmodul ein Hardware Testmodul sein, weiter umfassend zumindest einen Prozessor, wobei die Befehle, wenn sie durch den zumindest einen Prozessor des Hardware Testmoduls ausgeführt werden, das Testmodul dazu veranlassen, die Operationen auszuführen.
Weiterhin sind hierin, in bestimmten weiteren Ausführungsformen, ein entsprechendes Verfahren zum Testen a Rechensystem und ein nichttransitorisches computerlesbares Medium, welches Befehle enthält, die, wenn sie von einem oder von mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren dazu veranlassen, das entsprechende Verfahren auszuführen, beschrieben. Weiterhin sind, in weiteren Ausführungsformen, eine Verwendung der Aspekte, Verfahren und Systeme, die hierin beschrieben sind, zum Testen von zumindest einem Rechensystem bereitgestellt, wobei das zumindest eine Rechensystem eine Speichereinheit umfassen kann, die den Programmcode enthält.
Die vorstehende Zusammenfassung wird allein beispielhaft gegeben und ist nicht dazu gedacht, beschränkend zu sein.
Figurenliste
Der Fachmann wird versehen, dass die hierin beschriebenen Zeichnungen allein den Zwecken der Illustration dienen. Es sei verstanden, dass in einigen Fällen verschiedene Aspekte der Erfindung auf übertriebene oder vergrößerte Weise gezeigt sein mögen, um das Verständnis der Erfindung zu erleichtern. In den Zeichnungen bezeichnen gleiche Bezugszeichen allgemein gleiche Merkmale, funktionell ähnliche und/oder strukturell ähnliche Elemente in den verschiedenen Figuren. Die Zeichnungen sind nicht notwendiger Weise maßstabsgerecht, wobei das Hauptaugenmerk vielmehr darauf gelegt ist, die Prinzipien der Lehren zu illustrieren. Die Zeichnungen sind nicht dazu gedacht, den Bereich der vorliegenden Lehren in irgendeiner Weise zu beschränken.

1 zeigt das Generieren einer Assoziation zwischen Programminformation und Testinformation;
2 zeigt eine beispielhafte Umgebung, in welcher Systeme und/oder Verfahren, die hierin beschrieben sind, implementiert werden können;
3 zeigt ein beispielhaftes Schema von einer oder von mehreren der Vorrichtungen der in 2 gezeigten Umgebung;
4 zeigt eine beispielhafte grafische Benutzerschnittstelle, die eine Modell enthält, das geeignet ist zur Analyse gemäß dem Verfahren von 1;
5 zeigt eine beispielhafte Assoziation zwischen Abdeckungsinformation und Programminformation;
6 zeigt beispielhaft Anforderungs-Kontextinformation;
7 zeigt eine beispielhafte Anwendung von Beurteilungs-Kontextinformation;
8 zeigt eine beispielhafte Anwendung von Testkriterien-Kontextinformation;
9 zeigt eine beispielhafte Anwendung von temporaler Beurteilungs-Kontextinformation;
10A zeigt ein beispielhaftes Verfahren zum Unterteilen von Abdeckungsinformation;
10B zeigt eine beispielhafte Verfahren zum Bestimmen einer Assoziation zwischen der Abdeckungsinformation und der Programminformation;
11A und 11B zeigen eine beispielhafte grafische Benutzerschnittstelle zum Anzeigen einer Abdeckung, die mit Modellelementen assoziiert ist.
12A und 12B zeigen eine beispielhafte grafische Benutzerschnittstelle zum Anzeigen einer aggregierten Abdeckung.

Die Merkmale und Vorteile der vorliegenden Erfindung werden ersichtlicher aus der nachfolgenden detaillierten Beschreibung, wenn in Verbindung mit den Zeichnungen genommen.
Detaillierte Beschreibung
Die folgende detaillierte Beschreibung bezieht sich auf die beigefügten Zeichnungen. Dieselben Bezugszeichen in unterschiedlichen Zeichnungen können dieselben oder ähnliche Elemente identifizieren.
Ein Programmcode, der in Systemen in der echten Welt eingesetzt werden soll, muss vor dessen Einsatz getestet und verifiziert werden. Beispielsweise müssen Steuer- und/oder Regelsysteme für Gefährt, wie beispielsweise Flugzeuge oder Automobile, getestet und verifiziert werden, bevor sie in eingebetteten Steuer- und/oder Regelsystemen für das Gefährt eingesetzt werden. Ein solches Testen und Verifizieren soll dazu dienen, unerwünschte oder unerwartete Verhaltensweisen zu identifizieren und die Leistungsfähigkeit und Funktionalität des Programmcodes zu verifizieren. Die Ausführlichkeit der Tests kann wichtig sein, da sonst unerwünschte oder unerwartete Verhaltensweisen übersehen werden können. Zum Beispiel kann die Entwicklung eines Flugzeugsteuer- und/oder -regelungssystems mit unbekannten Fehlermöglichkeiten tragische Konsequenzen haben. Insbesondere verbessern die hierin beschriebenen Aspekte, Verfahren und Systeme zu Zuverlässigkeit und Effektivität derartiger Tests und Verifikationen signifikant. Weiterhin verbessern diese Aspekte, Verfahren und Systeme daher die korrekte Funktionalität von getestetem Programmcode und/oder getesteten Vorrichtungen, und verbessern auch Sicherheitsaspekte des getesteten Programmcodes und/oder der getesteten Vorrichtung, die auf der korrekten Ausführung des Codes beruht. Daher ist es zum Beispiel möglich, ein verbessertes Testsystem zum Testen von Code mit verbesserter Zuverlässigkeit und Effektivität bereitzustellen.
Das Testen und Verifikation von Programmcode kann beinhalten Ausführen einer Abdeckungsanalyse des Programmcodes. Eine solche Abdeckungsanalyse kann beinhalten, dynamisch zu analysieren, wie der Programmcode ausgeführt wird, und kann ein Maß der Vollständigkeit für das Testen bereitstellen. Solange es jedoch keine Möglichkeit gibt, die Abdeckungsanalyse zu einer aussagefähigen Abdeckung zu verfeinern, mag die Abdeckungsanalyse die Vollständigkeit des Testens zu hoch angeben. Zum Beispiel kann ein Test, der dazu gedacht oder geeignet ist, eine erste Komponente des Programmcodes zu testen, die Ausführung der ersten Komponente veranlassen und die Ausführung einer zweiten Komponente des Programmcodes veranlassen. Der Test mag jedoch nicht dazu gedacht oder geeignet sein, die zweite Komponente des Programmcodes zu testen. Eine Abdeckungsanalyse, die nicht zwischen der Ausführung der ersten Komponente und der Ausführung der zweiten Komponente unterscheidet, mag die Vollständigkeit des Testens überschätzen. Insbesondere können die hierin beschriebenen Aspekte, Verfahren und Systeme es ermöglichen, dass die Tests und Verifikationen die Eignung der Tests und Verifikationen für eine oder mehrere Komponenten des Programmcodes identifizieren und/oder berücksichtigen. Insbesondere ermöglichen die hierin beschriebenen Aspekte, Verfahren und Systeme somit Tests und Verifikationen mit verbesserter Zuverlässigkeit und Genauigkeit. Es ist daher zum Beispiel möglich, ein Testsystem zum Testen von Code mit erhöhter Zuverlässigkeit und Genauigkeit bereitzustellen, wobei insbesondere die Überschätzung der Vollständigkeit des Testens verhindert und/oder verringert werden kann.
Die Erfinder haben erkannt und wahrgenommen, dass eine Abdeckungsanalyse basierend auf Kontextinformation verfeinert werden kann. Die kontextuelle/Kontextinformation kann zusätzliche Information sein, zum Beispiel extern der oder extrahiert von den Tests und/oder dem Programmcode. Die Kontextinformation kann verwendet werden, um eine Abdeckungsanalyse des Programmcodes zu verfeinern, und um zu bestimmen, ob eine Abdeckung, die während der Tests gesammelt wird, unter diesem Kontext aussagefähig ist. Zum Beispiel kann in dem oben beschriebenen Beispiel die Abdeckung der ersten Komponente des Programmcodes als aussagefähig zu sein bestimmt werden, während die Abdeckung der zweiten Komponente des Programmcodes nicht aussagefähig ist, unter dem Kontext der Absicht der Tests, der abgeleitet werden kann aus den Entwurfsanforderungen, Testanforderungen oder anderen Quellen. Insbesondere die hierin beschriebenen Aspekte, Verfahren und Systeme können daher Tests und Verifikationen mit verbesserter Genauigkeit und Signifikanz ermöglichen. Daher ist es zum Beispiel möglich, ein Testsystem zum Testen von Code mit erhöhter Genauigkeit und Signifikanz bereitzustellen, wobei das Testsystem in der Lage sein kann, dass eine nicht aussagefähige Abdeckung als aussagefähig bestimmt wird, was in besser getestetem Programmcode und demzufolge einem höheren Grad an Gewissheit in der Zuverlässigkeit des Testens resultiert.
Die Erfinder haben erkannt und wahrgenommen, dass ein Verfeinern einer Abdeckungsanalyse basierend auf Kontextinformation die Präzision der Abdeckungsanalyse verbessern kann. Ein Test kann zum Beispiel mehrere Teile des Programmcodes zur Ausführung bringen, aber der Test mag nur dazu entworfen oder gedacht sein, die Leistungsfähigkeit oder Funktionalität einer Teilmenge dieser mehrerer Teile des Programmcodes zu verifizieren. Der Beitrag des Tests zur Abdeckungsanalyse kann dann auf die Teile des Programmcodes verfeinert werden, welche der Test zu verifizieren entworfen oder gedacht wurde. Das Verfeinern der Abdeckungsanalyse auf diese Weise mag auf bessere Weise das Design oder die Absicht des Tests reflektieren und kann zusätzliche Lücken in der Abdeckung sichtbar machen. Eine solche Lücke kann einen Teil des Programmcodes beinhalten, für welchen eine Abdeckung durch einen Test fehlt, der entworfen oder erdacht wurde, diesen Teil des Programmcodes abzudecken, wie aus dem Kontext bestimmt. Die hierin beschriebenen Aspekte, Verfahren und Systeme können daher Tests und Verifikationen mit erhöhter Genauigkeit und Relevanz für die zu testenden Komponenten des Programmcodes bereitstellen und können weiter eine Überschätzung der ausgeführten Abdeckungsanalyse verhindern, was ein gründlicheres und zielgerichteteres Testen erlauben kann, und infolge dessen eine bessere Leistungsfähigkeit des getesteten Programmcodes, wenn dieser ausgeführt wird. Daher ist es zum Beispiel möglich, ein Testsystem zum Testen von Code mit erhöhter Genauigkeit und Zuverlässigkeit bereitzustellen.
Das Verbessern der Präzision der Abdeckungsanalyse kann in besser getestetem Code resultieren. Lücken in aussagefähiger Abdeckung für einen Teil von Programmcode können durch Tests adressiert werden, die dazu entworfen oder gedacht sind, diesen Teil des Programmcodes abzudecken. Diese zusätzlichen Tests können unbeabsichtigtes Verhalten aufdecken, was in Revisionen an dem Programmcode resultiert. Auf diese Weise kann das Verfeinern von Abdeckungsanalysen basierend auf Kontextinformation die Qualität des analysierten Codes verbessern. Weiterhin können die hierin beschriebenen Aspekte, Verfahren und Systeme daher auch ein umfassenderes Testen ermöglichen durch Identifizieren von Lücken, wodurch es ermöglicht wird, ein zielgerichtetes zusätzliches Testen auszuführen, um die Gesamtgenauigkeit und Gesamteffizienz der Tests und Verifikationen zu verbessern. Es ist daher zum Beispiel möglich, ein Testsystem zum Testen von Code mit erhöhter Genauigkeit und Signifikanz bereitzustellen, während gleichzeitig auch die erforderlichen Ressourcen reduziert werden, wie beispielsweise Rechenressourcen, die notwendig sind, um das Testen auszuführen, indem zum Beispiel eine präzisere Bestimmung des erforderlichen zusätzlichen Testens ermöglicht wird.
Die Erfinder haben technische Probleme mit alternativen Ansätzen zum Verfeinern einer Abdeckungsanalyse erkannt und identifiziert. Das Beschränken von Tests auf bestimmte Komponenten oder eine bestimmte Subkomponente kann schwierig oder unmöglich sein, wenn der Programmcode mehrere Komponenten oder Subkomponenten. Das Erzeugen von Testausrüstungen, um einzelne Testkomponenten oder Subkomponenten zu testen, kann schwierig, unhandlich oder ineffizient sein. Ein solches individuelles Testen mag auch inadäquat sein, weil ein bestimmtes Verhalten nur auftreten mag, wenn eine Komponente im Kontext des Gesamtsystems arbeitet. Daher kann ein Benutzer, zum Beispiel ein Entwickler eines Programmcodes, Szenarios zu testen wünschen, das mehrere Komponenten oder Subkomponenten des Programmcodes impliziert. Die hierin beschriebenen Aspekte, Verfahren und Systeme können daher ein umfassenderes Testen von Programmcode ermöglichen, wie beispielsweise von Programmcode, der mehrere Komponenten und/oder Subkomponenten umfasst, welches anderweitig inadäquat oder unmöglich wäre. Weiterhin kann die Effizienz der Tests und Verifikationen verbessert werden, da ineffiziente oder inadäquate individuelle Tests der Komponenten oder Subkomponenten vermieden werden kann, wodurch die Zeit, die notwendig ist, um das Testen auszuführen, weiter reduziert wird. Darüber hinaus ist es zum Beispiel möglich, ein Testsystem zum Testen von Code mit einer verbesserten Mensch-Maschine Interaktion bereitzustellen, indem es dem Benutzer ermöglicht wird, Testen signifikant effizienter auszuführen.
Die Erfinder haben auch erkannt und wahrgenommen, dass der Umfang und die Komplexität von Abdeckungsanalysen die manuelle Identifikation aussagefähiger Abdeckung verhindern kann. Wie die Fachleute verstehen würden, kann das Testen tausende von Anforderungen und hunderte von Tests involvieren. Programmcode kann tausende von Komponenten beinhalten (und für grafischen Programmcode einige zehn- bis hunderttausende Blöcke). Abdeckungsanalysen können einige zehnbis hunderttausende Abdeckungspunkte involvieren. Das Identifizieren von aussagefähiger Abdeckung unter solchen Bedingungen stellt ein erhebliches technisches Problem dar. Dementsprechend stellen die hierin beschriebenen Systeme und Verfahren technische Lösungen zu technischen Problemen mit alternativen Ansätzen zur Verfeinerung bereit. Weiterhin verbessern die beschriebenen Systeme und Verfahren, indem sie die Identifikation von aussagefähiger Abdeckung verbessern, weiter die Effizienz des Testens und des Entwerfens von Programmcode. Darüber hinaus ermöglichen die hierin beschriebenen Aspekte, Verfahren und Systeme eine signifikant verbesserte Mensch-Maschine-Interaktion der Tests und Verifikationen. Es ist daher zum Beispiel möglich, ein effizientes Testsystem zum Testen komplexen und/oder extensiven Programmcodes bereitzustellen, welcher anderweitig eine aussagefähige oder hinreichende Abdeckungsanalyse verhindern würde.
Daher erlauben die hierin beschriebenen Aspekte, Verfahren und Systeme, wie beispielsweise ein Testsystem, eine signifikante Verbesserung der Genauigkeit, Zuverlässigkeit und Signifikanz des Testens von Programmcode, was besser getesteten Programmcode und in Konsequenz dessen erhöhte Performanz des getesteten Programmcodes, wenn dieser ausgeführt wird, ermöglicht. Weiterhin ist es daher möglich, die Zuverlässigkeit von Vorrichtungen zu verbessern, die auf der Ausführung des getesteten Programmcodes beruhen, wenn dieser ausgeführt wird, wie beispielsweise ein Tempomat System und/oder ein Steuer- und/oder Regelungssystem für Maschinen und/oder Gefährt. Insbesondere können derartige Vorrichtungen mittels einem modellbasierten Entwurfsprozess gemäß der Offenbarung entworfen werden, wobei der modellbasierte Entwurfsprozess einen Testprozess gemäß der Offenbarung beinhalten kann. Insbesondere kann es daher möglich sein, ein akkurateres Design bereitzustellen und es der entworfenen Vorrichtung zu ermöglichen, wie gewünscht zu arbeiten (zum Beispiel gemäß Entwurfsanforderungen, welche eine Art von Kontextinformation wie hierin beschrieben sein können). Insbesondere mag es, ohne korrektes und/oder extensives Testen, möglich sein, dass ein entworfenes System in einer Rechenumgebung, sobald es in einer Hardwarevorrichtung implementiert ist, es der Hardwarevorrichtung nicht erlaubt, so zu arbeiten, wie es von den Anforderungen der entworfenen Vorrichtung spezifiziert ist. Darüber hinaus kann Programmcode, der in der Hardwarevorrichtung zum Einsatz gebracht wird, von einem Modell wie hierin beschrieben generiert werden, und kann die Funktionalitäten dieses Modells Widerspiegeln. Weiterhin reduzieren die Aspekte, Verfahren und Systeme signifikant die Zeit, die notwendig ist zum Testen, Verbessern des Systemdesigns, Testen der Genauigkeit und/oder die Ressourcen zu reduzieren, die erforderlich sind zum Testen, indem zum Beispiel die Präzision des Testens verbessert wird und/oder eine präzisere Bestimmung von erforderlichem zusätzlichen Testen ermöglicht wird. Darüber hinaus ermöglichen die Aspekte, Verfahren und Systeme eine verbesserte Mensch-Maschine-Interaktion, wie oben diskutiert. Die obigen technischen Effekte und Vorteile sind jedoch allein illustrativ gedacht und andere technische Effekte und Vorteile werden ersichtlicher werden aus der Offenbarung.
Die Begriffe „Code“, „Programm“, „Programmcode“ und/oder „Programmiercode“, wie hierin verwendet, werden synonym gebraucht und sind allgemein so zu verstehen, textuellen Code, graphischen Code oder eine Kombination von textuellem und graphischen Code zu beinhalten. Textueller Code kann textbasierten Code beinhalten, der einer weiteren Verarbeitung bedarf, um ausgeführt zu werden (zum Beispiel Ada, Basic, JAVA, C, C++, C#, FORTRAN oder Assemblersprachencode; Hardwarebeschreibungssprachen- („Hardware Beschreibung Sprache“, HDL) Code, ultraschnelle integrierte Schaltungen („veryhigh-speed integrated circuits“, VHSIC) HDL (VHDL) Code, VERILOG, Systeme und/oder andere Arten von Hardware- oder Software-basiertem Code, der kompiliert und/oder synthetisiert werden kann); Binärcode, der ausgeführt werden kann (zum Beispiel ausführbare Dateien, die von einem Betriebssystem direkt ausgeführt werden können, Bitstrom-Dateien, die verwendet werden können, um eine feldprogrammierbare Gatterlogik (FPGA) zu konfigurieren, JAVA Bytecode, Code (zum Beispiel LLVM Intermediärrepräsentation), der von einer virtuellen Maschine, zum Beispiel LLVM, konsumiert oder verarbeitet werden kann, Objektdateien kombiniert mit Linkerdirektiven, Quellcode, Make-Dateien und so weiter); Textdateien, die ausgeführt werden können in Verbindung mit anderen ausführbaren Dateien (zum Beispiel Python Textdateien, eine Sammlung von dynamischen Linker-Bibliotheksdateien (DLL) mit textbasiertem Kombinieren, Konfigurationsinformation, welche vorkompilierte Module verbindet, eine erweiterbare Markierungssprachen-(XML) Datei, welche Modullinken beschreibt, etc.); und so weiter. In einem Beispiel beinhaltet textueller Code unterschiedliche Kombinationen der oben identifizierten Klassen (zum Beispiel textbasierter Code, Binärcode, Textdateien, etc.). Alternativ oder zusätzlich kann textueller Code einen Code in einer Programmiersprache beinhalten, welche dynamische Typisierung unterstützt (zum Beispiel die M Sprache, eine MATLAB® Sprache, eine MATLAB-kompatible Sprache, eine MATLAB-ähnliche Sprache, Julia, etc.), welche verwendet werden kann, um Probleme und/oder Lösungen in mathematischer Notation auszudrücken. Graphischer Code kann Modelle beinhalten, die erstellt wurden durch Verbinden von graphischen Blöcken, wo jeder Block ein Objekt repräsentieren kann, das mit einer Funktionalität und/oder Daten assoziiert ist. Blöcke können hierarchisch sein in dem Sinn, dass jeder Block selbst als ein oder mehrere Blöcke implementiert sein kann. Ein Benutzer kann zum Beispiel das Modell auf einer hohen Ebene betrachten, und dann Blöcke auswählen, um tiefer in das Modell hinabzusteigen, um zunehmende Ebenen von Modelldetail zu betrachten. Graphischer Code kann direkt in textlichen Code konvertierbar sein, der in einer Zielumgebung ausgeführt werden kann. Graphischer Code kann beispielsweise ein Modell eines Steuer- und/oder Regelungssystems für ein Automobil beinhalten, das in textlichem Code implementiert sein kann, der in einem eingebetteten System in dem Automobil zum Einsatz gebracht wird. Beispielhafte Umgebungen zum Generieren von graphischem Code beinhalten Simulink®, Stateflow®, SimEvents™, etc., von The MathWorks, Inc.; VisSim von Visual Solutions: LabView® von National Instruments; Dymola von Dynasim: SoftWIRE von Measurement Computing: WiT von DALSA Coreco; VEE Pro oder SystemVue von Agilent; Vision Program Manager von PPT Vision; Khoros von Khoral Research; Gedae von Gedae, Inc.; Scicos von (INRIA); Virtuoso von Cadence: Rational Rose von IBM; Rhopsody oder Tau von Telelogic; Ptolemy von der University of California at Berkeley; Agilent VEE von Agilent Technologies; Advanced Design System (ADS) von Agilent Technologies; Agilent Ptolemy von Agilent Technologies; SCADE Suite von Ansys; ASCET, CoWare, oder Aspekte einer Unified Modeling Language (UML) oder SysML Umgebung.
Der Ausdruck „Abdeckungsanalyse“, wie hierin verwendet, ist breit zu verstehen, so dass er eine Bestimmung beinhaltet, wieviel Programmcode von einer Testsuite ausgeübt wurde. Eine Abdeckungsanalyse kann eine Kontrollfluss-basierte Abdeckungsanalyse beinhalten, welche bestimmt, ob Anweisungen, Entscheidungen oder Bedingungen in dem Programmcode ausgeführt wurden, und/oder eine Datenfluss-basierte Abdeckungsanalyse, welche die Erzeugung und Verwendung von Werten während der Ausführung des Programmcodes evaluiert. Die Datenfluss-basierte Abdeckungsanalyse kann zum Beispiel die Erzeugung und den Zugriff auf Speicherorte, die mit Variablen assoziiert sind, während der Ausführung des Programmcodes nachverfolgen. Eine Abdeckungsanalyse kann beinhalten, zu bestimmen, ob ein Test die Stimulation von Pfaden durch ein Modell ausübt. Die Abdeckungsanalyse kann zum Beispiel bestimmen, ob Komponenten, Transitionen, Eingänge, Ausgänge oder Zustände eines grafischen Modells exerziert wurden. Eine Abdeckungsanalyse kann Ausführungsabdeckung, Entscheidungsabdeckung, Bedingungsabdeckung, modifizierte Bedingungs-/Entscheidungsabdeckung, Lookup-Tabellen-Abdeckung, Signalbereichsabdeckung, Signalgrößenabdeckung, Ziel- und Bedingungsabdeckung, Sättigung bei Ganzzahl-Überlauf-Abdeckung, Relationsgrenzenabdeckung, Toggie-Abdeckung und/oder andere Abdeckungsmaße beinhalten.
Der Ausdruck „Abdeckungspunkt“, wie hierin verwendet, ist breit zu verstehen, so dass er ein Objekt einer Abdeckungsanalyse beinhaltet. Für eine bestimmte Abdeckungsanalyse kann Programmcode mit mehreren Abdeckungspunkten assoziiert sein. Die Art der Abdeckungsanalyse kann die bestimmten Abdeckungspunkte für den Programmcode bestimmen. Wenn zum Beispiel die Abdeckungsanalyse eine Entscheidungsabdeckung ist, können die Abdeckungspunkte die Entscheidungspunkte in dem Programmcode sein (zum Beispiel potentielle Ergebnisse von Kontrollflussanweisungen, Schaltblockausgänge in einem grafischen Modell, Stateflow® Zustände oder ähnliches). Als ein weiteres Beispiel, wenn die Abdeckungsanalyse eine Bedingungsabdeckung ist, können die Abdeckungspunkte Kombinationen der logischen Anweisungen in dem Programmcode und Boolsche Werte für diese logischen Anweisungen sein (zum Beispiel kann ein Abdeckungspunkt eine logische Anweisung in dem Programmcode sein, die als „WAHR“ evaluiert wurde, und ein anderer Abdeckungspunkt kann dieselbe logische Anweisung sein, die als „FALSCH“ evaluiert wurde - ein vollständige Bedingungsabdeckung kann jede logische Anweisung in dem Programmcode sein, welche beide möglichen Wahrheitswerte angenommen hat). Als ein weiteres Beispiel, wenn die Abdeckungsanalyse eine Anweisungsabdeckung ist, können die Abdeckungspunkte die Anweisungen des Programmcodes sein. Wie aus diesen Beispielen verständlich, können unterschiedliche Abdeckungsanalysen desselben Programmcodes unterschiedliche Abdeckungspunkte evaluieren. In einigen Ausführungsformen können die Abdeckungspunkte statisch bestimmt werden basierend zumindest zum Teil auf der Struktur des Programmcodes. In einigen Fällen können die Abdeckungspunkte mit Komponenten des Programmcodes assoziiert sein.
Abdeckungspunkte können nachverfolgbar bzw. rückverfolgbar sein zu entsprechenden Teilen des Programmcodes. Wenn zum Beispiel eine Entscheidungsabdeckungsanalyse auf grafischem Programmcode ausgeführt wird, der einen Umschaltblock enthält, können Abdeckungspunkte, die dem Umschaltblock entsprechend, zu dem Umschaltblock zurückverfolgbar sein. Beispielsweise kann eine Umgebung zum technischen Rechnen, welche die Entscheidungsabdeckungsanalyse ausführt, eine Assoziation zwischen dem Umschaltblock und den Abdeckungspunkten, welche dem Umschaltblock entsprechen, erzeugen oder verwalten. Diese Assoziation kann die Identifikation des Umschaltblock aus einem oder mehreren der entsprechenden Abdeckungspunkte ermöglichen, oder die Identifikation des einen oder der mehreren entsprechenden Abdeckungspunkte von dem Umschaltblock. Auf ähnliche Weise kann eine Umgebung zum technischen Rechnen, die eine Bedingungsabdeckungsanalyse ausführt, eine Assoziation zwischen einem Abdeckungspunkt, der einem Boolschen Wert für eine logische Anweisung in textuellem Programmcode entspricht, und der logischen Anweisung in dem textuellen Programmcode erzeugen oder verwalten.
Der Ausdruck „Abdeckungspunktergebnis“, wie hierin verwendet, ist breit zu verstehen, dahingehend, Daten zu beinhalten, die angeben, dass ein Abdeckungspunkt erreicht wurde während dem Testen des Programmcodes. In einigen Ausführungsformen kann der Programmcode instrumentiert werden, um eine Indikation aufzuzeichnen, dass ein Abdeckungspunkt erreicht wurde während dem Testen des Programmcodes. Auf diese Weise können die Abdeckungspunktergebnisse während dem Testen des Programmcodes gesammelt werden. Als ein nichtbeschränkendes Beispiel können Abdeckungseinstellungen zum Testen von Programmcode die Performanz einer Entscheidungsabdeckungsanalyse spezifizieren. Dementsprechend können Entscheidungspunkte in dem Programmcode identifiziert werden. Der Programmcode kann instrumentiert werden, um aufzuzeichnen, ob diese Entscheidungspunkte während dem Testen des Programmcodes erreicht werden.
Die Abdeckungspunktergebnisse können rückverfolgbar sein zu entsprechenden Abdeckungspunkten, und können rückverfolgbar sein zu einem Test oder Testschritt, während welchem das Abdeckungspunktergebnis gesammelt wurde. In einigen Ausführungsformen kann ein Abdeckungspunktergebnis beinhalten oder assoziiert sein mit Daten (zum Beispiel gespeicherten Daten), die einen Kontext angeben, in welchem das Abdeckungspunktergebnis gesammelt wurde. Dieser Kontext kann eine Zeit beinhalten, zu der das Abdeckungspunktergebnis gesammelt wurde.
Übersicht
Wie hierin beschrieben, können Abdeckungsanalysen verbessert werden, indem Kontextinformation verwendet wird, um eine Unterteilung von Abdeckungsinformation zu ermöglichen. In einigen Ausführungsformen kann die Unterteilung ausgeführt werden durch Kategorisieren der Abdeckungsinformation und Auswählen von Abdeckungsinformation in einer oder in mehreren der Kategorien. 1 zeigt Generieren einer Assoziation 117 zwischen Testinformation und Programminformation unter Verwendung von Kontextinformation 105, konsistent mit offenbarten Ausführungsformen. Die Assoziation 117 kann generiert werden unter Verwendung der Assoziation 111 zwischen der Kontextinformation 105 und der Programminformation 101 und der Assoziation 113 zwischen der Testinformation 103 und der Kontextinformation 105. In einigen Ausführungsformen kann die Assoziation 115 zwischen der Abdeckungsinformation 107 und der Testinformation 103 und die Assoziation 117 verwendet werden, um die Abdeckungsinformation 107 zu unterteilen. Die Abdeckungsinformation 107 kann zum Beispiel kategorisiert werden unter Verwendung der Assoziation 117. Elemente der Abdeckungsinformation 107 in einer oder in mehreren der Kategorien können ausgewählt werden. Eine Indikation der ausgewählten Elemente kann dann angezeigt werden.
Wie in 1 können Assoziationen zwischen der Programminformation 101, der Testinformation 103, der Kontextinformation 105 und der Abdeckungsinformation 107 erzeugt werden. Diese unterschiedlichen Arten von Information werden hierin beschrieben. Die Programminformation 101 kann Programmcode beinhalten, der von einer Umgebung zum technischen Rechnen ausgeführt werden kann. In einigen Ausführungsformen kann der Programmcode hierarchisch ist, dass er eine oder mehrere Komponenten oder Subkomponenten beinhaltet. Wenn zum Beispiel der Programmcode ein grafischer Programmcode ist, kann die Programminformation 101 ein grafisches Modell beinhalten, das Modellkomponenten beinhalten kann, wie beispielsweise Blöcke oder andere Modelle. Ein Modell oder block kann eine Menge von Eingängen, eine Menge von Ausgängen, eine Menge von Zuständen, eine Menge von Parametern und eine Menge von Ausgängen beinhalten. Der Ausgang eines Modells oder Blocks kann mit dem Eingang eines anderen Blocks verbunden sein. Während der Ausführung eines Modells können die Ausgänge einer Modellkomponente von einer Simulationszeit, den Eingängen zu der Modellkomponente, den Parametern der Modellkomponente, und/oder den Zuständen der Modellkomponente abhängen. Blöcke können eine vorbestimmte Funktionalität und/oder eine benutzerdefinierte Funktionalität beinhalten. Beispielsweise kann ein Block eine gemeinsame Funktionalität implementieren, wie das Integral oder die Ableitung eines Eingangssignals auszugeben. Als ein weiteres Beispiel kann ein Block benutzerdefinierten textuellen Code beinhalten, wie beispielsweise MATLAB®, C, C++, oder FORTRAN.
In verschiedenen Ausführungsformen kann die Programminformation 101 eine Beschreibung des Programmcodes enthalten. Die Beschreibung kann eine Partitionierung des Programmcodes in Komponenten und Subkomponenten widerspiegeln. Die Beschreibung kann beispielsweise ein Baum sein, wobei sich das Programm als Ganzes am Wurzelknoten und die Komponenten und Subkomponenten als Kinderknoten. In einigen Ausführungsformen kann die Partitionierung des Programmcodes von einem Typ von Abdeckungsanalyse abhängen, der während dem Testen ausgeführt wird. Die Blätter des Baums können beispielsweise Abdeckungspunkten entsprechen, die durch die Abdeckungsanalyse, wie hierin beschrieben, definiert werden. Die Beschreibung des Programmcodes ist auf keine bestimmte Realisierung beschränkt. Die Beschreibung kann beispielweise als Daten realisiert werden, die separat von dem Programmcode gespeichert werden (zum Beispiel eine separate Datei, die eine Hierarchie von Programmkomponenten, Subkomponenten und Abdeckungspunkten) enthält. Als ein weiteres Beispiel kann die Beschreibung verwirklicht werden als Daten, die zusammen mit dem Programmcode gespeichert werden (zum Beispiel als Metadaten, Labels, Tags, oder dergleichen). In verschiedenen Ausführungsformen kann die Partitionierung des i Programmcodes von der Testinformation 103 abhängen. Wenn der Programmcode zum Beispiel ein grafisches Modell beinhaltet, kann das grafische Modell partitioniert werden in Teilmodelle, einzelne Blöcke und/oder Gruppen von Blöcken. Das Ausmaß, zu dem das grafische Modell partitioniert wird (zum Beispiel die Granularität der Partitionierung) und die bestimmte Weise, in welcher das Modell partitioniert wird, kann von den ausgeführten Tests abhängen. Wenn zum Beispiel ein Test entworfen oder gedacht ist, die Funktionalität einer Modellkomponente zu testen, kann der Programmcode so partitioniert werden, dass ein Element in der Hierarchie der getesteten Modellkomponente entsprechen kann. Abdeckungspunkte und/oder Unterelemente können von diesem Element in der Hierarchie abhängen.
Die Testinformation 103 kann Daten und/oder Befehle beinhalten oder spezifizieren, die verwendet werden, um ein Testen des Programmcodes, der in der Programminformation 101 enthalten ist, auszuführen. Die Testinformation 103 kann Eingabeinformation, Programmcode Parametereinstellungen, Simulationskonfigurationseinstellungen, Verifikationseinstellungen und/oder Abdeckungseinstellungen für einen oder für mehrere Tests beinhalten oder spezifizieren. Die Tests können dynamische Tests sein: das Testen kann ausgeführt werden, indem der Programmcode mit spezifizierten Eingabedaten, Modellparametern und Simulationsparametern ausgeführt wird. Ein Test kann sich über mehrere Ausführungen des Programmcodes erstrecken und kann mehrere Zeitschritte beinhalten. Die Eingabeeinstellungen können Eingabedaten beinhalten oder spezifizieren; Programme, Formeln oder andere Befehle zum Generieren von Eingabedaten; und/oder Links auf Eingabedatenquellen, wie beispielsweise Pfade oder URLs; oder Verbindungen zu anderen Rechenvorrichtungen, wie beispielsweise Test- und Messausrüstungen. Die Eingabeinformation kann verwendet werden, um spezifische Eingabedaten zu erzeugen zur Verwendung, wenn ein Test ausgeführt wird. Die Programmcode Parametereinstellungen können Werte für Programmcodeparameter beinhalten. Solche Parameter können Eigenschaften oder Charakteristiken des Programmcodes beschreiben, welche die Beziehung zwischen Programmcodeeingaben und Programmcodeausgaben beeinflussen. Die Ausführungs-Konfigurationseinstellungen können Werte für Ausführungsparameter während einem Test beinhalten (zum Beispiel Zeitschritt, numerische Approximationsstrategien, Datenloggen während der Ausführung), zur Verwendung während der Ausführung des Programmcodes. Die Verifikationseinstellungen können Anweisungen betreffend Programmwerten während der Ausführung des Programmcodes beinhalten. Derartige Anweisungen können Programmwerte während einem Zeitintervall nach einem Ereignis betreffen, einen Vergleich eines Programmwerts mit einem anderen Werte, einen Verglich zwischen einem oder mehreren Programmwerten mit einem oder mehreren Baseline-Werten, oder einen Vergleich zwischen einem Merkmal, das von einem oder mehreren Programmwerten extrahiert wurde, und einem Template-Wert oder Muster. Derartige Anweisungen können weiter das Programmtiming und die Ereignisreihenfolge betreffen. Die Abdeckungseinstellungen kann Typen und/oder Scopes an Abdeckung spezifizieren, die während einem Test gesammelt werden soll. Wie oben beschrieben, können die Arten an Abdeckung Ausführungsabdeckung, Entscheidungsabdeckung, Bedingungsabdeckung, modifizierte Bedingungs-/Entscheidungsabdeckung, Lookup-Tabellen Abdeckung, Signalbereichsabdeckung, Signalgrößenabdeckung, Ziele und Randbedingungs-Abdeckung, Sättigung bei Ganzzahlüberlauf-Abdeckung, Toggle Abdeckung, Relationale Begrenzungsabdeckung und/oder andere Abdeckungsmaße beinhalten. In einigen Aspekten kann das Spezifizieren des Abdeckungs-Scopes beinhalten, die Modelle oder Modellkomponenten zu spezifizieren, für welche während dem Test die Abdeckung gesammelt werden soll.
Die Testinformation 103 kann Testsequenzinformation beinhalten. Die Testsequenzinformation kann einen oder mehrere Testschritte spezifizieren. Die Testsequenzinformation kann eine Testlogik spezifizieren, welche Aktionen beinhalten kann, die vor einem Test auszuführen sind, Aktionen, die während einem Test auszuführen sind, und potentielle Transitionen zu nachfolgenden Tests basierend auf den Ergebnissen des gegenwärtigen Tests. Die Testsequenz kann hierarchisch sein. Zum Beispiel kann ein Testschritt mehrere Test-Unterschritte beinhalten. Das Ausführen eines höherrangigen Testschritts kann das Ausführen von zumindest einem der untergeordneten Testschritte beinhalten. Die Verifikationslogik kann mit jeder Ebene des Testens in dieser Hierarchie assoziiert sein und kann ausgedrückt werden als eine oder mehrere Bewertungen zur Evaluation. Zum Beispiel kann eine Bewertung evaluiert werden, um zu prüfen, ob der Programmcode Entwurfskriterien erfüllt (zum Beispiel ob ein Ausgabewert der erwartete Wert ist). Das Testen kann gemäß der Testsequenzinformation ausgeführt werden.
Die Kontextinformation 105 kann Information beinhalten, die explizit oder implizit Bedingungen für den Beitrag der Abdeckungspunktergebnisse zu einer Abdeckungsanalyse auferlegen. In einigen Ausführungsformen kann die Kontextinformation 105 Anforderungsinformation beinhalten, wie sie gespeicherte Daten beinhalten kann, die Entwurfsanforderungen für ein System der realen Welt spezifizieren, das unter Verwendung yon dem Programmcode simuliert wird. Zum Beispiel kann die Anforderungsinformation ein oder mehrere Dokumente beinhalten, welche eine Hierarchie von Entwurfsanforderungen spezifiziert. Derartige Anforderungen können vom Typ des Systems abhängen. Wenn das System zum Beispiel ein Tempomat ist, können die Anforderungen das Verhalten des Tempomats in Antwort auf Benutzereingaben spezifizieren (zum Beispiel Geschwindigkeit inkrementieren, Geschwindigkeit dekrementieren, Tempomat einschalten, bremsen oder ähnliches).
In verschiedenen Ausführungsformen kann die Kontextinformation 105 Beurteilungsinformation beinhalten. Die Beurteilungsinformation kann Bedingungen über Programmvariablen beschreiben (zum Beispiel eine Programmausgabe). Solche Bedingungen können einen oder mehrere Werte der Variablen betreffen (zum Beispiel während einem Zeitintervall nach einem Ereignis, im Vergleich mit einem oder mehreren anderen Werten, im Vergleich mit einem Template Wert oder Muster). Die Beurteilungsinformation kann Inferenzen bezüglich Teilen des Programmcodes unterstützen. Zum Beispiel kann das Erfüllen einer Bedingung über eine Programmvariable das korrekte Funktionieren von Teilen des Programmcodes implizieren, die für den Wert der Programmvariablen verantwortlich sind. Solche Teile des Programmcodes können identifiziert werden unter Verwendung einer Abhängigkeitsanalyse. In einigen Ausführungsformen kann die Beurteilungsinformation temporale Beurteilungsinformation beinhalten. Zum Beispiel kann die Beurteilungsinformation Bedingungen über die zeitliche Antwort eines Systems, das von dem Programmcode simuliert wird, auf ein Triggerereignis beschreiben, oder das Timing von Ereignissen, welche von dem simulierten System generiert werden.
In verschiedenen Ausführungsformen kann die Kontextinformation 105 Information beinhalten, die Testkriterien auferlegen (zum Beispiel dass der Test innerhalb eines bestimmten Zeitintervalls ausgeführt werden muss, einen bestimmten Testzustand enthalten muss, oder einen bestimmten Programmzustand beinhalten muss). Zum Beispiel kann die Kontextinformation 105 eine Bedingung auferlegen, dass die Abdeckung erhalten wird innerhalb eines identifizierten Testschritts (zum Beispiel muss die Abdeckung während dem zweiten Testschritt gesammelt werden in einer Reihenfolge von Testschritte, einem „Inkrement“ Test eines Tempomaten, oder ähnliches), eines Programmzustands (zum Beispiel muss die Abdeckung während eines bestimmten Tests gesammelt werden, während ein Tempomat „eingeschaltet“ ist, oder dergleichen), eines Testzustands (die Abdeckung muss gesammelt werden, während der Test mit einer minimalen Zeitschrittweite ausgeführt wird, oder dergleichen), oder eines Zeitintervalls (zum Beispiel muss die Abdeckung zwischen 10 und 15 Sekunden eines bestimmten Tests gesammelt werden), oder dergleichen.
Die Abdeckungsinformation 107 kann Information beinhalten, welche eine oder mehrere Abdeckungsanalysen beschreibt, die von der Testinformation 103 spezifiziert werden. In einigen Ausführungsformen kann die Abdeckungsinformation 107 Abdeckungspunktergebnisse und/oder Abdeckungspunkte für die eine oder die mehreren Abdeckungsanalysen beinhalten. In verschiedenen Ausführungsformen kann die Abdeckungsinformation 107 eine Gesamtzahl von Abdeckungspunkten und/oder Abdeckungspunktergebnissen für die Abdeckungsanalyse angeben. Zum Beispiel kann die Abdeckungsinformation 107 angeben, dass die Abdeckungspunktergebnisse während dem Testen für 150 von 300 Abdeckungspunkten aufgezeichnet wurden. Auf diese Weise kann die Abdeckungsinformation 107 die Abdeckungspunkte, die während dem Testen des Programmcodes erreicht wurden, und die Abdeckungspunkte, die nicht erreicht wurden, angeben. Wenn zum Beispiel die Anweisungsabdeckung ausgeführt wird, kann die Abdeckungsinformation 107 Indikationen der Anweisungen in dem Programmcode beinhalten, die ausgeführt wurden, und der Anweisungen in dem Programmcode, die nicht ausgeführt wurden.
Wie in 1 gezeigt, kann die Assoziation 117 Programminformation 101 und Testinformation 103 assoziieren. Die Assoziation 117 kann generiert werden unter Verwendung der Assoziation 113 zwischen der Testinformation 103 und der Kontextinformation 105, und der Assoziation 111 zwischen der Kontextinformation 105 und dem Programminformation 101. Die Assoziation 117 kann zusammen mit einer Assoziation 115 zwischen der Abdeckungsinformation 107 und der Testinformation 103 verwendet werden, um die Abdeckungsinformation 107 zu kategorisieren (zum Beispiel in zufällige oder aussagefähige Abdeckungsinformation).
Die Assoziation 111 kann die Programminformation 101 und die Kontextinformation 105 assoziieren. Zum Beispiel kann ein Element der Kontextinformation 105 eine Komponente des Programmcodes spezifizieren. Die Assoziation 111 kann dieses Element an Kontextinformation mit dem Programmcode assoziieren. Die Kontextinformation 105 kann zum Beispiel Entwurfsanforderungen beinhalten. Diese Entwurfsanforderungen können eine Hochebenen-Entwurfsanforderung beinhalten, die mit einer Entwurfsanforderung niedriger Ebene verknüpft ist. Die Assoziation 111 kann eine Verknüpfung zwischen der Entwurfsanforderung niedriger Ebene und einem Teil des Programmcodes enthalten. Wenn zum Beispiel der Programmcode ein grafischer Programmcode ist, kann die Entwurfsanforderung niedriger Ebene mit einer Komponente eines grafischen Modells verknüpft sein. In diesem Beispiel kann das grafische Modell generiert oder erzeugt werden in Übereinstimmung mit den Entwurfsanforderungen.
Die Assoziation 113 kann die Kontextinformation 105 und die Testinformation 103 assoziieren. Beispielsweise kann ein Element der Kontextinformation 105 eine Bedingung aufstellen hinsichtlich dem Beitrag von Abdeckungspunktergebnissen zu einer Abdeckungsanalyse. Die Assoziation 113 kann dieses Element der Kontextinformation 105 mit einem Test, der durch die Testinformation 103 spezifiziert wird, assoziieren. In einigen Ausführungsformen kann der Test konfiguriert sein, die Bedingung zu erfüllen, die durch das Element der Kontextinformation 105 auferlegt wird. Die Assoziation 113 kann zum Beispiel eine Anforderung, die durch die Kontextinformation 105 spezifiziert wird, und einen Test, der durch die Testinformation 103 spezifiziert wird, assoziieren, wobei der Test der Anforderung entspricht. Als ein weiteres Beispiel kann ein Element der Kontextinformation 105 eine Bedingung hinsichtlich einer Programmvariablen (zum Beispiel einer Programmausgabe) während einem Test aufstellen. Die Bedingung kann einen oder mehrere Werte der Variablen betreffen (zum Beispiel während eines Zeitintervalls nach einem Ereignis, im Vergleich zu einem oder mehreren anderen Werten, im Vergleich mit einem Template Wert oder Muster). Alternativ oder zusätzlich kann das Element der Kontextinformation 105 eine Bedingung hinsichtlich des Programmtimings und der Ereignisabfolge aufstellen (beispielsweise die zeitliche Antwort eines Systems, das durch den Programmcode simuliert wird, auf ein Triggerereignis, oder das Timing von Ereignissen, die von dem simulierten System erzeugt werden). Die Assoziation 113 kann das Element der Kontextinformation 105 mit einem Test assoziieren, der von der Testinformation 103 spezifiziert wird, wobei der Test konfiguriert ist, die Bedingung zu verifizieren, die hinsichtlich der Programmvariablen aufgestellt wurde. Als ein weiteres Beispiel kann ein Element der Kontextinformation 105 ein Testkriterium auferlegen (der Test muss zum Beispiel innerhalb eines bestimmten Zeitintervalls ausgeführt werden, einen bestimmten Testzustand enthalten, oder einen bestimmten Programmzustand enthalten). Die Assoziation 113 kann das Element der Kontextinformation 105 mit einem Test assoziieren, welcher durch die Testinformation 103 spezifiziert wird, wobei der Test konfiguriert ist, das Testkriterium zu erfüllen. Die Testinformation 103 kann zum Beispiel den Test so konfigurieren, dass er innerhalb eines bestimmten Zeitintervalls ausgeführt wird, einen bestimmten Testzustand enthält, oder einen bestimmten Programmzustand enthält.
Die Assoziation 115 kann Testinformation 103 und Abdeckungsinformation 107 assoziieren. Wie oben beschrieben, kann die Abdeckungsinformation 107 Abdeckungspunktergebnisse beinhalten, die während einem Test gesammelt wurden, der durch die Testinformation 103 spezifiziert ist. Wie oben beschrieben, können derartige Abdeckungspunkte zu den Tests zurückverfolgbar sein, während welchen sie gesammelt wurden. Daher kann, in einigen Aspekten, die Assoziation 115 einen Test, der durch die Testinformation 103 spezifiziert ist, mit Abdeckungspunktergebnissen assoziieren, die durch dem Test gesammelt werden. Wenn zum Beispiel die Testinformation 103 eine Testsequenz spezifiziert, welche zwei Testschritte beinhaltet, kann die Assoziation 115 den ersten Testschritt mit der Abdeckung assoziieren, die während dem ersten Testschritt gesammelt wurde, und den zweiten Testschritt mit der Abdeckung assoziieren, die während dem zweiten Testschritt gesammelt wurde. Als ein weiteres Beispiel kann in einigen Ausführungsformen die Assoziation 115 die Testsequenz mit der Abdeckung assoziieren, die während beiden Testschritten gesammelt wurde.
Die Assoziation 117 kann Programminformation 101 und Testinformation 103 assoziieren. Die Assoziation 117 kann eine Kategorisierung der Abdeckungspunktergebnisse ermöglichen, die während dem Testen gesammelt wurden, konsistent mit offenbarten Ausführungsformen. Zum Beispiel kann die Assoziation 117 eine Komponente des Programmcodes und einen Test, der durch die Testinformation 103 spezifiziert ist assoziieren. Der Test kann durch die Assoziation 115 mit der Abdeckungsinformation 107 assoziiert werden. Wie oben beschrieben kann die Abdeckungsinformation 107 Abdeckungspunktergebnisse beinhalten, die zu Komponenten des Programmcodes zurückverfolgbar sind. In einigen Ausführungsformen kann ein Abdeckungspunktergebnis kategorisiert werden (zum Beispiel in zufällige oder aussagefähige Abdeckungsinformation) basierend darauf, ob (i) die Assoziation 117 den Test und die Komponente assoziiert, und ob (ii) sowohl der Test als auch die Komponente zu dem Abdeckungspunkt verfolgt werden können. Wenn zum Beispiel ein Abdeckungspunktergebnis zu einem Test zurückverfolgbar ist, der durch die Testinformation 103 spezifiziert wird, und zu einer Komponente des Programmcodes, und die Assoziation 117 den Test und die Komponente assoziiert, dann kann der Abdeckungspunkt als aussagefähige Abdeckung kategorisiert werden.
Die Assoziation 117 kann generiert werden basierend auf Assoziationen zwischen der Programminformation 101 und der Testinformation 103 durch die Kontextinformation 105 (zum Beispiel die Assoziation 111 und die Assoziation 113). In einigen Ausführungsformen kann die Assoziation 117 generiert werden, wenn die Assoziation 111 und die Assoziation 113 Assoziationen mit denselben Elementen der Kontextinformation 105 enthalten, oder unterschiedlichen Elementen der Kontextinformation 105, die assoziiert sind.
Die Assoziation 117 kann generiert werden, wenn die Assoziation 111 und die Assoziation 113 die Programminformation 101 und die Testinformation 103 jeweils mit demselben Element der Kontextinformation 105 assoziieren. Zum Beispiel kann die Kontextinformation 105 eine Anforderung beinhalten. Die Assoziation 111 kann eine Komponente des Programmcodes mit der Anforderung assoziieren. Die Assoziation 113 kann die Anforderung mit einem Test assoziieren. Basierend auf diesen Assoziationen kann die Assoziation 117 generiert werden, um die Komponente des Programmcodes mit dem Test zu assoziieren.
Die Assoziation 117 kann generiert werden, wenn die Assoziation 111 und die Assoziation 113 die Programminformation 101 und die Testinformation 103 jeweils mit unterschiedlichen Elemente an Kontextinformation 105 assoziieren. In solchen Ausführungsformen können die unterschiedlichen Elemente an Kontextinformation 105 assoziiert sein. Als ein nichtbeschränkendes Beispiel kann die Kontextinformation 105 eine Hierarchie von Entwurfsanforderungen für ein Tempomat System beinhalten. Die Entwurfsanforderungen können eine erste Anforderung (zum Beispiel, dass die eingestellte Geschwindigkeit eines Tempomats sich erhöht, wenn eine Inkrement bzw. Erhöhen Taste gedrückt wird) und eine zweite Anforderung (zum Beispiel, dass die eingestellte Geschwindigkeit sich jeweils um eine Meile pro Stunde erhöht bzw. inkrementiert wird, wenn die Taste gedrückt wird). Die erste Anforderung kann mit der zweiten Anforderung assoziiert sein. Die zweite Anforderung kann beispielsweise eine Unteranforderung der ersten Anforderung sein. Die Assoziation 111 kann eine Komponente des Programmcodes mit der ersten Anforderung assoziieren, und die Assoziation 113 kann einen Test mit der zweiten Anforderung assoziieren. Die Assoziation 117 kann generiert werden basierend auf der Assoziation zwischen der ersten und der zweiten Anforderungen, Assoziation 111 und Assoziation 113.
Wie ein Fachmann versteht, können die Assoziation 111 und die Assoziation 113 eine Komponente des Programmcodes mit einem Test assoziieren durch Assoziationen mit mehreren Elementen der Kontextinformation 105. In einigen Ausführungsformen kann die Assoziation 117 eine einzelne Assoziation beinhalten, die denn Assoziationen mit mehreren Elementen der Kontextinformation 105 entspricht. In verschiedenen Ausführungsformen kann die Assoziation 117 mehrere Assoziationen beinhalten, die den Assoziationen mit mehreren Elementen der Kontextinformation 105 entsprechen.
Die oben mit Bezug auf 1 beschriebenen Assoziationen (zum Beispiel die Assoziationen, die enthalten sind in der Assoziation 111, der Assoziation 113, der Assoziation 115 und der Assoziation 117) können bestimmt werden durch eine Programmierumgebung (zum Beispiel eine Umgebung zum technischen Rechnen wie hierin beschrieben). Zum Beispiel kann die Programmierumgebung konfiguriert sein, eine Assoziation von einem anderen Programm zu empfangen, oder eine Assoziation von einem computerlesbaren Medium zu empfangen (zum Beispiel ein Computerspeicher). Die Assoziation kann von einer oder von mehreren Vorrichtungen empfangen werden oder abgerufen werden, welche die Programmierumgebung hosten, oder einer anderen Vorrichtung (zum Beispiel ein Server, der kommunikativ mit einer oder mit mehreren Vorrichtungen verbunden ist, welche die Programmierumgebung hostet bzw. hosten). Als ein weiteres Beispiel kann die Programmierumgebung konfiguriert sein, eine Assoziation zu erzeugen. Die Assoziation kann erzeugt werden unter Verwendung von Daten und/oder Befehlen, die von einem anderen Programm empfangen werden, oder die von einem computerlesbaren Medium wie oben beschrieben abgerufen werden.
Die Assoziationen, die oben mit Bezug auf 1 beschrieben sind, können als gespeicherte Daten unterhalten werden, wie beispielsweise Schlüssel-Wert Paare, die von einer Programmierumgebung gespeichert werden (zum Beispiel eine Umgebung zum technischen Rechnen, wie hierin beschrieben). Die Assoziationen können von einem Benutzer erzeugt werden. Ein Benutzer kann beispielsweise mit einer grafischen Benutzerschnittstelle interagieren, um Assoziationen zwischen Komponenten eines Modells und Anforderungen zu erzeugen, oder zwischen Anforderungen und Tests. Alternativ können Assoziationen automatisch erzeugt werden. Zum Beispiel kann eine Programmierumgebung konfiguriert sein, um Tests zu erzeugen, welche Entwurfsanforderungen entsprechen, und die erzeugten Tests mit den entsprechenden Entwurfsanforderungen assoziieren. Als ein weiteres Beispiel kann die Umgebung zum technischen Rechnen konfiguriert sein, automatisch Tests mit Abdeckungsinformation zu assoziieren, die unter Verwendung der Tests generiert wurden. Die oben beschriebenen Assoziationen können eins-zu-eins, eins-zu-viele oder viele-zu-eins Verknüpfungen beinhalten. Zum Beispiel kann ein Element der Kontextinformation 105 mit mehreren Tests assoziiert sein, die von der Testinformation 103 spezifiziert sind. Als ein weiteres Beispiel kann eine Komponente des Programmcodes mit mehreren Elementen der Kontextinformation 105 assoziiert sein.
Beispielhafte Umgebungsanordnung
2 ist ein Diagramm einer beispielhaften Umgebung 200, in welcher hierin beschriebene Systeme und/oder Verfahren implementiert werden können. Wie in 2 gezeigt, kann die Umgebung 200 eine Clientvorrichtung 210 beinhalten, die eine Umgebung zum technischen Rechnen (TCE) 220 beinhalten kann. Weiterhin kann die Umgebung 200 eine Servervorrichtung 230 beinhalten, welche die TCE 220 beinhalten kann, und ein Netzwerk 240. Vorrichtungen der Umgebung 200 können miteinander verbunden sein über drahtgebundene Verbindungen, drahtlose Verbindungen oder eine Kombination von drahtgebundenen und drahtlosen Verbindungen.
Die Clientvorrichtung 210 kann eine oder mehrere Vorrichtungen beinhalten, die eingerichtet ist bzw. sind, Programmcode und/oder Information, die mit Programmcode assoziiert ist (zum Beispiel ein Ergebnis des Evaluierens des Programmcodes) zu empfangen, generieren, speichern und/oder bereitzustellen. Zum Beispiel kann die Clientvorrichtung 210 eine Rechenvorrichtung beinhalten, wie beispielsweise einen Schreibtischcomputer, einen Laptop Computer, einen Tablet Computer, einen handgehaltenen Computer, einen Server, ein Mobiltelefon (zum Beispiel ein Smartphone, ein Funktelefon, etc.), oder eine ähnliche Vorrichtung. Die Clientvorrichtung 210 kann Programmcode evaluieren, indem sie zum Beispiel den Programmcode ausführt, einen Fehler bestimmt, der mit dem Programmcode assoziiert ist (zum Beispiel durch Validieren des Programmcodes, Debuggen des Programmcodes, etc.), Information bestimmt, die mit dem Programmcode assoziiert ist (zum Beispiel Bestimmen von Hilfeinformation, die mit dem Programmcode assoziiert ist), oder dergleichen. In einigen Implementierungen kann die Clientvorrichtung 210 Information empfangen von und/oder Information senden an die Servervorrichtung 230 (zum Beispiel Programmcode und/oder Information, die mit dem Programmcode assoziiert ist).
Die Clientvorrichtung 210 kann die TCE 220 hosten. Die TCE 220 kann eine Hardware-basierte Komponente oder eine Kombination von Hardware- und Softwarebasierten Komponenten beinhalten, die eine Rechenumgebung bereitstellen, welche es ermöglicht, Tasks auszuführen (zum Beispiel durch Benutzer), die sich auf Aufgabengebiete beziehen wie beispielsweise, und ohne hierauf beschränkt zu sein, Mathematik, Wissenschaft, Ingenieurswesen, Medizin und Wirtschaft. Die TCE 220 kann eine textbasierte Umgebung beinhalten (zum Beispiel MATLAB® Software), eine grafisch-basierte Umgebung (zum Beispiel Simulink® Software, Stateflow® Software, SimEvents® Software, etc., von The MathWorks, Inc.; VisSim von Visual Solutions; LabView® von National Instruments; Agilent VEE von Agilent Technologies; Advanced Design System (ADS) von Agilent Technologies; Agilent Ptolemy von Agilent Technologies; SCADE Suite von Ansys; etc.), oder eine andere Art von Umgebung, wie beispielsweise eine hybride Umgebung, welche zum Beispiel eine textbasierte Umgebung und eine grafisch-basierte Umgebung beinhaltet.
Die TCE 220 kann zum Beispiel eine Benutzerschnittstelle beinhalten, die einen Codeeditierteil bereitstellt, der es einem Benutzer ermöglicht, Programmcode einzugeben (zum Beispiel textuellen Programmcode, grafischen Programmcode, etc.). Zusätzlich oder alternativ kann die TCE 220 eine Benutzerschnittstelle beinhalten, die einen Codeevaluationsteil bereitstellt, der Ergebnisse bereitstellt, die dem Programmcode entsprechen, der in dem Codeeditierteil dargestellt ist. Die TCE 220 kann einen oder mehrere entsprechende Indikatoren bereitstellen, die eine Korrespondenz zwischen unterschiedlichen Teilen von Programmcode und jeweiligen Ergebnissen, die mit den unterschiedlichen Teilen des Programmcodes assoziiert sind, darstellen. Die TCE 220 kann es einem Benutzer ermöglichen, einen oder mehrere Konfigurationsparameter einzugeben, welche zum Beispiel eine Weise steuern können, in welcher ein Ergebnis angezeigt und/oder bereitgestellt wird, eine Weise, in welcher ein Programmcode angezeigt und/oder bereitgestellt wird, eine Weise, in welcher ein Korrespondenziridikator angezeigt und/oder bereitgestellt wird, oder dergleichen.
Die Servervorrichtung 230 kann eine oder mehrere Vorrichtungen beinhalten, die eingerichtet sind, zu empfangen, Programmcode und/oder Information, die mit dem Programmcode assoziiert ist, zu generieren, zu speichern, zu evaluieren und/oder bereitzustellen. Die Servervorrichtung 230 kann zum Beispiel eine Rechenvorrichtung beinhalten, wie beispielsweise einen Server, einen Arbeitsplatzrechner, einen Laptop Computer, einen Tablet Computer, einen handgehaltenen Computer, eine mobile Vorrichtung oder eine ähnliche Vorrichtung. In einigen Implementierungen kann die Servervorrichtung 230 eine eingebettete Vorrichtung beinhalten, wie beispielsweise einen Mikrocontroller (zum Beispiel einen Arduino Mikrocontroller, eine Vorrichtung, die eine ARM Architektur nutzt, eine Vorrichtung, die eine x86 Architektur nutzt, etc.). In einigen Implementierungen kann die Servervorrichtung 230 die TCE 220 hosten. In einigen Implementierungen kann die Clientvorrichtung 210 verwendet werden, um auf eine oder mehrere TCEs 220 zuzugreifen, die auf einem oder mehreren Servervorrichtungen 230 ausgeführt werden. Zum Beispiel können mehrere Servervorrichtungen 230 verwendet werden, um den Programmcode zu evaluieren (zum Beispiel seriell oder parallel), und kann jeweilige Ergebnisse des Evaluierens des Programmcodes an die Clientvorrichtung 210 bereitstellen.
In einigen Implementierungen können die Clientvorrichtung 210 und die Servervorrichtung 230 unterschiedlichen Entitäten gehören. Zum Beispiel kann ein Endbenutzer die Clientvorrichtung 210 besitzen, und eine dritte Partei kann die Servervorrichtung 230 besitzen. In einigen Implementierungen kann die Servervorrichtung 230 eine Vorrichtung beinhalten, die in einer Cloud-Rechenumgebung arbeitet. Auf diese Weise können Frontend-Anwendungen (zum Beispiel eine Benutzerschnittstelle) von Backend-Anwendungen (zum Beispiel Ausführung von Programmcode) getrennt werden.
Das Netzwerk 240 kann ein oder mehrere drahtgebundene und/oder drahtlose Netzwerke beinhalten. Zum Beispiel kann das Netzwerk 240 ein zelluläres Netzwerk, ein öffentliches terrestrisches Mobilfunknetz (PLMN), ein lokales Netz (LAN), ein Weitbereichsnetz (WAN), ein Großstadtnetz (MAN), ein Telefonnetz (zum Beispiel das öffentliche Fernsprechwählnetz (PSTN)), ein Ad-hoc-Netz, ein Intranet, das Internet, ein glasfaserbasiertes Netz und/oder eine Kombination dieser oder anderer Typen von Netzwerken.
Die in 2 dargestellte Anzahl an Vorrichtungen und Netzwerken dient als Beispiel. In der Praxis kann es zusätzliche Vorrichtungen und/oder Netzwerke geben, weniger Vorrichtungen und/oder Netzwerke, andere Vorrichtungen und/oder Netzwerke oder anders angeordnete Vorrichtungen und/oder Netzwerke als die in 2 gezeigten. Weiterhin können zwei oder mehr der in 2 dargestellten Vorrichtungen in einer einzigen Vorrichtung implementiert werden, oder eine einzelne Vorrichtung aus 2 kann als mehrere, verteilte Vorrichtungen implementiert werden. Weiterhin können ein oder mehrere der Vorrichtungen der Umgebung 200 eine oder mehrere Funktionen übernehmen, die von einer oder mehreren anderen Vorrichtungen der Umgebung 200 ausgeführt werden.
Beispielhafte Vorrichtungsarchitektur
3 ist ein Diagramm von beispielhaften Komponenten einer Vorrichtung 300, die der Clientvorrichtung 210 und/oder der Servervorrichtung 230 entspricht. In einigen Implementierungen können die Clientvorrichtung 210 und/oder die Servervorrichtung 230 eine oder mehrere Vorrichtungen 300 und/oder eine oder mehrere Komponenten der Vorrichtung 300 beinhalten. Wie in 3 gezeigt, kann die Vorrichtung 300 einen Bus 310, einen Prozessor 320, einen Speicher 330, eine Speicherkomponente 340, eine Eingabekomponente 350, eine Ausgabekomponente 360 und eine Kommunikationsschnittstelle 370 beinhalten.
Der Bus 310 kann eine Komponente beinhalten, welche Kommunikation unter den Komponenten der Vorrichtung 300 erlaubt. Der Prozessor 320 kann einen Prozessor (zum Beispiel eine Zentralverarbeitungseinheit, eine Graphikverarbeitungseinheit, etc.), einen Mikroprozessor, einen Mikrocontroller und/oder eine Verarbeitungskomponente (zum Beispiel eine feldprogrammierbare Logik (FPGA), eine anwendungsspezifische integrierte Schaltung (ASIC), ein Arduino Mikrocontroller, etc.) beinhalten, welche(r) Befehle (zum Beispiel gemäß einer Befehlssatzarchitektur, wie beispielsweise ARM, x86, etc.) interpretiert und/oder ausführt, und/oder der bzw. die entworfen ist, einen oder mehrere Rechentasks zu implementieren. In einigen Implementierungen kann der Prozessor 320 mehrere Prozessorkerne zum parallelen Rechnen beinhalten. Der Speicher 330 kann einen Speicher mit wahlfreiem Zugriff (RAM), einen Nur-Lese-Speicher (ROM) und/oder eine andere Art von dynamischer oder statischer Speicherkomponente beinhalten (zum Beispiel einen Flash-, magnetischen oder optischen Speicher), die Information und/oder Befehle zur Verwendung durch den Prozessor 320 speichert.
Die Speicherkomponente 340 kann Information und/oder Software speichern, die sich auf den Betrieb und die Verwendung der Vorrichtung 300 bezieht. Die Speicherkomponente 340 kann zum Beispiel eine Festplatte (zum Beispiel eine Magnetplatte, eine optische Platte, eine magneto-optische Platte, eine Halbleiterplatte etc.), eine Compact Disc (CD), eine Digital Versatile Disc (DVD), eine Floppy Diskette, eine Cartridge, ein Magnetband und/oder eine andere Art von computerlesbarem Medium beinhalten, zusammen mit einem entsprechenden Laufwerk. In einigen Implementierungen kann die Speicherkomponente 340 die TCE 220 speichern.
Die Eingabekomponente 350 kann eine Komponente beinhalten, welche es einem Benutzer ermöglicht, Information in die Vorrichtung 300 einzugeben (zum Beispiel ein Berührungsbildschirm, eine Tastatur, ein Tastenfeld, eine Maus, eine Taste, ein Schalter, etc.). Die Ausgabekomponente 360 kann eine Komponente beinhalten, welche Information von der Vorrichtung 300 ausgibt (zum Beispiel eine Anzeige, ein Lautsprecher, eine oder mehrere Leuchtdioden (LEDs), etc.).
Die Kommunikationsschnittstelle 370 kann eine Transceiver-artige Komponente beinhalten, wie beispielsweise einen Transceiver und/oder einen separaten Empfänger und Sender, welche es der Vorrichtung 300 ermöglicht, mit anderen Vorrichtungen zu kommunizieren, wie beispielsweise über eine drahtgebundene Verbindung, eine drahtlose Verbindung, oder eine Kombination von drahtgebundenen und drahtlosen Verbindungen. Beispielsweise kann die Kommunikationsschnittstelle 370 eine Ethernet-Schnittstelle, eine optische Schnittstelle, eine koaxiale Schnittstelle, eine Infrarotschnittstelle, eine Funk- (RF) Schnittstelle, eine Universal Serial Bus (USB)-Schnittstelle, eine hochauflösende Multimedia-Schnittstelle (HDMI), oder dergleichen beinhalten.
Die Vorrichtung 300 kann einen oder mehrere Prozesse, die hierin beschrieben sind, ausführen. Die Vorrichtung 300 kann diese Prozesse ausführen in Antwort darauf, dass der Prozessor 320 Softwarebefehle ausführt, die in einem computerlesbaren Medium enthalten sind, wie beispielsweise dem Speicher 330 und/oder der Speicherkomponente 340. Ein computerlesbares Medium kann definiert sein als eine nichttransitorische Speichervorrichtung. Eine Speichervorrichtung kann einen Speicherraum mit einer einzelnen physischen Speichervorrichtung beinhalten, oder Speicherraum, der über mehrere physische Speichervorrichtungen verteilt ist.
Softwarebefehle können in den Speicher 330 und/oder die Speicherkomponente 340 gelesen werden von einem anderen computerlesbaren Medium oder von einer anderen Vorrichtung über die Kommunikationsschnittstelle 380. Wenn sie ausgeführt werden, können die Softwarebefehle, die im Speicher 330 und/oder Speicherkomponente 340 gespeichert sind, denn Prozessor 320 veranlassen, einen oder mehrere hierin beschriebene Prozesse auszuführen. Zusätzlich oder alternativ kann eine festverdrahtete Schaltung verwendet werden anstelle von, oder in Kombination mit, Softwarebefehlen, um einen oder mehrere hierin beschriebene Prozesse auszuführen. Daher sind die hierin beschriebenen Implementierungen nicht auf eine spezifische Kombination von Hardwareschaltung und Software beschränkt.
Die Anzahl an Komponenten, die in 3 gezeigt sind, ist als ein Beispiel gegeben. In der Praxis kann die Vorrichtung 300 zusätzliche Komponenten, weniger Komponenten, andere Komponenten oder anders angeordnete Komponenten beinhalten als diejenigen, die in 3 gezeigt sind. Zusätzlich oder alternativ kann eine oder können mehrere Komponenten der Vorrichtung 300 eine oder mehrere Funktionen ausführen, die als von einer oder mehreren anderen Komponenten der Vorrichtung 300 ausgeführt beschrieben sind.
Beispielhaftes grafisches Model
4 zeigt eine beispielhafte grafische Benutzerschnittstelle, welche ein Modell beinhaltet, dass zur Analyse gemäß dem Verfahren von 1 geeignet ist. Die grafische Schnittstelle kann einen Modellbereich 400 beinhalten, in welchem ein Modell (zum Beispiel aus Blöcken aufgebaut) von einem Benutzer erstellt werden kann. Das Modell, das nachstehend als in dem Modellbereich 400 erstellt beschrieben wird, repräsentiert nur ein Beispiel eines Modells, das erstellt werden kann.
Ein Benutzer kann Blöcke auswählen und die Blöcke in dem Modellbereich 400 platzieren. Ein Benutzer kann beispielsweise einen Block aus einer Blockbibliothek auswählen und den Block in den Modellbereich 400 bewegen unter Verwendung einer Zeigervorrichtung, wie beispielsweise einer Maus. Ein Block kann eine Funktionalität und/oder Daten repräsentieren, und kann definiert sein unter Verwendung von einer beliebigen einer Anzahl möglicher Programmiersprachen. Ein Block kann auch selbst durch einen oder mehrere andere Blöcke definiert sein.
In einigen Implementierungen kann ein Modell Elemente, die keine grafischen Blöcke sind, beinhalten. Zum Beispiel kann ein Modell zusätzlich von einem Benutzer erzeugten externen Quellcode und/oder Zustandsdiagramme beinhalten.
In dem Beispiel von 4 beinhaltet der Modellbereich 400 ein Modell, welches das Verhalten eines Tempomat Systems eines Automobils simuliert. Das Modell kann eine Anzahl von Blöcken beinhalten (zum Beispiel die Modellkomponente 410). Jeder der Blöcke kann ein primitives Element repräsentieren aus denen ein Modell gebaut werden kann, oder ein Teilmodell, welches wiederum weitere Teilmodelle oder Primitive beinhalten kann. Das in 4 gezeigte Modell kann von einem Benutzer erzeugt worden sein, der jeden der Blöcke in den Modellbereich 400 platziert hat, Eingänge (zum Beispiel den Modelleingang 430) und Ausgänge (zum Beispiel Modellausgang 420) der Blöcke verbunden hat, logische Verbindungen zwischen den Blöcken erstellt hat und Parameter, die sich auf die Blöcke beziehen, konfiguriert hat.
Der Menübalken 460 kann eine Anzahl graphisch auswählbarer Menüoptionen beinhalten, wie beispielsweise eine Date Menüoption 461, eine Ändern Menüoption 462, eine Ansicht Menüoption 463, eine Simulieren Menüoption464 und eine Verifikation Menüoption 465. Jede Menüoption kann zum Beispiel einem von einem Benutzer auswählbaren Befehl oder einem Untermenü mit weiteren Befehlen entsprechen.
Wie in 4 gezeigt, kann eine erste Modellkomponente (zum Beispiel die Modellkomponente 410) Treibereingaben behandeln (zum Beispiel Freigeben, Löschen, Setzen, Wiederaufnehmen, Geschwindigkeit erhöhen bzw. inkrementieren oder Geschwindigkeit senken bzw. dekrementieren), die von dem Tempomat System empfangen werden. Eine zweite Modellkomponente kann die Anforderung von dem Fahrer und Information von dem Auto empfangen (beispielsweise Bremsendruck, Fahrzeuggeschwindigkeit, Vorhandensein des Schlüssels, Gang) und kann eine Statusausgabe und einen Tempomat Modus bereitstellen. Eine dritte Komponente des Modells kann die aktuellen Drosselklappeneinstellungen, die Fahrzeuggeschwindigkeit und den Tempomat Modus empfangen und eine Zielgeschwindigkeit und ein Drosselklappensteuersignal ausgeben.
Ein Benutzer kann, nach Erzeugen des Modells, das durch die Blöcke repräsentiert wird, über die Simulier-Menüoption 464 die Umgebung zum technischen Rechnen anweisen, das Modell zu simulieren (zum Beispiel auszuführen oder laufen zu lassen). Die Simulation kann ausgeführt werden unter Verwendung von Testinformation 103, wie beschrieben mit Bezug auf 1. Zum Beispiel kann das Testen ausgeführt werden gemäß Testszenarien, mit über die Zeit spezifizierten Werten für Modelleingaben. 8 zeigt ein beispielhaftes Testszenario für das in 4 gezeigte Modell, das mehrere Schritte in Test 810 zeigt, Modelleingabeparameterwerte, spezifizierte Transitionen zwischen Testzuständen und logischen Tests, die auf den Modellausgaben ausgeführt werden. Die Modellabdeckung kann gesammelt werden während dem Testen. Wie oben mit Bezug auf 1 beschriebenen, kann das Modell durch eine Hierarchie von Elementen und Abdeckungspunkten repräsentiert werden. Die Umgebung zum technischen Rechnen kann konfiguriert sein, diese Hierarchie mit einer Teilmenge der Abdeckungsinformation zu assoziieren, die während dem Testen gesammelt wird. Die grafische Benutzerschnittstelle kann dann diese Teilmenge der Abdeckungsinformation anzeigen.
Beispielhafte Assoziation von Abdeckungsinformation mit Programminformation
5 zeigt eine beispielhafte Kategorisierung von Abdeckungsinformation 107, konsistent mit offenbarten Ausführungsformen. In einigen Ausführungsformen kann die dargestellte Kategorisierung verwaltet werden als eine Datenstruktur (zum Beispiel als eine Tabelle, die in einem Speicher gespeichert ist, ein Datenbankeintrag, eine Struktur oder dergleichen). In verschiedenen Ausführungsformen kann die gezeigte Kategorisierung als verwaltet werden als Attribute der, oder assoziiert mit den, Abdeckungspunktergebnissen (zum Beispiel kann ein Abdeckungspunktergebnis assoziiert sein mit einem Test, einem Abdeckungspunkt und einer Kategorie) in den Abdeckungsinformation 107. Die offenbarten Ausführungsformen sind nicht gedacht, auf eine bestimmte Repräsentation der Assoziationen, die in 5 gezeigt ist, beschränkt zu sein.
In einigen Ausführungsformen kann die Programmraum 510 eine Hierarchie von Elementen des Programmcodes umfassen, wie oben mit Bezug auf 1 beschriebenen. Zum Beispiel wurde der Programmcode wie gezeigt in die Komponenten 1 und 2 partitioniert, wobei die Komponente 1 die Subkomponenten 1.1 und 1.2 beinhaltet und die Komponente 2 die Subkomponenten 2.1 und 2.2 beinhaltet. Um mit diesem Beispiel fortzufahren, wenn der Programmcode ein grafisches Modell ist, kann die Komponente 1 ein Untermodell sein, und die Komponente 1.1 kann ein Block in dem Untermodell sein. Der Programmraum 510 beinhaltet weiter den Abdeckungspunkt 1 bis Abdeckungspunkt 8. Wie oben beschrieben, können die Abdeckungspunkte vom Typ der Abdeckungsanalyse abhängen, der ausgeführt wird. Die Abdeckungspunkte können mit Elementen der Hierarchie von Programmcodeelementen assoziiert sein. Zum Beispiel sind der Abdeckungspunkt 1 und der Abdeckungspunkt 2 mit der Komponente 1.1 assoziiert. In einigen Ausführungsformen kann der Programmraum 510 mehrere Mengen von Abdeckungspunkten beinhalten, welche mehrere Typen von Abdeckungsanalysen entsprechen.
In einigen Ausführungsformen kann der Testraum 520 die Tests angeben, welche von der Testinformation 103 spezifiziert werden. Wenn zum Beispiel die Testinformation 103 einen ersten Test (Test 1) und einen zweiten Test, der zwei Testschritte (Test 2.1 und Test 2.2) beinhaltet, spezifiziert, kann der Testraum Test 1, Test 2.1 und Test 2.2 angeben. Wie gezeigt, können die Abdeckungspunktergebnisse, die während einem Test erreicht werden, zu diesem Test rückverfolgbar sein. Zum Beispiel kann das Abdeckungspunktergebnis 531 zu dem ersten Testschritt des zweiten Tests (zum Beispiel Test 2.1) rückverfolgbar sein. Eine Granularität der Rückverfolgbarkeit kann von der Testinformation 103 und/oder der Kontextinformation 105 abhängen. Zum Beispiel kann die Kontextinformation 105 eine Bedingung aufstellen, dass die Abdeckung erhalten werden soll innerhalb eines identifizierten Testschritts (zum Beispiel muss die Abdeckung während dem zweiten Testschritt in einer Reihenfolge von Testschrittes gesammelt werden, in einem „Inkrement“ Test in einem Tempomat, oder dergleichen), Programmzustand (zum Beispiel muss die Abdeckung während einem bestimmten Test gesammelt werden, während ein Tempomat „aktiv geschaltet“ ist, oder dergleichen), Testzustand (die Abdeckung muss gesammelt werden, während der Test mit einer minimalen Zeitschrittgröße ausgeführt wird, oder dergleichen), oder Zeitintervall (zum Beispiel muss die Abdeckung gesammelt werden zwischen 10 und 15 Sekunden eines bestimmten Tests), oder dergleichen. In solchen Ausführungsformen können die Abdeckungspunktergebnisse rückverfolgbar sein zu einem bestimmten Testschritt (wie in 5 gezeigt); oder Programmzustand, Testzustand, oder Zeitintervall (nicht gezeigt in 5).
In einigen Ausführungsformen kann ein Abdeckungspunktergebnis (zum Beispiel das Abdeckungspunktergebnis 531 oder das Abdeckungspunktergebnis 533) mit einem Abdeckungspunkt in dem Programmraum 510 und einem Test in dem Testraum 520 (oder Testschritt, Programmzustand, Testzustand, Zeitintervall oder dergleichen, abhängig von der Kontextinformation 105) assoziiert sein.
In einigen Ausführungsformen kann eine Abdeckungsteilmenge (zum Beispiel eine der Abdeckungsteilmengen 541, 543 oder 545) angeben, dass die Assoziation 117 eine Komponente des Programmcodes mit einem Test assoziiert, wie oben mit Bezug auf 1 beschriebenen. Zum Beispiel kann der Test 2.1 mit der Komponente 1.1 assoziiert sein (zum Beispiel die Abdeckungsteilmenge 543), und der Test 2.2 kann mit der Komponente 1.2 assoziiert sein (zum Beispiel die Abdeckungsteilmenge 545). Als ein weiteres Beispiel kann der. Test 1 mit der Komponente 2 assoziiert sein (zum Beispiel die Abdeckungsteilmenge 541). Wie gezeigt, kann die Assoziation 117 Elemente auf jeder Ebene des Programmraums 510 (zum Beispiel Komponente oder Subkomponente) mit Tests bei jeder Granularität des Testraums 520 (zum Beispiel Test oder Testschritt) assoziieren. In einigen Ausführungsformen können die Abdeckungspunktergebnisse kategorisiert werden basierend darauf, ob diese zu einer Abdeckungsteilmenge gehören. Zum Beispiel gehört das Abdeckungspunktergebnis 531 zur Abdeckungsteilmenge 543, während der Abdeckungspunkt 533 zu keiner Abdeckungsteilmenge gehört. In einigen Ausführungsformen kann der Abdeckungspunkt 531 als aussagefähige, oder nicht zufällige, Abdeckung kategorisiert werden, während der Abdeckungspunkt 533 als nicht aussagefähige, oder zufällige, Abdeckung kategorisiert wird. Eine solche Kategorisierung kann verwendet werden, um Abdeckungspunktergebnisse auszuschließen, die während einem Test gesammelt wurden, der nicht dazu entworfen oder gedacht ist, eine bestimmte Komponente des Programmcodes zu testen. Wie ein Fachmann versteht, sind die offenbarten Ausführungsformen nicht dazu gedacht, auf eine bestimmte Repräsentation von Abdeckungsteilmengen, oder der Mitgliedschaft von Abdeckungspunktergebnissen in Abdeckungsteilmengen beschränkt.
In einigen Ausführungsformen kann die Abdeckung über den Testraum 520 kumuliert werden. Wie gezeigt, kann in einigen Ausführungsformen ein Abdeckungspunktergebnis für einen Abdeckungspunkt indiziert werden, wenn ein Abdeckungspunktergebnis, das zu der Abdeckungsteilmenge gehört, für irgendeinen Test im Testraum 520 indiziert wird. Dementsprechend trägt in diesem Beispiel das Abdeckungspunktergebnis 531 zur Ge4samtabdeckung bei, während das Abdeckungspunktergebnis 533 nicht zur Ge4samtabdeckung beiträgt. Auf diese Weise kann, durch Verfeinern der Abdeckungsanalyse auf Abdeckungsteilmengen, die durch die Assoziationen 117 definiert sind, eine nebensächliche Abdeckung optional von der Abdeckungsanalyse ausgeschlossen werden.
Beispielhafte Kontextinformation
6 zeigt beispielhaft Anforderungs-Kontextinformation, konsistent mit offenbarten Ausführungsformen. Diese Anforderungs-Kontextinformation kann verwendet werden, um Abdeckungsinformation mit Programminformation zu assoziierten, wie oben beschriebenen mit Bezug auf 1. Wie gezeigt umfasst der Programmcode 610 grafischen Programmcode und beinhaltet zwei Subkomponenten Dekrement 611 und Inkrement 613 einer Komponente „DriverSWRequest“. Dieses Beispiel ist nicht als Beschränkung gedacht. Zum Beispiel kann der Programmcode 610 zusätzlich oder alternativ textuellen Programmcode beinhalten. Ein Test, der mit der Anforderungs-Kontextinformation assoziiert ist, kann in einigen Ausführungsformen basierend auf der Anforderungs-Kontextinformation automatisch erzeugt werden, oder kann in verschiedenen Ausführungsformen von einem Benutzer manuell erzeugt werden. Die Assoziation 113 kann manuell oder automatisch erzeugt werden. Ein Benutzer kann beispielsweise manuell ein Element der Anforderungs-Kontextinformation mit einem Test assoziieren.
Der Testraum 620 umfasst einen Unit Test für die Komponente DriverSWRequest. Dier Unit Test beinhaltet zwei Testschritte „Dekrement“ und „Inkrement“. Die Umgebung zum technischen Rechnen kann diese Tests ausführen, um den Programmcode 610 zu testen. Wie gezeigt, kann der Dekrement Testschritt entworfen und/oder gedacht sein, die Dekrement Subkomponente zu testen, während der Inkrement Testschritt entworfen und/oder gedacht sein kann, die Inkrement Subkomponente zu testen. In einigen Ausführungsformen mag die während fehlgeschlagenen Tests gesammelte Abdeckung nicht zur Abdeckungsanalyse beitragen.
Die Anforderungen 630 können Entwurfsanforderungen für den Programmcode 610 beinhalten. Die Entwurfsanforderungen können eine erste Anforderung für die Inkrement-Schalter-Erkennungsfunktionalität und eine zweite Anforderung für die Dekrement-Schalter-Erkennungsfunktionalität beinhalten. Die Anforderungen in den Anforderungen 630 können, wie gezeigt, mit dem Programm 610 assoziiert werden. Die erste Anforderung in den Anforderungen 630 für die Inkrement-Schalterfunktionalität kann (zum Beispiel durch die Assoziation 641) mit der Inkrement Subkomponente des Programmcodes 610 assoziiert werden. Die Inkrement Subkomponente kann zum Beispiel die erste Anforderung implementieren. Die zweite Anforderung in den Anforderungen 630 für die Dekrement-Schalterfunktionalität kann (zum Beispiel durch die Assoziation 643) mit der Dekrement Subkomponente des Programmcodes 610 assoziiert werden. Die Dekrement Subkomponente kann zum Beispiel die zweite Anforderung implementieren. Wie weiter gezeigt, können die Anforderungen in den Anforderungen 630 mit Tests im Testraum 620 verknüpft sein. Die erste Anforderung kann (zum Beispiel durch die Assoziation 651) mit dem Inkrement Testschritt assoziiert sein. Der Inkrement Testschritt kann zum Beispiel die erste Anforderung verifizieren. Die zweite Anforderung kann (zum Beispiel durch die Assoziation 653) mit dem Dekrement Testschritt assoziiert sein. Der Dekrement Testschritt kann zum Beispiel die zweite Anforderung verifizieren. In einigen Ausführungsformen können die Assoziationen 641 und 643 in den Assoziationen 111 enthalten sein, und die Assoziationen 651 und 653 können in den Assoziationen 113 enthalten sein, wie oben beschriebenen mit Bezug auf 1.
Die Umgebung zum technischen Rechnen kann Abdeckungspunktergebnisse sammeln während der Ausführung des Unit Tests für die Komponente DriverSWRequest. Die gesammelten Abdeckungspunktergebnisse können mit den Testschritten assoziiert werden, während welcher die Abdeckungspunktergebnisse gesammelt wurden. Zum Beispiel können die Abdeckungspunktergebnisse, die während dem Dekrement Testschritt gesammelt werden, mit dem Dekrement Testschritt verknüpft werden. Die Umgebung zum technischen Rechnen kann konfiguriert sein, eine Assoziation zwischen dem Dekrement Testschritt und der Dekrement Subkomponente des Programmcodes 610 zu generieren, wie oben beschriebenen mit Bezug auf 1.
Als ein weiteres Beispiel kann der Unit Test für die Komponente DriverSWRequest mit einer höherrangigen Anforderung assoziiert werden, aus der sich sowohl die erste Anforderung als auch die zweite Anforderung ableiten (nicht dargestellt). Dementsprechend kann die Umgebung zum technischen Rechnen konfiguriert sein, eine Assoziation zwischen der Dekrement Subkomponente und dem ganzen Unit Test für die Komponente DriverSWRequest erzeugen, und zwischen der Inkrement Subkomponente und dem ganzen Unit Test für die Komponente DriverSWRequest. Diese Assoziationen können erzeugt werden basierend auf der Assoziation zwischen dem Unit Test für die Komponente DriverSWRequest, der Assoziation zwischen der höherrangigen Anforderung und der ersten und der zweiten Anforderung, und den einzelnen Assoziationen zwischen der ersten und der zweiten Anforderung und der Inkrement und der Dekrement Subkomponente.
7 zeigt eine beispielhafte Anwendung von Beurteilungs-Kontextinformation, konsistent mit offenbarten Ausführungsformen. Die Beurteilungsinformation kann in der Kontextinformation 105 enthalten sein, oben beschriebenen mit Bezug auf 1. Als ein nichtbeschränkendes Beispiel kann ein erstes Element der Beurteilungsinformation eine erste Bedingung hinsichtlich der Ausgabe des Modellteils 710 und eine zweite Bedingung hinsichtlich der Ausgabe des Modellteils 725 auferlegen. Wie gezeigt, betrifft die Abhängigkeits-Kontextinformation grafischen Programmcode, aber die offenbarten Ausführungsformen sind nicht gedacht, in dieser Hinsicht beschränkt zu sein. Zum Beispiel können die offenbarten Ausführungsformen zusätzlich oder alternativ ausgeführt werden unter Verwendung von textuellem Programmcode. Ein Test, der mit der Beurteilungs-Kontextinformation assoziiert ist, kann in einigen Ausführungsformen automatisch erzeugt werden basierend auf der Beurteilungs-Kontextinformation, oder kann in verschiedenen Ausführungsformen manuell von einem Benutzer erzeugt werden. Die Assoziation 113 kann manuell oder automatisch erzeugt werden. Ein Benutzer kann beispielsweise manuell ein Element der Beurteilungs-Kontextinformation mit einem Test assoziieren.
In einigen Ausführungsformen kann die Beurteilungsinformation mit der Testinformation 103 assoziiert sein. Die Beurteilungsinformation kann beispielsweise mit Tests assoziiert sein, die von der Testinformation 103 spezifiziert sind, welche die Bedingungen verifizieren, die auf die Ausgaben des Modellteils 710 und des Modellteils 720 auferlegt sind. Zum Beispiel kann die Assoziation 113 das erste Element der Beurteilungsinformation mit einem ersten Test assoziieren, das den Assert 715 verifiziert, und das zweite Element der Beurteilungsinformation mit einem zweiten Test assoziieren, der den Assert 725 verifiziert.
In verschiedenen Ausführungsformen kann die Beurteilungsinformation mit der Programminformation 101 assoziiert werden. Zum Beispiel kann das Ausführen einer Abhängigkeitsanalyse, gemäß bekannter Verfahren, bestimmen, dass das Verifizieren der Erfüllung der ersten Bedingung das korrekte Arbeiten des Modellteils 710 verifiziert, und dass das Verifizieren der Erfüllung der zweiten Bedingung das korrekte Arbeiten des Modellteils 720 verifiziert. Die Assoziation 111 kann daher das erste Element der Beurteilungsinformation mit Komponenten des Programmcodes im Modellteil 710 assoziieren, und das zweite Element der Beurteilungsinformation mit Komponenten des Programmcodes im Modellteil 720 assoziieren.
In verschiedenen Ausführungsformen kann die Assoziation 117 die Komponenten des Programmcodes im Modellteil 710 mit dem ersten Test assoziieren, der den Assert 715 verifiziert, und kann die Komponenten des Programmcodes im Modellteil 720 mit dem zweiten Test assoziieren, der den Assert 725 verifiziert, basierend auf der Assoziation 111 und der Assoziation 113. Die Abdeckungspunktergebnisse, die während dem ersten Test gesammelt und mit Komponenten des Modellteils 710 assoziiert sind, können kategorisiert werden basierend auf der Assoziation 117, wie oben mit Bezug auf 1 beschriebenen. Zum Beispiel können diese Abdeckungspunktergebnisse als aussagefähig kategorisiert werden. Die Abdeckungspunktergebnisse, welche während des ersten Tests gesammelt wurden und mit Komponenten des Modellteils 720 assoziiert sind, können basierend auf einer Abwesenheit einer Assoziation zwischen dem ersten Test und Komponenten des Modellteils 720 kategorisiert werden. Zum Beispiel können diese Abdeckungspunktergebnisse als zufällig kategorisiert und von einer Analyse der Abdeckung, die von dem ersten und dem zweiten Test geboten wird, ausgeschlossen werden. Sollte einer von dem ersten oder dem zweiten Test fehlschlagen, zum Beispiel weil die Ausgabe nicht mit dem Assertionswert übereinstimmt, mag die Abdeckung, die während diesem Test gesammelt wurde, nicht zur Abdeckungsanalyse beitragen.
8 zeigt eine beispielhafte Anwendung von Testkriterien-Kontextinformation, konsistent mit offenbarten Ausführungsformen. Die Testkriterien-Kontextinformation kann in der Kontextinformation 105 enthalten sein. Die Assoziation 113 kann die Testkriterien-Kontextinformation mit einem oder mit mehreren Tests assoziieren, die von der Testinformation 103 spezifiziert werden. Die Assoziation 117 kann generiert werden unter Verwendung der Assoziation 113, konsistent mit offenbarten Ausführungsformen. Ein Test, der mit der Testkriterien-Kontextinformation assoziiert ist, kann in einigen Ausführungsformen automatisch erzeugt werden basierend auf der Testkriterien-Kontextinformation, oder kann in verschiedenen Ausführungsformen manuell durch einen Benutzer erzeugt werden. Die Assoziation 113 kann manuell oder automatisch erzeugt werden. Ein Benutzer kann beispielsweise manuell ein Element der Testkriterien-Kontextinformation mit einem Test assoziieren.
Als ein illustratives, nichtbeschränkendes Beispiel beinhaltet der Test 810 einen Initialisierungsschritt und einen Bremstestschritt. Der Bremstestschritt beinhaltet verschiedene Unterschritte, wie beispielsweise einen Werteinstellschritt, einen Einschalt- bzw. Eingriffsschritt, einen Bremsschritt und einen Verifizierungsschritt. In einigen Ausführungsformen können Bedingungen, die dem Testen des Programmcodes auferlegt werden, einen Testzustand, einen Programmzustand, eine Testsequenz, oder eine Ausführung des Tests betreffen. Wenn zum Beispiel der Programmcode ein Tempomat System simuliert, kann die Bedingung spezifizieren, dass der Test ein Bremstest sein soll. In diesem Beispiel kann die Assoziation 113 die Testkriterien-Kontextinformation mit dem Brems-Teilschritt assoziieren. Als ein weiteres Beispiel kann die Bedingung erfordern, dass das Testen erfolgt, wenn das Programm in einem bestimmten Zustand ist. Zum Beispiel können die Testkriterien erfordern, dass Abdeckungspunktergebnisse gesammelt werden, wenn „CoastSetSW = TRUE“ in Test 810. In diesem Beispiel kann die Assoziation 113 die Testkriterien-Kontextinformation mit dem Einschalten-Teilschritt assoziieren. Die Testkriterien können eine Reihenfolge bzw. Sequenz der Tests beinhalten. Zum Beispiel können die Testkriterien erfordern, dass ein Test als zweiter in einer Reihe von Tests ausgeführt wird. In diesem Beispiel kann die Assoziation 113 die Testkriterien-Kontextinformation mit dem Bremstestschritt assoziieren. In einigen Ausführungsformen können die Testkriterien die Ausführung des Tests betreffen. Zum Beispiel können die Testkriterien erfordern, dass das Testen während einer Simulationen erfolgt, die kein anomales Löserverhalten gezeigt hat. Als ein nichtbeschränkendes Beispiel solchen Verhaltens kann ein Löser der Umgebung zum technischen Rechnen mit einem variablen Zeitschritt konfiguriert sein. Der Löser mag manchmal „stecken“ bleiben, wobei wiederholt die Größe des variablen Zeitschritts reduziert wird. Ein solches Verhalten kann einen Fehler in einem Watchdog Timer erzeugen, welcher den Status der Simulation überwacht. Die Assoziation 113 kann einen Test, der einen solchen Watchdog Timer beinhaltet, mit einem entsprechenden Element der Testkriterien-Kontextinformation assoziieren.
Wie in 8 gezeigt, beinhaltet der Test 810 einen Verifikations-Teilschritt. Die Assoziation 113 kann den Test 810, oder lediglich den Verifikations-Teilschritt des Tests 810, mit einem Element der Beurteilungs-Kontextinformation assoziieren. Das Ausführen einer Abhängigkeitsanalyse kann Komponenten des Programmcodes identifizieren, die verifizierbar sind basierend auf der Verifikation des eingestellten Werts In dem Verifikations-Teiltest. Die Assoziation 111 kann die identifizierten Komponenten mit dem Element der Beurteilungs-Kontextinförmation assoziieren. Die Assoziation 117 kann basierend auf der Assoziation 111 und der Assoziation 113 den Test 810, oder lediglich den Verifikations-Teilschritt des Tests 810, mit den identifizierten Komponenten assoziieren.
9 zeigt eine beispielhafte Anwendung von temporaler Beurteilungs-Kontextinformation, konsistent mit offenbarten Ausführungsformen. Die temporale Beurteilungs-Kontextinformation kann in der Kontextinformation 105 enthalten sein. Die temporale Beurteilungs-Kontextinformation kann Bedingungen hinsichtlich der zeitlichen Antwort eines Systems, das durch den Programmcode simuliert wird, auf ein Triggerereignis aufstellen, oder das Timing von Ereignissen, die von dem simulierten System erzeugt werden.
Die Assoziation 113 kann die temporale Beurteilungs-Kontextinformation mit einem oder mit mehreren Tests assoziieren, die von der Testinformation 103 spezifiziert werden. Die Assoziation 117 kann generiert werden unter Verwendung der Assoziation 113, konsistent mit offenbarten Ausführungsformen. Ein Test, der mit der temporalen Beurteilungs-Kontextinformation assoziiert ist, kann basierend auf der temporalen Beurteilungs-Kontextinformation automatisch erzeugt werden, in einigen Ausführungsformen, oder kann manuell von einem Benutzer erzeugt werden, in verschiedenen Ausführungsformen. Die Assoziation 113 kann manuell oder automatisch erzeugt werden. Ein Benutzer kann beispielsweise manuell ein Element der temporalen Beurteilungs-Kontextinformation mit einem Test assoziieren.
Wie in 9 gezeigt, zeigt die Simulation 900 das Ergebnis der Ausführung eines Tests auf dem Programmcode. Die Ausgabe eines Verifikationsblocks ist oben gezeigt, und die Werte von zwei Eingängen zu dem Verifikationsblock, PhiRef und Phi, sind unten gezeigt. Der Ausgang des Verifikationsblocks wird zwischen 10 und 15 Sekunden in dem Test als korrekt verifiziert. In diesem nichtbeschränkenden Beispiel kann ein Element der temporalen Beurteilungs-Kontextinformation eine Zeitintervall Bedingung für das Testen aufstellen, was die Abdeckungsanalyse verfeinert auf Abdeckungspunktergebnisse, die innerhalb des Zeitintervalls 910 gesammelt wurden. Die Assoziation 113 kann den Teil des Tests innerhalb des Zeitintervalls mit dem Element der temporalen Beurteilungs-Kontextinformation assoziieren.
Wie in 9 gezeigt, verifiziert der Test, der auf dem Programmcode ausgeführt wurde, den Wert von PhiRef. Die Ausführung einer Abhängigkeitsanalyse kann Komponenten des Programmcodes identifizieren, die basierend auf der Verifikation von PhiRef verifiziert werden können. Die Assoziation 111 kann die identifizierten Komponenten mit einem Element der Beurteilüngs-Kontextinformation assoziieren. Die Assoziation 117 kann die identifizierten Komponenten mit dem Teil der Simulation 900 innerhalb des Zeitintervalls 910 assoziieren, basierend auf der Assoziation zwischen dem Element der temporalen Beurteilungs-Kontextinformation und dem Teil der Simulation 900 innerhalb des Zeitintervalls 910 und der Assoziation zwischen dem Element der Beurteilungs-Kontextinformation und den identifizierten Komponenten.
Beispielhafte Benutzerschnittstellen
10A zeigt eine beispielhafte Verfahren 1000 zum Unterteilen von Abdeckungsinformation, konsistent mit offenbarten Ausführungsformen. Der einfacheren Beschreibung halber ist das Verfahren 1000 hierin als von der Servervorrichtung 220 ausgeführt beschrieben. Diese Beschreibung ist jedoch nicht als Beschränkung gedacht, da das Verfahren 1000 individuell oder kooperativ von einer oder mehreren von der Clientvorrichtung 210, der Servervorrichtung 220 oder zusätzlichen Client- oder Servervorrichtungen ausgeführt werden kann. Weiterhin ist die Reihenfolge der Schritte, die mit Bezug auf 10A beschrieben sind, nicht als beschränkend gedacht. Zum Beispiel kann die Abdeckungsinformation generiert werden, bevor die Kontextinformation empfangen wird.
Das Verfahren 1000 kann beinhalten Erhalten von Programminformation, Testinformation und Kontextinformation in Schritt 1010, konsistent mit offenbarten Ausführungsformen. Die Programminformation kann Programmcode beinhalten, wie beispielsweise textuellen Code und/oder grafischen Code. Die Testinformation kann Daten und/oder Befehle beinhalten oder spezifizieren, die verwendet werden, um das Testen des Programmcodes auszuführen. Die Kontextinformation kann Information beinhalten, welche die Programminformation betrifft, und/oder Information, welche die Testinformation betrifft. Zum Beispiel kann die Kontextinformation Anforderungsinformation, Abhängigkeitsinformation und/oder Testkriterien beinhalten. Jedes von der Programminformation, Testinformation und Kontextinformation kann von einer einzelnen Quelle oder von mehreren Quellen erhalten, alles gleichzeitig oder über die Zeit, automatisch oder in Antwort auf eine Benutzereingabe.
Die Servervorrichtung 220 kann eines oder mehrere von der Programminformation, Testinformation und Kontextinformation von einer einzelnen Quelle oder von mehreren Quellen erhalten, konsistent mit offenbarten Ausführungsformen. Zum Beispiel kann die Servervorrichtung 220 eines oder mehrere von der Programminformation, der Testinformation und der Kontextinformation von der Clientvorrichtung 210 empfangen. Zusätzlich oder alternativ kann die Servervorrichtung 220 die Programminformation, Testinformation und/oder Kontextinformation von mehreren Vorrichtungen erhalten, wie beispielsweise andere Client- oder Servervorrichtungen, die in Kommunikation mit der Servervorrichtung 220 stehen. Zusätzlich oder alternativ kann die Servervorrichtung 220 die Programminformation, die Testinformation und/oder die Kontextinformation von einem Speicher abrufen, auf den die Servervorrichtung 220 zugreifen kann (zum Beispiel ein Computerspeicher der Servervorrichtung 220 oder einer anderen Vorrichtung, oder ein nichttransitorisches computerlesbares Medium, wie beispielsweise ein USB Speicher). Zusätzlich oder alternativ kann die Servervorrichtung 220 Programminformation, Testinformation, und/oder Kontextinformation erzeugen unter Verwendung von Daten und/oder Befehle, welche von der Servervorrichtung 220 erhalten werden.
Die Servervorrichtung 220 kann die Programminformation, Testinformation und/oder Kontextinformation auf einmal oder über eine Zeitdauer erhalten, konsistent mit offenbarten Ausführungsformen. Zum Beispiel kann der Server 220 einige der Testinformation, Programminformation und/oder Kontextinformation von einer ersten Quelle empfangen und speichern, und dann nachfolgend zusätzliche Testinformation, Programminformation und/oder Kontextinformation von einer anderen Quelle zu einem anderen Zeitpunkt erhalten. Als ein weiteres Beispiel kann die Servervorrichtung 220 Testinformation von einer anderen Vorrichtung zu einer ersten Zeit empfangen, Kontextinformation von einem Speicher, auf den die Servervorrichtung 220 zugreifen kann, zu einer zweiten Zeit empfangen, und Programminformation unter Verwendung von Daten und/oder Befehle generieren, die von der Servervorrichtung 220 zu einer dritten Zeit erhalten werden. Die Servervorrichtung 220 kann auch die Programminformation, Testinformation und Kontextinformation in jeder beliebigen Reihenfolge oder Sequenz erhalten, konsistent mit offenbarten Ausführungsformen.
Die Servervorrichtung 220 kann die Programminformation, die Testinformation und/oder die Kontextinformation erhalten über Interaktionen mit einem oder mit mehreren Benutzern. Ein Benutzer kann beispielsweise Information bereitstellen, die zumindest einen Teil beinhaltet von einem oder von mehreren von der Programminformation, der Testinformation und der Kontextinformation. Der Server kann konfiguriert sein, Befehle bereitzustellen, um dem Benutzer eine Benutzerschnittstelle anzuzeigen, wie beispielsweise eine grafische Benutzerschnittstelle, oder einer Kommandozeilen-Benutzerschnittstelle. Der Benutzer kann mit der Benutzerschnittstelle interagieren, um die Information bereitzustellen.
Das Verfahren 1000 kann beinhalten Generieren von Abdeckungsinformation durch Testen des Modells gemäß der Testinformation in Schritt 1020, konsistent mit offenbarten Ausführungsformen. Zum Beispiel kann der Server 220 Tests oder Simulationen des Programmcodes unter Verwendung der Daten und/oder Befehle ausführen, die in der Testinformation spezifiziert sind. Während dem Testen oder der Simulation kann die Umgebung zum technischen Rechnen konfiguriert sein, Abdeckungsinformation zu sammeln. Die gesammelte Abdeckungsinformation kann durch die Testinformation bestimmt werden, oder durch Daten oder Befehle, die von einem Benutzer empfangen werden. Zum Beispiel kann die Testinformation einen oder mehrere Typen der Abdeckungsanalyse spezifizieren. Als ein weiteres Beispiel kann der Server 220 Befehle bereitstellen, um auf einer Benutzerschnittstelle eine Option zum Auswählen von einem oder von mehreren Typen der Abdeckungsanalyse anzuzeigen. Ein Benutzer kann mit der Benutzerschnittstelle interagieren, um eine Auswahl von einem oder von mehreren Typen der Abdeckungsanalyse vorzunehmen. In Antwort auf die Auswahl kann der Programmcode gemäß bekannter Verfahren instrumentiert werden, eine Abdeckung für die gewählten Typen von Abdeckungsanalysen zu sammeln. Die i Abdeckungsinformation, die während jedem Test generiert wird, kann zu diesem Test rückverfolgbar sein. Weiterhin kann die Umgebung zum technischen Rechnen konfiguriert sein, Metadaten aufzuzeichnen, welche den Test beschreiben, wie beispielsweise wann der Test ausgeführt wurde, ob der Test Teil einer Reihe von Tests war, Das Resultat etwaiger Verifikationen, die als Teil des Testens ausgeführt wurden, oder jede andere Information, die notwendig ist, um zumindest einen Teil der Testinformation mit der Kontextinformation zu assoziieren.
Das Verfahren 1000 kann beinhalten Bestimmen einer Teilmenge der gesammelten Abdeckungsinformation unter Verwendung der Kontextinformation in Schritt 1030, konsistent mit offenbarten Ausführungsformen, Wie unten mit Bezug auf 10B beschrieben, kann die Umgebung zum technischen Rechnen konfiguriert sein, Assoziationen zwischen Tests und Teilen der Programminformation zu generieren. Zum Beispiel kann die Programminformation eine hierarchische Beschreibung des Programmcodes beinhalten, welche den Programmcode in Komponenten und Subkomponenten unterteil. Die Details der Unterteilung, und damit der Hierarchie, können von der Testinformation abhängen. Abdeckungspunkte können mit den Teilen der Programminformation assoziiert werden. Abdeckungspunkte können beispielsweise mit den Komponenten und Subkomponenten des Programmcodes assoziiert werden. Die Abdeckungspunkte können einer Abdeckungsanalyse entsprechen, die in Schritt 1020 ausgeführt wurde, während dem Testen des Programmcodes gemäß der Testinformation. Um mit dem Beispiel fortzufahren, kann die Abdeckungsinformation Abdeckungspunktergebnisse beinhalten, die während der Ausführung von Tests gemäß der Testinformation gesammelt wurden. Die Umgebung zum technischen Rechnen kann konfiguriert sein, Abdeckungspunktergebnisse zu bestimmen, die mit Tests und Teilen der Programminformation assoziiert sind, welche wiederum assoziiert sind mit Assoziationen, welche von der Umgebung zum technischen Rechnen generiert wurden. Die Umgebung zum technischen Rechnen kann derartige Abdeckungspunkte kategorisieren basierend auf dem Vorliegen einer Assoziation zwischen den Tests und Teilen der Programminformation (zum Beispiel als eine aussagefähige oder nicht zufällige Abdeckung). In einigen Ausführungsformen kann die Umgebung zum technischen Rechnen konfiguriert sein, die Teilmenge der Abdeckungspunkte basierend auf der Kategorisierung der Abdeckungspunktergebnisse zu bestimmen. In verschiedenen Ausführungsformen kann die Umgebung zum technischen Rechnen konfiguriert sein, die Teilmenge der Abdeckungsinformation basierend auf dem Vorliegen oder der Abwesenheit einer Assoziation zwischen einem Test, der mit der Abdeckungsinformation assoziiert ist, und einem Teil der Programminformation, die mit der Abdeckungsinformation assoziiert ist, zu bestimmen.
Das Verfahren 1000 kann beinhalten Anzeigen, in Schritt 1040, einer Indikation der Teilmenge der Abdeckungsinformation, die in Schritt 1030 generiert wurde, konsistent mit offenbarten Ausführungsformen. Zum Beispiel kann der Server 220 konfiguriert sein, Befehle bereitzustellen, um eine Indikation der Teilmenge der Abdeckungsinformation 1040 einem Benutzer anzuzeigen. Die Anzeige kann gegeben werden unter Verwendung einer grafischen Benutzerschnittstelle, wie beispielsweise die in 11A bis 12B gezeigten beispielhaften grafischen Benutzerschnittstellen. In einigen Ausführungsformen kann die Anzeige eine grafische Repräsentation des Programmcodes beinhalten. Beispielsweise können Komponenten des Programmcodes in der grafischen Benutzerschnittstelle angezeigt werden. Eine oder mehrere visuelle Charakteristiken können einen Abdeckungsgrad angeben, der mit den Komponenten des Programmcodes assoziiert ist. In Antwort auf eine Benutzereingabe kann die Benutzerschnittstelle konfiguriert sein, eine Darstellung von einer oder von mehreren Komponenten in der grafischen Repräsentation des Programmcodes zu ändern.
Die Teilmenge der Abdeckungsinformation, die in Schritt 1030 generiert wurde, kann auf jeder Ebene der Aggregation angezeigt werden. Die Anzeige kann zum Beispiel eine Anzahl von Abdeckungspunktergebnissen angeben, die während dem Testen des Programmcodes gesammelt wurden, und/oder einen Anteil der Abdeckungspunkte, für die Abdeckungspunktergebnisse gesammelt wurden während dem Testen des Programmcodes, für den Programmcode als Ganzes oder für eine Komponente oder Subkomponente des Programmcodes. Die Teilmenge kann weiter verfeinert werden um eine Indikation von Abdeckungspunktergebnissen anzuzeigen, die während der Ausführung von einem oder von mehreren Tests gesammelt wurden. Wenn zum Beispiel das Testen die Ausführung eines ersten Tests und eines zweiten Tests beinhaltet hat, kann die Anzeige einen Anteil der Abdeckungspunktergebnisse angeben, die während der Ausführung des ersten Tests gesammelt wurden. Die Teilmenge kann weiter verfeinert werden, um eine Indikation der gesammelten Abdeckungspunktergebnisse anzuzeigen, die mit einem bestimmten Element der Kontextinformation assoziiert sind. Zum Beispiel kann die Anzeige eine Anzahl an Abdeckungspunktergebnissen angeben, die gesammelt wurden, und/oder einen Anteil der Abdeckungspunkte, für welche Abdeckungspunktergebnisse gesammelt wurden, die assoziiert sind mit einer Entwurfsanforderung, einer Abhängigkeitsbeziehung oder einem Testkriterium (zum Beispiel assoziiert durch eine oder mehrere intermediäre Assoziationen, wie oben beschriebenen mit Bezug auf 1). Die Teilmenge kann weiter verfeinert werden, um eine Indikation der gesammelten Abdeckungspunktergebnisse anzuzeigen, die mit einem bestimmten Element in der hierarchischen Beschreibung des Programmcodes assoziiert sind. Wenn zum Beispiel der Programmcode grafischen Programmcode beinhaltet, der Blöcke enthält, kann die Anzeige eine Anzahl an Abdeckungspunktergebnissen angeben, die gesammelt wurden, und/oder einen Anteil der Abdeckungspunkte, für die Abdeckungspunktergebnisse gesammelt wurden, die mit einem Block in dem grafischen Programmiercode assoziiert sind.
Der Benutzer kann mit dem Server 220 interagieren, um die Anzeige von Abdeckungsinformation zu modifizieren, konsistent mit offenbarten Ausführungsformen. Zum Beispiel kann, in Antwort auf eine Eingabe von einem Benutzer, der Server 220 Befehle bereitstellen, um zwischen dem Anzeigen einer Indikation aller Abdeckungsinformation und dem Anzeigen einer Indikation der Teilmenge von Abdeckungsinformation, die in Schritt 1030 generiert wurden, umzuschalten. Als ein weiteres Beispiel kann, in Antwort auf eine Eingabe von einem Benutzer, der Server 220 Befehle bereitstellen, um die angezeigte Abdeckungsinformation zu verfeinern zu Abdeckungsinformation, die assoziiert ist mit einem bestimmten Element des Programmcodes, Abdeckungsinformation, die assoziiert ist mit einem bestimmten Element der Kontextinformation, oder Abdeckungsinformation, die assoziiert ist mit einem bestimmten Test, oder eine Kombination der vorstehenden.
10B zeigt ein beispielhaftes Verfahren zum Bestimmen einer Assoziation zwischen der Abdeckungsinformation und dem Programmraum, konsistent mit offenbarten Ausführungsformen. Der einfacheren Beschreibung halber wird das Verfahren 1005 hierin als von einer Servervorrichtung 220 ausgeführt beschrieben. Diese Beschreibung ist jedoch nicht dazu gedacht, beschränkend zu sein, da das Verfahren 1005 einzeln oder kooperativ ausgeführt werden kann durch eine oder durch mehrere von einer Clientvorrichtung 210, einer Servervorrichtung 220 oder zusätzlichen Client- oder Servervorrichtungen. Weiterhin kann die Reihenfolge der Schritte, die mit Bezug auf 10B beschrieben werden, nicht als beschränkend gedacht. Zum Beispiel können die ersten, die zweiten und die dritten Assoziationen in beliebiger Reihenfolge erhalten werden. Als ein weiteres Beispiel kann die vierte Assoziation vor dem Erhalten der dritten Assoziation bestimmt werden.
Das Verfahren 1005 kann beinhalten Erhalten einer Assoziation (zum Beispiel die Assoziation 113) zwischen der Kontextinformation und der Testinformation in Schritt 1050, konsistent mit offenbarten Ausführungsformen. In einigen Fällen kann die Assoziation von einer anderen Vorrichtung empfangen werden. Zum Beispiel kann die Assoziation von dem Client 210 empfangen werden. In verschiedenen Ausführungsformen kann die Assoziation von einem Speicher empfangen werden, der mit dem Server 220 assoziiert ist (zum Beispiel ein Computerspeicher der Servervorrichtung 220 oder einer anderen Vorrichtung, oder ein nichttransitorisches computerlesbares Medium, wie beispielsweise ein USB Speicher). In einigen Fällen kann die Assoziation durch den Server 220 erzeugt werden. Die Assoziation kann durch den Server 220 automatisch oder manuell erstellt werden, basierend auf Daten oder Befehlen, die von dem Server 220 erhalten werden.
In einigen Ausführungsformen kann die Assoziation zwischen der Kontextinformation und der Testinformation automatisch identifiziert werden durch die Umgebung zum technischen Rechnen. Wenn zum Beispiel die Kontextinformation Abhängigkeitsinformation umfasst, die angibt, dass das Verhalten von Komponenten des Programmcodes verifiziert werden kann durch Prüfen eines Asserts (wie in 7 gezeigt), kann die Umgebung zum technischen Rechnen konfiguriert sein, automatisch Tests, welche diesen Assert prüfen, mit der Kontextabhängigkeitsinformation zu assoziieren. Als ein weiteres Beispiel kann die Umgebung zum technischen Rechnen konfiguriert sein, automatisch einen Test mit einer Entwurfsanforderung zu assoziieren, basierend auf Metadaten für den Test und/oder für die Komponente. Als ein weiteres Beispiel kann die Umgebung zum technischen Rechnen konfiguriert sein, automatisch einen Test mit einem Testkriterium zu assoziieren, basierend auf einem Typ des Tests, oder Metadaten, die mit dem Test assoziiert sind. Als ein weiteres Beispiel kann eine Umgebung zum technischen Rechnen konfiguriert sein, automatisch einen Test und ein Element der Kontextinformation zu assoziieren basierend auf Weise der Erzeugung des Tests und/oder des Elements der Kontextinformation. Wenn zum Beispiel ein Benutzer eine Entwurfsanforderung erstellt durch Interagieren mit einer grafischen Benutzerschnittstellenansicht, die mit einem Test assoziiert ist, oder wenn ein Benutzer einen Test erstell durch Interagieren mit einer grafischen Benutzerschnittstellenansicht, die mit einer Entwurfsanforderung assoziiert ist, kann die Umgebung zum technischen Rechnen automatisch den Test mit der Entwurfsanforderung assoziieren.
In einigen Ausführungsformen kann die Assoziation zwischen der Kontextinformation und der Testinformation erzeugt werden in Antwort auf eine Benutzeranweisung, die erste Assoziation zu erstellen. In einigen Fällen kann ein Benutzer Befehle bereitstellen, um einen Teil der Testinformation mit einem Element der Kontextinformation zu assoziieren durch Interagieren mit einer grafischen Benutzerschnittstelle. Ein Benutzer kann beispielsweise eine Repräsentation des Teils der Testinformation auswählen und eine Repräsentation des Elements der Kontextinformation auswählen. In Antwort auf diese Auswahlen kann die Umgebung zum technischen Rechnen eine Assoziation zwischen dem Teil der Testinformation und dem Element der Kontextinformation erstellen.
Das Verfahren 1005 kann beinhalten Erhalten einer Assoziation (zum Beispiel die Assoziation 111) zwischen der Kontextinformation und dem Programmcode in Schritt 1060, konsistent mit offenbarten Ausführungsformen. In einigen Fällen kann die Assoziation von einer anderen Vorrichtung empfangen. Zum Beispiel kann die zweite Assoziation von dem Client 210 empfangen werden. In verschiedenen Ausführungsformen kann die Assoziation von einem Speicher empfangen werden, der mit dem Server 220 assoziiert ist (zum Beispiel ein Computerspeicher der Servervorrichtung 220 oder einer anderen Vorrichtung, oder ein nichttransitorisches computerlesbares Medium, wie beispielsweise ein USB Speicher). In einigen Fällen kann die Assoziation von dem Server 220 erzeugt werden. Die Assoziation kann durch den Server 220 automatisch oder manuell erzeugt werden, basierend auf Daten oder Befehle, die von dem Server 220 erhalten werden.
In einigen Ausführungsformen kann die Assoziation zwischen der Kontextinformation und dem Programmcode durch die Umgebung zum technischen Rechnen automatisch identifiziert werden. Wenn zum Beispiel die Kontextinformation Abhängigkeitsinformation umfasst, die angibt, dass das Verhalten der Komponenten des Programmcodes verifiziert werden kann durch Überprüfen eines Asserts (wie in 7 gezeigt), kann die Umgebung zum technischen Rechnen konfiguriert sein, die Komponenten des Programmcodes automatisch mit der Kontextabhängigkeitsinformation assoziieren. Als ein weiteres Beispiel kann die Umgebung zum technischen Rechnen konfiguriert sein, eine Komponente des Programmcodes automatisch mit einer Entwurfsanforderung zu assoziieren basierend auf Metadaten für die Entwurfsanforderung und/oder für die Komponente. Als ein weiteres Beispiel kann die Umgebung zum technischen Rechnen konfiguriert sein, eine Komponente automatisch assoziieren mit einem Element der Kontextinformation zu assoziieren, das ein Testkriterium angibt, basierend auf einem Typ der Komponente. Als ein weiteres Beispiel kann eine Umgebung zum technischen Rechnen konfiguriert sein, automatisch einen Teil der Programminformation und ein Element der Kontextinformation zu assoziieren basierend auf einer Weise der Erzeugung des Teils der Programminformation und/oder des Elements der Kontextinformation. Wenn zum Beispiel ein Benutzer eine Entwurfsanforderung erstellt, indem er mit einer grafischen Benutzerschnittstellenansicht interagiert, die mit einer Komponente des Programmcodes assoziiert ist, oder wenn ein Benutzer eine Komponente des Programms erstellt, indem er mit einer grafischen Benutzerschnittstellenansicht interagiert, die mit einer Entwurfsanforderung assoziiert ist, kann die Umgebung zum technischen Rechnen die Komponente automatisch mit der Entwurfsanforderung assoziieren.
In einigen Ausführungsformen kann die Assoziation zwischen der Kontextinformation und dem Programmcode erzeugt werden in Antwort auf eine Benutzeranweisung, diese Assoziation zu erzeugen. In einigen Fällen kann ein Benutzer Befehle bereitstellen, um einen Teil des Programmcodes mit einem Element der Kontextinformation zu assoziieren, indem er mit einer grafischen Benutzerschnittstelle interagiert. Ein Benutzer kann beispielsweise eine Repräsentation des Teils des Programmcodes auswählen und eine Repräsentation des Elements der Kontextinformation auswählen. In Antwort auf diese Auswahlen kann die Umgebung zum technischen Rechnen eine Assoziation zwischen dem Teil des Programmcodes und dem Element der Kontextinformation erzeugen.
Das Verfahren 1005 kann beinhalten Erhalten einer Assoziation (zum Beispiel die Assoziation 115) zwischen der Abdeckungsinformation und der Testinformation in Schritt 1070, konsistent mit offenbarten Ausführungsformen. In einigen Fällen kann die Assoziation von einer anderen Vorrichtung empfangen werden, wie beispielsweise dem Client 210. Die Assoziation kann beispielsweise von einer Vorrichtung empfangen werden, welche das Testen des Programmcodes gemäß der Testinformation ausgeführt hat. In einigen Ausführungsformen kann die Assoziation zusammen mit der Abdeckungsinformation empfangen werden. In verschiedenen Ausführungsformen kann die Assoziation von einem Speicher empfangen werden, der mit dem Server 220 assoziiert ist (zum Beispiel ein Computerspeicher der Servervorrichtung 220 oder einer anderen Vorrichtung, oder ein nichttransitorisches computerlesbares Medium, wie beispielsweise ein USB Speicher). In einigen Fällen kann die Assoziation durch den Server 220 erzeugt werden. Die Umgebung zum technischen Rechnen kann beispielsweise konfiguriert sein, um sicherzustellen, dass Abdeckungsinformation, die während der Ausführung eines Tests auf dem Programmcode gesammelt wurde, zu dem Test zurückverfolgt werden kann (zum Beispiel durch Instrumentieren des Programmcodes, um Abdeckungspunktergebnisse zu sammeln). Diese Rückverfolgbarkeit kann eine Assoziation zwischen der gesammelten Abdeckungsinformation und dem Test bilden, konsistent mit offenbarten Ausführungsformen.
In einigen Ausführungsformen kann die Assoziation zwischen der Kontextinformation und dem Programmcode erzeugt werden in Antwort auf einen Benutzerbefehlt, die Assoziation zu erzeugen. In einigen Fällen kann ein Benutzer Befehle bereitstellen, um Abdeckungsinformation mit einem Test zu assoziieren, durch Interagieren mit einer grafischen Benutzerschnittstelle. Ein Benutzer kann beispielsweise eine Repräsentation des Tests auswählen, und eine Repräsentation der Abdeckung auswählen. In Antwort auf diese Auswahlen kann die Umgebung zum technischen Rechnen eine Assoziation zwischen der Test- und der Abdeckungsinformation erzeugen.
Das Verfahren 1005 kann beinhalten Bestimmen einer vierten Assoziation zwischen der Testinformation und der Programminformation in Schritt 1080. In einigen Ausführungsformen kann die vierte Assoziation für eine bestimmte Menge der Kontextinformation bestimmt werden unter Verwendung der ersten Assoziation und der zweiten Assoziation, wie oben beschriebenen mit Bezug auf 1. Diese Bestimmung kann von Assoziationen und/oder Strukturen innerhalb der Programminformation, der Kontextinformation und der Testinformation abhängen.
11A und 11B zeigen eine beispielhafte grafische Benutzerschnittstelle zum Anzeigen einer Abdeckung, die mit Modellelementen assoziiert ist. Wie gezeigt, kann die grafische Benutzerschnittstelle eine Heat Map der Abdeckungsinformation beinhalten, die über eine grafische Darstellung des Programmcodes (zum Beispiel ein Blockdiagramm des grafischen Programmcodes) gelegt ist. 11A zeigt einen ersten Modus der grafischen Benutzerschnittstelle, in welcher alle gesammelten Abdeckungen zur Abdeckungsanzeige für alle Teile des Programmcodes beitragen. 11B zeigt einen zweiten Modus der grafischen Benutzerschnittstelle, in welcher nur die Abdeckung, die mit einem Teil des Programmcodes assoziiert ist, zur Abdeckungsanzeige für die assoziierten Teile des Programmcodes beiträgt.
In 11A, zeigt die Dekrement Test Abdeckung 1110 eine beispielhafte Anzeige eines Teiles eines grafischen Programmcodes, der zwei Komponenten beinhaltet (eine Dekrement-Komponente, die mit der Anforderung „R1“ assoziiert ist, und eine Inkrement-Komponente, die mit der Anforderung „R2“ assoziiert ist). Der Dekrement-Tasten Test, der im Testraum 1103 gezeigt wird; ein Dekrement-Tasten Test ist mit der Dekrement-Komponente assoziiert. Der Dekrement-Tasten Test kann zum Beispiel mit Kontextinformation assoziiert sein, die wiederum mit der Dekrement-Komponente assoziiert ist (in diesem nichtbeschränkenden Beispiel die Anforderung „R1“, wie oben beschriebenen mit Bezug auf 6). Ähnlich kann der Inkrement-Tasten Test mit der Inkrement-Komponente assoziiert sein.
Ein Benutzer kann mit der grafischen Benutzerschnittstelle interagieren, um den Dekrement-Tasten Test auszuwählen. In Antwort darauf werden, wie in der Dekrement Test Abdeckung 1110 gezeigt, Indikationen eines Abdeckungsgrads für die Dekrement-Komponente und die Inkrement-Komponente angezeigt. Die Indikationen können Änderungen in der Form, Größe, Farbe, Animation, Hervorhebung, Schatten, Texteffekten oder anderen visuellen Eigenschaften der Dekrement-Komponente und der Inkrement-Komponente, wie in der Dekrement Test Abdeckung 1110 gezeigt, beinhalten. Wie gezeigt, kann die Farbe der Dekrement-Komponente und der Inkrement-Komponente von einem Abdeckungsgrad für die Komponente abhängen. Auf diese Weise kann die grafische Benutzerschnittstelle eine Indikation eines Abdeckungsgrads der Dekrement-Komponente und der Inkrement-Komponente des grafischen Programmcodes anzeigen.
In einigen Ausführungsformen kann der Abdeckungsgrad der Anteil der Abdeckungspunkte sein, die mit der Komponente assoziiert sind und während dem Test erreicht werden. Der Abdeckungsgrad kann gebinned bzw. in Klassen eingeteilt werden. Zum Beispiel kann der Anteil der Abdeckung, die mit einer Komponente assoziiert ist, auf drei Bins bzw. Intervall abgebildet werden. Ein Anteil von weniger als ein erste Schwellwert (zum Beispiel 0,5) kann auf eine erste Bin abbilden, ein Anteil größer als der erste Schwellwert und weniger als ein zweiter Schwellwert (zum Beispiel 0,8) kann auf eine zweite Bin abbilden, und ein Anteil größer als der dritte Schwellwert kann auf eine dritte Bin abbilden. Jeder Schwellwert kann mit unterschiedlichen Werten einer visuellen Eigenschaft assoziiert sein. Zum Beispiel kann, wie in 11A gezeigt, die erste Bin bzw. Klasse mit der Farbe Rot assoziiert sein, und die dritte Bin bzw. Klasse kann mit der Farbe Grün assoziiert sein. In diesem Beispiel hat die Dekrement-Komponente einen Anteil an Abdeckung von weniger als 0,5, während die Inkrement-Komponente einen Anteil an Abdeckung von größer als 0,8 hat. Der Dekrement-Tasten-Test war jedoch weder entworfen noch dazu gedacht, die Inkrement-Komponente zu testen. Daher ist die dargestellte Abdeckung der Inkrement-Komponente zufällig (beispielsweise als zufällige Abdeckung 1111 gezeigt).
Wie in der Inkrement Testabdeckung 1120 gezeigt können, in Antwort darauf, dass ein Benutzer mit der grafischen Benutzerschnittstelle interagiert, um den Inkrement-Taste Unit Test auszuwählen, Indikationen eines Abdeckungsgrads für die Dekrement-Komponente und die Inkrement-Komponente, für die Abdeckung, die während des Inkrement-Tasten-Tests gesammelt werden, angezeigt werden. Jedoch war, auch wenn die Dekrement-Komponente als einen Abdeckungsgrad von größer als 0,8 aufweisend gezeigt ist, der Inkrement-Tasten Test nicht dazu entworfen oder gedacht, die Dekrement-Komponente zu testen. Daher ist die dargestellte Abdeckung der Dekrement-Komponente zufällig (zum Beispiel als zufällige Abdeckung 1121 gezeigt).
Wie in der kumulative Testabdeckung 1130 gezeigt können, in Antwort darauf, dass ein Benutzer mit der grafischen Benutzerschnittstelle interagiert, um den Gesamt-DriverSWRequest Unit Test auszuwählen, Indikationen eines Abdeckungsgrads für die Dekrement-Komponente und die Inkrement-Komponente, für die Abdeckung, die sowohl während dem Dekrement als auch dem Inkrement Test gesammelt wird, gezeigt werden; Die gezeigte Abdeckung ist kumulativ, und daher ist die Dekrement-Komponente mit einem Abdeckungsgrad von größer als 0,8 dargestellt, selbst wenn die gemessene Abdeckung der Dekrement-Komponente während dem Inkrement-Tasten-Test gesammelt wurde, welcher weder dazu entworfen noch dazu gedacht war, die Dekrement-Komponente zu testen. Daher beinhaltet die dargestellte Abdeckung der Dekrement-Komponente eine zufällige Abdeckung (beispielsweise als zufällige Abdeckung 1131 gezeigt). Wie in 11A gezeigt, kann eine solche zufällige Abdeckung eine Testlücke verdunkeln. Der Test, der entworfen und dazu gedacht ist, eine Abdeckung der Dekrement-Komponente bereitzustellen, bietet keine ausreichende Abdeckung, aber diese Unzulänglichkeit wird durch die zufällige Abdeckung verdunkelt, die während der Ausführung des Inkrement-Tasten-Tests gesammelt wird.
In 11B beinhaltet der Testraum 1103, wie in 11A, einen DriverSWRequest Unit Test, der einen Dekrement-Tasten Test beinhaltet, der mit einer Dekrement-Komponente assoziiert ist, und einen Inkrement-Tasten Test, der mit einer Inkrement-Komponente assoziiert ist. Die grafische Benutzerschnittstelle von 11B ist jedoch konfiguriert, eine Indikation, für eine Programmkomponente, der Abdeckung anzuzeigen, die während einem Test gesammelt wurde und die mit der Programmkomponente assoziiert ist. Zum Beispiel zeigt die Dekrement Test Abdeckungsteilmenge 1140 Indikationen der Teilmenge der Abdeckung an, die während dem Dekrement-Tasten Test gesammelt wurde, die mit der Dekrement-Komponente assoziiert ist. Wie gezeigt verbleibt der Abdeckungsgrad für die Dekrement-Komponente kleiner als 0,5, aber es wird nicht länger eine Indikation der zufälligen Abdeckung 1111 angezeigt. Auf ähnliche Weise zeigt die Inkrement Test Abdeckungsteilmenge 1150 Indikationen der Teilmenge der Abdeckung an, die während dem Inkrement-Tasten Test gesammelt wurde, der assoziiert mit der Inkrement-Komponente assoziiert ist. Wie gezeigt verbleibt der Abdeckungsgrad für die Inkrement-Komponente größer als 0,8, aber es wird nicht länger eine Indikation zufälliger Abdeckung 1121 angezeigt. Weiter zeigt die kumulative Testabdeckungsteilmenge 1160 Indikationen des Abdeckungsgrads an, der mit jeder von der Dekrement und der Inkrement-Komponente assoziiert ist. Während in der kumulativen Testabdeckung 1130 die zufällige Abdeckung, die während dem Inkrement-Tasten Test gesammelt wurde, das relative Fehlen an Abdeckung, die mittels dem Dekrement-Tasten Test erlangt wurde, verdunkelt hat, sind die Unzulänglichkeiten des Dekrement-Tasten Tests klar ersichtlich in der kumulativen Testabdeckungsteilmenge 1160.
12A und 12B zeigen ein illustratives Beispiel einer beispielhaften grafischen Benutzerschnittstelle zum Anzeigen von Abdeckungsinformation, konsistent mit offenbarten Ausführungsformen. Wie in 12A und 12B gezeigt, ist eine Komponente „System 1.0“ eines Modells aufgelistet, zusammen mit Subkomponenten „System 1.1“ bis „System 1.8“. Mit jedem Eintrag in der Liste ist eine Indikation eines Abdeckungsgrads angezeigt. In diesem nichtbeschränkenden Beispiel wird der Abdeckungsgrad durch den Grad an Schattierung in einem Fortschrittsbalken dargestellt. Beispielsweise ist in 12A ein größerer Abdeckungsgrad für das „System 1.2“ gezeigt als für das „System 1.5“. Wie von den Fachleuten verstanden werden wird, sind andere Ansätze zum Anzeigen eines Abdeckungsgrads möglich, und die partikulären Benutzerschnittstellen, die in 12A und 12B gezeigt sind, sind nicht dazu gedacht, beschränkend zu sein. 12A zeigt einen ersten Modus der beispielhaften grafischen Benutzerschnittstelle, in welchem die gesamte Abdeckung, die während dem Testen gemäß der Testinformation gesammelt wurde, angezeigt wird. Weil die Anzeige in 12A die gesamte gesammelte Abdeckung beinhaltet, kann sie die Abdeckung beinhalten, die für Komponenten gesammelt wurden während Tests, die nicht dazu entworfen oder beabsichtigt waren, diese Komponenten zu testen (zum Beispiel zufällige Abdeckung). Im Gegensatz dazu zeigt 12B einen zweiten Modus, in welchem nur die Abdeckung, die mit einer Komponente assoziiert ist, für die Komponente angezeigt wird, zum Beispiel mittels einer Assoziation, die wie oben mit Bezug auf 1 beschriebenen generiert wird. Der in 12B gezeigte Abdeckungsgrad ist allgemein kleiner als der in 12A gezeigte Abdeckungsgrad, da die Anzeige für eine Komponente keine Abdeckung beinhaltet, die während dem Testen der Komponente gesammelt wurde, aber nicht mit der Komponente assoziiert ist. Demzufolge kann 12B einen Benutzer in die Lage versetzen, Komponenten zu identifizieren, welche zusätzliches Testen durch Tests erfordern, die dazu entworfen und gedacht sind, diese Komponenten abzudecken. Zum Beispiel ist der Abdeckungsgrad, der für die Subkomponenten „System 1.2“ und „System 1.6“ in 12B dargestellt ist, viel kleiner als der Abdeckungsgrad, der für diese Subkomponenten in 12A dargestellt ist. Dieser Unterschied legt nahe, dass ein Großteil der Abdeckung dieser Komponenten zufällig gesammelt wurde beim Testen anderer Komponenten, und dass diese Komponenten zusätzlichen Testens bedürfen mögen.
Erste beispielhafte Ausführungsform
In einer nichtbeschränkenden beispielhaften Ausführungsform kann ein grafisches Modell eine Komponente beinhalten. Ein Benutzer kann eine Assoziation zwischen der Komponente und einer Entwurfsanforderung für das grafische Modell erstellen. Der Benutzer kann eine Assoziation zwischen der Entwurfsanforderung und einem ersten Test in einer Testsuite erstellen. Die Umgebung zum technischen Rechnen kann konfiguriert sein, eine Assoziation zwischen der Komponente und dem ersten Test zu erzeugen basierend auf der Assoziation zwischen der Entwurfsanforderung und einem ersten Test und der Assoziation zwischen der Komponente und der Entwurfsanforderung.
Die Umgebung zum technischen Rechnen kann konfiguriert sein, Abdeckungspunktergebnisse zu sammeln, während Tests auf dem grafischen Modell ausgeführt werden. Die Abdeckungspunktergebnisse, die während der Ausführung eines Tests gesammelt werden, können durch die Umgebung zum technischen Rechnen automatisch mit diesem Test und mit entsprechenden Abdeckungspunkten assoziiert werden.
Basierend auf der Assoziation zwischen der Komponente und dem Test, der Assoziation zwischen dem Abdeckungspunktergebnis und dem Test, und der Assoziation zwischen den Abdeckungspunktergebnissen und den entsprechenden Abdeckungspunkten, kann die Umgebung zum technischen Rechnen die Abdeckungspunktergebnisse als aussagefähig kategorisieren.
Die Umgebung zum technischen Rechnen kann konfiguriert sein, eine grafische Repräsentation des grafischen Modells anzuzeigen, wobei eine Heat Map darübergelegt ist. Die Heat Map kann einen Abdeckungsgrad angaben, basierend auf allen Abdeckungspunktergebnissen, die während der Ausführung der Tests gesammelt wurden. In Antwort auf eine Benutzereingabe mag die Heat Map allein die Abdeckung anzeigen, die als aussagefähig kategorisiert wurde. In diesem Beispiel der Abdeckungspunktergebnisse, die während dem ersten Test gesammelt wurden, werden nur die Abdeckungspunktergebnisse für die Komponente verwendet, um die Heat Map zu erzeugen.
Zusammenfassung
Systeme und/oder Verfahren, die hierin beschrieben sind, können das Kategorisieren und/oder Unterteilen von Abdeckungsinformation für Programmcode unter Verwendung von Kontextinformation ermöglichen. Die Systeme und/oder Verfahren können den Programmcode testen, und können während diesem Testen Abdeckungsinformation sammeln, welche Abdeckungspunktergebnisse beinhaltet. Die Systeme und/oder Verfahren können eine Assoziation zwischen einem Test und einer Komponente des Programms unter Verwendung von Kontextinformation bestimmen. Basierend auf der Assoziation können die Systeme und/oder Verfahren die Abdeckungsinformation kategorisieren und/oder unterteilen. Eine Indikation von einer oder von mehreren Kategorien (oder eine Teilmenge) der Abdeckungsinformation kann angezeigt werden.
Die vorstehende Beschreibung von Implementierungen bietet eine Veranschaulichung und Beschreibung, ist aber nicht dazu gedacht, erschöpfend zu sein oder die Implementierungen auf die präzisen diskutierten Formen zu Beschränkungen. Es sind Abwandlungen und Variationen möglich im Lichte der vorstehenden Lehren, oder können aus der Verwirklichung der Implementierungen erlangt werden.
Es wird ersichtlich sein, dass beispielhafte Aspekte, wie sie oben beschrieben sind, implementiert werden können in vielen unterschiedlichen Formen von Software, Firmware und Hardware, in den in den Figuren gezeigten Implementierungen. Der tatsächliche Softwarecode oder die spezialisierte Steuerhardware, die verwendet wird, um diese Aspekte zu implementieren, soll nicht als beschränkend verstanden werden. Daher wurden die Operation und das Verhalten der Aspekte ohne Bezug auf den spezifischen Softwarecode beschrieben - wobei verstanden sei, dass Software und Steuerhardware entworfen werden könnte, um die Aspekte zu implementieren, basierend auf der Beschreibung hierin.
Weiter können bestimmte Teile der Implementierungen als ein „Modul“ implementiert werden, das eine oder mehrere Funktionen ausführt. Diese Module können Hardware beinhalten, wie beispielsweise einen Prozessor, einen ASIC oder ein FPGA, oder eine Kombination von Hardware und Software.
Auch wenn bestimmte Kombinationen von Merkmalen in den Ansprüchen genannt und/oder in der Beschreibung offenbart sind, sind diese Kombinationen nicht dazu gedacht, die Offenbarung der Spezifikation zu beschränken. Tatsächlich können viele dieser Merkmale in Weisen kombiniert werden, die nicht ausdrücklich in den Ansprüchen genannt und/oder in der Beschreibung offenbart sind. Auch wenn jeder nachstehend aufgeführte Anspruch von nur einem anderen Anspruch abhängen mag, beinhaltet die Offenbarung der Spezifikation jeden abhängigen Anspruch in Kombination mit jedem anderen Anspruch in dem Anspruchssatz.
Kein Element, keine Handlung oder keine Instruktion, die hierin verwendet sind, sollen als kritisch oder essentiell verstanden werden, solange nicht ausdrücklich so beschrieben. Auch sind die Artikel „ein“ und „eine“, wie hierin verwendet, so gedacht, ein oder mehrere Elemente zu beinhalten, und können synonym mit „ein oder mehrere“ verwendet werden. Wo lediglich ein Element beabsichtigt ist, wird der Ausdruck „eines“ oder ein ähnlicher Ausdruck verwendet. Weiter soll der Ausdruck „basierend auf“ bedeuten „basierend zumindest zum Teil auf“, solange nicht ausdrücklich anders angegeben.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62855802 [0001]

Claims

Verfahren, umfassend Erhalten von Programminformation, welche Programmcode beinhaltet, und von Testinformation zum Testen des Programmcodes, wobei die Testinformation assoziiert ist mit Kontextinformation zum Bereitstellen von Kontext zum Testen des Programmcodes; Generieren von Abdeckungsinformation durch Testen des Programmcodes gemäß der Testinformation; Bestimmen einer ersten Assoziation zwischen der Kontextinformation und der Testinformation; Bestimmen einer zweiten Assoziation zwischen der Kontextinformation und dem Programmcode; Bestimmen einer dritten Assoziation zwischen der Abdeckungsinformation und der Testinformation; Bestimmen einer Teilmenge der Abdeckungsinformation basierend auf der dritten Assoziation und einer vierten Assoziation zwischen der Testinformation und dem Programmcode, wobei die vierte Assoziation bestimmt wird basierend auf der ersten und der zweiten Assoziation; und Bereitstellen von Befehlen zum Anzeigen einer Indikation der Teilmenge der Abdeckungsinformation.
Verfahren nach Anspruch 1, wobei: die Kontextinformation zumindest eines umfasst von einer Anforderung, einer Beurteilung oder einem Testkriterium; und/oder die Testinformation eine Testsequenz spezifiziert.
Verfahren nach einem der vorstehenden Ansprüche, wobei: der Programmcode Modellkomponenten umfasst; die Testinformation Tests spezifiziert; und die dritte Assoziation eine Assoziation zwischen einem der Tests und Abdeckungsinformation für eine der Modellkomponenten umfasst.
Verfahren nach einem der vorstehenden Ansprüche, wobei: der Programmcode ein Modell umfasst; Bestimmen der zweiten Assoziation das Ausführen einer Abhängigkeitsanalyse auf dem Modell umfasst.
Verfahren nach einem der Ansprüche 1 bis 3, wobei: der Programmcode ein Modell umfasst; das Verfahren weiter umfasst: in Antwort auf eine Benutzereingabe, Bestimmen dass die Teilmenge der Abdeckungsinformation Abdeckungspunktergebnisse beinhaltet, die mit einer Komponente des Modells assoziiert sind; und Anzeigen einer Indikation der Teilmenge der Abdeckungsinformation umfasst: in Antwort auf die Bestimmung, Ändern einer Darstellung der Komponente in einer grafischen Repräsentation des Modells.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Testinformation einen Test spezifiziert, und wobei: die Kontextinformation ein Zeitintervall angibt, und die erste Assoziation einen Teil des Tests während dem Zeitintervall mit der Kontextinformation assoziiert; oder die Kontextinformation einen Testzustand oder einen Programmzustand angibt, und die erste Assoziation den Test mit der Kontextinformation assoziiert.
Verfahren nach einem der Ansprüche 1 bis 5, wobei: die Testinformation einen Test umfasst; und das Bestimmen der Teilmenge der Abdeckungsinformation weiter ein Bestimmen umfasst, dass der Test erfolgreich ausgeführt wurde.
Verfahren nach einem der Ansprüche 1 bis 5, wobei: die Testinformation einen Test spezifiziert; die Kontextinformation Entwurfsanforderungen beinhaltet; die erste Assoziation die Entwurfsanforderungen mit dem Test assoziiert; die zweite Assoziation die Entwurfsanforderungen mit dem Programmcode assoziiert; und die vierte Assoziation ein Propagieren der ersten Assoziation durch Entwurfsanforderungen zu der zweiten Assoziation angibt.
Verfahren nach einem der Ansprüche 1 bis 5, wobei: die Testinformation einen Test spezifiziert; die Kontextinformation Entwurfsanforderungen beinhaltet; die erste Assoziation die Entwurfsanforderungen mit dem Test assoziiert; die zweite Assoziation die Entwurfsanforderungen mit dem Programmcode assoziiert; und Anzeigen einer Indikation der Teilmenge der Abdeckungsinformation umfasst: in Antwort auf die Auswahl von zumindest einem von einer Entwurfsanforderung der Entwurfsanforderungen oder einer Modellkomponente der Komponenten, Anzeigen eines Teils der Teilmenge der Abdeckungsinformation, wobei der Teil assoziiert ist mit dem ausgewählten zumindest einen von der Entwurfsanforderung oder der Modellkomponente.
Verfahren nach einem der vorstehenden Ansprüche, wobei: der Programmcode grafischen Programmcode umfasst; und Bereitstellen von Befehlen zum Anzeigen einer Indikation der Teilmenge der Abdeckungsinformation ein Bereitstellen von Befehlen umfasst zum Anzeigen einer Heat Map der Abdeckungsinformation, die über eine Anzeige des grafischen Programmcodes gelegt ist.
Verfahren nach einem der vorstehenden Ansprüche, wobei das Verfahren ein computerimplementiertes Verfahren ist.
Verfahren nach einem der vorstehenden Ansprüche, wobei das Verfahren ein Verfahren zum Testen zumindest eines Rechensystems ist, wobei das zumindest eine Rechensystem eine Speichereinheit umfasst, welche den Programmcode beinhaltet, und optional wobei der Programmcode, wenn er durch das zumindest eine Rechensystem ausgeführt wird, das Rechensystem dazu veranlasst, zumindest eine Aktion auszuführen, und optional, wobei das zumindest eine Rechensystem ein Steuer- und/oder Regelungssystem zum Steuern und/oder Regeln zumindest einer Vorrichtung ist, und optional wobei die zumindest eine Vorrichtung ein Automobil, ein Schiff, ein Flugzeug oder ein anderes Gefährt ist.
System, umfassend: zumindest einen Prozessor; und zumindest einen Speicher, welcher Befehle beinhaltet, die, wenn sie durch den zumindest einen Prozessor ausgeführt werden, das System dazu veranlassen, Operationen auszuführen, welche umfassen: Erhalten von Programminformation, welche Programmcode beinhaltet, und von Testinformation zum Testen des Programmcodes, wobei die Testinformation mit Kontextinformation zum Bereitstellen von Kontext zum Testen des Programmcodes assoziiert ist; Generieren von Abdeckungsinformation durch Testen des Programmcodes gemäß der Testinformation; Bestimmen einer ersten Assoziation zwischen der Kontextinformation und der Testinformation; Bestimmen einer zweiten Assoziation zwischen der Kontextinformation und dem Programmcode; Bestimmen einer dritten Assoziation zwischen der Abdeckungsinformation und der Testinformation; Bestimmen einer Teilmenge der Abdeckungsinformation basierend auf der dritten Assoziation und einer vierten Assoziation zwischen der Testinformation und dem Programmcode, wobei die vierte Assoziation bestimmt wird basierend auf der ersten und der zweiten Assoziation; und Bereitstellen von Befehlen zum Anzeigen einer Indikation der Teilmenge der Abdeckungsinformation.
System nach Anspruch 13, wobei: die Kontextinformation zumindest eines umfasst von einer Anforderung, einer Beurteilung oder einem Testkriterium; und/oder die Testinformation eine Testinformationssequenz spezifiziert.
System nach einem der Ansprüche 13 bis 14, wobei: der Programmcode Modellkomponenten umfasst; die Testinformation Tests spezifiziert; und die dritte Assoziation eine Assoziation zwischen einem der Tests und Abdeckungsinformation für eine der Modellkomponenten umfasst.
System nach einem der Ansprüche 13 bis 15, wobei: der Programmcode ein Modell umfasst; Bestimmen der zweiten Assoziation ein Ausführen einer Abhängigkeitsanalyse auf dem Modell umfasst.
System nach einem der Ansprüche 13 bis 15, wobei: der Programmcode ein Modell umfasst; die Befehle weiter umfassen: in Antwort auf eine Benutzereingabe, Bestimmen, dass die Teilmenge der Abdeckungsinformation Abdeckungspunktergebnisse beinhaltet, die mit einer Komponente des Modells assoziiert sind; und Anzeigen einer Indikation der Teilmenge der Abdeckungsinformation umfasst: in Antwort auf die Bestimmung, Ändern einer Darstellung der Komponente in einer grafischen Repräsentation des Modells.
System nach einem der Ansprüche 13 bis 17, wobei die Testinformation einen Test spezifiziert, wobei: die Kontextinformation ein Zeitintervall angibt, und die erste Assoziation einen Teil des Tests während dem Zeitintervall mit der Kontextinformation assoziiert; oder die Kontextinformation einen Testzustand oder einen Programmzustand angibt, und die erste Assoziation den fest mit der Kontextinformation assoziiert.
System nach einem der Ansprüche 13 bis 17, wobei: die Testinformation einen Test umfasst; und Bestimmen der Teilmenge der Abdeckungsinformation weiter ein Bestimmen umfasst, dass der Test erfolgreich ausgeführt wurde.
System nach einem der Ansprüche 13 bis 17, wobei: die Testinformation einen Test spezifiziert; die Kontextinformation Entwurfsanforderungen beinhaltet; die erste Assoziation die Entwurfsanforderungen mit dem Test assoziiert; die zweite Assoziation die Entwurfsanforderungen mit dem Programmcode assoziiert; und die vierte Assoziation ein Propagieren der ersten Assoziation durch Entwurfsanforderungen zu der zweiten Assoziation angibt.
System nach einem der Ansprüche 13 bis 17, wobei: die Testinformation einen Test spezifiziert; die Kontextinformation Entwurfsanforderungen beinhaltet; die erste Assoziation die Entwurfsanforderungen mit dem Test assoziiert; die zweite Assoziation die Entwurfsanforderungen mit dem Programmcode assoziiert; und Anzeigen einer Indikation der Teilmenge der Abdeckungsinformation umfasst: in Antwort auf Auswählen von zumindest einem von einer Entwurfsanforderung der Entwurfsanforderungen oder einer Modellkomponente der Komponenten, Anzeigen eines Teils der Teilmenge der Abdeckungsinformation, wobei der Teil assoziiert ist mit dem ausgewählten zumindest einen von der Entwurfsanforderung oder der Modellkomponente.
System nach einem der Ansprüche 13 bis 21, wobei: der Programmcode grafischen Programmcode umfasst; und Bereitstellen von Befehlen zum Anzeigen einer Indikation der Teilmenge der Abdeckungsinformation ein Bereitstellen von Befehlen umfasst zum Anzeigen einer Heat Map der Abdeckungsinformation, die über eine Anzeige des grafischen Programmcodes gelegt ist.
Testsystem für zumindest ein Rechensystem, umfassend: das zumindest eine Rechensystem; und ein Testmodul, wobei das zumindest eine Rechensystem eine Speichereinheit umfasst, welche Programmcode enthält, der, wenn er durch das zumindest eine Rechensystem ausgeführt wird, das zumindest eine Rechensystem dazu veranlassen, eine Aktion auszuführen, wobei das Testmodul ein System gemäß einem der Ansprüche 13 bis 22 ist, das konfiguriert ist, den Programmcode zu testen.
Testsystem nach Anspruch 23, wobei das zumindest eine Rechensystem ein Steuer- und/oder Regelungssystem zum Steuern und/oder Regeln zumindest einer Vorrichtung ist, und optional wobei die zumindest eine Vorrichtung ein Automobil, ein Schiff, ein Flugzeug oder ein anderes Gefährt ist.
Nichttransitorisches computerlesbares Medium, welches Befehle beinhaltet, welche, wenn sie von zumindest einem Prozessor ausgeführt werden, das System dazu veranlassen, Operationen auszuführen, die dem Verfahren gemäß einem der Ansprüche 1 bis 12 entsprechen.
Verwendung des Verfahrens gemäß einem der Ansprüche 1 bis 12 zum Testen zumindest eines Rechensystems, wobei das zumindest eine Rechensystem eine Speichereinheit umfasst, welche den Programmcode enthält, und optional wobei der Programmcode, wenn er durch das zumindest eine Rechensystem ausgeführt wird, das Rechensystem dazu veranlasst, zumindest eine Aktion auszuführen.
Verwendung des Systems gemäß einem der Ansprüche 13 bis 22 zum Testen von zumindest einem Rechensystem, wobei das zumindest eine Rechensystem eine Speichereinheit umfasst, welche den Programmcode beinhaltet, und optional wobei der Programmcode, wenn er durch das zumindest eine Rechensystem ausgeführt wird, das Rechensystem dazu veranlasst, zumindest eine Aktion auszuführen.