Automatic test method and device for drive code, electronic equipment and medium

Abstract

The invention discloses an automatic test method and device for a drive code, electronic equipment and a medium. The method comprises the steps of obtaining an abstraction layer drive code, a target global variable and a target reading function of a microcontroller to be tested; executing the test case to execute an operation for realizing at least one target function through an interface function in an abstraction layer driving code of the microcontroller to be tested, the operation including writing a target parameter value for realizing the at least one target function into a target register; based on the target reading function, reading a target parameter value in the target register, and storing the target parameter value to the target global variable; and comparing the expected value corresponding to the target register with the value of the target global variable, and verifying the abstraction layer drive code of the microcontroller to be tested.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an automated testing method, device, electronic device and medium for driver code. Background Art

[0002] As the cornerstone of embedded software architecture, MCAL (Microcontroller Abstraction Layer) driver code directly bears the heavy responsibility of interacting with hardware chips. Due to this feature, it inevitably involves a large number of register accesses and read and write operations of storage media such as FLASH / RAM. In order to ensure the correctness of these underlying interactions, most MCAL functions must be verified through detailed hardware-level inspections. In addition, the various interfaces of MCAL do not exist in isolation, but are interdependent and closely connected. This means that during the testing process, simply verifying a certain module is far from enough, because such testing cannot fully reflect the complex interaction relationship between MCAL interfaces.

[0003] Due to the interdependence of its functions and the close interaction with hardware, the commonly used test solutions in the industry mostly rely on compiler or debugger platforms to verify its functions by compiling and debugging the code on these platforms. However, this testing method often requires testers to manually compile the code and download it to the target device. In order to observe the execution effect of the code, testers must also use input and output (IO) related functions to read and display data through external devices or interfaces. For those functions that need to be verified by observing internal variables, register status or chip addresses, testers can only rely on manual debugging and manual observation. This usually means that they need to manually set breakpoints, single-step code execution, view variable values, and even manually modify registers or memory addresses to simulate different test scenarios.

[0004] Although this testing method can verify the functionality of the MCAL code to a certain extent, the testing process is highly dependent on the skills and experience of the tester, and requires a lot of time and energy for manual operation and observation, which is inefficient and low in accuracy. Summary of the invention

[0005] In view of the above problems, the present application provides an automated testing method, device, electronic device and medium for driver code, so as to realize automated testing of driver code and ensure the efficiency and accuracy of the test. The specific scheme is as follows:

[0006] The first aspect of the present application provides an automated testing method for driver code, comprising:

[0007] Acquire the abstract layer driver code of the microcontroller to be tested, the target global variable and the target read function; the abstract layer driver code of the microcontroller to be tested is used to implement at least one target function of the microcontroller to be tested; the target global variable and the target read function are used to assist in testing the abstract layer driver code of the microcontroller to be tested;

[0008] Executing a test case to perform an operation for implementing at least one target function through an interface function in the abstract layer driver code of the microcontroller under test, wherein the operation includes writing a target parameter value for implementing at least one target function into a target register;

[0009] Based on the target read function, read the target parameter value in the target register, and store the target parameter value in the target global variable;

[0010] The expected value corresponding to the target register is compared with the value of the target global variable, and the abstract layer driver code of the microcontroller to be tested is verified.

[0011] In a possible implementation, obtaining the abstract layer driver code of the microcontroller under test includes:

[0012] Obtain at least one module to be tested in the source driver code of the microcontroller abstraction layer;

[0013] Compiling the at least one module to be tested to obtain a compiled file corresponding to the at least one module to be tested;

[0014] Obtaining a compiled file corresponding to at least one other module from a specified folder; the at least one other module is a module other than the at least one module to be tested in the source program file; the compiled file is a file obtained by pre-compiling the other module;

[0015] The compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module are linked to obtain the abstract layer driver code of the microcontroller to be tested.

[0016] In a possible implementation, linking the compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module includes:

[0017] Modifying the background link command so that the modified background link command includes the path of the specified folder;

[0018] The modified background link command is executed to obtain a compiled file corresponding to at least one other module from the designated folder, and the compiled file corresponding to the at least one module to be tested is linked with the compiled file corresponding to the at least one other module.

[0019] In a possible implementation, before executing the test case to drive the interface function in the code of the microcontroller abstraction layer under test to perform an operation for implementing at least one target function, the method further includes:

[0020] An initialization function is executed to initialize the microcontroller according to the abstract layer driver code of the microcontroller to be tested, so that the microcontroller enters a test state.

[0021] In a possible implementation, before executing the test case to drive the interface function in the code of the microcontroller abstraction layer under test to perform an operation for implementing at least one target function, the method further includes:

[0022] In the macro definition configuration item of the test tool, a target item is set, and the target item is used to enable the test tool to ignore the const modifier of the configuration calibration parameter in the abstract layer driver code of the microcontroller to be tested during processing, so as to allow the value of the configuration calibration parameter in the test case to be the same as or different from the value of the configuration calibration parameter in the abstract layer driver code of the microcontroller to be tested; the const modifier is used to limit the value of the configuration calibration parameter to be unchangeable.

[0023] In another aspect of the present application, an automated testing device for a driver code is provided, comprising:

[0024] An acquisition module is used to acquire the abstract layer driver code of the microcontroller under test, target global variables and target read functions; the abstract layer driver code of the microcontroller under test is used to implement at least one target function of the microcontroller under test; the target global variables and the target read functions are used to assist in testing the abstract layer driver code of the microcontroller under test;

[0025] An execution module, configured to execute a test case to execute an operation for realizing at least one target function through an interface function in the abstract layer driver code of the microcontroller to be tested, wherein the operation includes writing a target parameter value for realizing at least one target function into a target register;

[0026] A reading module, configured to read the target parameter value in the target register based on the target reading function, and store the target parameter value in the target global variable;

[0027] The comparison module is used to compare the expected value corresponding to the target register with the value of the target global variable, and verify the abstract layer driver code of the microcontroller to be tested.

[0028] In a possible implementation, the process of the acquisition module acquiring the abstraction layer driver code of the microcontroller to be tested specifically includes:

[0029] Obtain at least one module to be tested in the source driver code of the microcontroller abstraction layer;

[0030] Compiling the at least one module to be tested to obtain a compiled file corresponding to the at least one module to be tested;

[0031] Obtaining a compiled file corresponding to at least one other module from a specified folder; the at least one other module is a module other than the at least one module to be tested in the source program file; the compiled file is a file obtained by pre-compiling the other module;

[0032] The compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module are linked to obtain the abstract layer driver code of the microcontroller to be tested.

[0033] In a possible implementation, the process of the acquisition module linking the compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module specifically includes:

[0034] Modifying the background link command so that the modified background link command includes the path of the specified folder;

[0035] The modified background link command is executed to obtain a compiled file corresponding to at least one other module from the designated folder, and the compiled file corresponding to the at least one module to be tested is linked with the compiled file corresponding to the at least one other module.

[0036] In a third aspect of the present application, an electronic device is provided, comprising at least one processor and a memory connected to the processor, wherein:

[0037] The memory is used to store computer programs;

[0038] The processor is used to execute the computer program so that the electronic device can implement the automated testing method for the driving code as described in any one of the above items.

[0039] In a fourth aspect of the present application, a computer storage medium is provided, which carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement an automated testing method for a driver code as described in any one of the above.

[0040] In the present application, the microcontroller abstraction layer source driver code is compiled in advance to obtain the compiled files corresponding to each module in the microcontroller abstraction layer source driver code, and the compiled files corresponding to at least one other module in the microcontroller abstraction layer source driver code except at least one module to be tested are saved in a designated folder. During testing, the compiled files in the designated folder can be directly used to ensure that only at least one module to be tested is compiled without losing functions. There is no need to recompile the entire microcontroller abstraction layer source driver code, which saves compilation time and thus saves overall testing time. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.

[0042] Figure 1 A flowchart of an automated testing method for driver code provided in Example 1 of the present application;

[0043] Figure 2 A flowchart of an automated testing method for driver code provided in Example 2 of the present application;

[0044] Figure 3 A flowchart of an automated testing method for driver code provided in Example 3 of the present application;

[0045] Figure 4 A flowchart of an automated testing method for driver code provided in Example 4 of the present application;

[0046] Figure 5 A flowchart of an automated testing method for driver code provided in Example 5 of the present application;

[0047] Figure 6 A schematic diagram of the structure of an automated testing device for driver code provided in this application. DETAILED DESCRIPTION

[0048] The following describes the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation method section of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

[0049] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0050] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, which is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0051] In order to automate the testing of MCAL driver code, you can try to use a highly automated white-box testing tool (such as TESSY). After importing the source code, the white-box testing tool will first perform an in-depth code analysis, which can accurately identify all function interfaces, global variables, formal parameters, and return values ​​in the code. By cleverly controlling global variables and formal parameters, the white-box testing tool can simulate various possible input scenarios, and observe and verify the output by reading global variables and function return values, thereby achieving a comprehensive test of the software functions.

[0052] However, although white-box testing tools perform well in most software testing scenarios, they face the following limitations when testing MCAL (Microcontroller Abstraction Layer) code:

[0053] As a bridge between upper-layer applications and underlying hardware, many functions of MCAL need to verify their correctness by evaluating the values ​​and expected values ​​of specific registers in the microcontroller. However, white-box testing tools cannot directly observe the values ​​of specific registers when evaluating expected values.

[0054] The test cases rely on the configuration code generated by the EB configuration tool, but the configuration code generated by the EB configuration tool defines the relevant configuration information as constants, which are modified by const. Since normal tests cannot modify the constant values ​​modified by const, it is impossible to simulate a variety of different configuration results by modifying the configuration code, and thus it is impossible to achieve the expected test effect. Therefore, the present application provides an automated testing method for driver code to improve the effect of automated testing.

[0055] Next, the present application will be further described in detail with reference to the accompanying drawings and specific implementation methods.

[0056] Reference Figure 1, is a flow chart of an automated testing method for driver code provided in Example 1 of the present application, such as Figure 1 As shown, the method may include but is not limited to the following steps:

[0057] Step S101, obtaining the abstract layer driver code, target global variables and target read functions of the microcontroller to be tested.

[0058] The microcontroller abstraction layer driver code to be tested is used to implement at least one target function of the microcontroller to be tested.

[0059] The microcontroller abstraction layer driver code under test can be part or all of the MCAL driver code.

[0060] The target global variable and the target read function are used to assist in testing the abstract layer driver code of the microcontroller to be tested.

[0061] Step S102, executing the test case to perform an operation for implementing at least one target function through the interface function in the abstract layer driver code of the microcontroller under test, wherein the operation includes writing a target parameter value for implementing at least one target function into a target register.

[0062] In this embodiment, step S102 is described by taking an example, for example, the abstract layer driver code of the microcontroller to be tested is used to control a GPIO (general purpose input output) pin of the microcontroller to be high level (i.e., an implementation method of realizing at least one target function). The test case is executed to modify the value of the GPIO status register to 1 through the interface function in the abstract layer driver code of the microcontroller to be tested (i.e., an implementation method of writing the target parameter value used to realize at least one target function into the target register). The microcontroller can adjust the voltage level of the GPIO pin according to the change of the value of the GPIO status register and set it to a high level (i.e., an implementation method of realizing at least one target function).

[0063] Step S103: Based on the target read function, read the target parameter value in the target register, and store the target parameter value in the target global variable.

[0064] In this embodiment, the type of the target global variable is consistent with the storage type of the data of the target register in the microcontroller.

[0065] The target global variable can be accessed during the entire running period of the test case. Therefore, after the target parameter value is stored in the target global variable, the target parameter value in the target register can be observed at any time.

[0066] Step S104: Compare the expected value corresponding to the target register with the value of the target global variable, and verify the abstract layer driver code of the microcontroller to be tested.

[0067] Include one or more expected values ​​in the test case. One or more expected values ​​can be set based on the expected behavior of the driver code of the microcontroller abstraction layer under test. For example, the driver code of the microcontroller abstraction layer under test is used to control a GPIO (general purpose input and output) pin of the microcontroller to a high level, and the expected value of the GPIO status register should be 1.

[0068] If the expected value corresponding to the target register is equal to the value of the target global variable, it means that the abstract layer driver code of the microcontroller to be tested correctly implements the expected function and the test passes.

[0069] If the expected value corresponding to the target register is not equal to the value of the target global variable, it indicates that there is a problem with the abstract layer driver code of the microcontroller under test and it fails to work as expected, and the abstract layer driver code of the microcontroller under test fails the test.

[0070] In this embodiment, by defining the target global variable and the read function in advance, and after executing the test case through the interface function in the test microcontroller abstract layer driver code, the value in the target register is automatically read into the target global variable with the help of the read function, the problem that test tools such as TESSY cannot directly read the register value can be overcome, and the automatic observation of the value in the register can be realized. By comparing the expected value corresponding to the target register with the value of the target global variable, the test microcontroller abstract layer driver code is verified, and the test microcontroller abstract layer driver code is automatically tested to ensure test efficiency and accuracy.

[0071] As another optional embodiment of the present application, refer to Figure 2 , is a flow chart of an automated testing method for driver code provided in Example 2 of the present application. This embodiment is mainly an implementation method of the above step S101, such as Figure 2 As shown, step S101 may include but is not limited to the following steps:

[0072] Step S1011: obtaining at least one module to be tested in the source driver code of the microcontroller abstraction layer.

[0073] The microcontroller abstraction layer source driver code can be understood as the source code that implements the MCAL function. The microcontroller abstraction layer source driver code may include at least one module (e.g., at least one .C file), each module is responsible for processing a specific hardware function, such as ADC (analog-to-digital conversion), CAN (controller area network), DIO (digital input and output), etc.

[0074] The at least one module to be tested may be at least one module selected from the source driver code of the microcontroller abstraction layer and requiring to be tested.

[0075] Step S1012: compile the at least one module to be tested to obtain a compilation file corresponding to the at least one module to be tested.

[0076] Step S1013, obtaining a compiled file corresponding to at least one other module from a designated folder; the at least one other module is a module other than the at least one module to be tested in the source program file; the compiled file is a file obtained by pre-compiling the other module.

[0077] In this embodiment, the microcontroller abstraction layer source driver code may be compiled in advance to obtain the compiled files (e.g., .o files) corresponding to each module in the microcontroller abstraction layer source driver code. The compiled files corresponding to each module in the microcontroller abstraction layer source driver code may be saved in advance in a designated folder. After determining at least one module to be tested, the compiled files with the same name as each module to be tested in at least one module to be tested may be deleted from the designated folder, and then the compiled files corresponding to at least one other module may be obtained from the designated folder to prevent redefinition during linking, which may lead to compilation failure.

[0078] In this embodiment, after determining at least one module to be tested, only the compiled file corresponding to at least one other module may be saved in a designated folder to ensure that the designated folder does not contain a file with the same name as the at least one module to be tested, thereby preventing compilation failure.

[0079] Step S1014: link the compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module to obtain the abstract layer driver code of the microcontroller to be tested.

[0080] Linking is to combine the compiled file corresponding to the at least one module to be tested, the compiled file corresponding to the at least one other module and the library files that may be needed into an executable file, that is, the abstract layer driver code of the microcontroller to be tested.

[0081] Steps S1011 - S1014 are an implementation method of obtaining the abstract layer driver code of the microcontroller to be tested in step S101 .

[0082] Step S1015: Obtain target global variables and target read functions.

[0083] In this embodiment, by compiling the microcontroller abstraction layer source driver code in advance, the compiled files corresponding to the modules in the microcontroller abstraction layer source driver code are obtained, and the compiled files corresponding to at least one other module in the microcontroller abstraction layer source driver code except at least one module to be tested are saved in a designated folder. During testing, the compiled files in the designated folder can be directly used to ensure that only at least one module to be tested is compiled without losing functions, and there is no need to recompile the entire microcontroller abstraction layer source driver code, thereby saving compilation time and thus saving overall testing time.

[0084] As another optional embodiment of the present application, refer to Figure 3 , is a flow chart of an automated testing method for driver code provided in Example 3 of the present application. This embodiment is mainly an implementation method of the above step S1014, such as Figure 3 As shown, step S1014 may include but is not limited to the following steps:

[0085] Step S10141, modify the background link command so that the modified background link command includes the path of the designated folder.

[0086] In this embodiment, the path of the designated folder may be determined, and the background link command may be modified so that the modified background link command may include the path of the designated folder.

[0087] Step S10142: execute the modified background link command, obtain the compiled file corresponding to at least one other module from the specified folder, and link the compiled file corresponding to the at least one module to be tested with the compiled file corresponding to the at least one other module.

[0088] In this embodiment, by modifying the background link command, the modified background link command can be executed during testing, and the compiled file corresponding to at least one other module can be obtained from the designated folder, and the compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module can be linked, without recompiling the entire microcontroller abstraction layer source driver code, thereby saving compilation time and thus saving overall testing time.

[0089] As another optional embodiment of the present application, refer to Figure 4 , is a flow chart of an automated testing method for driver code provided in Example 4 of the present application, such as Figure 4 As shown, the method may include but is not limited to the following steps:

[0090] Step S201, obtaining the abstract layer driver code, target global variables and target read functions of the microcontroller to be tested.

[0091] The microcontroller abstraction layer driver code to be tested is used to implement at least one target function of the microcontroller to be tested.

[0092] The target global variable and the target read function are used to assist in testing the abstract layer driver code of the microcontroller to be tested;

[0093] The detailed process of step S201 can refer to the relevant introduction of step S101 in embodiment 1, which will not be repeated here.

[0094] Step S202 , executing an initialization function to initialize the microcontroller according to the abstract layer driver code of the microcontroller to be tested, so that the microcontroller enters a test state.

[0095] For example, in the TESSY tool, a timeline may be created, and an initialization function may be dragged into the timeline to execute the initialization function, and the microcontroller may be initialized according to the abstract layer driver code of the microcontroller to be tested, so that the microcontroller enters a test state.

[0096] Initializing the microcontroller may include but is not limited to: configuring registers in the microcontroller, setting interrupt priorities, initializing data buffers, etc.

[0097] Step S203, executing the test case to perform an operation for implementing at least one target function through the interface function in the abstract layer driver code of the microcontroller under test, wherein the operation includes writing a target parameter value for implementing at least one target function into a target register.

[0098] Step S204: Based on the target read function, read the target parameter value in the target register, and store the target parameter value in the target global variable.

[0099] Step S205: Compare the expected value corresponding to the target register with the value of the target global variable, and verify the abstract layer driver code of the microcontroller to be tested.

[0100] The detailed process of steps S203-S205 can refer to the relevant introduction of steps S102-S104 in Example 1, which will not be repeated here.

[0101] In this embodiment, the microcontroller is initialized for the abstract layer driver code of the microcontroller to be tested by executing the initialization function, so that the microcontroller enters the test state, thereby ensuring the stability and accuracy of the test environment and ensuring the accuracy of the test of the abstract layer driver code of the microcontroller to be tested.

[0102] As another optional embodiment of the present application, refer to Figure 5, is a flow chart of an automated testing method for driver code provided in Example 5 of the present application, such as Figure 5 As shown, the method may include but is not limited to the following steps:

[0103] Step S301, obtaining the abstract layer driver code, target global variables and target read functions of the microcontroller to be tested.

[0104] The microcontroller abstraction layer driver code to be tested is used to implement at least one target function of the microcontroller to be tested.

[0105] The target global variable and the target read function are used to assist in testing the abstract layer driver code of the microcontroller to be tested;

[0106] The detailed process of step S301 can refer to the relevant introduction of step S101 in embodiment 1, which will not be repeated here.

[0107] Step S302, in the macro definition configuration item of the test tool, set the target item, wherein the target item is used to enable the test tool to ignore the const modifier of the configuration calibration parameter in the abstract layer driver code of the microcontroller under test during processing, so as to allow the value of the configuration calibration parameter in the test case to be the same as or different from the value of the configuration calibration parameter in the abstract layer driver code of the microcontroller under test.

[0108] The configuration calibration parameters in the abstract layer driver code of the microcontroller to be tested are generally configuration codes generated by the EB configuration tool. In the configuration code generated by the EB configuration tool, the const modifier is used to define the relevant configuration calibration parameters as constants to ensure that these configuration calibration parameters will not be accidentally modified when the software is running.

[0109] The const modifier is used to restrict the value of the configuration scalar parameter to be immutable.

[0110] For example, in the TESSY tool, "const=;" can be set in the macro definition configuration item so that the TESSY tool can ignore the const modifier of the configuration calibration parameter in the abstract layer driver code of the microcontroller under test during the parsing and compilation stages, and allow the value of the configuration calibration parameter to be modified in the test case.

[0111] Step S303, executing the test case to perform an operation for implementing at least one target function through the interface function in the abstract layer driver code of the microcontroller under test, wherein the operation includes writing a target parameter value for implementing at least one target function into a target register.

[0112] Step S304: Based on the target read function, read the target parameter value in the target register, and store the target parameter value in the target global variable.

[0113] Step S305 : Compare the expected value corresponding to the target register with the value of the target global variable, and verify the abstract layer driver code of the microcontroller to be tested.

[0114] The detailed process of steps S303-S305 can refer to the relevant introduction of steps S102-S104 in Example 1, which will not be repeated here.

[0115] In this embodiment, a target item is set in the macro definition configuration item of the test tool. The target item is used to enable the test tool to ignore the const modifier of the configuration calibration parameter in the abstract layer driver code of the microcontroller under test during processing, so as to avoid the influence of the const modifier and make the configuration calibration parameter recognized as an ordinary global variable, so that the value of the configuration calibration parameter can be freely modified by TESSY, thereby simulating different configurations of EB to test different scenarios.

[0116] Next, the automated testing device for the driver code provided by the present application is introduced. The automated testing device for the driver code introduced below and the automated testing method for the driver code introduced above can refer to each other.

[0117] Reference Figure 6 The automated testing device for the driver code includes: an acquisition module 100 , an execution module 200 , a reading module 300 and a comparison module 400 .

[0118] The acquisition module 100 is used to acquire the abstract layer driver code, target global variables and target read function of the microcontroller under test; the abstract layer driver code of the microcontroller under test is used to implement at least one target function of the microcontroller under test; the target global variables and the target read function are used to assist in testing the abstract layer driver code of the microcontroller under test.

[0119] The execution module 200 is used to execute the test case to execute the operation for realizing at least one target function through the interface function in the abstract layer driver code of the microcontroller under test, and the operation includes writing the target parameter value for realizing at least one target function into the target register.

[0120] The reading module 300 is used to read the target parameter value in the target register based on the target reading function, and store the target parameter value in the target global variable.

[0121] The comparison module 400 is used to compare the expected value corresponding to the target register with the value of the target global variable, and verify the abstract layer driver code of the microcontroller under test.

[0122] The process of the acquisition module 100 acquiring the abstract layer driver code of the microcontroller to be tested specifically includes:

[0123] Obtain at least one module to be tested in the source driver code of the microcontroller abstraction layer;

[0124] Compiling the at least one module to be tested to obtain a compiled file corresponding to the at least one module to be tested;

[0125] Obtaining a compiled file corresponding to at least one other module from a specified folder; the at least one other module is a module other than the at least one module to be tested in the source program file; the compiled file is a file obtained by pre-compiling the other module;

[0126] The compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module are linked to obtain the abstract layer driver code of the microcontroller to be tested.

[0127] The process of the acquisition module 100 linking the compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module specifically includes:

[0128] Modifying the background link command so that the modified background link command includes the path of the specified folder;

[0129] The modified background link command is executed to obtain a compiled file corresponding to at least one other module from the designated folder, and the compiled file corresponding to the at least one module to be tested is linked with the compiled file corresponding to the at least one other module.

[0130] The automated testing device for the driver code may also include:

[0131] The initialization module is used to execute the initialization function to initialize the microcontroller according to the abstract layer driver code of the microcontroller to be tested, so that the microcontroller enters the test state.

[0132] The automated testing device for the driver code may also include:

[0133] A setting module is used to set a target item in the macro definition configuration item of the test tool, wherein the target item is used to enable the test tool to ignore the const modifier of the configuration calibration parameter in the abstract layer driver code of the microcontroller to be tested during processing, so as to allow the value of the configuration calibration parameter in the test case to be the same as or different from the value of the configuration calibration parameter in the abstract layer driver code of the microcontroller to be tested; the const modifier is used to limit the value of the configuration calibration parameter to be unchangeable.

[0134] In another embodiment of the present application, an electronic device is provided.

[0135] An electronic device comprising at least one processor and a memory connected to the processor, wherein:

[0136] The memory is used to store computer programs;

[0137] The processor is used to execute the computer program so that the electronic device can implement the automated testing method for the driving code as described in any one of embodiments 1-5.

[0138] In another embodiment of the present application, a computer storage medium is provided, which carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement an automated testing method for a driver code as described in any one of Examples 1-5.

[0139] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0140] Through the description of the above implementation mode, the technicians in the field can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. In general, all functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be various, such as analog circuits, digital circuits or special circuits. However, for the present application, software program implementation is a better implementation mode in more cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, a U disk, a mobile hard disk, a ROM, a RAM, a disk or an optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer, a training device, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0141] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0142] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a training device, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, training device, or data center. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

Claims

1. An automated testing method for driver code, characterized in that: include: Get the abstract layer driver code, target global variables and target read functions of the microcontroller under test; The microcontroller abstraction layer driver code to be tested is used to implement at least one target function of the microcontroller to be tested; The target global variable and the target read function are used to assist in testing the abstract layer driver code of the microcontroller to be tested; Executing a test case to perform an operation for implementing at least one target function through an interface function in the abstract layer driver code of the microcontroller under test, wherein the operation includes writing a target parameter value for implementing at least one target function into a target register; Based on the target read function, read the target parameter value in the target register, and store the target parameter value in the target global variable; The expected value corresponding to the target register is compared with the value of the target global variable, and the abstract layer driver code of the microcontroller to be tested is verified.

2. The automated testing method for driver code according to claim 1, characterized in that: Get the abstract layer driver code of the microcontroller under test, including: Obtain at least one module to be tested in the source driver code of the microcontroller abstraction layer; Compiling the at least one module to be tested to obtain a compiled file corresponding to the at least one module to be tested; Obtaining a compiled file corresponding to at least one other module from a specified folder; the at least one other module is a module other than the at least one module to be tested in the source program file; the compiled file is a file obtained by pre-compiling the other module; The compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module are linked to obtain the abstract layer driver code of the microcontroller to be tested.

3. The automated testing method for driver code according to claim 2, characterized in that: Linking the compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module includes: Modifying the background link command so that the modified background link command includes the path of the specified folder; The modified background link command is executed to obtain a compiled file corresponding to at least one other module from the designated folder, and the compiled file corresponding to the at least one module to be tested is linked with the compiled file corresponding to the at least one other module.

4. The automated testing method for driver code according to claim 1, characterized in that: Executing the test case to drive the interface function in the code of the microcontroller abstraction layer under test to perform an operation for implementing at least one target function also includes: An initialization function is executed to initialize the microcontroller according to the abstract layer driver code of the microcontroller to be tested, so that the microcontroller enters a test state.

5. The automated testing method for driver code according to claim 2, characterized in that: Executing the test case to drive the interface function in the code of the microcontroller abstraction layer under test to perform the operation for implementing at least one target function also includes: In the macro definition configuration item of the test tool, a target item is set, and the target item is used to enable the test tool to ignore the const modifier of the configuration calibration parameter in the abstract layer driver code of the microcontroller to be tested during processing, so as to allow the value of the configuration calibration parameter in the test case to be the same as or different from the value of the configuration calibration parameter in the abstract layer driver code of the microcontroller to be tested; the const modifier is used to limit the value of the configuration calibration parameter to be unchangeable.

6. An automated testing device for driver code, characterized in that: include: An acquisition module is used to acquire the abstract layer driver code, target global variables and target read functions of the microcontroller under test; The microcontroller abstraction layer driver code to be tested is used to implement at least one target function of the microcontroller to be tested; the target global variable and the target read function are used to assist in testing the microcontroller abstraction layer driver code to be tested; An execution module, configured to execute a test case to execute an operation for realizing at least one target function through an interface function in the abstract layer driver code of the microcontroller to be tested, wherein the operation includes writing a target parameter value for realizing at least one target function into a target register; A reading module, configured to read the target parameter value in the target register based on the target reading function, and store the target parameter value in the target global variable; The comparison module is used to compare the expected value corresponding to the target register with the value of the target global variable, and verify the abstract layer driver code of the microcontroller to be tested.

7. The device according to claim 6, characterized in that The process of the acquisition module acquiring the abstract layer driver code of the microcontroller to be tested specifically includes: Obtain at least one module to be tested in the source driver code of the microcontroller abstraction layer; Compiling the at least one module to be tested to obtain a compiled file corresponding to the at least one module to be tested; Obtaining a compiled file corresponding to at least one other module from a specified folder; the at least one other module is a module other than the at least one module to be tested in the source program file; the compiled file is a file obtained by pre-compiling the other module; The compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module are linked to obtain the abstract layer driver code of the microcontroller to be tested.

8. The device according to claim 7, characterized in that The process of the acquisition module linking the compiled file corresponding to the at least one module to be tested and the compiled file corresponding to the at least one other module specifically includes: Modifying the background link command so that the modified background link command includes the path of the specified folder; The modified background link command is executed to obtain a compiled file corresponding to at least one other module from the designated folder, and the compiled file corresponding to the at least one module to be tested is linked with the compiled file corresponding to the at least one other module.

9. An electronic device, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the electronic device can implement the automated testing method for the driving code as described in any one of claims 1 to 5.

10. A computer storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by an electronic device, the electronic device can implement the automated testing method for the driver code as described in any one of claims 1 to 5.

Images