A software testing method, system, device, and storage medium

Abstract

The present invention belongs to the technical field of automotive software testing, and particularly relates to a software testing method, including: obtaining an interface file of the RTE layer of the controller software; preprocessing the interface file to obtain an interface target file; obtaining the C code of the application layer of the controller software; creating a running file according to the C code; compiling and generating a first dynamic link library file according to the interface target file and the running file; compiling the vehicle model corresponding to the controller to generate a second dynamic link library file; constructing a software testing model according to the first dynamic link library file and the second dynamic link library file. The present invention ideally simulates the functions of the basic software layer by simulating a software testing environment, simplifies the functions of the basic software layer that originally supports the operation of the application layer and is strongly associated with the hardware and complex, enables the test to focus on the application layer strategy issues, and does not need to pay attention to the impact of the basic software layer implementation on the application layer.

Description

Technical Field

[0001] The present invention belongs to the technical field of automotive software testing, and particularly relates to a software testing method, system, device, and storage medium. Background Art

[0002] The development of automotive controller software generally includes the following processes: model-based programming, generating C code, integrating binary files, burning them into the controller, and performing functional verification in a hardware-in-the-loop environment. When functional implementation deviations are found during verification, it is necessary to locate problems separately from the basic software layer / strategy application software layer. In each layer, according to calibration address description files such as a2l, relevant variables are read to find logical deviations.

[0003] The current systematic black-box testing method has the following disadvantages: The verification of application layer strategies is restricted by the development progress of basic software and hardware, and cannot be synchronized with the development of application layer strategy software; The iteration cycle is long. For in-phase improvement of application layer strategies, it is necessary to repeat the integration into binary files and burn them into the controller; The verification of application layer strategies is affected by implementation deviations in the basic software layer.

[0004] For controller software that complies with the AutoSar standard, various services / drivers are included in the BSW (Basic Software, basic software layer), which are functions that the ASW (Application Software, application layer) strategy does not need to concern about the specific implementation. Summary of the Invention

[0005] In view of the above-mentioned disadvantages of the prior art, the purpose of the present invention is to provide a software testing method that enables testing not to depend on the hardware and BSW software implementations that are not concerned about, and the development of the test environment can be synchronized with the development of ASW software.

[0006] To achieve the above object and other related objects, the present invention provides a software testing method, including: obtaining an interface file of the RTE layer of the controller software; preprocessing the interface file to obtain an interface target file; obtaining the C code of the application layer of the controller software; creating a running file according to the C code; compiling and generating a first dynamic link library file according to the interface target file and the running file; compiling the vehicle model corresponding to the controller to generate a second dynamic link library file; constructing a software testing model according to the first dynamic link library file and the second dynamic link library file.

[0007] According to a specific embodiment of the present invention, the step of preprocessing the interface file to obtain an interface target file includes: screening out the interface files in the interface file that have a dependency relationship with the basic software layer of the controller software and defining them as empty; filling the screened interface file with default values to obtain the interface target file.

[0008] According to a specific embodiment of the present invention, the step of creating a running file according to the C code includes: creating an initialization function and a periodic function according to the C code; creating a scheduling function according to the calibration parameters of the software in the controller, and generating corresponding task files in the running file for the initialization function, the periodic function, and the scheduling function; configuring non-volatile storage variables according to the calibration parameters of the software in the controller, and generating corresponding storage files in the running file.

[0009] According to a specific embodiment of the present invention, the interface files include: a complex driver layer interface definition file, an I / O hardware abstraction layer interface definition file, a communication service layer interface definition file, a storage service layer interface definition file, an OS service layer interface definition file, and an application layer SWC interface definition file.

[0010] According to a specific embodiment of the present invention, the interface target files include: an I / O hardware abstraction layer interface definition file, a communication service layer interface definition file, and an application layer SWC interface definition file.

[0011] According to a specific embodiment of the present invention, the interface files of the RTE layer of the controller software are obtained through the Davinci tool.

[0012] According to a specific embodiment of the present invention, the first dynamic link library file is compiled and generated through the "sbsBuild.exe" instruction of Silver; the second dynamic link library file is compiled and generated through the "SimBuild.dll" component of Silver; and the first dynamic link library file and the second dynamic link library file generate the software test model in the Silver environment.

[0013] A software test system includes: an interface file extraction module for obtaining the interface files of the RTE layer of the controller software; an interface file processing module for preprocessing the interface files to obtain interface target files; a C code extraction module for obtaining the C code of the application layer of the controller software; a running configuration module for creating a running file according to the C code; a first model generation module for compiling and generating a first dynamic link library file according to the interface target files and the running file; a second model generation module for compiling and generating a second dynamic link library file for the vehicle model corresponding to the controller; and a third model generation module for constructing a software test model according to the first dynamic link library file and the second dynamic link library file.

[0014] An electronic device includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the steps of any one of the above-mentioned methods are implemented.

[0015] A computer-readable medium stores instructions thereon, and the instructions are loaded and executed by a processor to perform the method as described in any one of the above.

[0016] The technical effect of the present invention is that by simulating a software test environment, the test does not depend on the hardware and the software implementation of the basic application layer that is not concerned, and the development of the test environment can be synchronized with the software development of the application layer. At the same time, the functions of the basic software layer are ideally simulated, making the functions of the basic software layer that are strongly associated with the hardware and complex and originally support the operation of the application layer become simple, enabling the test to focus on the application layer policy issues and not need to pay attention to the impact of the basic software layer implementation on the application layer. Further, the iteration within a small stage of the test process is fast, and there is no need to re-integrate binary files. Description of the Drawings

[0017] Figure 1 It is a schematic flowchart of a specific embodiment of a software test method provided by the present invention;

[0018] Figure 2 It is a schematic flowchart of a specific embodiment of a software test system provided by the present invention;

[0019] Figure 3 It is a schematic structural diagram of a specific embodiment of an electronic device provided by the present invention. Detailed Embodiments

[0020] The following will describe the embodiments of the present invention with reference to the drawings and preferred embodiments. Those skilled in the art can easily understand the other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the protection scope of the present invention.

[0021] It should be noted that the drawings provided in the following embodiments only illustrate the basic concept of the present invention schematically. Therefore, only the components related to the present invention are shown in the drawings, rather than being drawn according to the number, shape, and size of the components in actual implementation. The type, quantity, and ratio of each component in actual implementation can be arbitrarily changed, and the component layout type may also be more complex.

[0022] In the following description, numerous specific details are explored to provide a more thorough explanation of embodiments of the present invention. However, it will be apparent to those skilled in the art that the embodiments of the present invention can be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring the embodiments of the present invention.

[0023] First of all, it should be noted that in order to enable the personnel in the technical field to better understand the solutions of this application, the technical solutions in the embodiments of this application are described clearly and completely.

[0024] AUTOSAR, whose full name is Automotive Open System Architecture, that is, the automotive open system architecture. It is a collaborative development framework for automotive electronic systems jointly participated by global automotive manufacturers, component suppliers, and various research and service institutions, and has established an open standard software architecture for automotive controllers (ECUs).

[0025] In the AUTOSAR architecture, the system software is neatly layered. The entire architecture is layered from top to bottom in turn as follows: Application Layer (Application Software, ASW), Runtime Environment (Runtime Environment, RTE), Basic Software Layer (Basic Software, BSW), and Microcontroller. To maintain independence between each layer, each layer can only call the interfaces of the next layer and provide interfaces for the layer above it. The layered architecture is the key to realizing the separation of software and hardware, and it also enables automotive embedded system control software developers to get rid of the dependence on the hardware system during the ECU software development and verification process.

[0026] The emergence of AUTOSAR has greatly solved the biggest troubles of automobile manufacturers and suppliers, and greatly reduced the coupling degree between software and hardware. The benefits it brings are obvious: it is conducive to improving the reuse degree of software, enabling the software to be reused across platforms; facilitating the exchange and update of software; the software functions can be defined and verified at the pre-architecture level, thus reducing development errors; reducing the amount of manual code, lightening the test and verification burden, and improving software quality; using a standardized data exchange format, facilitating communication and cooperation between companies. These advantages enable each enterprise to greatly reduce the development risks and costs while ensuring software quality.

[0027] The ASW contains several software components (SWCs), and the SWCs interact with each other through ports. Each software component can contain one or more runnable entities (REs), and the relevant control algorithms are encapsulated in the runnable entities, which can be triggered by RTE events. Generally, the vehicle manufacturer will master the application layer development of the main controller. In the era of software-defined vehicles, the main controller affects a series of indicators such as vehicle drivability, comfort, and economy, and it embodies the inheritance and style of the vehicle manufacturer.

[0028] As a bridge for the interaction between ASW and BSW, the RTE makes it possible to separate software from hardware. The RTE can implement communication between software components, between basic software, and between software components and basic software. The RTE encapsulates the communication and services of the basic software layer and provides standardized basic software and communication interfaces for ASW components, enabling ASW to call the services of the basic software through RTE interface functions. In addition, the RTE abstracts the communication between ECUs, that is, the RTE unifies it into communication between software components by using standardized interfaces. Since the implementation of the RTE is related to specific ECUs, it must be implemented separately for each ECU.

[0029] The BSW contains many basic software modules, and it is responsible for the functions of the ECU that are not related to applications. One of the most important functions of the BSW is the communication between ECUs, that is, signal interaction. The BSW can be further divided into four layers, namely the Services Layer, the ECU Abstraction Layer, the Microcontroller Abstraction Layer (MCAL), and the Complex Drivers. Each of the above layers is composed of a series of basic software components, including System Services, Memory Services, Communication Services, etc., which are mainly used to provide basic software services, including standardized system functions and function interfaces.

[0030] In the embodiments of the present application, by simulating the interfaces for the RTE layer to interact with the ASW / BSW, these interface functions can achieve universality and advance according to the AutoSar standard. The controller software that complies with the AutoSar standard can, according to the specific information of the controller, implement the definition of the RTE layer interfaces and the verification that is ahead of the BSW development. At the same time, configure the interfaces for the RTE layer to interact with the BSW according to the calibration parameters of the software in the controller, match with the bus signals / hardwired signals simulated by the controlled vehicle model to form a closed loop, and simulate the power-on initialization / cyclic scheduling / EEProm of the BSW OS layer, so as to decouple the ASW and the BSW, making the test independent of the hardware and the BSW software implementation that are not concerned, and enabling the development of the test environment to be synchronized with the ASW software development.

[0031] Embodiment 1

[0032] Please refer to Figure 1 as shown in the figure, a software testing method includes:

[0033] Step S10, obtain the interface file of the RTE layer of the controller software.

[0034] As a bridge between the application layer and the basic software layer, the RTE layer provides standardized basic software and communication interfaces for the application layer software components, enabling the application layer to call the services of the basic software layer through the RTE interface functions. Therefore, the interface file of the RTE layer is generated by compiling with the Davinci tool to cooperate with the running file to construct the environment for the software to run normally. Specifically, the interface file includes: the interface definition file of the complex driver layer, the interface definition file of the I / O hardware abstraction layer, the interface definition file of the communication service layer, the interface definition file of the storage service layer, the interface definition file of the OS service layer, and the interface definition file of the application layer SWC. Since most of the interface files do not actually participate in the normal operation of the software, they need to be screened and removed, so that the functions of the basic software layer that are strongly associated with the hardware and complex and originally support the operation of the application layer become simple, enabling the test to focus on the application layer policy issues without having to pay attention to the impact of the basic software layer implementation on the application layer.

[0035] Step S20, preprocess the interface file to obtain an interface target file. The specific steps are as follows:

[0036] Filter out the interface files that have dependencies on the base software layer and are useless, and define them as empty, thus completing the simplification. Further, there may be missing global variables or data type definitions in the filtered interface files. Therefore, to ensure the normal operation of the created software test environment, the interface files are supplemented according to the set default values to make them perfect, and finally the target interface files are obtained. Specifically, the target interface files at least include: the I / O hardware abstraction layer interface definition file, the communication service layer interface definition file, and the application layer SWC interface definition file.

[0037] Step S30, obtain the C code of the application layer of the controller software.

[0038] The application layer contains several software components SWC. Software components are not only the core of the application layer but also the carriers for the implementation of some abstraction layers, complex driver layers, etc. Software components interact through ports. The ports of software components can be divided into require ports (RPort), provide ports (PPort), and provide and require ports (PRPort) according to the input / output direction. Among them, the require port is used to obtain the required data or the requested operations from other software components. The provide port is used to provide certain data or certain types of operations externally. The provide and require port has the characteristics of both the require port and the provide port. Further, the software component SWC contains one or more running entities. The control algorithm is encapsulated in the running entity, and each running entity is assigned an RTE event, which can trigger the execution of this running entity. Therefore, compile and generate the code of the application layer, and parse the C code to construct the running environment of the software.

[0039] Step S40, create a running file according to the C code. The specific steps are as follows:

[0040] Identify and extract the initialization function and periodic function of software operation in the software component, and create a scheduling function for software operation according to the calibration parameters of the software in the controller. Specifically, the calibration parameters are the parameter conditions for the fixed operation of different software in the controller. At the same time, generate the corresponding task file Task.c for the initialization function, periodic function, and scheduling function. Further, configure the non-volatile storage variables of the software according to the calibration parameters of the software in the controller. Specifically, when the software runs, if it is shut down, the current running progress will be lost. Copy the calibration parameters stored in the software of the controller to configure the non-volatile storage variables of the software. At the same time, generate the corresponding storage file NVMCtrl.c for the non-volatile storage variables. Among them, the task file and the storage file are integrated into the running file.

[0041] Therefore, the software operation parameter files in the application layer, RTE layer, and basic software layer are generated through compilation to simulate the software test environment.

[0042] Step S50: Compile and generate the first dynamic link library file according to the interface target file and the operation file.

[0043] Meanwhile, to ensure the normal operation of the software, it is also necessary to simulate the power supply interface and the circuit.

[0044] Step S60: Compile and generate the second dynamic link library file for the vehicle model corresponding to the controller.

[0045] Specifically, the first dynamic link library file is generated through compilation using the "sbsBuild.exe" instruction of Silver, and the second dynamic link library file is generated through compilation using the "SimBuild.dll" component of Silver. Among them, the vehicle model includes bus input and output interfaces / hardwired input and output interfaces / vehicle simulation models.

[0046] Step S70: Construct a software test model according to the first dynamic link library file and the second dynamic link library file.

[0047] Specifically, the software test model is generated by the first dynamic link library file and the second dynamic link library file in the Silver environment.

[0048] Among them, Silver is a virtual ECU simulation platform, which is used to transfer the development tasks from the road and test bench to the PC to achieve the maximum efficiency of software development. Engineers can use Silver to build virtual ECUs, which behave very similarly to real ECUs. At the same time, Silver is also a powerful simulation platform that can be used to simulate and verify the data interaction between multiple controllers, such as engines, transmissions, and other vehicle components. By setting up an automated build process, new virtual ECUs can be automatically built within a few minutes every time the ECU software version is updated, so that software errors can be detected earlier through simulation means before the ECU software is applied to the actual vehicle.

[0049] Silver can be deployed on Windows or Linux PCs, supporting simulation models running various tools (such as MATLAB / Simulink, Dymola, SimulationX, MapleSim, AMEsim, GT-Power, axisuite), and during the simulation process, these tools do not need to be started. In the process of distributed collaborative development, models are exchanged in binary form (FMU, sFunction, Silver module) among different developers without the need to transfer the corresponding source code, which is beneficial to information security and intellectual property protection.

[0050] Once the software test model is constructed, the software can be tested. In the embodiments of this application, by simulating a software test model, the software test work can be completed without being in the AUTOSAR software architecture. It ideally simulates the functions of the basic software layer, making the functions of the basic software layer, which originally supports the operation of the application layer and is strongly associated with the hardware and complex, become simple, enabling the test to focus on the application layer policy issues without having to concern about the impact of the basic software layer implementation on the application layer. At the same time, it enables fast iteration within a small stage without the need to re-integrate binary files.

[0051] Embodiment 2

[0052] Please refer to Figure 2 As shown, the embodiments of this application also provide a software test system, including:

[0053] An interface file extraction module 30, configured to obtain the interface files of the RTE layer of the controller software.

[0054] An interface file processing module 40, configured to preprocess the interface files to obtain interface target files.

[0055] A C code extraction module 10, configured to obtain the C code of the application layer of the controller software.

[0056] A running configuration module 20, configured to create a running file according to the C code.

[0057] A first model generation module 50, configured to compile and generate a first dynamic link library file according to the interface target file and the running file.

[0058] A second model generation module 60, configured to compile and generate a second dynamic link library file from the vehicle model corresponding to the controller.

[0059] A third model generation module 70, configured to construct a software test model according to the first dynamic link library file and the second dynamic link library file.

[0060] It should be noted that the software testing system provided by the above embodiments and the software testing method provided by the above Embodiment 1 belong to the same concept. The specific ways in which each module and unit perform operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the software testing method provided by the above Embodiment 1 can, according to needs, allocate the above functions to different functional modules, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above. This is not limited here either.

[0061] Embodiment 3

[0062] Please refer to Figure 3 As shown, an embodiment of the present application further provides an electronic device, including a memory 2, a processor 1, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method described in any one of the above.

[0063] Among them, the memory includes at least one type of readable storage medium, and the readable storage medium includes flash memory, mobile hard disk, multimedia card, card-type memory (such as SD or DX memory, etc.), magnetic memory, magnetic disk, optical disk, etc. The memory can be an internal storage unit of the electronic device in some embodiments, such as the mobile hard disk of the electronic device. The memory can also be an external storage device of the electronic device in other embodiments, such as a plug-in mobile hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. equipped on the electronic device. Further, the memory can also include both the internal storage unit and the external storage device of the electronic device. The memory can be used not only to store application software and various types of data installed in the electronic device, but also to temporarily store data that has been output or will be output.

[0064] The processor can be composed of integrated circuits in some embodiments. For example, it can be composed of a single packaged integrated circuit, or can be composed of multiple integrated circuits with the same or different functions, including a combination of one or more Central Processing Units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The processor is the control core (Control Unit) of the electronic device, connecting various components of the entire electronic device through various interfaces and circuits, and executing various functions of the electronic device and processing data by running or executing programs or modules stored in the memory, and calling data stored in the memory.

[0065] The processor executes the operating system of the electronic device and various installed application programs. The processor executes the application programs to implement the steps in the above-described embodiments of the virtual soldering detection method for lithium power batteries.

[0066] Exemplarily, the computer program may be divided into one or more modules. The one or more modules are stored in the memory and executed by the processor to complete the present invention. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, and these instruction segments are used to describe the execution process of the computer program in the electronic device.

[0067] The above-mentioned integrated unit implemented in the form of a software functional module may be stored in a computer-readable storage medium. The above-mentioned software functional module stored in a storage medium includes several instructions for causing a computer device (which may be a personal computer, a computer device, or a network device, etc.) or a processor to execute some functions of the virtual soldering detection method for lithium batteries in various embodiments of the present invention.

[0068] In summary, the technical effect of the present invention is that by simulating a software test environment, the test does not depend on the hardware and the software implementation of the basic application layer that is not concerned about, and the development of the test environment can be synchronized with the software development of the application layer. At the same time, the functions of the basic software layer are ideally simulated, making the functions of the basic software layer, which are strongly associated with the hardware and complex and originally support the operation of the application layer, become simple, enabling the test to focus on the application layer policy issues and not need to pay attention to the impact of the basic software layer implementation on the application layer. Further, the test process can be iterated quickly within a small stage without the need to re-integrate binary files.

[0069] The above embodiments are only used to exemplarily illustrate the principles and effects of the present invention, rather than to limit the present invention. Any person familiar with this technology can modify or change the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or changes completed by those with ordinary knowledge in the technical field without departing from the spirit and technical idea disclosed by the present invention should still be covered by the claims of the present invention.

Claims

1. A software testing method, characterized in that Including: Obtain the interface file of the RTE layer of the controller software; Preprocess the interface file to obtain an interface target file, and the steps include: screening out the interface files in the interface file that have a dependency relationship with the basic software layer of the controller software and defining them as empty; filling the screened interface file with default values to obtain the interface target file; Obtain the C code of the application layer of the controller software; Create a running file according to the C code, and the steps include: creating an initialization function and a periodic function according to the C code; creating a scheduling function according to the calibration parameters of the software in the controller, and generating the corresponding task file in the running file for the initialization function, periodic function, and scheduling function; configuring non-volatile storage variables according to the calibration parameters of the software in the controller and generating the corresponding storage file in the running file; wherein, the calibration parameters are the parameter conditions for the fixed operation of the software in the controller; Compile and generate a first dynamic link library file according to the interface target file and the running file; Compile the vehicle model corresponding to the controller to generate a second dynamic link library file; Construct a software test model according to the first dynamic link library file and the second dynamic link library file to perform tests based on the software test model.

2. The software testing method according to claim 1, wherein The interface file includes: complex driver layer interface definition file, I / O hardware abstraction layer interface definition file, communication service layer interface definition file, storage service layer interface definition file, OS service layer interface definition file, and application layer SWC interface definition file.

3. The software testing method according to claim 1, characterized in that, The interface target file includes: I / O hardware abstraction layer interface definition file, communication service layer interface definition file, and application layer SWC interface definition file.

4. The software testing method according to claim 1, characterized in that, Obtain the interface file of the RTE layer of the controller software through the Davinci tool.

5. The software testing method according to claim 1, wherein Compile and generate the first dynamic link library file through the "sbsBuild.exe" instruction of Silver; compile and generate the second dynamic link library file through the "SimBuild.dll" component of Silver; and the first dynamic link library file and the second dynamic link library file generate the software test model in the Silver environment.

6. A software testing system, characterized in that, Including: Interface file extraction module, used to obtain the interface file of the RTE layer of the controller software; Interface file processing module, used to preprocess the interface file to obtain an interface target file, and the steps include: screening out the interface files in the interface file that have a dependency relationship with the basic software layer of the controller software and defining them as empty; filling the screened interface file with default values to obtain the interface target file; C code extraction module, used to obtain the C code of the application layer of the controller software; The running configuration module is used to create a running file according to the C code, and the steps include: creating an initialization function and a periodic function according to the C code; creating a scheduling function according to the calibration parameters of the software in the controller, and generating corresponding task files in the running file for the initialization function, the periodic function, and the scheduling function; configuring non-volatile storage variables according to the calibration parameters of the software in the controller, and generating corresponding storage files in the running file; wherein, the calibration parameters are the parameter conditions for the fixed operation of the software in the controller. The first model generation module is used to compile and generate a first dynamic link library file according to the interface target file and the running file. The second model generation module is used to compile and generate a second dynamic link library file for the vehicle model corresponding to the controller. The third model generation module is used to construct a software test model according to the first dynamic link library file and the second dynamic link library file, so as to perform tests based on the software test model.

7. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer-readable medium, characterized in that, Instructions are stored thereon, and the instructions are loaded and executed by the processor to perform the method according to any one of claims 1 to 5.

Images