EP2188723A2 - Procédé de génération automatique de script pour tester la validité d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre - Google Patents

Procédé de génération automatique de script pour tester la validité d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre

Info

Publication number
EP2188723A2
EP2188723A2 EP08836799A EP08836799A EP2188723A2 EP 2188723 A2 EP2188723 A2 EP 2188723A2 EP 08836799 A EP08836799 A EP 08836799A EP 08836799 A EP08836799 A EP 08836799A EP 2188723 A2 EP2188723 A2 EP 2188723A2
Authority
EP
European Patent Office
Prior art keywords
test
script
software
developer
aircraft
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP08836799A
Other languages
German (de)
English (en)
Inventor
Famantanantsoa Randimbivololona
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus Operations SAS
Original Assignee
Airbus Operations SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Airbus Operations SAS filed Critical Airbus Operations SAS
Publication of EP2188723A2 publication Critical patent/EP2188723A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software

Definitions

  • the present invention belongs to the field of the operational safety of the systems when the operation of these systems depends on the execution, in a computer, of logical instruction sequences.
  • the subject of the invention is a program generation method for testing an operating software of a system to execute logic instruction sequences, in particular of a system having high security requirements such as a system. electronic device intended to be carried on board an aircraft.
  • the method enables a developer to be able to automatically generate programs for testing logical instruction suites of system operating software intended to be on board an aircraft.
  • the present invention finds particularly advantageous, but not exclusive, applications in the field of aeronautics and, more particularly, in the field of carrying out tests of operating software for systems intended to be embedded.
  • each computer is dedicated to an application or to several applications of the same nature, for example flight control applications.
  • Each calculator includes a hardware part and a software part.
  • the hardware part comprises at least one central processing unit (CPU) and at least one input / output unit by which the computer is connected to a computer network, to external peripherals, etc. ..
  • An essential feature of embedded systems is related to an architecture, both hardware and software, which avoids the introduction, as much as possible, of any means not necessary to perform the functions dedicated to these systems. .
  • the computer is not equipped with a complex operating system.
  • the software is produced in a language as close as possible to the language understood by the central processing unit and the only available inputs / outputs are those necessary for the operation of the system, for example information from sensors or other elements of the aircraft or information intended for actuators or other elements.
  • the operation of such a system is much more difficult to observe.
  • the system does not have conventional human-machine interfaces, such as keyboards and screens, to check the correct sequence of instructions and to interact with this sequence, which makes it difficult to make the necessary checks during development. , verification and qualification of software.
  • the software part of the computer includes a software specific to the application in question and which ensures the operation of the computer, which the logical instructions correspond to the algorithms that determine the operation of the system.
  • the validation phase consists, in general, in verifying, at each stage of the calculator's production process, that it complies with the specifications that have been established so that said computer responds to the expected operation of the system.
  • a first verification step the simplest software items that can be tested are subjected to tests, called unit tests. During these tests, it is verified that the logical instructions, that is to say the code, of said software elements have been individually taken according to the design requirements.
  • a second step the so-called integration step, various software components, individually subjected to an isolated verification, are integrated to constitute a set in which the software components interact. These different software components are subjected to integration tests to verify that the software components are compatible, in particular at the functional interfaces between said components.
  • all the software components are integrated in the calculator for which they are intended. Validation tests are then carried out to demonstrate that the software, formed by all the components integrated in the computer, complies with the specification, that is to say that it performs the expected functions, and that its operation is reliable and safe.
  • a first known method is to set up a file distribution system between the computer under test with the implanted software and an associated platform, using emulators.
  • An emulator means a device for simulating, on the associated platform, the logical operation of a computing unit, a processor of the computer.
  • the processor of the computer is replaced by a probe that provides the interface with the associated platform carrying the emulation of the processor.
  • a second method is to simulate, on a host platform, the operation of the computer to run the program to be tested.
  • the software under test must access files from the platform. host form, either to read test vectors or to record test results.
  • system call instructions that are issued by the simulated test environment are generally used.
  • the system call instructions can be, for example, opening a file, writing a file or reading a file.
  • the system call instructions are intercepted by the operating system of the host platform which converts them into system calls of the host platform.
  • test programs For this purpose, a running environment of the computer operating software tests generates several test programs or, the test programs often represent a large volume of instruction codes, often more important than the volume of the instruction codes of the software that the we want to test.
  • test case is meant the functional path to be implemented to achieve a test goal.
  • a test case is defined by a test set to be implemented, a test scenario to be executed and the expected results.
  • test program for each test case of the operating software intended to be loaded in the computer, is associated a program that will simulate the test case.
  • test programs are made by developers who have a perfect command of the functions of the software to be tested, their context and their execution conditions. There are two essential steps in developing test programs: a first step in the design of test data tests and a second step which concerns the writing of the instruction strings of the test programs.
  • test programs The development of test programs is the subject of a repetitive sequence of manual tasks performed by the developer. This repetitive sequence of manual tasks is an important source of errors.
  • test case data With such a generation of test case data, the developer must formulate each test objective in a formal language and then translate those objectives into a programming language. Each objective thus modeled constitutes a test case.
  • the present invention aims to overcome the disadvantages of the techniques described above.
  • the invention proposes a method which makes it possible to automatically generate test programs and to check the validity of the tests carried out.
  • the implementation of the method according to the invention makes it possible to reduce the cost of the test phase, while avoiding the need for manual development of test programs.
  • the invention thus makes it possible to increase the flexibility of development of the test programs, since the development of the operating software is carried out incrementally according to the evolutions of the tests carried out.
  • the test programs are developed in parallel with the tests of the operating software, which implies that, whenever there is an evolution of at least one test, the test programs evolve at the same time as the test software. tested operation.
  • the invention also makes it possible to improve the reliability of the test programs since the synthesis of these test programs is done automatically from scripts unrolled and validated interactively by the developer. More specifically, the subject of the invention is a method for generating a script for testing the validity of an operating software of an onboard system on board an aircraft, characterized in that it comprises the following steps: test cases valid by a developer, interactively, by setting an entry point and a breakpoint, respectively, at the beginning and at the end of a function of the operating software being tested.
  • test script by first analyzing the states of the variables observed during the identification of the test cases and generating, in a second step, a test script in the form of a source code , - automatic execution in a test run environment of the generated test script.
  • the invention may also include one or more of the following features:
  • test case The generation of the test script is performed test case by test case.
  • a compilation of the source code is performed to automatically translate the source code of the test script into an equivalent script in machine language.
  • the compilation is followed by a linkage of the test script providing binary code executable and usable in the test execution environment selected by the developer.
  • Test results are generated in a form directly compatible with the type of test execution environment selected.
  • the invention also for a device object simulating the operation of an on-board computer on board an aircraft, characterized in that it implements the method as defined above.
  • the invention may also include the following feature:
  • the device is simulated virtually on a host platform for testing and debugging.
  • the invention also relates to a test program loadable on a control unit comprising instruction sequences for implementing the method as defined above, when the program is loaded on the unit and is executed there.
  • FIG. 1 illustrates the functional diagram of the method of the invention.
  • FIG. 2 is a schematic representation of a control unit of the test execution environment, allowing the generation of test programs of an operating software.
  • the present invention provides a method for automatically generating scripts for testing the operating software throughout the development phase. This method makes it possible to take into account each modification made to the operating software during its development.
  • the concept of operating software is defined as consisting of a set of programs.
  • a program consisting of a set of written instruction sequences subsequently called instruction string.
  • a script is a set of written instructions that perform a particular task.
  • the method of the invention also allows, via a succession of steps, to check the validity of each test performed on the operating software as it develops.
  • FIG. 1 represents a functional diagram of the method of the invention.
  • This functional diagram corresponds to one embodiment of the invention.
  • This functional diagram comprises a step 20 in which an identification of the test cases is performed by the developer interactively.
  • the notion of a test case is here a scenario defined by the developer to verify that the instruction strings of the operating software already debugged meet its specifications, but also that its execution by the computer of the embedded system will not cause a malfunction of said system.
  • a developer can define several test cases to exercise the operating software as much as possible. This developer has the functionality of a debugger allowing him, in particular, to search for possible errors in instruction chains.
  • This debugger also controls the execution of the tests by positioning an entry point and an exit or stop point, respectively, at the beginning and at the end of a function of the operating software during the test.
  • the control of the execution of the tests includes, in particular, an observation of the state of the variables selected by the developer, called significant variables. These significant variables are variables allowing the developer to verify that the values obtained are those that are expected.
  • step 21 A verification of the validity of the test is performed in step 21 to decide whether or not the execution of the test is valid with respect to the states of the variables observed.
  • a step 22 offers the developer a validation interface for recording the valid tests by keeping all the states of observed variables. In the case where the test is not valid, the process is reiterated from step 20.
  • step 22 of valid test registration verification of new test cases is performed at step 23 under the action and decision of the developer. If a new test case is detected, then the process is reiterated from step 20. If no new cases are detected, a test script generation step 26 is applied. This step 26 is preceded by two intermediate steps 24 and 25. The purpose of step 24 is to detect whether parameters of the test execution environment have been indicated by the developer. These settings allow you to select the type of test run environment for which the test scripts should be generated. If parameters have been detected, step 25 is to take these parameters into account for the generation of the test script.
  • Step 26 of generating test script is performed automatically by a script generator.
  • This script generator analyzes, firstly, the states of the controlled variables that were recorded after step 20 of identifying valid test cases and, in a second step, generates a source code of the test script (step 27).
  • This generation of source code is performed test case by test case.
  • the source code is presented directly in a regular programming language, which makes it easier for most software developers to understand.
  • step 28 a compilation of the source code is performed to automatically translate the source code of the test script into an equivalent script in machine language. This compilation is followed by an editing of the links of the test program providing in step 29 a binary code executable and usable in the test execution environment selected in step 24 or preconfigured.
  • step 30 the binary code of the test script is automatically executed in the test execution environment.
  • step 31 the results due to the execution of the tests performed on the operating software are generated in a form directly compatible with the type of test execution environment selected by the developer.
  • the method has the advantage of being able to adapt to any type of execution environment of running software tests. It can therefore adapt to any type of virtual or real environment.
  • the generated test scripts are directly valid and free of errors. Indeed, during the validation phase of the test scripts, the non-validation of one of said scripts corresponds to the discovery of an error, implicitly resulting in a correction of the tested function of the operating software.
  • FIG. 2 is a schematic representation of the control unit 1 of the test execution environment, allowing the generation of test scripts of the operating software intended to be loaded into an embedded system (not represented).
  • Figure 2 shows an exemplary control unit 1 of a test execution environment.
  • the test execution environment may be, according to embodiments, simulated virtually on a host platform, such as a workstation, or based on emulator hardware equipment.
  • Test run environment means an environment to check, correct, perform a functional burn-in and test an operating software of an embedded system.
  • the control unit 1 of the test environment comprises, in a non-exhaustive manner, a processor 2, a program memory 3, a data memory 4, and an input / output interface 5.
  • the processor 2, the memory program 3, the data memory 4, and the input / output interface 5 are connected to each other via a bidirectional communication bus 6.
  • the processor 2 is controlled by instruction codes stored in a program memory 3 of the control unit 1.
  • the program memory 3 comprises, in a zone 7, instructions for performing an identification of the valid test cases. This identification allows the interaction of the developer through an interface, to various features found in a conventional debugger. Among these features is the possibility of setting a run control point to the input of the function of the operating software that is under test. Another feature is to set a breakpoint at the exit of the function. This developer interaction allows him to control the states of variables to determine if the execution of the function was successful.
  • the program memory 3 comprises, in an area 8, instructions for performing a validation. This validation consists in automatically recording all the states of controlled variables. These states constitute a record 12 of the valid test cases. This validation also makes it possible to edit all the controlled states. These controlled states become the reference value of validated test cases.
  • the program memory 3 comprises, in a zone 9, instructions for carrying out a generation of test scripts.
  • This generation of test scripts results from an analysis of the states of the variables of the record 12.
  • This generation of test scripts is in the form of a source code 13. It is case by test case.
  • the program memory 3 comprises, in a zone 10, instructions for compiling the source code 13 in order to translate it into the machine language. Following this compilation, an edition of links is made to transform the source code 13 (which is in machine language) into a binary code executable.
  • the program memory 3 comprises, in an area 11, instructions for executing the test script to output test results 15.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un procédé de génération de script pour tester la validité d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, caractérisé en ce qu'il comporte les étapes suivantes : a) identifications (20) de cas de test valides par un développeur, de manière interactive, en positionnant un point d'entrée et un point d'arrêt, respectivement, au début et à la fin d'une fonction du logiciel de fonctionnement en cours de test; b) observation et enregistrement (22) des états de variables de ladite fonction par l'intermédiaire de la position du point d'arrêt et du point d'entrée; c) génération automatique (26) de script de test, en analysant dans un premier temps, les états des variables observés lors de l'identification des cas de test et en générant, dans un deuxième temps, un script de test sous la forme d'un code source (13); d) exécution automatique (30) dans un environnement d'exécution des tests du script de test généré.

Description

Procédé de génération automatique de script pour tester la validité d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en œuvre
La présente invention appartient au domaine de la sécurité de fonctionnement des systèmes lorsque le fonctionnement de ces systèmes dépend de l'exécution, dans un calculateur, de suites d'instructions logiques.
En particulier, l'invention a pour objet un procédé de génération de programme pour tester un logiciel de fonctionnement d'un système devant exécuter des suites d'instructions logiques, notamment d'un système ayant des exigences de sécurité élevées tel qu'un système électronique destiné à être embarqué à bord d'un aéronef.
Le procédé permet, à un développeur, de pouvoir générer automatiquement des programmes pour tester des suites d'instructions logiques de logiciels de fonctionnement de systèmes destinés à être embarqués à bord d'un aéronef. La présente invention trouve des applications particulièrement avantageuses, mais non exclusives, dans le domaine de l'aéronautique et, plus particulièrement, dans le domaine de la réalisation de tests de logiciels de fonctionnement de systèmes destinés à être embarqués.
Pour des raisons de sécurité, les systèmes destinés à être embarqués à bord d'un aéronef sont soumis à des vérifications de bon fonctionnement au cours desquels il doit être démontré que lesdits systèmes répondent à des exigences de certification, avant qu'un aéronef équipé de tels systèmes soit autorisé à voler et, plus encore, à entrer en service commercial.
Actuellement, avant leur implantation, ces systèmes subissent de nombreux tests pour vérifier qu'ils répondent aux exigences d'intégrité et de sécurité, entre autres, émises par les autorités de certification. Ces systèmes embarqués peuvent être, notamment, des calculateurs spécialisés destinés à réaliser des fonctions pouvant être importantes pour l'aéronef, par exemples des fonctions de pilotage. Ces systèmes seront appelés par la suite calculateurs.
Le plus souvent, dans les architectures des systèmes actuels, chaque calculateur est dédié à une application ou à plusieurs applications de même nature, par exemple des applications de commande de vol. Chaque calculateur comprend une partie matérielle et une partie logicielle. La partie matérielle comporte au moins une unité de traitement central (CPU: Central Processing Unit en anglais) et au moins une unité d'entrées/sorties par laquelle le calculateur est connecté à un réseau de calculateurs, à des périphériques externes, etc....
Une caractéristique essentielle des systèmes embarqués, souvent mis en œuvre dans le domaine aéronautique, est liée à une architecture, tant matérielle que logicielle, qui évite l'introduction, autant que possible, de tout moyen non nécessaire pour exécuter les fonctions dédiées aux dits systèmes.
Ainsi, contrairement aux systèmes généralement rencontrés dans des applications répandues, en aéronautique, le calculateur n'est pas pourvu d'un système d'exploitation complexe. De plus, le logiciel est réalisé dans un langage aussi proche que possible du langage compris par l'unité de traitement central et les seules entrées/sorties disponibles sont celles nécessaires au fonctionnement du système, par exemple des informations provenant de capteurs ou d'autres éléments de l'aéronef ou des informations à destination d'actionneurs ou d'autres éléments.
L'avantage de ce type d'architecture tient au fait que le fonctionnement d'un tel système est beaucoup mieux maîtrisé. Il n'est pas dépendant d'un système d'exploitation complexe dont certains aspects du fonctionnement sont fonction de paramètres non maîtrisés et qui devrait, sinon, faire l'objet des mêmes démonstrations de sécurité que les logiciels d'application. Le système est plus simple et moins vulnérable car il ne comporte que les moyens strictement nécessaires à l'exécution des fonctions confiées audit système.
En contrepartie, le fonctionnement d'un tel système est beaucoup plus difficile à observer. Par exemple, le système ne dispose pas des interfaces homme/machine conventionnelles, comme les claviers et écrans, permettant de vérifier le déroulement correct des suites d'instructions et d'interagir sur ce déroulement, ce qui rend difficile les vérifications indispensables pendant le développement, la vérification et la qualification des logiciels.
La partie logicielle du calculateur comprend un logiciel spécifique à l'application considérée et qui assure le fonctionnement du calculateur, dont les instructions logiques correspondent aux algorithmes qui déterminent le fonctionnement du système.
Pour obtenir la certification du système, préalable à sa mise en service et à celle de l'aéronef, une phase de validation du calculateur est effectuée. De façon connue, la phase de validation consiste, en général, à vérifier, à chaque étape du processus de réalisation du calculateur, que celui-ci est conforme aux spécifications qui ont été établies pour que ledit calculateur réponde au fonctionnement attendu du système.
Cette conformité aux spécifications est réalisée, en particulier pour les logiciels, par étapes successives depuis la vérification des composants les plus simples du logiciel jusqu'au logiciel complet intégrant tous les composants devant être intégrés dans le calculateur cible.
Dans une première étape de vérification, les éléments de logiciel les plus simples pouvant être testés sont soumis à des tests, dits tests unitaires. Au cours de ces tests, il est vérifié que les instructions logiques, c'est-à-dire le code, des dits éléments de logiciel ont été, pris individuellement, réalisés conformément aux exigences de conception.
Dans une deuxième étape, dite étape d'intégration, différents composants logiciels, ayant été soumis individuellement à une vérification isolée, sont intégrés pour constituer un ensemble dans lequel les composants logiciels interagissent. Ces différents composants logiciels sont soumis à des tests d'intégration destinés à vérifier que les composants logiciels sont compatibles, en particulier au niveau des interfaces fonctionnelles entre lesdits composants. Dans une troisième étape, l'ensemble des composants logiciels est intégré dans le calculateur auquel ils sont destinés. Des essais de validation sont alors réalisés pour démontrer que le logiciel, formé par l'ensemble des composants intégrés dans le calculateur, est conforme à la spécification, c'est-à-dire qu'il réalise les fonctions attendues, et que son fonctionnement est fiable et sûr.
Pour garantir qu'un logiciel est sûr, et pour satisfaire aux exigences de certification, il est également nécessaire, au cours de cette phase de validation, de démontrer que l'ensemble des tests auxquels le logiciel a été soumis permet de conclure, avec un niveau d'assurance adéquat, que le logiciel est conforme aux exigences de sûreté requises du système où il est incorporé.
Les différents tests effectués, pendant la phase de validation, sur le logiciel, permettent de s'assurer qu'aucun dysfonctionnement du dit logiciel (qui pourrait avoir un impact sur le bon fonctionnement des calculateurs, et par suite sur l'aéronef et sa sécurité) ne peut se produire ou que, si un dysfonctionnement se produit, le logiciel est apte à le maîtriser.
Toutefois, pendant la phase de validation, et surtout pour les opérations d'investigation lorsque des anomalies sont constatées, il est souvent nécessaire de s'assurer que, non seulement, les paramètres d'entrée et de sortie du calculateur sur lequel est implanté le logiciel sont conformes aux attentes mais, également, que certains comportements internes du logiciel sont corrects.
Dans ce cas, en raison de l'architecture spécifique des calculateurs spécialisés pour les applications embarquées, il est généralement très difficile d'observer le fonctionnement du logiciel sans mettre en œuvre des dispositifs et des méthodes particulières.
Une première méthode connue consiste à mettre en place un système de distribution de fichiers entre le calculateur en test avec le logiciel implanté et une plate-forme associée, en utilisant des émulateurs. On entend, par émulateur, un dispositif permettant de simuler, sur la plate-forme associée, le fonctionnement logique d'une unité de calcul, d'un processeur du calculateur.
Dans un tel mode de fonctionnement avec un émulateur, le processeur du calculateur est remplacé par une sonde qui assure l'interface avec la plate-forme associée portant l'émulation du processeur.
Ainsi, il est possible de faire exécuter le logiciel à tester sur le calculateur, sauf pour la partie processeur et, par des fonctions propres de la plate-forme associée, d'observer le fonctionnement ou certains dysfonctionnements internes du logiciel, par exemple, en réponse à des stimulations des entrées des unités d'entrée/sortie, en plus de l'observation des sorties des dites unités d'entrée/sortie.
Une deuxième méthode consiste à simuler, sur une plate-forme hôte, le fonctionnement du calculateur devant exécuter le programme à tester. Dans ce cas, les logiciels sous test doivent accéder à des fichiers de la plate- forme hôte, soit pour lire les vecteurs de tests, soit pour enregistrer des résultats de tests.
Comme le logiciel à tester ne comporte pas naturellement les fonctions pour de tels accès aux fichiers de la plate-forme hôte, il est nécessaire de modifier le logiciel à tester pour intégrer ces fonctions d'accès.
Pour transférer les informations, on utilise généralement des instructions d'appels système qui sont émises par l'environnement de test simulé. Les instructions d'appels système peuvent être, par exemple, l'ouverture d'un fichier, l'écriture d'un fichier ou encore la lecture d'un fichier. Les instructions d'appels système sont interceptées par le système d'exploitation de la plate-forme hôte qui les convertit en appels système de la plate-forme hôte.
Durant la phase de validation du calculateur, et surtout pour les opérations d'investigation lorsque des anomalies sont constatées, il peut être nécessaire de s'assurer que, non seulement, les paramètres d'entrée et de sortie du calculateur sur lequel est implanté le logiciel sont conformes aux attentes mais, également, que certains comportements internes du logiciel sont corrects.
Pour cela, un environnement d'exécution de tests des logiciels de fonctionnement des calculateurs génère plusieurs programmes de test or, les programmes de test représentent souvent un volume de codes instructions important, souvent plus important que le volume des codes instructions du logiciel que l'on veut tester.
Actuellement, le développement des programmes de test est réalisé cas de test par cas de test. On entend par cas de test le chemin fonctionnel à mettre en œuvre pour atteindre un objectif de test. Autrement dit, un cas de test se définit par un jeu de test à mettre en œuvre, un scénario de test à exécuter et les résultats attendus. Ainsi, à chaque cas de test du logiciel de fonctionnement destiné à être chargé dans le calculateur, est associé un programme qui va simuler le cas de test. Ces programmes de test sont réalisés par des développeurs qui maîtrisent parfaitement les fonctions des logiciels à tester, leur contexte et leurs conditions d'exécution. Le développement des programmes de test passe par deux étapes essentielles : une première étape qui concerne la conception de données de tests et une deuxième étape qui concerne l'écriture des chaînes d'instructions des programmes de test.
Le développement de programmes de test fait l'objet d'un enchaînement répétitif de tâches manuelles, effectué par le développeur. Cet enchaînement répétitif de tâches manuelles est une source importante d'introduction d'erreurs.
Pour résoudre ce problème, des générateurs automatiques de tests ont été développés pour permettre de générer les données des cas de test. Avec une telle génération de données de cas de test, le développeur doit formuler chaque objectif de test dans un langage formel puis traduire ces objectifs en langage de programmation. Chaque objectif ainsi modélisé constitue un cas de test.
Cependant, cette formulation de chaque objectif de test n'est praticable que pour des objectifs simples sur des fonctions simples et une automatisation de cette formulation est difficile à mettre en œuvre à l'échelle industrielle.
La présente invention a pour but de remédier aux inconvénients des techniques exposées précédemment. Pour cela, l'invention propose un procédé qui permet de générer automatiquement des programmes de test et de contrôler la validité des tests effectués.
La mise en œuvre du procédé selon l'invention permet de réduire le coût de la phase de test, en évitant le recours au développement manuel des programmes de test. L'invention permet ainsi de gagner en souplesse de développement des programmes de test, puisque le développement du logiciel de fonctionnement est effectué de façon incrémentale en fonction des évolutions des tests effectués. En effet, les programmes de test sont développés parallèlement aux tests du logiciel de fonctionnement, ce qui implique que, chaque fois qu'il y a une évolution d'au moins un test, les programmes de test évoluent en même temps que le logiciel de fonctionnement testé.
L'invention permet aussi d'améliorer la fiabilité des programmes de test puisque la synthèse de ces programmes de test est faite automatiquement à partir de scripts déroulés et validés de façon interactive par le développeur. Plus précisément l'invention a pour objet un procédé de génération de script pour tester la validité d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, caractérisé en ce qu'il comporte les étapes suivantes : - identification de cas de test valides par un développeur, de manière interactive, en positionnant un point d'entrée et un point d'arrêt, respectivement, au début et à la fin d'une fonction du logiciel de fonctionnement en cours de test.
- observation et enregistrement des états de variables de ladite fonction par l'intermédiaire de la position du point d'arrêt et du point d'entrée,
- génération automatique de script de test, en analysant dans un premier temps, les états des variables observés lors de l'identification des cas de test et en générant, dans un deuxième temps, un script de test sous la forme d'un code source, - exécution automatique dans un environnement d'exécution des tests du script de test généré.
L'invention peut comporter aussi une ou plusieurs des caractéristiques suivantes :
- entre l'étape d'observation et d'enregistrement des états de variables et l'étape de génération automatique d'un script de test, est effectuée une étape de vérification de la validité des cas de test permettant au développeur de décider si l'exécution de la fonction testée est valide par rapport aux états de variables observés.
- la génération du script de test est effectuée cas de test par cas de test.
- entre l'étape de génération automatique de script et l'étape d'exécution automatique du script, est effectuée une compilation du code source pour traduire automatiquement ledit code source du script de test en un script équivalent en langage machine. - la compilation est suivie d'une édition de liens du script de test fournissant un code binaire exécutable et utilisable dans l'environnement d'exécution des tests sélectionné par le développeur.
- des résultats de tests sont générés sous une forme directement compatible avec le type d'environnement d'exécution des tests sélectionné. L'invention a également pour un objet dispositif simulant le fonctionnement d'un calculateur embarqué à bord d'un aéronef, caractérisé en ce qu'il met en œuvre le procédé tel que défini précédemment.
L'invention peut comporter aussi la caractéristique suivante : Le dispositif est simulé virtuellement sur une plate-forme hôte de test et de débogage.
L'invention a également pour objet un programme de test chargeable sur une unité de commande comprenant des séquences d'instructions pour mettre en œuvre le procédé tel que défini précédemment, lorsque le programme est chargé sur l'unité et y est exécuté.
L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif de l'invention.
La figure 1 illustre le diagramme fonctionnel du procédé de l'invention. La figure 2 est une représentation schématique d'une unité de commande de l'environnement d'exécution des tests, permettant la génération de programmes de test d'un logiciel de fonctionnement.
La présente invention propose un procédé permettant de générer automatiquement des scripts pour tester tout au long de la phase de développement le logiciel de fonctionnement. Ce procédé permet de prendre en compte chaque modification apportée au logiciel de fonctionnement durant son développement.
La notion de logiciel de fonctionnement se définit comme étant constitué d'un ensemble de programmes. Un programme étant constitué d'un ensemble de suites d'instructions écrites appelé par la suite chaîne d'instructions. Un script est un ensemble d'instructions écrites réalisant une tâche particulière.
Le procédé de l'invention permet également, par l'intermédiaire d'une succession d'étapes, de contrôler la validité de chaque test effectué sur le logiciel de fonctionnement au fur et à mesure de son développement.
La figure 1 représente un diagramme fonctionnel du procédé de l'invention. Ce diagramme fonctionnel correspond à un mode de réalisation de l'invention. Ce diagramme fonctionnel comporte une étape 20 dans laquelle une identification des cas de test est effectuée par le développeur de manière interactive. La notion de cas de test étant ici un scénario défini par le développeur pour vérifier que les chaînes d'instructions du logiciel de fonctionnement déjà débogué répondent bien à son cahier des charges, mais aussi que son exécution par le calculateur du système embarqué n'entraînera pas de défaillance de fonctionnement dudit système. Dans le cadre de l'invention, un développeur peut définir plusieurs cas de test pour exercer au maximum le logiciel de fonctionnement. Ce développeur dispose des fonctionnalités d'un débogueur lui permettant, notamment, de rechercher les erreurs éventuelles dans des chaînes d'instructions. Ce débogueur permet aussi de contrôler l'exécution des tests en positionnant un point d'entrée et un point de sortie ou d'arrêt, respectivement, au début et à la fin d'une fonction du logiciel de fonctionnement au cours du test. Le contrôle de l'exécution des tests comporte, notamment, une observation de l'état des variables sélectionnées par le développeur, appelées variables significatives. Ces variables significatives sont des variables permettant au développeur de vérifier que les valeurs obtenues sont celles qui sont attendues.
Une vérification de la validité du test est effectuée à l'étape 21 permettant de décider si oui ou non l'exécution du test est valide par rapport aux états des variables observés. Dans le cas où le test est valide, une étape 22 offre au développeur une interface de validation pour enregistrer les tests valides en conservant l'ensemble des états de variables observés. Dans le cas où le test n'est pas valide, le procédé est réitéré à partir de l'étape 20.
Lorsque l'étape 22 d'enregistrement des tests valides est appliquée, une vérification de nouveaux cas de test est effectuée à l'étape 23 sous l'action et la décision du développeur. Si un nouveau cas de tests est détecté, alors le procédé est réitéré à partir de l'étape 20. Si aucun nouveau cas n'est détecté, une étape 26 de génération de script de test est appliquée. Cette étape 26 est précédée par deux étapes intermédiaires 24 et 25. L'étape 24 a pour but de détecter si des paramètres de l'environnement d'exécution des tests ont été indiqués par le développeur. Ces paramètres permettent de sélectionner le type d'environnement d'exécution de tests pour lequel les scripts de test doivent être générés. Si des paramètres ont été détectés, l'étape 25 consiste à prendre ces paramètres en compte pour la génération du script de test.
L'étape 26 de génération de script de test est effectuée de manière automatique par un générateur de scripts. Ce générateur de script analyse, dans un premier temps, les états des variables contrôlés qui ont été enregistrés après l'étape 20 d'identification des cas de test valides et, dans un deuxième temps, génère un code source du script de test (étape 27).
Cette génération du code source est effectuée cas de test par cas de test. Le code source est présenté directement dans un langage de programmation habituel, ce qui facilite sa compréhension par la plupart des développeurs de logiciels.
A l'étape 28, une compilation du code source est effectuée permettant de traduire automatiquement le code source du script de test en un script équivalent en langage machine. Cette compilation est suivie d'une édition des liens du programme de test fournissant à l'étape 29 un code binaire exécutable et utilisable dans l'environnement d'exécution des tests sélectionné à l'étape 24 ou préconfiguré.
A l'étape 30, le code binaire du script de test est exécuté automatiquement dans l'environnement d'exécution des tests. A l'étape 31 , les résultats dus à l'exécution des tests effectués sur le logiciel de fonctionnement sont générés sous une forme directement compatible avec le type d'environnement d'exécution des tests sélectionné par le développeur.
Le procédé présente l'avantage de pouvoir s'adapter à tout type d'environnement d'exécution de tests de logiciels de fonctionnement. Il peut donc s'adapter à tout type d'environnement virtuel ou réel.
Avec le procédé de l'invention, les scripts de test générés sont directement valides et exempts d'erreurs. En effet, durant la phase de validation des scripts de test, la non validation d'un desdits scripts correspond à la découverte d'une erreur, ce qui entraîne implicitement une correction de la fonction testée du logiciel de fonctionnement.
La figure 2 est une représentation schématique de l'unité de commande 1 de l'environnement d'exécution des tests, permettant la génération de scripts de test du logiciel de fonctionnement destiné à être chargé dans un système embarqué (non représenté). La figure 2 montre un exemple d'unité de commande 1 d'un environnement d'exécution des tests. L'environnement d'exécution des tests peut être, selon des variantes de réalisation, soit simulé virtuellement sur une plateforme hôte, telle qu'une station de travail, soit basé sur un équipement matériel de type émulateur. On entend par environnement d'exécution des tests un environnement permettant de vérifier, corriger, effectuer un rodage fonctionnel et tester un logiciel de fonctionnement d'un système embarqué. L'unité de commande 1 de l'environnement de test comporte, de manière non exhaustive, un processeur 2, une mémoire programme 3, une mémoire de données 4, et une interface d'entrée/sortie 5. Le processeur 2, la mémoire programme 3, la mémoire de données 4, et l'interface entrée/sortie 5 sont connectés les uns aux autres par un bus de communication 6 bidirectionnel.
Le processeur 2 est commandé par des codes instructions enregistrés dans une mémoire programme 3 de l'unité de commande 1. La mémoire programme 3 comporte, dans une zone 7, des instructions pour effectuer une identification des cas de tests valides. Cette identification permet l'interaction du développeur par l'intermédiaire d'une interface, à divers fonctionnalités que l'on retrouve dans un débogueur classique. Parmi ces fonctionnalités existe notamment la possibilité de positionner un point de contrôle d'exécution à l'entrée de la fonction du logiciel de fonctionnement qui est sous test. Une autre fonctionnalité permet de positionner un point d'arrêt à la sortie de la fonction. Cette interaction du développeur lui permet de contrôler les états de variables afin de déterminer si l'exécution de la fonction s'est déroulée correctement. La mémoire programme 3 comporte, dans une zone 8, des instructions pour effectuer une validation. Cette validation consiste à enregistrer de manière automatique l'ensemble des états de variables contrôlés. Ces états constituent un enregistrement 12 des cas de tests valides. Cette validation permet également d'éditer l'ensemble des états contrôlés. Ces états contrôlés deviennent la valeur de référence des cas de tests validés.
La mémoire programme 3 comporte, dans une zone 9, des instructions pour effectuer une génération de scripts de test. Cette génération de scripts de test découle d'une analyse des états des variables de l'enregistrement 12. Cette génération de scripts de test se présente sous la forme d'un code source 13. Elle se présente cas de test par cas de test.
La mémoire programme 3 comporte, dans une zone 10, des instructions pour effectuer une compilation du code source 13 afin de le traduire dans le langage machine. Suite à cette compilation, une édition des liens est effectuée pour transformer le code source 13 (qui se trouve en langage machine) en un code binaire 14 exécutable.
La mémoire programme 3 comporte, dans une zone 11 , des instructions pour effectuer une exécution du script de test pour générer en sortie des résultats de test 15.

Claims

REVENDICATIONS
1 - Procédé de génération de script pour tester la validité d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, caractérisé en ce qu'il comporte les étapes suivantes :
- a) identification (20) de cas de tests valides par un développeur, de manière interactive, en positionnant un point d'entrée et un point d'arrêt, respectivement, au début et à la fin d'une fonction du logiciel de fonctionnement en cours de test. - b) observation et enregistrement (22) des états de variables de ladite fonction par l'intermédiaire de la position du point d'arrêt et du point d'entrée,
- c) génération automatique (26) de script de test, en analysant dans un premier temps, les états des variables observés lors de l'identification des cas de test et en générant, dans un deuxième temps, un script de test sous la forme d'un code source (13),
- d) exécution automatique (30) dans un environnement d'exécution des tests du script de test généré.
2 - Procédé selon la revendication 1 caractérisé en ce que, entre l'étape d'observation et d'enregistrement des états de variables et l'étape de génération automatique d'un script de test, est effectuée une étape de vérification de la validité des cas de test permettant au développeur de décider si l'exécution de la fonction testée est valide par rapport aux états de variables observés.
3 - Procédé selon l'une quelconque des revendications 1 à 2 caractérisé en ce que la génération du script de test est effectuée cas de test par cas de test.
4 - Procédé selon l'une quelconque des revendications 1 à 3 caractérisé en ce qu'entre l'étape de génération automatique du script et d'exécution automatique du script, est effectuée une compilation du code source pour traduire automatiquement ledit code source du script de test en un script équivalent en langage machine.
5 - Procédé selon la revendication 4 caractérisé en ce que la compilation est suivie d'une édition de liens du script de test fournissant un code binaire exécutable et utilisable dans l'environnement d'exécution des tests sélectionné par le développeur. 6 - Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que des résultats de tests sont générés sous une forme directement compatible avec le type d'environnement d'exécution des tests sélectionné. 7 - Dispositif simulant le fonctionnement d'un calculateur embarqué à bord d'un aéronef, caractérisé en ce qu'il met en œuvre le procédé selon l'une quelconque des revendications 1 à 6.
8 - Dispositif selon la revendication 7 caractérisé en ce qu'il est simulé virtuellement sur une plate-forme hôte de test et de débogage. 9 - Programme de test chargeable sur une unité de commande 1 comprenant des séquences d'instructions pour mettre en œuvre le procédé selon l'une des revendications 1 à 6, lorsque le programme est chargé sur l'unité et y est exécuté.
EP08836799A 2007-09-14 2008-09-12 Procédé de génération automatique de script pour tester la validité d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre Withdrawn EP2188723A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0757615A FR2921170B1 (fr) 2007-09-14 2007-09-14 Procede de generation automatique de programmes de test d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre
PCT/FR2008/051644 WO2009047430A2 (fr) 2007-09-14 2008-09-12 Procédé de génération automatique de script pour tester la validité d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre

Publications (1)

Publication Number Publication Date
EP2188723A2 true EP2188723A2 (fr) 2010-05-26

Family

ID=39273116

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08836799A Withdrawn EP2188723A2 (fr) 2007-09-14 2008-09-12 Procédé de génération automatique de script pour tester la validité d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre

Country Status (9)

Country Link
US (1) US20110047529A1 (fr)
EP (1) EP2188723A2 (fr)
JP (1) JP2010539576A (fr)
CN (1) CN101802792B (fr)
BR (1) BRPI0817102A2 (fr)
CA (1) CA2696020A1 (fr)
FR (1) FR2921170B1 (fr)
RU (1) RU2473115C2 (fr)
WO (1) WO2009047430A2 (fr)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8732663B2 (en) * 2010-02-24 2014-05-20 Salesforce.Com, Inc. System, method and computer program product for providing automated testing by utilizing a preconfigured point of entry in a test or by converting a test to a predefined format
FR2958427B1 (fr) 2010-03-30 2016-11-18 Eurocopter France Procede d'agencement d'un logiciel d'application sur le materiel informatique d'un equipement reel ou virtuel et architecture de commande de l'equipement comprenant un tel logiciel
CN102541735A (zh) * 2011-12-28 2012-07-04 云海创想信息技术（天津）有限公司 软件自动化测试方法
US9135147B2 (en) * 2012-04-26 2015-09-15 International Business Machines Corporation Automated testing of applications with scripting code
US9286273B1 (en) * 2013-03-11 2016-03-15 Parallels IP Holding GmbH Method and system for implementing a website builder
CN104281518B (zh) * 2013-07-02 2018-05-15 腾讯科技（深圳）有限公司 终端应用测试方法、装置、系统、平台及移动终端
CN103500141A (zh) * 2013-10-09 2014-01-08 中国联合网络通信集团有限公司 自动化测试方法和装置
US20160098259A1 (en) * 2014-10-02 2016-04-07 The Boeing Company Software Aircraft Part Installation System
GB2533117A (en) * 2014-12-10 2016-06-15 Ibm Software test automation
ES2864004T3 (es) * 2015-04-03 2021-10-13 Iveco Spa Método para mejorar y extender la lógica de una instalación de prueba para un componente de vehículo, en particular una batería o un alternador
CN106502896B (zh) * 2016-10-21 2019-08-23 武汉斗鱼网络科技有限公司 一种函数测试代码的生成方法及装置
US11142345B2 (en) 2017-06-22 2021-10-12 Textron Innovations Inc. System and method for performing a test procedure
RU2679350C2 (ru) * 2017-07-10 2019-02-07 Федеральное государственное бюджетное образовательное учреждение высшего образования "Воронежский государственный технический университет" Система генерации тестовых данных
DE112018006331B4 (de) * 2018-01-17 2022-05-05 Mitsubishi Electric Corporation Testfallgenerierungsvorrichtung, Testfallgenerierungsverfahren und Testfallgenerierungsprogramm
CN109214043B (zh) * 2018-07-20 2023-04-07 北京航空航天大学 数字飞行器动力学环境信息传输源代码人工智能书写方法
CN112445467A (zh) * 2019-09-04 2021-03-05 常州星宇车灯股份有限公司 汽车风扇模块软件生成方法
US11144437B2 (en) 2019-11-25 2021-10-12 International Business Machines Corporation Pre-populating continuous delivery test cases
CN112699033B (zh) * 2020-12-29 2023-05-23 中国航空工业集团公司西安飞机设计研究所 一种多分区机载软件测试用例多级同步加载方法
CN113297083B (zh) * 2021-05-27 2022-08-19 山东云海国创云计算装备产业创新中心有限公司 一种跨平台ic测试方法、装置、设备及介质
CN116756043B (zh) * 2023-08-10 2023-11-03 东方空间技术(山东)有限公司 一种目标设备的软件测试方法、装置、设备及存储介质

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SU1541617A1 (ru) * 1988-05-10 1990-02-07 Предприятие П/Я А-3821 Устройство отладки микропрограммных блоков
JPH06110733A (ja) * 1992-09-30 1994-04-22 Hitachi Ltd プログラムのテストケース生成装置
US6161216A (en) * 1998-04-29 2000-12-12 Emc Corporation Source code debugging tool
US7039912B1 (en) * 1998-05-12 2006-05-02 Apple Computer, Inc. Integrated computer testing and task management systems
JP2002207611A (ja) * 2001-01-11 2002-07-26 Mitsubishi Heavy Ind Ltd ソフトウェアワーキングベンチ
CA2440031C (fr) * 2001-02-22 2013-07-02 Accenture Global Services Gmbh Environnement de developpement reparti pour la mise au point d'applications internet par des developpeurs travaillant dans des endroits eloignes
US7058857B2 (en) * 2001-10-10 2006-06-06 International Business Machines Corporation Method and system for testing a software product
JP4061931B2 (ja) * 2002-03-13 2008-03-19 株式会社デンソー 実行履歴記録装置、ブレーク命令設定装置、及びプログラム
RU2213939C1 (ru) * 2002-10-14 2003-10-10 Загороднев Александр Васильевич Способ передачи информации с бортового накопителя информации летательного аппарата во внешние блоки обработки и система для его осуществления
JP2004220269A (ja) * 2003-01-14 2004-08-05 Cyx Inc 統合テスト管理システム
US7512526B2 (en) * 2004-03-01 2009-03-31 Raytheon Company System and method for dynamic runtime HLA-federation-execution data display
RU2263973C1 (ru) * 2004-05-07 2005-11-10 Федеральное государственное унитарное предприятие Летно-исследовательский институт им. М.М. Громова Пилотажно-тренировочный комплекс
CN100375057C (zh) * 2004-08-31 2008-03-12 中国银联股份有限公司 一种自动化测试辅助系统及相应的软件自动测试方法
US7543278B2 (en) * 2004-10-15 2009-06-02 Microsoft Corporation System and method for making a user interface element visible
JP2006155047A (ja) * 2004-11-26 2006-06-15 Nec Electronics Corp 検証システム及び検証方法
JP2006260390A (ja) * 2005-03-18 2006-09-28 Nomura Research Institute Ltd テストケース生成プログラム及び方法
US7526759B2 (en) * 2005-04-19 2009-04-28 International Business Machines Corporation Debugging prototyped system solutions in solution builder wizard environment
CN100362479C (zh) * 2005-12-09 2008-01-16 华为技术有限公司 基于自动化测试脚本对被测对象进行测试的方法和系统
US7895565B1 (en) * 2006-03-15 2011-02-22 Jp Morgan Chase Bank, N.A. Integrated system and method for validating the functionality and performance of software applications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2009047430A2 *

Also Published As

Publication number Publication date
CN101802792A (zh) 2010-08-11
BRPI0817102A2 (pt) 2015-03-24
WO2009047430A2 (fr) 2009-04-16
FR2921170A1 (fr) 2009-03-20
FR2921170B1 (fr) 2018-01-12
WO2009047430A3 (fr) 2009-12-30
CA2696020A1 (fr) 2009-04-16
US20110047529A1 (en) 2011-02-24
CN101802792B (zh) 2012-12-26
RU2473115C2 (ru) 2013-01-20
RU2010114709A (ru) 2011-10-20
JP2010539576A (ja) 2010-12-16

Similar Documents

Publication Publication Date Title
EP2188723A2 (fr) Procédé de génération automatique de script pour tester la validité d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre
US8943478B2 (en) Fault detection and localization in dynamic software applications
US20170212829A1 (en) Deep Learning Source Code Analyzer and Repairer
US8578342B2 (en) Fault detection and localization in dynamic software applications requiring user inputs and persistent states
US8561021B2 (en) Test code qualitative evaluation
Schäfer et al. An empirical evaluation of using large language models for automated unit test generation
Soltani et al. A guided genetic algorithm for automated crash reproduction
US20110016456A1 (en) Generating additional user inputs for fault detection and localization in dynamic software applications
US11023362B2 (en) Co-verification of hardware and software
CN104156311B (zh) 一种基于cpu模拟器的嵌入式c语言目标码级单元测试方法
WO2009047435A2 (fr) Procédé de débogage d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef et dispositif de mise en oeuvre
EP2150897B1 (fr) Procede de simulation d'un systeme embarque a bord d'un aeronef pour tester un logiciel de fonctionnement et dispositif pour la mise en oeuvre de ce procede
Svenningsson et al. Model-implemented fault injection for hardware fault simulation
CA2697725C (fr) Procede de traitement du volume d'informations manipule durant une phase de debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre
Jaffuel et al. LEIRIOS test generator: Automated test generation from B models
Chalupa et al. Symbiotic 3: New Slicer and Error-Witness Generation: (Competition Contribution)
US20220129371A1 (en) Initialization Sequences for Automatic Software Test Generation
Berthier et al. Tutorials on testing neural networks
EP3182286A1 (fr) Procede de verification de fonctionnalites d'un logiciel destine a etre embarque dans un composant cryptographique, systeme
Mateo Navarro et al. A proposal for automatic testing of GUIs based on annotated use cases
Rezaalipour et al. An annotation-based approach for finding bugs in neural network programs
Niemiec et al. ExecutionFlow: a tool to compute test paths of Java methods and constructors
Lancia Detecting fault injection vulnerabilities in binaries with symbolic execution
FR3042291A1 (fr) Dispositif et procede de verification d'un logiciel
Eichelberger et al. Debugger-based record replay and dynamic analysis for in-vehicle infotainment

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100204

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20110316

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150401