Embedded software simulation test environment construction method based on virtual machine

Abstract

The invention relates to an embedded software simulation test environment construction method based on a virtual machine, and belongs to the technical field of embedded software testing. According to the method, an interface adaptation layer and a network communication layer are added, a driver of a bottom specific special hardware interface device or bus is replaced, operation of the specific special hardware interface device or bus is redirected into network communication operation, and embedded software virtual machine environment deployment is achieved. An external real crosslinking device or system is replaced by a simulation device, excitation or response data is provided for operation of embedded software, meanwhile, output data of the embedded software is received, real-time automatic response is carried out according to the output data, and uninterrupted operation of the embedded software is guaranteed; through a test driver, external simulation equipment is managed in a centralized manner, and the simulation equipment is tested and scheduled according to a business process, so that automatic testing of embedded software is cooperatively completed.

Description

Technical Field

[0001] The invention belongs to the technical field of embedded software testing, and in particular relates to a method for constructing an embedded software simulation testing environment based on a virtual machine. Background Art

[0002] Embedded systems are special computer systems that are designed to perform various control, computing, monitoring and communication tasks by building embedded hardware platforms and developing corresponding embedded software for specific application requirements and working environments. Embedded systems have been widely used in aviation, aerospace, industrial process control, civil electronics and many other fields.

[0003] Embedded systems generally have the characteristics of operating platform specificity and external cross-linking device specificity. Operating platform specificity means that embedded software cannot run normally before the embedded hardware platform is developed; external cross-linking device specificity means that embedded software needs to interact with external devices or systems to achieve the expected functions. The operating platform specificity and external device specificity of embedded systems bring great difficulties and challenges to embedded software testing. On the one hand, due to the lack of external cross-linking devices or systems, it is impossible to build a complete embedded software configuration item or system test environment, and software testing cannot cover the embedded software timing and interface, and the adequacy of the test is difficult to ensure. On the other hand, when embedded software is put into the actual installation environment for configuration item or system testing, it is impossible to provide the execution conditions of extreme or abnormal test cases, such as simulating over-limit actions or over-boundary range inputs, and the execution of such extreme or abnormal test cases is very likely to cause damage to hardware equipment, and the cost of errors and error correction is high. In addition, due to various resource constraints, the effective time that the actual installation environment can provide for software testing is also very limited; the characteristics of embedded systems such as strong real-time performance, high reliability and safety requirements, specific timing and information interaction characteristics between external cross-linked devices, and abnormal or error scenarios that are difficult to trigger and simulate also make embedded software testing more difficult. Summary of the invention

[0004] 1. Technical issues to be resolved

[0005] The technical problem to be solved by the present invention is: how to build an embedded software simulation test environment based on virtual machines and simulation devices, decouple the specificity of the embedded software running platform and the specificity of external cross-linking devices, provide embedded software testers with a flexible and controllable simulation test environment, support embedded software automated testing, and meet the software testing needs of various normal or abnormal scenarios.

[0006] (II) Technical solution

[0007] In order to solve the above technical problems, the present invention provides a method for constructing an embedded software simulation test environment based on a virtual machine. In the method, the embedded software simulation test environment is designed to consist of three parts: a virtual target machine, an external simulation device and a test driver. The virtual target machine provides an operating environment for the embedded software that does not rely on a dedicated embedded hardware platform; the external simulation device interacts with the virtual target machine to provide a simulated external cross-linking device or system, i.e., a companion test device or system, for the embedded software test; the test driver provides automated support for the embedded software test, centrally manages and controls the external simulation device, schedules the external simulation device according to the test process described by the test script, and collaboratively completes the automated test of the embedded software.

[0008] The invention also provides an embedded software simulation test environment constructed based on the method.

[0009] (III) Beneficial effects

[0010] (1) By adding an interface adaptation layer and a network communication layer, the driver of the underlying specific dedicated hardware interface device or bus is replaced, and the operation of the specific dedicated hardware interface device or bus is redirected into a network communication operation, which saves the procurement and development of dedicated hardware interface devices and reduces the cycle and cost of building an embedded software simulation test environment.

[0011] (2) By deploying and running the embedded software virtual machine environment, the limitations of the specificity of the embedded software running platform are eliminated, the portability of the embedded software simulation test environment is improved, and the rapid deployment and sharing of the embedded software simulation test environment can be achieved.

[0012] (3) The embedded software interface protocol is described by the data model, and the interaction model is used to describe the embedded software interaction behavior, so as to realize the simulation of the external cross-linking device or system function of the embedded software based on the interface data, thereby reducing the complexity of building the embedded software simulation test environment.

[0013] (4) By providing external simulation device management and control interfaces, the control capability of external simulation devices is enhanced, and the flexibility and controllability of embedded software testing are improved.

[0014] (5) Through script description testing, it supports embedded software automated testing according to business processes, improving the effectiveness and efficiency of embedded software testing;

[0015] (6) Through the simulation device registration center, the test driver and the specific external simulation device are completely decoupled, realizing the universalization of the test driver. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a composition and technical principle diagram of the embedded software simulation test environment of the present invention;

[0017] Figure 2 It is the composition and technical principle diagram of the external simulation device of the present invention;

[0018] Figure 3 It is a composition and technical principle diagram of the test driver of the present invention. DETAILED DESCRIPTION

[0019] In order to make the purpose, content and advantages of the present invention more clear, the specific implementation methods of the present invention are further described in detail below in conjunction with the drawings and examples.

[0020] The present invention provides a method for constructing an embedded software simulation test environment based on a virtual machine. The method adds an interface adaptation layer and a network communication layer, replaces the driver of the underlying specific dedicated hardware interface device or bus, redirects the operation of the specific dedicated hardware interface device or bus into a network communication operation, and realizes the deployment of the embedded software virtual machine environment; replaces the external real cross-linking device or system with a simulation device, provides stimulus or response data for the operation of the embedded software, receives the output data of the embedded software, and performs real-time automatic response according to the output data, so as to ensure the uninterrupted operation of the embedded software; centrally manages the external simulation device through a test driver, and schedules the simulation device according to the business process test, so as to collaboratively complete the automatic test of the embedded software.

[0021] The composition and technical principle diagram of the embedded software simulation test environment based on virtual machines are as follows: Figure 1 As shown. The embedded software simulation test environment consists of three parts: virtual target machine, external simulation device and test driver. The virtual target machine provides an operating environment for embedded software that does not rely on a dedicated embedded hardware platform; the external simulation device provides simulated external cross-linking devices or systems for embedded software testing, that is, accompanying test devices or systems; the test driver provides automated support for embedded software testing. The following details the specific steps for building the embedded software simulation test environment.

[0022] Step 1: Embedded software virtual target machine deployment

[0023] The deployment of embedded software virtual target machines is achieved by adding an interface adaptation layer and a network communication layer, replacing the drivers of the underlying specific hardware interface devices or buses, decoupling the embedded software's dependency on dedicated hardware interfaces, and providing a virtual target machine-based operating environment for the embedded software.

[0024] The interface adaptation layer redirects the upper embedded software's access operations to specific hardware interface devices or buses into ordinary network communication operations by adapting dedicated hardware interface operation functions. From the perspective of ensuring the operation of embedded software, the embedded software only needs to obtain the same operation effect through dedicated hardware interface operation functions, and does not perceive or care about the actual operation process of the underlying hardware interface. There are two ways to implement the interface adaptation layer:

[0025] (1) Maintain the hardware interface function prototype and redirect the dedicated hardware interface operations to the corresponding operations of the network communication layer by redefining the function implementation part.

[0026] (2) Register the corresponding operation functions of the network communication layer into the operating system I / O system, so that the dedicated hardware interface operations can be automatically redirected to the corresponding operations of the network communication layer through standard I / O operations (such as device registration, device start and stop, device reset and exit, device interruption, device reading and writing, etc.).

[0027] The network communication layer mainly realizes the communication interaction between embedded software and external systems or devices. On the one hand, it receives the stimulus data from the external system or device, and on the other hand, it outputs the response or feedback data to the external system or device. The network communication layer is implemented by: using the TCP / UDP server mode, realizing multiplexing through select, and managing the connection and data reception of all external TCP / UDP clients.

[0028] Step 2: External simulation device construction

[0029] External simulation equipment is mainly used to replace the external real cross-linking equipment or system of embedded software, provide stimulus or response data for embedded software operation, receive the output data of embedded software, and make real-time automatic responses according to the output data to ensure the uninterrupted operation of embedded software and support embedded software to carry out testing according to business processes. External simulation equipment consists of three layers: network communication layer, function simulation layer and device control layer, such as Figure 2 shown.

[0030] (1) Network communication layer

[0031] The network communication layer mainly implements communication interaction with the "network communication layer" of the virtual target machine. Since the network communication layer in the virtual target machine adopts the TCP / UDP server mode and multiplexing is achieved through select, the "network communication layer" of the external simulation device is implemented in the TCP / UDP client mode. On the one hand, it is responsible for sending network data to the virtual target machine and receiving the output data of the virtual target machine. On the other hand, it receives control from the "device control layer" of the external simulation device, such as establishing connections, disconnecting connections, sending data, etc.

[0032] (2) Functional simulation layer

[0033] The functional simulation layer mainly realizes the functional simulation of real cross-linked devices or systems outside the embedded software, and mainly simulates the input, output and interaction timing of real cross-linked devices or systems. The "functional simulation layer" of the external simulation device includes four parts: simulation model, data frame parser, command frame responder and data frame encoder.

[0034] The simulation model mainly includes a data model and an interaction model. The data model describes the embedded software interface protocol and is the basis for parsing and identifying request commands, as well as constructing stimulus and response commands. The interaction model describes the interactive behavior of the embedded software and is the basis for realizing real-time response processing. The data frame parser is based on the data model to parse and identify request commands from the embedded software output data. The command frame responder is based on the interaction model to complete the real-time response processing of the embedded software request commands (embedded software output data). The data frame encoder is based on the data model to realize the construction of embedded software stimulus and response commands (embedded software input data).

[0035] (3) Equipment control layer

[0036] The device control layer mainly provides management and control interfaces for simulation devices. The device control layer is implemented using remote call technology, publishing the related functions of external simulation device management and control as interface functions that can be called externally, such as obtaining simulation device information, obtaining simulation device data models, turning on / off devices, turning on / off automatic response functions, turning on / off automatic status feedback functions, sending command frames, preparing command frames, etc.

[0037] Step 3: Test drive build

[0038] The test driver is mainly used to centrally manage and control external simulation devices, schedule external simulation devices according to the test process described by the test script, and collaboratively complete the automated testing of embedded software. The test driver consists of four parts: script engine, general function library, simulation device related function library, and simulation device registration center. Figure 3 shown.

[0039] The script engine mainly implements the interpretation and operation of test scripts, and is the key to realizing the automation of embedded software testing; the general function library provides general operation functions for test scripts, such as file operations (opening files, reading data, writing data, closing files, etc.), string operations (string concatenation, string interception, obtaining string length, obtaining characters at a specific position, etc.), and mathematical operations (trigonometric functions, square root functions, finding maximum values, finding minimum values, generating random numbers, etc.).

[0040] The simulation device related function library provides the test script with interface functions for operating the simulation device. These interface functions are encapsulations of the interface functions released by the "device control layer" of the external simulation device, such as obtaining simulation device information, obtaining simulation device data model, turning on / off the device, turning on / off the automatic response function, turning on / off the automatic status feedback function, sending command frames, preparing command frames, etc.; by calling these interface functions, on the one hand, the external simulation device information can be obtained, and then according to the simulation device identification, control commands and stimulus commands can be sent to the simulation device to control the behavior of the simulation device; on the other hand, the external simulation device data model can be obtained, and then according to the simulation device data model, response or stimulus data that meets the reception requirements of the simulation device can be constructed.

[0041] The simulation device registration center mainly realizes the centralized management and maintenance of external simulation devices. According to the name of the external simulation device, the proxy object of the external simulation device is queried in the "Simulation Device Registration Center", and then the real external simulation device is called through the proxy object to complete the external simulation device status acquisition or behavior control.

[0042] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for constructing an embedded software simulation test environment based on a virtual machine, characterized in that: In the method, the embedded software simulation test environment is designed to consist of three parts: a virtual target machine, an external simulation device and a test driver, wherein the virtual target machine provides an operating environment for the embedded software that does not rely on a dedicated embedded hardware platform; the external simulation device interacts with the virtual target machine to provide a simulated external cross-linking device or system, i.e., a companion test device or system, for the embedded software test; The test driver provides automated support for embedded software testing, centrally manages and controls external simulation devices, schedules external simulation devices according to the test process described by the test script, and collaboratively completes embedded software automated testing.

2. The method according to claim 1, characterized in that In this method, the embedded software virtual target machine is deployed by adding an interface adaptation layer and a network communication layer, replacing the driver of the underlying specific dedicated hardware interface device or bus, decoupling the embedded software's dedicated hardware interface dependency, and providing a virtual target machine-based operating environment for the embedded software.

3. The method according to claim 2, characterized in that The interface adaptation layer redirects the upper embedded software's access operations to specific hardware interface devices or buses into ordinary network communication operations by adapting dedicated hardware interface operation functions. From the perspective of ensuring the operation of embedded software, the embedded software only needs to obtain the same operation effect through dedicated hardware interface operation functions, and does not perceive or care about the actual operation process of the underlying hardware interface.

4. The method according to claim 3, characterized in that The interface adaptation layer has two implementation modes: (1) Keep the hardware interface function prototype and redirect the dedicated hardware interface operation to the corresponding operation of the network communication layer by redefining the function implementation part; (2) Register the corresponding operation functions of the network communication layer into the I / O system of the operating system, so as to automatically redirect the dedicated hardware interface operations to the corresponding operations of the network communication layer through standard I / O operations. Standard I / O operations include device registration, device start and stop, device reset and exit, device interruption, and device reading and writing.

5. The method according to claim 4, characterized in that The network communication layer realizes the communication interaction between the embedded software and the external system or device. On the one hand, it receives the stimulus data of the external system or device, and on the other hand, it outputs the response or feedback data to the external system or device. The network communication layer is implemented by: using the TCP / UDP server mode, realizing multiplexing through select, and managing the connection and data reception of all external TCP / UDP clients.

6. The method according to claim 5, characterized in that The external simulation device provides stimulus or response data for the operation of the embedded software, receives output data of the embedded software, and performs real-time automatic response according to the output data, thereby ensuring uninterrupted operation of the embedded software and supporting the embedded software to carry out testing according to business processes.

7. The method according to claim 6, characterized in that The external simulation device is composed of three layers: network communication layer, function simulation layer and device control layer; The network communication layer of the external simulation device realizes communication interaction with the network communication layer of the virtual target machine; the network communication layer in the virtual target machine adopts the TCP / UDP server mode and realizes multiplexing through select, and the network communication layer of the external simulation device adopts the TCP / UDP client mode, which is responsible for sending network data to the virtual target machine and receiving the output data of the virtual target machine on the one hand, and receiving the control of the device control layer of the external simulation device on the other hand, including establishing connection, disconnecting connection and sending data; The functional simulation layer realizes the functional simulation of the real cross-linking device or system outside the embedded software, and simulates the input, output and interaction timing of the real cross-linking device or system; The device control layer provides external management and control interfaces for simulation devices; The device control layer is implemented using remote call technology, publishing the relevant functions of external simulation device management and control as interface functions that can be called externally.

8. The method according to claim 7, characterized in that The functional simulation layer of the external simulation device includes a simulation model, a data frame parser, a command frame responder and a data frame encoder; the simulation model includes a data model and an interaction model. The data model describes the embedded software interface protocol and is the basis for parsing and identifying request commands, as well as constructing stimulus and response commands; the interaction model describes the embedded software interaction behavior and is the basis for achieving real-time response processing; the data frame parser is based on the data model to parse and identify request commands from the embedded software output data; The command frame responder completes the real-time response processing of the embedded software request command based on the interaction model; The data frame encoder implements the construction of embedded software stimulus and response commands based on the data model.

9. The method according to claim 8, characterized in that The test driver consists of four parts: script engine, general function library, simulation device related function library, and simulation device registration center; The script engine implements test script interpretation and operation, which is used to realize embedded software test automation; the general function library provides general operation functions for test scripts; The simulation device related function library provides the test script with interface functions for operating the simulation device. These interface functions are the encapsulation of the interface functions released by the device control layer of the external simulation device. By calling these interface functions, on the one hand, the external simulation device information can be obtained, and then control commands and stimulus commands can be sent to the simulation device according to the simulation device identification to control the behavior of the simulation device; On the other hand, it is possible to obtain an external simulation device data model, and then construct response or stimulus data that meets the reception requirements of the simulation device according to the simulation device data model; The simulation device registration center realizes the centralized management and maintenance of external simulation devices. According to the name of the external simulation device, the proxy object of the external simulation device is queried in the simulation device registration center, and then the real external simulation device is called through the proxy object to complete the status acquisition or behavior control of the external simulation device.

10. An embedded software simulation test environment constructed based on the method according to any one of claims 1 to 9.

Images