HAL layer test method, device, computer program product and system

Abstract

The invention provides an HAL layer testing method, device, computer program product and system, and the method comprises the steps: obtaining a first testing instruction in response to an input operation of the first testing instruction, the first testing instruction comprising an interface identifier of a first target API interface of a tested system HAL layer and a testing parameter of the first target API interface; according to the interface identifier, determining a calling path of the first target API interface; the first target API interface is called according to the calling path and the test parameters, so that the first target API interface executes a first operation based on the test parameters, and the first operation is matched with a function operation corresponding to the first target API interface. The operation result of the first operation represents the function test result of the first target API interface. According to the application, efficient and flexible testing of the HAL layer can be realized, and the test maintainability and expandability are improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a HAL layer testing method, device, computer program product and system. Background Art

[0002] In modern computer systems, there are usually multiple hardware components and corresponding software interfaces. The system uses the HAL layer (hardware abstraction layer) to realize the interaction between hardware and upper-level applications. The HAL layer provides a standardized API interface (application programming interface), so that upper-level applications do not need to deal directly with the underlying hardware, but instead perform various functional operations by calling these API interfaces. The correctness of the HAL layer is directly related to whether the upper-level applications can normally access and control the underlying hardware, which in turn affects the performance and user experience of the entire system. Therefore, comprehensive and effective testing of the HAL layer is a key link in ensuring system quality.

[0003] However, the testing methods for the HAL layer in the prior art are often inefficient and difficult to meet the requirements of rapid iteration and flexible response to market demand. For example, the existing patent CN201210478051 proposes a testing scheme, which controls the code source file to generate a test program that can be directly executed under the Android system by setting a source code file and a corresponding configuration file for generating a test program in the Android source code, and the test program can call the API interface in the HAL layer shared library corresponding to the hardware device in a preset manner for testing. Although this method can realize the functional testing of the HAL layer, there are still some significant problems in practical applications. Specifically, since the test code is embedded in the Android source code of the tested system, it is necessary to compile it together with the Android source code of the tested system, resulting in each function change requiring R&D personnel to modify the code and recompile, thereby spending a lot of time, not only reducing the efficiency of the test, but also increasing the R&D cost and time investment, and failing to meet the efficient and flexible development and testing requirements. Summary of the invention

[0004] In view of this, the embodiments of the present application are committed to providing a HAL layer testing method, device, computer program product and system, which can realize efficient and flexible testing of the HAL layer and improve test maintainability and scalability.

[0005] According to a first aspect of an embodiment of the present application, a HAL layer testing method is provided, including:

[0006] In response to an input operation of a first test instruction, acquiring the first test instruction, wherein the first test instruction includes an interface identifier of a first target API interface of a HAL layer of a system under test and a test parameter of the first target API interface;

[0007] Determine, according to the interface identifier, a calling path of the first target API interface;

[0008] According to the calling path and the test parameters, the first target API interface is called so that the first target API interface performs a first operation based on the test parameters, the first operation matches the functional operation corresponding to the first target API interface, and the operation result of the first operation represents the functional test result of the first target API interface.

[0009] Optionally, determining the calling path of the first target API interface according to the interface identifier includes:

[0010] The calling path of the first target API interface is determined according to the interface identifier and a preset first mapping relationship, wherein the first mapping relationship represents the corresponding relationship between the interface identifier of the API interface and the calling path of the API interface.

[0011] Optionally, the method further includes:

[0012] A pre-stored test script is run so that the test script performs an input operation on the first test instruction according to a preset input strategy, and the test script includes at least one test instruction.

[0013] Optionally, the method is applied to a HAL layer test system, and the HAL layer test system includes a plurality of execution submodules;

[0014] The first test instruction also includes a module identifier of a target execution submodule;

[0015] The determining, according to the interface identifier, a calling path of the first target API interface; and calling the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters, includes:

[0016] Determining the target execution submodule according to the module identifier;

[0017] The first test instruction is sent to the target execution submodule, and the target execution submodule determines the calling path of the first target API interface according to the interface identifier, and calls the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters.

[0018] Optionally, the method further includes:

[0019] Sending a first analog signal to the system under test, so that the system under test performs a second operation after receiving the first analog signal, wherein the first analog signal is used to simulate a trigger signal of a first event;

[0020] The performing of the second operation comprises:

[0021] Generate a calling instruction according to the first simulation signal and a preset calling instruction generation strategy, wherein the calling instruction includes an interface identifier of a second target API interface and execution parameters of the second target API interface;

[0022] The second target API interface is called according to the calling instruction so that the second target API interface performs a second operation based on the execution parameters, the second operation matches the functional operation corresponding to the second target API interface, and the operation result of the second operation represents the functional test result of the second target API.

[0023] According to a second aspect of an embodiment of the present application, a HAL layer testing device is provided, including:

[0024] A first unit is configured to obtain, in response to an input operation on a first test instruction, the first test instruction including an interface identifier of a first target API interface of a HAL layer of a system under test and a test parameter of the first target API interface;

[0025] A second unit is used to determine a calling path of the first target API interface according to the interface identifier;

[0026] The third unit is used to call the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters, the first operation matches the functional operation corresponding to the first target API interface, and the operation result of the first operation represents the functional test result of the first target API interface.

[0027] According to a third aspect of an embodiment of the present application, a computer program product is provided, comprising computer program instructions, which, when executed by a processor, enable the processor to implement the HAL layer testing method as described in any one of the first aspects of the embodiments of the present application.

[0028] According to a fourth aspect of an embodiment of the present application, a HAL layer testing system is provided, comprising: an input module and an execution module, wherein the execution module is respectively connected to the input module and the HAL layer of the system under test in communication;

[0029] The input module is used to obtain the first test instruction in response to an input operation on the first test instruction, and send the first test instruction to the execution module, wherein the first test instruction includes an interface identifier of a first target API interface of a HAL layer of the tested system and a test parameter of the first target API interface;

[0030] The execution module is used to determine the calling path of the first target API interface according to the interface identifier, and to call the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters; wherein the first operation matches the functional operation corresponding to the first target API interface, and the operation result of the first operation represents the functional test result of the first target API.

[0031] Optionally, the execution module is integrated into the system under test.

[0032] Optionally, the system further includes:

[0033] The script execution module is used to run a pre-stored test script so that the test script executes an input operation on the first test instruction according to a preset input strategy, and the test script includes at least one test instruction.

[0034] Optionally, the system further includes:

[0035] an analog signal sending module, configured to send a first analog signal to the system under test, so that the system under test performs a second operation after receiving the first analog signal, wherein the first analog signal is used to simulate a trigger signal of a first event;

[0036] The performing of the second operation comprises:

[0037] Generate a calling instruction according to the first simulation signal and a preset calling instruction generation strategy, wherein the calling instruction includes an interface identifier of a second target API interface and parameters to be executed of the second target API interface;

[0038] The second target API interface is called according to the calling instruction, so that the second target API interface performs a second operation based on the parameters to be executed, and the operation result of the second operation represents the functional test result of the second target API.

[0039] The HAL layer testing method provided in the embodiment of the present application first responds to the input operation of the first test instruction, dynamically obtains the first test instruction including the first target API interface identifier and test parameters; then, determines the calling path of the first target API interface according to the interface identifier; finally, according to the calling path and the test parameters, calls the first target API interface to perform the corresponding functional operation, and characterizes the functional test result of the first target API interface through the operation result.

[0040] The HAL layer testing method provided in the embodiment of the present application, through a test instruction input mechanism, makes the test instruction independent of the source code of the system being tested, avoids the close coupling of the test code and the source code of the system being tested, and makes the testing process more independent and flexible. When the function of the system being tested changes or the hardware is upgraded, there is no need to make a large number of modifications and recompiles to the test code, only the test instructions need to be updated, which greatly improves the testing efficiency, reduces the R&D cost, and enables the testing process to better adapt to rapid iterations and changes in market demand. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0042] Figure 1 A schematic diagram of the structure of a HAL layer testing system provided in an embodiment of the present application.

[0043] Figure 2 A flowchart of a HAL layer testing method provided in an embodiment of the present application.

[0044] Figure 3 A flowchart of another HAL layer testing method provided in an embodiment of the present application.

[0045] Figure 4 A flowchart of another HAL layer testing method provided in an embodiment of the present application.

[0046] Figure 5 A schematic diagram of the structure of a HAL layer testing device provided in an embodiment of the present application.

[0047] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] The technical solution of the embodiment of the present application is applicable to various scenarios where the HAL layer needs to be tested, and is applicable to various fields such as mobile communications, smart homes, the Internet of Things, and automotive electronics. In the application scenario, the tester needs to perform functional verification and performance testing on the HAL layer of the system to ensure that the upper-layer application can access and control the underlying hardware normally. The technical solution of the embodiment of the present application can make the testing process of the HAL layer independent of the source code of the system being tested, improve testing efficiency and flexibility, reduce R&D costs, and better adapt to rapid iterations and changes in market demand.

[0049] The technical solution provided in the embodiments of the present application can be exemplarily applied to hardware devices such as processors, electronic devices, servers (including cloud servers), or packaged into software programs to be run. When the hardware device executes the processing of the technical solution of the embodiments of the present application, or the above-mentioned software program is run, the automatic splitting of the target task and the automatic calling of the application program interface required for the task can be achieved to complete the purpose of the target task. The embodiments of the present application only exemplarily introduce the specific processing of the technical solution of the present application, and do not limit the specific implementation form of the technical solution of the present application. Any technical implementation form that can execute the processing of the technical solution of the present application can be adopted by the embodiments of the present application.

[0050] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0051] Before introducing this application solution, the relevant technologies are first introduced:

[0052] In modern computer systems, there are usually multiple hardware components and corresponding software interfaces. The system uses the HAL layer (hardware abstraction layer) to realize the interaction between hardware and upper-level applications. The HAL layer provides a standardized API interface (application programming interface), so that upper-level applications do not need to deal directly with the underlying hardware, but instead perform various functional operations by calling these API interfaces. The correctness of the HAL layer is directly related to whether the upper-level applications can normally access and control the underlying hardware, which in turn affects the performance and user experience of the entire system. Therefore, comprehensive and effective testing of the HAL layer is a key link in ensuring system quality.

[0053] However, the testing methods for the HAL layer in the prior art are often inefficient and difficult to meet the requirements of rapid iteration and flexible response to market demand. For example, the existing patent CN201210478051 proposes a testing scheme, which controls the code source file to generate a test program that can be directly executed under the Android system by setting a source code file and a corresponding configuration file for generating a test program in the Android source code, and the test program can call the API interface in the HAL layer shared library corresponding to the hardware device in a preset manner for testing. Although this method can realize the functional testing of the HAL layer, there are still some significant problems in practical applications. Specifically, since the test code is embedded in the Android source code of the tested system, it is necessary to compile it together with the Android source code of the tested system, resulting in each function change requiring R&D personnel to modify the code and recompile, thereby spending a lot of time, not only reducing the efficiency of the test, but also increasing the R&D cost and time investment, and failing to meet the efficient and flexible development and testing requirements.

[0054] In view of this, the embodiments of the present application are committed to providing a HAL layer testing method, device, computer program product and system, which can realize efficient and flexible testing of the HAL layer, improve test maintainability and scalability, and are described in detail one by one in the following embodiments.

[0055] Exemplary Systems

[0056] For ease of understanding, the implementation environment of the HAL layer testing method provided in the embodiment of the present application is first introduced exemplarily. Figure 1 , Figure 1 This is a schematic diagram of the structure of a HAL layer testing system provided in an embodiment of the present application. The HAL layer testing method provided in the present application can be exemplarily applied to the HAL layer testing system.

[0057] like Figure 1 As shown, the HAL layer test system includes an input module 110 and an execution module 120, wherein the execution module 120 is respectively connected to the input module 110 and the HAL layer of the system under test for communication.

[0058] The system under test can be understood as the target system that needs to perform HAL layer testing. The system can be any system that includes a hardware abstraction layer (HAL), for example, a cockpit domain Android system, an in-vehicle information system, a mobile device operating system, an Internet of Things device or other embedded systems, etc. This application does not limit this.

[0059] The system under test includes a hardware abstraction layer (HAL). The HAL layer provides a standardized API interface between the operating system kernel and the hardware, so that upper-level applications do not need to interact directly with the underlying hardware, but instead control and operate the hardware by calling the API interface of the HAL layer. The API interface of the HAL layer covers various functions of the hardware, such as sensor data reading, device control, communication interface, display interface, audio interface, etc.

[0060] For example, the system under test is the cockpit domain Android system, which is the core part of the in-vehicle infotainment system and is responsible for providing functions such as navigation, audio playback, and telephone communication. Through the HAL layer, the Android system can interact with various hardware components of the vehicle, such as the touch screen, audio amplifier, GPS module, etc.

[0061] The purpose of HAL layer testing is to verify whether the API interface of the HAL layer of the tested system works as expected, and whether the functions provided by these interfaces are stable and reliable. By calling the target API interface of the HAL layer of the tested system, the HAL layer testing system can trigger the tested system to perform specific operations. Based on the operation results of the operation, it can be verified whether its functions meet the design requirements and whether it can meet the needs of the upper-level software.

[0062] The input module 110 is used to obtain the first test instruction in response to an input operation on the first test instruction, and send the first test instruction to the execution module. The first test instruction includes an interface identifier of the first target API interface of the HAL layer of the tested system and test parameters of the first target API interface.

[0063] Specifically, the input module 110 can receive the user's test instructions through a graphical user interface (GUI), a command line interface (CLI) or a remote interface (such as a REST API). The user can input the test instructions through the input module 110, specifying the target API interface to be tested and the test parameters passed to the target API interface. After the input module 110 obtains the test instructions, it sends them to the execution module 120.

[0064] The execution module 120 is used to determine the calling path of the first target API interface according to the interface identifier, and to call the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters; wherein the first operation matches the functional operation corresponding to the first target API interface, and the operation result of the first operation represents the functional test result of the first target API.

[0065] Specifically, the execution module 120 parses the test instruction received from the input module 110, identifies the interface identifier of the target API interface, and searches for the corresponding call path based on the interface identifier, and then dynamically loads and calls the target API interface according to the call path and the test parameters to perform the corresponding functional operation. The operation result of the functional operation may include one or more of the return value, status code, log information, etc., which can be used to evaluate the functional correctness and performance of the target API interface.

[0066] The execution module 120 may be a dedicated test framework, a script engine, or any module capable of parsing test instructions and calling corresponding API interfaces, etc., and this application does not limit this.

[0067] Optionally, the execution module 120 is implemented based on a pipeline program, an executable file, a scripting language interpreter, or a custom call engine, etc. These implementations can support the execution module 120 to parse the test instructions, identify the interface identifier of the target API interface, find the call path, and dynamically load and call the target API interface according to the call path and test parameters to perform corresponding functional operations.

[0068] The specific contents executed by the input module 110 and the execution module 120 will be described in the corresponding parts of the subsequent method embodiments. Please refer to the contents of the subsequent method embodiments and no detailed description will be given here.

[0069] The communication connection can be any communication method that can realize data transmission between devices or systems, such as a wired connection (such as Ethernet, USB, etc.), a wireless connection (such as Wi-Fi, Bluetooth, etc.), a serial communication interface (such as UART) or other suitable communication protocols, etc., and this application does not limit this.

[0070] As an optional implementation, the input module 110 is connected to the execution module 120 via ADB (Android Debug Bridge). ADB is a general command line tool that allows developers to communicate with Android devices and supports the installation and debugging of applications. Through ADB, the input module can easily send test instructions to the execution module and receive test result feedback.

[0071] The execution module 120 may run independently of the system under test, or may be integrated into the system under test, which is not limited in the present application.

[0072] When the execution module 120 is used as an independent test tool, it can communicate with the HAL layer of the tested system through an external interface. This optional method is highly flexible and does not require modifying the source code of the tested system, and is applicable to a variety of different test scenarios.

[0073] When the execution module 120 is integrated into the system under test as a component inside the system under test, the API interface of the HAL layer can be directly called without external communication. This optional method can cooperate more closely with the HAL layer of the system under test, reducing external dependence and configuration complexity. At the same time, since the execution module 120 is closely integrated with the system under test, the state changes of the system under test can be obtained in real time, and the test process can be dynamically adjusted.

[0074] Furthermore, the execution module 120 may be integrated in the system under test in an embedded manner or in a non-embedded manner.

[0075] As an optional implementation, the execution module 120 is embedded and integrated in the system under test. In this implementation, the source code of the execution module 120 is included in the version control system together with the source code of the system under test, and compiled through a unified build process, and the compiled executable file is embedded in the final system image. During the flashing process, the system image containing the execution module is written to the storage medium of the target device. The execution module 120 is usually placed in a specific directory of the target device (such as / vendor / bin / hw / ) to facilitate subsequent calls and executions. After the target device is started, the execution module can communicate directly with the HAL layer of the system under test. It can perform various test tasks by calling the API interface provided by the HAL layer.

[0076] As an optional implementation manner, the HAL layer testing system further includes a script execution module 130 .

[0077] The script execution module 130 is used to run a pre-stored test script so that the test script executes the input operation of the first test instruction according to a preset input strategy, and the test script includes at least one test instruction.

[0078] The main function of the script execution module 130 is to automatically generate and send a series of test instructions to the input module 110 by running a pre-stored test script. The test script is written in advance and contains a series of test instructions for testing the HAL layer API interface. These instructions are arranged according to a specific logic and sequence to simulate different user operation scenarios of the HAL layer. In this implementation, the user does not need to manually enter each test instruction, but can automatically complete this process by running the test script, which significantly improves the test efficiency and ensures the consistency and repeatability of the test.

[0079] The specific content executed by the script execution module 130 will be described in the corresponding part of the subsequent method embodiment. Please refer to the content of the subsequent method embodiment, and no detailed description will be given here.

[0080] As an optional implementation manner, the HAL layer testing system further includes a simulation signal sending module 140 .

[0081] The analog signal sending module 140 is used to send a first analog signal to the system under test, so that the system under test performs a second operation after receiving the first analog signal, wherein the first analog signal is used to simulate a trigger signal of a first event;

[0082] The performing of the second operation comprises:

[0083] A calling instruction is generated according to the first simulation signal and a preset calling instruction generation strategy, wherein the calling instruction includes an interface identifier of a second target API interface and parameters to be executed of the second target API interface; the second target API interface is called according to the calling instruction, so that the second target API interface performs a second operation based on the parameters to be executed, and the operation result of the second operation represents a functional test result of the second target API.

[0084] The analog signal sending module 140 can be an independent software module, responsible for generating and sending the first analog signal; it can also be a functional component integrated in the test framework, working in conjunction with other test components; it can also be a software interface of a hardware device or a hardware simulator, which sends the first analog signal to the system under test through hardware. This application does not limit this, and the specific implementation method can be flexibly selected according to the test requirements and system architecture.

[0085] The specific content executed by the analog signal sending module 140 will be described in the corresponding part of the subsequent method embodiment. Please refer to the content of the subsequent method embodiment, and no detailed description will be given here.

[0086] Exemplary Methods

[0087] Figure 2 A flow chart of a HAL layer testing method provided in an embodiment of the present application. Figure 2 As shown, the HAL layer test method can be exemplarily applied to Figure 1 The HAL layer test system in the embodiment of the present invention comprises steps S201-S203:

[0088] S201. In response to an input operation on a first test instruction, obtain the first test instruction, where the first test instruction includes an interface identifier of a first target API interface of a HAL layer of a system under test and test parameters of the first target API interface.

[0089] The first test instruction can be understood as an instruction input by a user or a test script to test a specific API interface (first target API interface) of the HAL layer, which is used to trigger the test of the first target API interface.

[0090] For example, when testing an API interface for obtaining sensor data, the first test instruction may include the name (such as "getSensorData") or code (such as "ID1") of the API interface, and also include parameters that need to be passed to the API interface (such as sensor type, data acquisition frequency, etc.).

[0091] The interface identifier of the first target API interface can be understood as information used to uniquely identify the first target API interface in the HAL layer, and the interface identifiers of each API interface are used to distinguish different API interfaces.

[0092] The test parameters can be understood as parameters that need to be passed to the first target API interface when testing the first target API interface, which are used to simulate input in actual usage scenarios and configure the behavior of the first target API interface. For example, for an API interface that obtains sensor data, the test parameters may include the sensor type (such as accelerometer, gyroscope, etc.) and the data acquisition frequency (such as acquiring data once per second).

[0093] The input operation may be understood as an operation performed by a user in some manner (such as keyboard input, mouse click, screen touch, etc.) or automatically performed by a test script, and is used to trigger the acquisition of the first test instruction.

[0094] Exemplarily, the user clicks a button on a graphical user interface (GUI), and the button is designed to trigger the acquisition of the first test instruction. Exemplarily, the user enters a specific string of commands through a command line interface (CLI), and the string of commands includes all necessary information of the first test instruction, such as the name of the API interface, test parameters, etc.

[0095] Specifically, the system (such as Figure 1 The input module 110 in the system continuously monitors the user's input operation or the execution of the test script. When the user inputs the first test instruction through the GUI, CLI or other means, or the test script automatically executes to the part containing the first test instruction, the system responds to the input operation and obtains the first test instruction.

[0096] Optionally, the system responds to an input operation of the first test instruction and obtains the first test instruction, including: parsing the input operation and extracting the first test instruction. The first test instruction may exist in the form of a string, a structure or other data, and the system needs to parse it into a format that can be used in subsequent steps.

[0097] S202: Determine a calling path of the first target API interface according to the interface identifier.

[0098] The call path can be understood as a sequence of classes, methods or functions that need to be passed through in order to call a certain API interface in the actual code, which describes the specific execution path to the first target API interface. For example, for an audio playback interface, the call path may point to a specific function in a shared library (such as a .so file), such as libaudio.so:play_audio(), indicating that the play_audio function in the libaudio.so library needs to be called.

[0099] Determining the correct calling path is a prerequisite for calling the first target API interface. If the calling path is wrong, then even if the test parameters are correct, the first target API interface cannot be successfully called, and effective functional testing cannot be performed.

[0100] Specifically, after obtaining the first test instruction, the system needs to search for the calling path corresponding to the first target API interface in the system configuration or a predefined mapping table (such as the code library or API document of the HAL layer) according to the interface identifier of the first target API to determine how to correctly call the first target API interface.

[0101] As an optional implementation, step S202 "determining the calling path of the first target API interface according to the interface identifier" includes:

[0102] The calling path of the first target API interface is determined according to the interface identifier and a preset first mapping relationship, wherein the first mapping relationship represents the corresponding relationship between the interface identifier of the API interface and the calling path of the API interface.

[0103] The first mapping relationship can be understood as a predefined data structure or rule, which represents the corresponding relationship between the interface identifier of the API interface and the calling path of the API interface.

[0104] Optionally, the first mapping relationship may be hard-coded, such as a mapping table pre-stored in a configuration file, database or code, recording the interface identifier of each API interface and its corresponding call path. Optionally, the mapping table may exist in the form of a key-value pair, where the key is the interface identifier and the value is the corresponding call path.

[0105] Specifically, after obtaining the first test instruction, the interface identifier of the first target API in the first test instruction is used as a key to query the first mapping relationship (i.e., the mapping table). The key that matches the interface identifier of the first target API can be found in the mapping table, and then the value corresponding to the key is obtained, i.e., the calling path of the first target API interface.

[0106] In this implementation, through the preset first mapping relationship, the system can quickly determine the calling path and reduce the time of manual search; when the calling path of the API interface changes, only the corresponding item in the mapping table needs to be updated without modifying other parts of the test code; in addition, the use of the mapping relationship can ensure that the test code always calls the correct API interface, avoiding test failures due to incorrect calling path.

[0107] S203. Call the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters, the first operation matches the functional operation corresponding to the first target API interface, and the operation result of the first operation represents the functional test result of the first target API interface.

[0108] The functional operation corresponding to the first target API interface can be understood as the specific function or behavior that the interface is expected to implement when it is designed. For example, the first target API interface is "AudioManager.playSound(filePath)", and its corresponding functional operation is to play the audio file in the specified path.

[0109] The first operation matches the functional operation corresponding to the first target API interface, which can be understood as that when executing the test, the operation actually triggered by the calling path of the first target API interface is consistent with the functional operation when the API interface is designed in terms of behavioral properties. For example, if the first target API interface is used to play an audio file, then the first operation may be to play the specified audio file. The difference is that the first operation is determined based on the specific test parameters in the first test instruction. For example, in the test of "AudioManager.playSound(filePath)", the first operation is specifically to play an audio file under a specific path (i.e., the path provided in the test parameters), rather than any audio file. This specific path is carefully selected during the test to verify the API interface function, and may contain special characters, unconventional file locations, or audio files in a specific format to comprehensively test the robustness and compatibility of the API interface.

[0110] Further, the operation result of the first operation is the direct output of the first target API interface executing the functional operation corresponding to the interface based on the specific test parameters after receiving the specific test parameters. By analyzing the operation result of the first operation, it can be determined whether the first target API interface performs the functional operation as expected and whether the result of the execution meets expectations. If the operation result of the first operation is consistent with expectations, it means that the function of the first target API interface is normal. If the operation result of the first operation is inconsistent with expectations, it means that the first target API interface may have functional defects or problems. Taking the first target API interface as "AudioManager.playSound(filePath)" as an example, a file path containing special characters may be provided as a test parameter during the test, and then the first target API interface is called to perform the first operation (i.e., play the audio file under the path). If the audio file can be successfully played and there is no abnormality during the playback process (such as freeze, skipping, silence, etc.), then the operation result of the first operation indicates that the function of the API interface when processing special character file paths is normal. On the contrary, if there is any abnormality during the playback process, then the operation result reveals that the API interface may have functional defects or problems when processing such file paths.

[0111] Specifically, in step S203, according to the calling path of the first target API interface, the system can locate the specific location of the first target API interface, and according to the instructions of the calling path, the first target API interface can be called. During the calling process, the system passes the test parameters to the first target API interface as the input for the first target API interface to perform the first operation. After receiving the test parameters, the first target API interface performs the corresponding operation, i.e., the first operation, according to its definition and functional logic. After the first operation is executed, an operation result will be generated. The operation result is the direct output of the execution of the first target API interface function and is also a key indicator of the functional test. By analyzing the operation result, it can be determined whether the function of the first target API interface is normal in this test.

[0112] The HAL layer testing method provided in the embodiment of the present application first responds to the input operation of the first test instruction, dynamically obtains the first test instruction including the first target API interface identifier and test parameters; then, determines the calling path of the first target API interface according to the interface identifier; finally, according to the calling path and the test parameters, calls the first target API interface to perform the corresponding functional operation, and characterizes the functional test result of the first target API interface through the operation result.

[0113] The HAL layer testing method provided by the embodiment of the present application makes the test instruction independent of the source code of the tested system through the test instruction input mechanism, thereby avoiding the close coupling of the test code with the source code of the tested system. Specifically, the test instruction contains all the information required for the test, such as the identification of the target API interface, test parameters, etc., which are independent of the source code of the tested system. When the source code of the tested system changes, such as the implementation method of the API interface, the parameter type or the return value changes, as long as these changes do not change the external interface specification of the API interface (such as the interface name, the order of parameters and the basic type, etc.), the test instruction does not need to be adjusted, and the tester only needs to ensure that the new system source code can still correctly respond to the original test instruction; if the change of the system source code does affect the external interface specification of the API interface, then what needs to be done is only to update the relevant information in the test instruction, such as modifying the interface identification, adjusting the test parameters, etc., without modifying the logic of the test code, and the impact of this change is limited to the test instruction level, without affecting the test code itself, thereby maintaining the independence and stability of the test code. Based on the above content, the HAL layer testing method provided in the embodiment of the present application does not require a large amount of modification and recompilation of the test code when the function of the tested system changes or the hardware is upgraded. It only requires a simple update of the test instructions, which greatly shortens the test preparation time, improves the test efficiency, reduces the R&D cost, and makes the test process more independent, flexible and adaptable, and can better adapt to rapid iterations and changes in market demand.

[0114] As an optional implementation manner, the method is applied to a HAL layer test system, and the HAL layer test system includes multiple execution submodules; the first test instruction also includes a module identifier of a target execution submodule.

[0115] In this implementation, step S202 and step S203 of "determining the calling path of the first target API interface according to the interface identifier; and calling the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters" include steps A1-A2:

[0116] A1. Determine the target execution submodule according to the module identifier.

[0117] A2. Send the first test instruction to the target execution submodule, and the target execution submodule determines the calling path of the first target API interface according to the interface identifier, and calls the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters.

[0118] The execution submodule can be understood as an independent unit in the HAL layer test system, which is responsible for processing specific types of tasks or managing the functional testing of specific hardware components. Different execution submodules are responsible for testing different API interfaces or specific functions in the HAL layer.

[0119] Exemplarily, the system under test is a cockpit domain Android system, and the system under test includes a first execution submodule, a second execution submodule and a third execution submodule, wherein the first execution submodule is implemented based on the McuApiTest executable file, the second execution submodule is implemented based on the McuClient executable file, and the third execution submodule is implemented based on the McuUnClient executable file. The McuApiTest executable file tests the McuHal->MCU data sending interface, and the McuClient and McuUnClient executable files test the MCU->McuHal data sending interface. The above executable files are all placed in the / vendor / bin / hw / directory and can be called by the input module through ADB.

[0120] Optionally, different execution submodules correspond to different test scenario types, and the test scenario type is determined based on the data transmission direction between the API interface in the HAL layer and the underlying hardware.

[0121] The test scenario types include but are not limited to the following categories: scenarios in which the HAL layer sends data to the hardware, simulating the situation in which the HAL layer interface sends control commands to the hardware in actual applications, such as increasing the volume, adjusting the screen brightness, etc.; scenarios in which the hardware sends data to the HAL layer, simulating the situation in which the hardware continues to send data to the HAL layer interface in actual applications, such as sensor data reporting, status updating, etc.; scenarios in which the hardware is stopped from sending data to the HAL layer, simulating the situation in which the hardware needs to stop sending data to the HAL layer interface in actual applications, such as turning off sensor data reporting, terminating status updating, etc.

[0122] In this implementation, in addition to the interface identifier and test parameters of the first target API interface, the first test instruction also includes a module identifier of the target execution submodule. The module identifier of the target execution submodule can be understood as a unique identifier of the target execution submodule, which is used to distinguish different execution submodules. The module identifier is used to specify which execution submodule processes the first test instruction.

[0123] In step A1, the HAL layer test system determines the target execution submodule from multiple execution submodules according to the module identifier of the target execution submodule in the first test instruction. This process may involve finding the mapping relationship between the module identifier and the execution submodule, or parsing the module identifier and finding the corresponding execution submodule through some mechanism (such as a configuration file, a registry, etc.).

[0124] In step A2, after determining the target execution submodule, the HAL layer test system will send the first test instruction to the target execution submodule. After receiving the first test instruction, the target execution submodule will determine the calling path of the first target API interface based on the interface identifier therein, and call the first target API interface based on the calling path and test parameters to trigger it to execute the first operation.

[0125] In this implementation, the HAL layer test system includes multiple execution sub-modules, each of which has independent functions and responsibilities. By introducing multiple execution sub-modules, the HAL layer test system implements a modular design. Each execution sub-module can be independently developed, tested and maintained, and it is convenient to add, delete or modify execution sub-modules to meet different testing requirements, making the HAL layer test system more flexible and scalable. It improves the adaptability and maintainability of the HAL layer test system and provides a more efficient and convenient solution for HAL layer testing.

[0126] As an optional implementation, Figure 3 As shown, the method further includes step S301:

[0127] S301. Run a pre-stored test script so that the test script performs an input operation on the first test instruction according to a preset input strategy, and the test script includes at least one test instruction.

[0128] The test script can be understood as a pre-written program or script code, and its core purpose is to automatically execute the input of a series of test instructions to verify the function of the HAL layer API interface of the tested system.

[0129] The test script includes at least one test instruction, which is used to trigger the test of the HAL layer API interface of the tested system. Each test instruction corresponds to a call or test operation on a specific API interface.

[0130] The test script can be written by the tester using a specific scripting language (such as Python, Shell, JavaScript, etc.). Optionally, the test script is written based on the API interface specification, test requirements, and expected results. Optionally, the test script is written based on the test case.

[0131] The preset input strategy can be understood as a set of strategies or rules that specify how the test script executes the test instructions, which may include at least one factor such as the execution order, execution conditions, execution time, and execution frequency of the test instructions. When the test script is running, it will follow the input strategy and input the test instructions in the prescribed manner and order.

[0132] Specifically, in this implementation, test scripts are pre-written and stored, and can be called and executed at any time when needed. When testing is required, the HAL layer test system will run the pre-stored test scripts, and the run test scripts will automatically input the test instructions one by one according to the preset input strategy. The input of each test instruction will trigger the test of the corresponding API interface, thereby verifying its function and performance.

[0133] This implementation method, on the one hand, can greatly improve the efficiency of testing by automating the execution of test scripts, especially when a large number of repetitive test tasks need to be performed; on the other hand, the test scripts are executed according to preset rules and strategies, and will not be affected by the subjective factors of the testers during the test process, thereby reducing errors and omissions caused by human factors; on the other hand, the test scripts can be run multiple times, and each run will obtain the same or similar test results, which helps to verify the stability and reliability of the test; on the other hand, the test scripts can be customized and modified according to the test requirements to adapt to different test scenarios and API interfaces.

[0134] In some application scenarios, the system under test needs to interact with external events or signals, and these signals may affect the behavior of different functional modules of the system under test. However, these external events or signals are difficult to directly reproduce or control in the test environment, resulting in the inability to effectively conduct some functional tests. For example, the in-vehicle cockpit entertainment system needs to interact with external hardware through CAN signals, and some test scenarios cannot be tested by the vehicle alone.

[0135] Based on this, as an optional implementation method, such as Figure 4 As shown, the method further includes step S401:

[0136] S401. Send a first simulation signal to the system under test so that the system under test performs a second operation after receiving the first simulation signal, wherein the first simulation signal is used to simulate the trigger signal of the first event, wherein the execution of the second operation includes: generating a calling instruction according to the first simulation signal and a preset calling instruction generation strategy, the calling instruction including an interface identifier of a second target API interface and execution parameters of the second target API interface; calling the second target API interface according to the calling instruction so that the second target API interface performs a second operation based on the execution parameters, the second operation matches the functional operation corresponding to the second target API interface, and the operation result of the second operation represents the functional test result of the second target API.

[0137] The first event can be understood as an external event or condition that actually occurs in a real environment and triggers a specific response of the tested system. For example, the first event is opening a car door, which triggers the in-car entertainment system to adjust the music playback sound (such as lowering the volume).

[0138] The first simulation signal can be understood as an electrical signal or data packet used to simulate a trigger signal generated by the first event in a real environment, and is used to simulate data sent by a hardware device or an external system to verify whether the response of the tested system meets expectations. For example, when the first event is opening a car door, the first simulation signal is an electrical signal or software instruction used to simulate the action or state of the car door opening.

[0139] The call instruction generation strategy can be understood as a preset rule or algorithm for generating a corresponding call instruction according to the received first analog signal. The call instruction generation strategy defines which API interfaces should be called and which parameters should be passed under different analog signals. For example, the software design of the in-vehicle entertainment system may include such a call instruction generation strategy: when the system detects a door opening signal, a call instruction is automatically generated to instruct the music playback module to lower the preset volume.

[0140] The call instruction generated based on the call instruction generation strategy will instruct the specific API interface of the tested system (i.e., the second target API interface) to execute a functional operation (i.e., the second operation) under specific parameters (i.e., the execution parameters of the second target API interface). For example, when the first event simulation signal is used to simulate the action or state of the car door opening, the call instruction indicates "lower the music playback volume by the first volume value", the second target API interface is the "adjust music playback volume interface" or a similarly named interface (the specific name depends on the API design of the system), and the execution parameter is the "volume reduction value" (i.e., the negative value of the first volume value) and possible other necessary parameters (such as the current music playback session ID to ensure that the operation is the correct music playback instance). The first simulation signal simulates the action of the car door opening, triggering the call instruction generation strategy to generate the corresponding call instruction, and finally the system executes the call instruction to call the second target API interface to adjust the music playback volume, thereby realizing the test of the function of the second target API interface in that the car door opening affects the music playback sound.

[0141] Through the above steps, the tested system successfully received and parsed the simulated signal, generated a call instruction according to the signal content and called the corresponding API interface, recorded the operation results and generated a detailed test report. By introducing the simulated signal, the various event triggering conditions in the actual operating environment can be simulated more realistically, thereby ensuring that the test results are more reliable and comprehensive, and providing a reliable test result evaluation. In this optional implementation, the test method not only relies on directly sending test instructions, but also triggers the tested system to perform specific operations through simulated signals (such as CAN signals). This method is particularly suitable for complex systems such as vehicle-mounted cockpit entertainment systems that need to interact with external hardware, and solves the problem that some test scenarios due to external hardware interactions cannot be completed by the tested system alone.

[0142] Exemplary Devices

[0143] Corresponding to the above-mentioned HAL layer testing method, an embodiment of the present application also provides a HAL layer testing device. Figure 5 is a schematic diagram of the structure of a HAL layer testing device provided in an embodiment of the present application, such as Figure 5 As shown, the HAL layer testing device provided in the embodiment of the present application includes:

[0144] The first unit 501 is used to obtain the first test instruction in response to an input operation of the first test instruction, where the first test instruction includes an interface identifier of a first target API interface of a HAL layer of a system under test and a test parameter of the first target API interface;

[0145] The second unit 502 is used to determine the calling path of the first target API interface according to the interface identifier;

[0146] The third unit 503 is used to call the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters, the first operation matches the functional operation corresponding to the first target API interface, and the operation result of the first operation represents the functional test result of the first target API interface.

[0147] The HAL layer testing device provided in the embodiment of the present application, through a test instruction input mechanism, makes the test instructions independent of the source code of the system being tested, thereby avoiding the close coupling of the test code and the source code of the system being tested, making the testing process more independent and flexible. When the function of the system being tested changes or the hardware is upgraded, there is no need to make a large number of modifications and recompiles to the test code, only the test instructions need to be updated, which greatly improves the testing efficiency, reduces the R&D cost, and enables the testing process to better adapt to rapid iterations and changes in market demand.

[0148] Optionally, the second unit 502 may be specifically used for:

[0149] The calling path of the first target API interface is determined according to the interface identifier and a preset first mapping relationship, wherein the first mapping relationship represents the corresponding relationship between the interface identifier of the API interface and the calling path of the API interface.

[0150] Optionally, the device further comprises:

[0151] The fourth unit is used to run a pre-stored test script so that the test script performs an input operation on the first test instruction according to a preset input strategy, and the test script includes at least one test instruction.

[0152] Optionally, the method is applied to a HAL layer test system, and the HAL layer test system includes a plurality of execution submodules;

[0153] The first test instruction also includes a module identifier of a target execution submodule;

[0154] The second unit 502 and the third unit 503 can be specifically used for:

[0155] Determining the target execution submodule according to the module identifier;

[0156] The first test instruction is sent to the target execution submodule, and the target execution submodule determines the calling path of the first target API interface according to the interface identifier, and calls the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters.

[0157] Optionally, the device further comprises:

[0158] A fifth unit is used to send a first simulation signal to the system under test, so that the system under test performs a second operation after receiving the first simulation signal, wherein the first simulation signal is used to simulate a trigger signal of a first event;

[0159] The performing of the second operation comprises:

[0160] A calling instruction is generated according to the first simulation signal and a preset calling instruction generation strategy, wherein the calling instruction includes an interface identifier of a second target API interface and execution parameters of the second target API interface; the second target API interface is called according to the calling instruction, so that the second target API interface performs a second operation based on the execution parameters, the second operation matches a functional operation corresponding to the second target API interface, and the operation result of the second operation represents a functional test result of the second target API.

[0161] The HAL layer testing device provided in this embodiment belongs to the same application concept as the HAL layer testing method provided in the above embodiments of this application, and can execute the HAL layer testing method provided in any of the above embodiments of this application, and has the corresponding functional modules and beneficial effects of executing the HAL layer testing method. For technical details not fully described in this embodiment, please refer to the specific processing content of the HAL layer testing method provided in the above embodiments of this application, and will not be repeated here.

[0162] The functions implemented by the above first unit 501, the second unit 502 and the third unit 503 may be implemented by the same or different processors, respectively, and the embodiment of the present application is not limited thereto.

[0163] It should be understood that the units in the above devices can be implemented in the form of a processor calling software. For example, the device includes a processor, the processor is connected to a memory, and instructions are stored in the memory. The processor calls the instructions stored in the memory to implement any of the above methods or realize the functions of each unit of the device, wherein the processor can be a general-purpose processor, such as a CPU or a microprocessor, etc., and the memory can be a memory in the device or a memory outside the device. Alternatively, the units in the device can be implemented in the form of hardware circuits, and the functions of some or all units can be realized by designing the hardware circuits. The hardware circuit can be understood as one or more processors; for example, in one implementation, the hardware circuit is an ASIC, and the functions of some or all of the above units are realized by designing the logical relationship of the components in the circuit; for another example, in another implementation, the hardware circuit can be implemented by PLD, taking FPGA as an example, which can include a large number of logic gate circuits, and the connection relationship between the logic gate circuits is configured by the configuration file, so as to realize the functions of some or all of the above units. All units of the above devices can be implemented in the form of a processor calling software, or in the form of hardware circuits, or in part by a processor calling software, and the remaining part is implemented in the form of hardware circuits.

[0164] In an embodiment of the present application, a processor is a circuit with the ability to process signals. In one implementation, the processor may be a circuit with the ability to read and run instructions, such as a CPU, a microprocessor, a GPU, or a DSP; in another implementation, the processor may implement certain functions through the logical relationship of a hardware circuit, and the logical relationship of the hardware circuit is fixed or reconfigurable, such as a hardware circuit implemented by an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document to implement the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, DPU, etc.

[0165] It can be seen that each unit in the above device can be one or more processors (or processing circuits) configured to implement the above method, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0166] In addition, all or part of the units in the above device can be integrated together, or can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a SOC. The SOC may include at least one processor for implementing any of the above methods or implementing the functions of each unit of the device. The type of the at least one processor may be different, for example, including a CPU and an FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.

[0167] Exemplary Electronic Devices

[0168] Another embodiment of the present application also provides an electronic device, see Figure 6 As shown, the device includes:

[0169] Memory 200 and processor 210;

[0170] The memory 200 is connected to the processor 210 and is used to store programs;

[0171] The processor 210 is used to implement the HAL layer testing method disclosed in any of the above embodiments by running the program stored in the memory 200.

[0172] Specifically, the electronic device may further include: a bus, a communication interface 220 , an input device 230 and an output device 240 .

[0173] The processor 210, the memory 200, the communication interface 220, the input device 230 and the output device 240 are connected to each other via a bus.

[0174] A bus may include a pathway that transfers information between components of a computer system.

[0175] The processor 210 may be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the scheme of the present invention. It may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0176] The processor 210 may include a main processor, and may also include a baseband chip, a modem, and the like.

[0177] The memory 200 stores a program for executing the technical solution of the present invention, and may also store an operating system and other key services. Specifically, the program may include a program code, and the program code includes a computer operation instruction. More specifically, the memory 200 may include a read-only memory (ROM), other types of static storage devices that can store static information and instructions, a random access memory (RAM), other types of dynamic storage devices that can store information and instructions, a disk storage, a flash, and the like.

[0178] The input device 230 may include a device for receiving data and information input by a user, such as a keyboard, a mouse, a camera, a scanner, a light pen, a voice input device, a touch screen, a pedometer, or a gravity sensor.

[0179] Output device 240 may include devices that allow information to be output to a user, such as a display screen, printer, speaker, etc.

[0180] The communication interface 220 may include any transceiver or the like to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0181] The processor 210 executes the program stored in the memory 200 and calls other devices, which can be used to implement each step of any HAL layer testing method provided in the above embodiments of the present application.

[0182] An embodiment of the present application also proposes a chip, which includes a processor and a data interface. The processor reads and runs a program stored in a memory through the data interface to execute the HAL layer testing method introduced in any of the above embodiments. The specific processing process and its beneficial effects can be found in the above-mentioned embodiment introduction of the HAL layer testing method.

[0183] Exemplary computer program products and storage media

[0184] In addition to the above-mentioned methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the HAL layer testing method according to various embodiments of the present application described in any of the above embodiments of this specification.

[0185] The computer program product may be written in any combination of one or more programming languages ​​to write program codes for performing the operations of the embodiments of the present application, including object-oriented programming languages, such as Java, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0186] In addition, the embodiment of the present application may also be a storage medium on which a computer program is stored. The computer program is executed by a processor to execute the steps of the HAL layer testing method according to various embodiments of the present application described in any of the above embodiments of this specification, and specifically the following steps may be implemented:

[0187] S201, in response to an input operation of a first test instruction, obtaining the first test instruction, where the first test instruction includes an interface identifier of a first target API interface of a HAL layer of a system under test and a test parameter of the first target API interface;

[0188] S202: Determine a calling path of the first target API interface according to the interface identifier;

[0189] S203. Call the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters, the first operation matches the functional operation corresponding to the first target API interface, and the operation result of the first operation represents the functional test result of the first target API interface.

[0190] For the aforementioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0191] It should be noted that each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other. For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0192] The steps in the methods of each embodiment of the present application can be adjusted in order, combined and deleted according to actual needs, and the technical features recorded in each embodiment can be replaced or combined.

[0193] The modules and sub-modules in the devices and terminals in the various embodiments of the present application can be combined, divided and deleted according to actual needs.

[0194] In the several embodiments provided in the present application, it should be understood that the disclosed terminals, devices and methods can be implemented in other ways. For example, the terminal embodiments described above are only schematic, for example, the division of modules or submodules is only a logical function division, and there may be other division methods in actual implementation, for example, multiple submodules or modules can be combined or integrated into another module, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or modules, which can be electrical, mechanical or other forms.

[0195] The modules or submodules described as separate components may or may not be physically separated, and the components of the modules or submodules may or may not be physical modules or submodules, that is, they may be located in one place, or they may be distributed on multiple network modules or submodules. Some or all of the modules or submodules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0196] In addition, each functional module or submodule in each embodiment of the present application may be integrated into one processing module, or each module or submodule may exist physically separately, or two or more modules or submodules may be integrated into one module. The above-mentioned integrated modules or submodules may be implemented in the form of hardware or in the form of software functional modules or submodules.

[0197] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0198] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly by hardware, software units executed by a processor, or a combination of the two. The software units may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0199] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "including a..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0200] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A HAL layer testing method, characterized in that: include: In response to an input operation of a first test instruction, acquiring the first test instruction, wherein the first test instruction includes an interface identifier of a first target API interface of a HAL layer of a system under test and a test parameter of the first target API interface; Determine, according to the interface identifier, a calling path of the first target API interface; According to the calling path and the test parameters, the first target API interface is called so that the first target API interface performs a first operation based on the test parameters, the first operation matches the functional operation corresponding to the first target API interface, and the operation result of the first operation represents the functional test result of the first target API interface.

2. The method according to claim 1, characterized in that The step of determining the calling path of the first target API interface according to the interface identifier includes: The calling path of the first target API interface is determined according to the interface identifier and a preset first mapping relationship, wherein the first mapping relationship represents the corresponding relationship between the interface identifier of the API interface and the calling path of the API interface.

3. The method according to claim 1, characterized in that The method further comprises: A pre-stored test script is run so that the test script performs an input operation on the first test instruction according to a preset input strategy, and the test script includes at least one test instruction.

4. The method according to claim 1, characterized in that: The method is applied to a HAL layer test system, wherein the HAL layer test system comprises a plurality of execution submodules; The first test instruction also includes a module identifier of a target execution submodule; Determining a calling path of the first target API interface according to the interface identifier; Calling the first target API interface according to the calling path and the test parameter so that the first target API interface performs a first operation based on the test parameter includes: Determining the target execution submodule according to the module identifier; The first test instruction is sent to the target execution submodule, and the target execution submodule determines the calling path of the first target API interface according to the interface identifier, and calls the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: Sending a first analog signal to the system under test, so that the system under test performs a second operation after receiving the first analog signal, wherein the first analog signal is used to simulate a trigger signal of a first event; The performing of the second operation comprises: Generate a calling instruction according to the first simulation signal and a preset calling instruction generation strategy, wherein the calling instruction includes an interface identifier of a second target API interface and execution parameters of the second target API interface; The second target API interface is called according to the calling instruction so that the second target API interface performs a second operation based on the execution parameters, the second operation matches the functional operation corresponding to the second target API interface, and the operation result of the second operation represents the functional test result of the second target API.

6. A HAL layer testing device, characterized in that: include: A first unit is configured to obtain, in response to an input operation of a first test instruction, the first test instruction, wherein the first test instruction includes an interface identifier of a first target API interface of a HAL layer of a system under test and a test parameter of the first target API interface; A second unit is used to determine a calling path of the first target API interface according to the interface identifier; The third unit is used to call the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters, the first operation matches the functional operation corresponding to the first target API interface, and the operation result of the first operation represents the functional test result of the first target API interface.

7. A computer program product, characterized in that The method comprises computer program instructions, which, when executed by a processor, enable the processor to implement the HAL layer testing method according to any one of claims 1 to 5.

8. A HAL layer testing system, characterized in that: include: An input module and an execution module, wherein the execution module is communicatively connected with the input module and the HAL layer of the system under test respectively; The input module is used for obtaining the first test instruction in response to an input operation on the first test instruction, and sending the first test instruction to the execution module, wherein the first test instruction includes an interface identifier of a first target API interface of the HAL layer of the system under test and a test parameter of the first target API interface; The execution module is used to determine the calling path of the first target API interface according to the interface identifier, and to call the first target API interface according to the calling path and the test parameters, so that the first target API interface performs a first operation based on the test parameters; wherein the first operation matches the functional operation corresponding to the first target API interface, and the operation result of the first operation represents the functional test result of the first target API.

9. The system according to claim 8, characterized in that The execution module is integrated in the system under test.

10. The system according to claim 8, characterized in that The system further comprises: The script execution module is used to run a pre-stored test script so that the test script executes an input operation on the first test instruction according to a preset input strategy, and the test script includes at least one test instruction.

11. The system according to claim 8, characterized in that The system further comprises: an analog signal sending module, configured to send a first analog signal to the system under test, so that the system under test performs a second operation after receiving the first analog signal, wherein the first analog signal is used to simulate a trigger signal of a first event; The performing of the second operation comprises: Generate a calling instruction according to the first simulation signal and a preset calling instruction generation strategy, wherein the calling instruction includes an interface identifier of a second target API interface and parameters to be executed of the second target API interface; The second target API interface is called according to the calling instruction, so that the second target API interface performs a second operation based on the parameters to be executed, and the operation result of the second operation represents the functional test result of the second target API.

Images