Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/36—Prevention of errors by analysis, debugging or testing of software
  • G06F11/3698—Environments for analysis, debugging or testing of 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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=39273116

Family Applications (1)

Country Status (9)

Families Citing this family (24)

Family Cites Families (19)

• 2007
  • 2007-09-14 FR FR0757615A patent/FR2921170B1/fr active Active
• 2008
  • 2008-09-12 CA CA2696020A patent/CA2696020A1/fr not_active Abandoned
  • 2008-09-12 US US12/678,143 patent/US20110047529A1/en not_active Abandoned
  • 2008-09-12 JP JP2010524554A patent/JP2010539576A/ja active Pending
  • 2008-09-12 EP EP08836799A patent/EP2188723A2/de not_active Withdrawn
  • 2008-09-12 RU RU2010114709/08A patent/RU2473115C2/ru not_active IP Right Cessation
  • 2008-09-12 BR BRPI0817102 patent/BRPI0817102A2/pt not_active IP Right Cessation
  • 2008-09-12 WO PCT/FR2008/051644 patent/WO2009047430A2/fr not_active Ceased
  • 2008-09-12 CN CN2008801065576A patent/CN101802792B/zh not_active Expired - Fee Related

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events