Driver testing method, device and system, electronic device, and storage medium

Abstract

The present disclosure provides a kind of driver test method, device and system, electronic equipment, storage medium, the method comprises: for the test task of the driver of processing equipment in terminal, in the case where test task includes the first test task for testing the hardware event processing function of driver, determine the test instruction corresponding to first test task;Wherein, test instruction is used to simulate the hardware event of processing equipment;According to test instruction, the first test task is executed, and the test result of first test task is obtained. According to the embodiment of the present disclosure, the test efficiency of driver can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a driver testing method, apparatus and system, electronic device and storage medium. Background Technology

[0002] A device driver is a dedicated system software that enables communication, instruction forwarding, and hardware control between the computer's operating system kernel and computer hardware devices (also known as processing devices, such as graphics cards, sound cards, scanners, and cameras). It is a low-level support program. It encapsulates the register operations, communication protocols, and control logic of the processing device, providing a unified interface to the operating system and directly controlling the processing device. Therefore, the normal and stable operation of a device driver is crucial. For this reason, before releasing a device driver, it needs to be tested from multiple aspects, including code, interfaces, hardware event handling, compatibility, and performance. Summary of the Invention

[0003] This disclosure provides a driver testing method, apparatus and system, electronic device, computer-readable storage medium and computer program product.

[0004] In a first aspect, this disclosure provides a driver testing method, which includes: a test task for a driver of a processing device in a terminal; if the test task includes a first test task for testing the hardware event handling function of the driver, determining a test instruction corresponding to the first test task; wherein the test instruction is used to simulate hardware events of the processing device; and executing the first test task according to the test instruction to obtain a test result of the first test task.

[0005] Secondly, this disclosure provides a driver testing apparatus, which includes: a determining module, configured to determine a test instruction corresponding to the first test task when the test task includes a first test task for testing the hardware event handling function of the driver; wherein the test instruction is used to simulate hardware events of the processing device; and a first execution module, configured to execute the first test task according to the test instruction to obtain a test result of the first test task.

[0006] Thirdly, this disclosure provides a driver testing system, which includes: a test scheduling module for scheduling test tasks of drivers for processing devices in a terminal and obtaining scheduling results; and a driver testing device for obtaining test results of the test tasks based on the scheduling results and the aforementioned driver testing method.

[0007] Fourthly, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the driver testing method described above.

[0008] Fifthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described driver testing method.

[0009] In a sixth aspect, this disclosure provides a computer program product comprising computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device executes the driver testing method described above.

[0010] According to the driver testing method of this disclosure, for the testing task of a driver for a processing device in a terminal, when the testing task includes a first test task for testing the hardware event handling function of the driver, a test instruction corresponding to the first test task is determined. The test instruction is used to simulate hardware events of the processing device. Then, the first test task is executed according to the test instruction to obtain the test result of the first test task. Thus, when testing the hardware event handling function of the driver for the processing device, the test instruction can be used to simulate hardware events for the processing device, converting the physical operations that need to be manually performed into test instructions. This not only simplifies the operation and improves the testing efficiency of the driver, but also enables automated testing, making it easy to integrate into automated processes such as continuous integration / continuous deployment.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0012] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the description of detailed exemplary embodiments with reference to the accompanying drawings, which are described below.

[0013] Figure 1This is a flowchart of a driver testing method provided in an embodiment of the present disclosure.

[0014] Figure 2 This is a schematic diagram of a driver testing method provided in an embodiment of this disclosure.

[0015] Figure 3 This is a block diagram of a driver testing apparatus provided in an embodiment of the present disclosure.

[0016] Figure 4 This is a block diagram of a driver testing system provided in an embodiment of the present disclosure.

[0017] Figure 5 This is a schematic diagram of a driver testing system provided in an embodiment of the present disclosure.

[0018] Figure 6 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0020] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0021] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0022] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0023] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0024] In related technologies, testing the driver for a processing device requires triggering hardware events (also known as physical events), which are typically triggered manually. For example, when testing the device connectivity of a driver, testers need to manually connect or disconnect the physical connections between the processing device and other devices (such as input devices, output devices, etc.) to change the connection status between the processing device and other devices. This method is not only complex and inefficient, but also cannot be integrated into automated processes such as Continuous Integration (CI) / Continuous Deployment (CD).

[0025] To address the aforementioned technical problems, embodiments of this disclosure provide a driver testing method, comprising: for a test task of a driver for a processing device in a terminal, wherein, if the test task includes a first test task for testing the hardware event handling function of the driver, determining a test instruction corresponding to the first test task; wherein the test instruction is used to simulate hardware events of the processing device; executing the first test task according to the test instruction, and obtaining the test result of the first test task.

[0026] According to the driver testing method of this disclosure, for the testing task of a driver for a processing device in a terminal, when the testing task includes a first test task for testing the hardware event handling function of the driver, a test instruction corresponding to the first test task is determined. The test instruction is used to simulate hardware events of the processing device. Then, the first test task is executed according to the test instruction to obtain the test result of the first test task. Thus, when testing the hardware event handling function of the driver for the processing device, the test instruction can be used to simulate hardware events for the processing device, converting the physical operations that need to be manually performed into test instructions. This not only simplifies the operation and improves the testing efficiency of the driver, but also enables automated testing, making it easy to integrate into automated processes such as continuous integration / continuous deployment.

[0027] The driver testing method according to embodiments of this disclosure can be executed by an electronic device such as a terminal device or a server. The terminal device can be a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Alternatively, the method can be executed by a server.

[0028] Figure 1 A flowchart illustrating a driver testing method provided in this disclosure. (Refer to...) Figure 1 The method includes steps S11 and S12, which are described in detail below.

[0029] In step S11, for the test task of the driver of the processing device in the terminal, if the test task includes a first test task for testing the hardware event handling function of the driver, the test instruction corresponding to the first test task is determined; wherein, the test instruction is used to simulate the hardware events of the processing device.

[0030] In step S12, the first test task is executed according to the test instruction, and the test result of the first test task is obtained.

[0031] In some possible implementations, the processing device may include a Graphics Processing Unit (GPU), a General-Purpose Graphics Processing Unit (GPGPU), etc. The terminal refers to an electronic device equipped with a processing device, such as a mobile phone equipped with a GPU or a server equipped with a GPGPU. The driver includes audio drivers for the processing device, such as GPU audio drivers, and may also include other types of drivers. It should be noted that this disclosure does not limit the specific types of terminals, processing devices, or drivers.

[0032] In some possible implementations, a test task for the driver of the processing device in the terminal can be determined in step S11. When testing the driver of the processing device in the terminal, the test task can be determined according to the test type. The test type can be any one of full test, smoke test, and regression test. The test task can include at least one of a first test task, a second test task, a third test task, a fourth test task, and a fifth test task. Specifically, the first test task is used to test the hardware event handling function of the driver, the second test task is used to test the internal logic of the driver, the third test task is used to test the specification of the driver's interface, the fourth test task is used to test the compatibility of the driver, and the fifth test task is used to perform stress testing on the driver.

[0033] In some possible implementations, the test types and corresponding test tasks can be set in the test configuration file. Then, when testing the driver for the processing device in the terminal, the test type for the current test is first determined, and then the test tasks for the driver for the processing device in the terminal are determined according to the test configuration file.

[0034] In some possible implementations, for a test task of a driver for a processing device in a terminal, it can be determined whether the test task includes a first test task for testing the hardware event handling function of the driver. If the test task includes a first test task, the test instructions corresponding to the first test task can be determined. The test instructions are used to simulate hardware events of the processing device in the form of software instructions. Hardware events include the connection and disconnection of other devices communicating with the processing device, changes in device state, etc., and this disclosure does not limit the specific types and contents of hardware events.

[0035] When determining the test instructions corresponding to the first test task, we can first identify the hardware events included in the first test task, that is, the hardware events that need to be triggered when executing the first test task. Then, we can determine the test instructions corresponding to the first test task based on the hardware events. For example, if the driver is a GPU audio driver, and the GPU communicates with the output device (such as a display device with built-in audio output) through a High-Definition Multimedia Interface (HDMI), the first test task includes two hardware events: the output device is connected to the GPU via HDMI, and the HDMI connection between the output device and the GPU is disconnected. In this case, there are two test instructions corresponding to the first test task. The first test instruction is used to simulate the hardware event of the output device connecting to the GPU via HDMI. The first test instruction can be set to "HDMI 1", where HDMI indicates that the connection type is HDMI, and 1 indicates that the output device is connected to the GPU. The second test instruction is used to simulate the hardware event of the HDMI connection between the output device and the GPU being disconnected. The second test instruction can be set to "HDMI 0", where 0 indicates that the connection between the output device and the GPU is disconnected.

[0036] In some possible implementations, after obtaining the test instructions corresponding to the first test task, the first test task can be executed according to the test instructions in step S12 to obtain the test result of the first test task. The test instructions corresponding to the first test task can be written into a first test script or a first test program to test the hardware event handling function of the driver. Then, the first test task is executed by executing the first test script or the first test program to obtain the test result of the first test task. The test result of the first test task includes the test result corresponding to each test instruction, where the test result corresponding to each test instruction is either "test passed" or "test failed". It should be noted that the first test task can also be executed in other ways, and this disclosure does not limit this.

[0037] The test results of the first test task may also include relevant statistical information such as the total number of test instructions, the number of test instructions that failed, and the number of defects found. It should be noted that the specific content included in the test results of the first test task can be set by those skilled in the art according to actual circumstances, and this disclosure does not impose any restrictions on this.

[0038] According to the driver testing method of this disclosure, for the testing task of a driver for a processing device in a terminal, when the testing task includes a first test task for testing the hardware event handling function of the driver, a test instruction corresponding to the first test task is determined. The test instruction is used to simulate hardware events of the processing device. Then, the first test task is executed according to the test instruction to obtain the test result of the first test task. Thus, when testing the hardware event handling function of the driver for the processing device, the test instruction can be used to simulate hardware events for the processing device, converting the physical operations that need to be manually executed into software instructions. This not only simplifies the operation and improves the testing efficiency of the driver, but also enables automated testing, making it easy to integrate into automated processes such as continuous integration / continuous deployment.

[0039] The driver testing method according to embodiments of this disclosure will now be described in detail.

[0040] In some possible implementations, the driver includes an audio driver for the processing device. Hardware events include at least one of the following: the terminal's output device connecting to the processing device, the output device disconnecting from the processing device, changes to the audio parameters of the output device, and changes to the output device identifier. Audio parameters may include at least one of the following: audio format supported by the output device, sampling rate, number of channels, and speaker location allocation information. The output device identifier is a unique identifier for the output device, and it may be the name of the output device.

[0041] The processing device can be a GPU, its driver can be a GPU audio driver, and the output device is used to output audio, which can be a display device with built-in audio output. When the processing device is a GPU and the driver is a GPU audio driver, hardware events can include at least one of the following: the terminal's display device connecting to the processing device, the display device disconnecting from the processing device, changes in the audio parameters of the display device, and changes in the display device identifier.

[0042] Audio formats include, for example, LPCM (Linear Pulse Code Modulation, an uncompressed raw digital audio format), AC-3 (Dolby Digital), or DTS (Digital Theater Systems, a lossy audio compression format). Sampling rates include, for example, 44.1kHz, 48kHz, or 96kHz. The number of channels includes, for example, stereo, 2-channel, 5.1-channel, or 7.1-channel. Speaker placement information includes, for example, whether left rear surround sound or a subwoofer is supported.

[0043] When the output device is a display device with built-in audio output, the audio parameters of the output device can be stored in ELD (EDID-Like Data), and the output device identifier can also be stored in ELD. In this case, changes to the audio parameters or the output device identifier can be considered as changes to ELD information. Here, EDID data refers to Extended Display Identification Data.

[0044] In other words, when the driver is a GPU audio driver, the output device is a display device with built-in audio output, and the GPU communicates with the display device via DP (DisplayPort), GPU hardware events can include: the display device connecting to the GPU via DP, the DP connection between the display device and the GPU being disconnected, and changes to the display device's ELD information. The display device's ELD information includes changes to the display device identifier and changes to the display device's audio parameters.

[0045] In some possible implementations, the driver includes a kernel debugging interface, and step S12 may include: writing test instructions to the driver through the kernel debugging interface so that the driver executes processing corresponding to hardware events based on the test instructions; and determining the test result of the first test task based on the processing result returned by the driver.

[0046] Drivers may include a kernel debugging interface. That is, a kernel debugging interface can be set in the driver. This interface runs in the kernel space of the terminal's operating system and serves as an interface for debugging tools (such as debuggers, test programs, and test scripts) to observe the driver's kernel state, control the driver's kernel execution flow, and inject test instructions into the driver's kernel. It can be seen as an interaction channel between the debugging tools and the driver's kernel. For example, the kernel debugging interface can be used to receive and parse test instructions from the operating system's user space. The kernel debugging interface can be in the form of a debug file, a debug stub, or a trace probe. For example, in the case of a Linux terminal operating system, a DebugFS debug file can be created in the driver as the kernel debugging interface, where DebugFS is a virtual file system in the Linux operating system kernel specifically used for debugging. It should be noted that this disclosure does not limit the specific implementation form of the kernel debugging interface.

[0047] When executing the first test task according to the test instructions, test instructions can be written to the driver through the driver's kernel debug interface, for example, by writing test instructions to the DebugFS debug file. After receiving the test instructions, the driver executes the processing corresponding to the hardware event simulated by the test instructions. This processing is the same as the driver's processing logic for real hardware events. After executing the corresponding processing, the driver returns the processing result. The driver can return the processing result in the following ways: event notification (e.g., User Event, which is an asynchronous event notification mechanism pushed by the Linux kernel to user space), jack (referring to the audio jack, in GPU audio drivers, the audio jack is an HDMI interface or a DP interface) control state change, preset state files (e.g., state files under / proc / asound / in Linux systems), kernel logs, etc., which are not limited in this disclosure.

[0048] For example, using Linux as the operating system, a test command simulates a hardware event where an output device connects to the GPU via HDMI. When the GPU audio driver receives this test command, it assumes the output device is connected to the GPU via HDMI. The GPU audio driver can update its internal jack state to "HDMI connected," and then update the jack control state in the Linux kernel to "HDMI connected," thus returning the processing result through changes in the jack control state. Testers can obtain the processing result returned by the driver for this test command by checking the jack control state. In the case of returning the processing result via event notification, the GPU audio driver can generate a jack event indicating that the output device is connected to the GPU via HDMI and send it to the Linux kernel. The Linux kernel then broadcasts this jack event to user space so that an event capture program running in user space can capture the jack event.

[0049] Then, based on the processing results returned by the driver for each test instruction, the test result (test passed or test failed) corresponding to each test instruction can be determined. For example, in the example above, the tester checks in the event capture program whether the jack event used to indicate that the output device is connected to the GPU via HDMI is captured. If captured, the test result corresponding to the test instruction used to simulate the hardware event of the output device connecting to the GPU via HDMI is considered to have passed; if not captured, the test result corresponding to the test instruction used to simulate the hardware event of the output device connecting to the GPU via HDMI is considered to have failed. Then, based on the test results (test passed or test failed) corresponding to each test instruction, the execution result of the first test task can be determined.

[0050] In the embodiments of this disclosure, the driver includes a kernel debugging interface. When executing a first test task, test instructions can be written to the driver through this kernel debugging interface, causing the driver to perform processing corresponding to hardware events based on the test instructions. Then, the test result of the first test task is determined based on the processing result returned by the driver. This method allows the driver to receive test instructions and perform the same processing as real hardware events, eliminating the need for manual operation by testing personnel, reducing testing costs, and improving test realism. Furthermore, this method, by writing test instructions through the driver's kernel debugging interface, is simple and fast, improving testing efficiency.

[0051] In some possible implementations, the driver testing method of this disclosure embodiment further includes: when the test task includes a second test task for testing the internal logic of the driver, testing the code implementing the internal logic of the driver in the kernel space of the terminal's operating system based on a kernel testing framework, and obtaining the test results of the second test task.

[0052] Testing tasks for drivers of processing devices in a terminal may also include a second testing task for testing the driver's internal logic. Testing the driver's internal logic can be viewed as testing the code that implements that logic. In other words, the second testing task is white-box testing of the driver. For example, the second testing task could be white-box testing of the driver's core logic functions, data structure processing, state machine transitions, etc. The second testing task is a code-level test.

[0053] The internal logic of a driver may include at least one of the following: parameter parsing logic, parameter verification logic, parameter conversion logic, configuration management logic for the processing device, and hardware register operation logic. For example, in the case of a GPU audio driver, the internal logic may include at least one of the following: ELD parsing logic, audio parameter verification logic, audio parameter conversion logic, GPU configuration management logic, and hardware register operation logic.

[0054] When a test task includes a second test task, the internal logic code implementing the driver can be tested in the kernel space of the operating system, based on the kernel testing framework provided by the terminal, to obtain the test results of the second test task. For example, if the driver is a GPU audio driver and the terminal's operating system is Linux, when executing the second test task, test code for testing the internal logic of the GPU audio driver can be written based on the KUnit (Kernel Unit Testing Framework) provided by Linux. This test code is then compiled together with the GPU audio driver code and run in the Linux kernel space to obtain the test results of the second test task.

[0055] The format of the test results for the second test task can be set according to the actual situation, and this disclosure does not impose any restrictions on it. For example, when the kernel testing framework is KUnit, the test results of the second test task can be in TAP (Test Anything Protocol) format.

[0056] In embodiments of this disclosure, when the test task includes a second test task for testing the internal logic of the driver, the kernel test framework provided by the terminal's operating system is used to test the code implementing the internal logic of the driver in the kernel space of the operating system, thereby improving the test efficiency and test coverage when performing white-box testing on the internal logic of the driver.

[0057] In some possible implementations, the driver testing method of this disclosure embodiment further includes: when the test task includes a third test task for testing the specification of the driver's interface, the specification of the driver's interface is tested by calling the driver's interface based on the standard library provided by the terminal's operating system, and the test result of the third test task is obtained.

[0058] Testing tasks for drivers of processing devices in a terminal may also include a third testing task for testing the specification of the driver's Application Programming Interface (API). When the driver's interface needs to conform to a specification, the third testing task can be performed according to the specification. The specification of the driver's interface may include at least one of the following: the specification of the driver's handling of interface boundary parameters, the specification of the handling of state transitions of the processing device, the specification of the interface's read / write functions, the specification of the handling of abnormal interface inputs, and the specification of the handling of interface errors.

[0059] For example, when the driver is a GPU audio driver and the terminal's operating system is Linux, the driver must comply with the ALSA (Advanced Linux Sound Architecture) specification. Therefore, the third test task can be used to verify whether the GPU audio driver's interface conforms to the ALSA specification. Specifically, when testing the conformity of the GPU audio driver's interface, at least one of the following can be tested: Whether the GPU audio driver's handling of interface boundary parameters (e.g., supported and unsupported sample rates, formats, number of channels, etc.) conforms to the ALSA specification; Whether the GPU audio driver's handling of GPU state transitions (e.g., open, prepare, start, stop, etc.) conforms to the ALSA specification; Whether the GPU audio driver's interface read / write functions (e.g., controlling the mixer) conform to the ALSA specification; Whether the GPU audio driver's handling of abnormal interface input conforms to the ALSA specification; Whether the GPU audio driver's handling of interface errors conforms to the ALSA specification.

[0060] When executing the third test task, the standard library provided by the terminal's operating system can be used to test the specification of the driver's interface by calling the driver's interface, thus obtaining the test results of the third test task. The third test task can be executed through a second test program, which can call the driver's interface by calling the standard library provided by the terminal's operating system. For example, if the driver is a GPU audio driver and the terminal's operating system is Linux, the second test program is a C / C++ test program based on the GTest (Google Test, a unit testing and mocking framework) / GMock (Google Mock, a testing tool for creating and using mock objects) framework. It can call the GPU audio driver's interface by calling the standard Linux ALSA userspace library (libasound). This second test program can be executed to test the specification of the GPU audio driver's interface, thus obtaining the test results of the third test task.

[0061] The format of the test results for the third test task can be set according to the actual situation, and this disclosure does not impose any restrictions on it. For example, if the second test program is a C / C++ test program based on the GTest / GMock framework, the test results of the second test task can be in XML (Extensible Markup Language) format.

[0062] In the embodiments of this disclosure, when the test task includes a third test task for testing the standardization of the driver's interface, the standardization of the driver's interface can be tested by calling the driver's interface based on the standard library provided by the terminal's operating system, thereby improving the test coverage and efficiency of the driver's interface standardization test. This method can also be used to verify whether the driver's interface conforms to relevant specification requirements.

[0063] In some possible implementations, the driver testing method of this disclosure embodiment further includes: when the test task includes a fourth test task for testing the compatibility of the driver, testing the compatibility between the driver and the target application by calling the target application to simulate a real usage scenario, and obtaining the test result of the fourth test task; wherein the target application is an application that the user actually runs and uses on the processing device.

[0064] Testing tasks for drivers of processing devices in a terminal may also include a fourth testing task to test driver compatibility. Driver compatibility refers to the compatibility between the driver and the application ecosystem. The fourth testing task can be executed by simulating real-world user scenarios. When executing the fourth testing task, the compatibility between the driver and the target application can be tested by calling the target application to simulate real-world usage scenarios, and the test results of the fourth testing task can be obtained.

[0065] The target application refers to the application that the user actually runs and uses on the processing device. The target application may include at least one of the following: an application that uses the processing device for input / output, an application that configures the processing device, an application that automatically responds to changes in the state of the processing device, an application that verifies the configuration information of the processing device, and an application that uses the configuration information of the processing device.

[0066] For example, if the driver is a GPU audio driver, the target application may include an audio player (e.g., the ALSA playback tool aplay), an audio output tool (e.g., the speaker testing tool speaker-test), a mixer control tool (e.g., the ALSA mixer control tool amixer), a mixer state management tool (e.g., the ALSA control tool, ALSAControl Tool, alsactl), an ALSA use case configuration manager, an audio server (e.g., the PulseAudio audio server or the PipeWire audio server), etc.

[0067] Accordingly, the fourth test task may include: playing audio files of different formats or sample rates using an audio player (e.g., aplay); performing audio output tests using an audio output tool (e.g., speaker-test); performing mixer control using a mixer control tool (e.g., amixer); listening to Jack events using a mixer state management tool (e.g., alsactl); verifying the correctness of GPU configuration information using the ALSA test case configuration manager; and testing whether an audio server (e.g., PulseAudio or PipeWire) can properly use the GPU configuration information, etc.

[0068] It should be noted that different drivers may result in different target applications, and the test content of the fourth test task may also be different. Those skilled in the art can set the specific test content of the fourth test task according to the actual situation, and this disclosure does not impose any restrictions on this.

[0069] To improve the execution efficiency of the fourth test task, the calls to the target application in the fourth test task can be written into a second test script. The second test script can be implemented using a shell scripting language. Then, the second test script can be executed to obtain the test results of the fourth test task.

[0070] In the embodiments of this disclosure, when the test task includes a fourth test task for testing the compatibility of the driver, the compatibility between the driver and the target application is tested by calling the target application to simulate real-world usage scenarios, thereby improving the effectiveness and efficiency of driver compatibility testing.

[0071] In some possible implementations, the driver testing method of this disclosure embodiment further includes: when the test task includes a fifth test task for stress testing the driver, the system resources used by the driver are tested by continuously executing the target test task for a preset time period, and the test result of the fifth test task is obtained; wherein the target test task includes at least one of the first test task, the third test task, and the fourth test task, and the system resources include at least one of hardware processing resources, storage resources, and process resources.

[0072] Test tasks for drivers of processing devices in the terminal may also include a fifth test task for stress testing the driver. Stress testing refers to testing the system resources used by the driver by running the driver for a long time and performing some processes at high frequency, in order to discover defects such as memory leaks and resource contention. For example, in the case of a GPU audio driver, the test content of the fifth test task may include: opening / closing the output device connected to the GPU a first preset number of times (e.g., 1000 times), changing the connection state between the GPU and the output device a second preset number of times (e.g., 100 times), playing audio for a duration greater than a duration threshold (e.g., 24 hours), and rapidly switching the mixer control a third preset number of times (e.g., 100 times).

[0073] When executing the fifth test task, the system resources used by the driver can also be tested by continuously executing the target test task for a preset duration, thus obtaining the test results of the fifth test task. The target test task includes at least one of the first, third, and fourth test tasks, and the system resources include at least one of hardware processing resources, storage resources, and process resources. For example, if the target test task includes the first, third, and fourth test tasks, the fifth test task can be a loop that executes the first, third, and fourth test tasks for a preset duration (e.g., 96 hours).

[0074] During the execution of the fifth test task, the driver's usage information of the terminal's system resources can be recorded through the terminal's operating system logs (such as kernel logs) or other preset methods. The terminal's system resources may include at least one of the terminal's hardware processing resources, storage resources, and process resources. Hardware processing resources may include the central processing unit (CPU), graphics processing unit (GPU), etc., and their usage information includes the driver's CPU utilization, CPU usage duration, GPU utilization, etc. Storage resources may include memory, video memory, disk, etc., and their usage information includes the size of the memory space occupied by the driver, the size of the video memory space occupied by the driver, the size of the disk space occupied by the driver, etc. Process resources include the number of handles used by the driver's process, etc. After the fifth test task is completed, the test results can be determined based on the recorded information about the driver's usage of the terminal's system resources.

[0075] It should be noted that the specific content of the system resources can be set by those skilled in the art according to the actual situation, and this disclosure does not impose any restrictions on this. In addition, whether the fifth test task is executed and its preset duration (i.e., the execution duration of the fifth test task) can both be set in the test configuration file.

[0076] In embodiments of this disclosure, when the test task includes a fifth test task for stress testing the driver, the system resources used by the driver are tested by continuously executing the target test task (at least one of the first test task, the third test task, and the fourth test task) for a preset duration, and the test results of the fifth test task are obtained. This method automates the stress testing of the driver and improves testing efficiency.

[0077] Figure 2 This diagram illustrates a driver testing method provided in an embodiment of the present disclosure. The method is used to test a GPU audio driver in a terminal. (Refer to...) Figure 2 The driver testing method includes steps S201-S209, which are described in detail below.

[0078] In step S201, upon receiving a test trigger signal indicating a full-scale test, a test task for performing a full-scale test on the GPU audio driver is determined from the test configuration file. This test task includes a first test task, a second test task, a third test task, a fourth test task, and a fifth test task. The test trigger signal can be automatically triggered through the CI system's build task or a scheduled task, or can be manually triggered; it can indicate the test type (any one of full-scale test, smoke test, or regression test).

[0079] In step S202, the test environment is initialized according to the test task. Test environment initialization may include checking the status of the GPU audio driver, checking the test programs used when executing the test task, and whether the target applications (including aplay, amixer, and speaker-test) are ready.

[0080] In step S203, the first test task is executed: the test instruction corresponding to the first test task is determined, and the test instruction is written to the DebugFS debug file of the GPU audio driver, so that the GPU audio driver executes the processing corresponding to the hardware event based on the test instruction. Then, the test result of the first test task is determined according to the processing result returned by the driver. Step S203 can be regarded as verifying the hardware event processing function of the GPU audio driver.

[0081] In step S204, the second test task is executed: based on the kernel testing framework KUnit, the code implementing the internal logic of the GPU audio driver is tested in the kernel space of the Linux operating system on the terminal, and the test results of the second test task are obtained. Step S204 can be regarded as verifying the kernel layer of the GPU audio driver.

[0082] In step S205, the third test task is executed: using the libasound standard library provided by the Linux operating system (based on the terminal), the interface of the GPU audio driver is tested for compliance with specifications by calling the driver's interface, and the test results of the third test task are obtained. Step S205 can be seen as verifying whether the GPU audio driver conforms to the ALSA specification.

[0083] In step S206, the compatibility between the GPU audio driver and the target application is tested by simulating a real-world usage scenario, yielding the test results for the fourth test task. The target application is the application actually run and used by the user on the processing device. Step S206 can be viewed as verifying the integration layer of the GPU audio driver.

[0084] In step S207, the system resources used by the GPU audio driver are tested by continuously executing the target test task within a preset duration, and the test results of the fifth test task are obtained. The preset duration is, for example, 96 hours. The target test task includes the first test task, the third test task, and the fourth test task. Step S207 can be seen as verifying the performance of the GPU audio driver.

[0085] In step S208, the test results of the first test task, the second test task, the third test task, the fourth test task, and the fifth test task are collected.

[0086] In step S209, statistical analysis is performed on the test results of the first test task, the second test task, the third test task, the fourth test task, and the fifth test task to generate a test report for the GPU audio driver.

[0087] According to the driver testing method of this disclosure, the driver of the processing device can be automatically tested at multiple levels, including hardware event handling (corresponding to the first test task), kernel layer (corresponding to the second test task), API layer (corresponding to the third test task), integration layer (corresponding to the fourth test task), and stress layer (corresponding to the fifth test task). This allows the test scope to cover multiple dimensions of the driver, such as hardware event handling, internal logic, interface implementation, application ecosystem compatibility, and long-term stable operation, thereby improving test efficiency and test coverage. In turn, it enables systematic verification of the driver of the processing device, improving the stability and robustness of the driver of the processing device.

[0088] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0089] In addition, this disclosure also provides driver testing apparatus, driver testing system, electronic device, computer-readable storage medium, and computer program product, all of which can be used to implement any of the driver testing methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the corresponding descriptions in the method section and will not be repeated here.

[0090] Figure 3 This is a block diagram of a driver testing apparatus provided in an embodiment of the present disclosure.

[0091] Reference Figure 3 This disclosure provides a driver testing device, which includes a determination module 31 and a first execution module 32.

[0092] The determining module 31 is used for testing tasks of the driver program of the processing device in the terminal. When the test task includes a first test task for testing the hardware event handling function of the driver program, the determining module 31 determines the test instruction corresponding to the first test task. The test instruction is used to simulate the hardware events of the processing device.

[0093] The first execution module 32 is used to execute the first test task according to the test instruction and obtain the test result of the first test task.

[0094] In some possible implementations, the driver includes a kernel debugging interface, wherein the first execution module 32 is specifically configured to: write the test instructions to the driver through the kernel debugging interface, so that the driver performs processing corresponding to the hardware event based on the test instructions; and determine the test result of the first test task based on the processing result returned by the driver.

[0095] In some possible implementations, the driver testing apparatus further includes: a second execution module, configured to, based on a kernel testing framework, test the code implementing the internal logic of the driver in the kernel space of the operating system of the terminal, when the test task includes a second test task for testing the internal logic of the driver, and obtain the test result of the second test task.

[0096] In some possible implementations, the internal logic of the driver includes at least one of the following: parameter parsing logic, parameter verification logic, parameter conversion logic, configuration management logic for the processing device, and hardware register operation logic.

[0097] In some possible implementations, the driver testing device further includes a third execution module, configured to, when the test task includes a third test task for testing the specification of the driver's interface, test the specification of the driver's interface by calling the driver's interface based on the standard library provided by the terminal's operating system, and obtain the test result of the third test task.

[0098] In some possible implementations, the standardization of the driver's interface includes at least one of the following: the standardization of the driver's handling of interface boundary parameters, the standardization of the handling of state transitions of the processing device, the standardization of interface read / write functions, the standardization of the handling of abnormal interface inputs, and the standardization of the handling of interface errors.

[0099] In some possible implementations, the driver testing device further includes: a fourth execution module, configured to, when the test task includes a fourth test task for testing the compatibility of the driver, test the compatibility between the driver and the target application by calling a target application to simulate a real usage scenario, and obtain the test result of the fourth test task; wherein the target application is an application that the user actually runs and uses on the processing device.

[0100] In some possible implementations, the target application includes at least one of the following: an application that uses the processing device for input / output, an application that configures the processing device, an application that automatically responds to changes in the state of the processing device, an application that verifies the configuration information of the processing device, and an application that uses the configuration information.

[0101] In some possible implementations, the driver testing device further includes: a fifth execution module, configured to, when the test task includes a fifth test task for stress testing the driver, continuously execute a target test task for a preset duration to test the system resources used by the driver and obtain the test result of the fifth test task; wherein the target test task includes at least one of a first test task for testing the hardware event handling function of the driver, a third test task for testing the standardization of the driver's interface, and a fourth test task for testing the compatibility of the driver, and the system resources include at least one of hardware processing resources, storage resources, and process resources.

[0102] In some possible implementations, the driver includes an audio driver for the processing device, and the hardware events include at least one of the following: the terminal's output device is connected to the processing device, the output device is disconnected from the processing device, the audio parameters of the output device are changed, and the output device identifier is changed. The audio parameters include at least one of the following: audio format supported by the output device, sampling rate, number of channels, and speaker location allocation information.

[0103] Figure 4 This is a block diagram of a driver testing system provided in an embodiment of the present disclosure.

[0104] Reference Figure 4 This disclosure provides a driver testing system, which includes:

[0105] The test scheduling module 41 is used to schedule test tasks of the driver program for the processing device in the terminal and obtain scheduling results. The scheduling results can be used to indicate the tasks to be executed, their execution order, and the number of executions. The tasks to be executed include at least one of the following: a first test task, a second test task, a third test task, a fourth test task, and a fifth test task.

[0106] The driver testing device 42 is used to obtain the test results of the test task based on the scheduling results and the driver testing method described above.

[0107] Figure 5 This is a schematic diagram of a driver testing system provided in an embodiment of this disclosure. (Refer to...) Figure 5 The driver testing system 500 is used to test the GPU audio driver 580. The driver testing system 500 includes a test scheduling module 510, a first execution module 520, a second execution module 530, a third execution module 540, a fourth execution module 550, a fifth execution module 560, and a report generation module 570.

[0108] The test scheduling module 510, acting as the main controller of the driver testing system 500, schedules the test tasks of the GPU audio driver 580 in the terminal upon receiving a test trigger signal (e.g., automatically triggered by a CI system build task, a scheduled task, or manually triggered). Based on the test type indicated by the trigger signal (full test, smoke test, or regression test), it schedules the test tasks and obtains the scheduling results. The scheduling results can be used to indicate whether to execute a stress test (i.e., whether to execute the fifth test task), the execution duration of the stress test (i.e., the preset duration, e.g., 24 hours), whether parallel execution of test tasks is supported, the tasks to be executed included in the test task and their execution order, and the number of executions. Then, based on the scheduling results, the test task is executed by calling at least one of the first execution module 520, the second execution module 530, the third execution module 540, the fourth execution module 550, and the fifth execution module 560. The test scheduling module 510 can be implemented using Python or Shell scripting languages.

[0109] The first execution module 520 is used to execute a first test task to test the hardware event handling function of the GPU audio driver 580. When the test task includes the first test task, the test scheduling module 510 can call the first execution module 520 to execute the first test task. When executing the first test task, the first execution module 520 can determine the test instructions (used to simulate hardware events of the processing device) corresponding to the first test task, and write the test instructions to the GPU audio driver 580 through the kernel debugging interface (DebugFS debug file) of the GPU audio driver 580, so that the GPU audio driver 580 executes the processing corresponding to the hardware event based on the test instructions; then, based on the processing result returned by the GPU audio driver 580, the test result of the first test task is determined.

[0110] The second execution module 530 is used to execute a second test task to test the internal logic of the GPU audio driver 580. When the test task includes a second test task, the test scheduling module 510 can call the second execution module 530 to execute the second test task. During the execution of the second test task, the second execution module 530 can test the code implementing the internal logic of the GPU audio driver 580 in the kernel space of the terminal's operating system based on the KUnit kernel testing framework, obtaining the test results of the second test task. The test results of the second test task can be KUnit logs in TAP format.

[0111] The third execution module 540 is used to execute a third test task to test the conformity of the interface of the GPU audio driver 580. When the test task includes a third test task, the test scheduling module 510 can call the third execution module 540 to execute the third test task. When executing the third test task, the third execution module 540 can use the libasound standard library provided by the Linux operating system of the terminal to test whether the interface of the GPU audio driver 580 conforms to the ALSA specification by calling the interface of the GPU audio driver 580, and obtain the test results of the third test task. The test results of the third test task can be a Gtest report in XML format.

[0112] The fourth execution module 550 is used to execute the fourth test task to test the compatibility of the GPU audio driver 580. When the test task includes the fourth test task, the test scheduling module 510 can call the fourth execution module 550 to execute the fourth test task. During the execution of the fourth test task, the fourth execution module 550 simulates real-world usage scenarios by calling shell-based ALSA tools (such as aplay, amixer, speaker-test, etc.) to test the compatibility between the GPU audio driver 580 and the ALSA tools, obtaining the test results of the fourth test task. The test results of the fourth test task can be output to the shell.

[0113] The fifth execution module 560 is used to execute the fifth test task to perform stress testing on the GPU audio driver 580. When the test task includes the fifth test task, the test scheduling module 510 can call the fifth execution module 560 to execute the fifth test task. When executing the fifth test task, the fifth execution module 560 continuously executes the target test task within a preset duration to test the system resources used by the GPU audio driver 580, obtaining the test results of the fifth test task; wherein the target test task includes at least one of the first test task, the third test task, and the fourth test task, and the system resources include at least one of hardware processing resources, storage resources, and process resources.

[0114] The first, second, third, fourth, and fifth test tasks mentioned above can each include multiple test cases.

[0115] The report generation module 570 is used to collect the test results output by each of the above-mentioned execution modules and generate a unified, traceable test report based on the test results output by each execution module. The test report format may be, for example, HTML (Hypertext Markup Language) or Markdown format. The content of the test report may include test statistics (e.g., total test execution time, test coverage statistics, number of passed test cases, number of failed test cases, etc.), information on failed test cases, defect trend analysis (compared to historical tests), etc. The format and content of the test report can be set by those skilled in the art according to actual circumstances, and this disclosure does not impose any restrictions on this.

[0116] The driver testing system of this disclosure can perform automated testing on the driver of a processing device at multiple levels, including hardware event handling (corresponding to the first test task), kernel layer (corresponding to the second test task), API layer (corresponding to the third test task), integration layer (corresponding to the fourth test task), and stress layer (corresponding to the fifth test task). This allows the test scope to cover multiple dimensions of the driver, such as hardware event handling, internal logic, interface implementation, application ecosystem compatibility, and long-term stable operation, thereby improving testing efficiency and test coverage. In turn, it enables systematic verification of the driver of the processing device, improving the stability and robustness of the driver.

[0117] Furthermore, the driver testing system of this disclosure includes a report generation module. This report generation module can integrate heterogeneous test results from different execution modules into a standardized, traceable, and comprehensive test report, which provides data support for automated quality measurement, trend analysis, and quality gate setting of drivers.

[0118] Figure 6 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0119] Reference Figure 6 This disclosure provides an electronic device, which includes: at least one processor 601; at least one memory 602; and one or more I / O interfaces 603 connected between the processor 601 and the memory 602; wherein the memory 602 stores one or more computer programs that can be executed by at least one processor 601, and the one or more computer programs are executed by at least one processor 601 to enable at least one processor 601 to perform the above-described driver testing method.

[0120] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the driver testing method described above. The computer-readable storage medium may be volatile or non-volatile.

[0121] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described driver testing method.

[0122] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0123] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0124] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0125] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0126] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0127] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0128] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0129] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0130] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0131] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A driver testing method, characterized in that, include: For a test task of a driver for a processing device in a terminal, if the test task includes a first test task for testing the hardware event handling function of the driver, a test instruction corresponding to the first test task is determined; wherein the test instruction is used to simulate hardware events of the processing device. The first test task is executed according to the test instruction, and the test result of the first test task is obtained.

2. The method according to claim 1, characterized in that, The driver includes a kernel debugging interface, wherein executing the first test task according to the test instructions and obtaining the test result of the first test task includes: The test instructions are written to the driver through the kernel debugging interface, so that the driver performs processing corresponding to the hardware event based on the test instructions; The test result of the first test task is determined based on the processing result returned by the driver.

3. The method according to claim 1, characterized in that, The method further includes: In the case where the test task includes a second test task for testing the internal logic of the driver, the code implementing the internal logic of the driver is tested in the kernel space of the operating system of the terminal based on the kernel test framework, and the test results of the second test task are obtained.

4. The method according to claim 3, characterized in that, The internal logic of the driver includes at least one of the following: parameter parsing logic, parameter verification logic, parameter conversion logic, configuration management logic for the processing device, and hardware register operation logic.

5. The method according to claim 1, characterized in that, The method further includes: In the case where the test task includes a third test task for testing the standardization of the driver's interface, the standardization of the driver's interface is tested by calling the driver's interface based on the standard library provided by the terminal's operating system, and the test result of the third test task is obtained.

6. The method according to claim 5, characterized in that, The standardization of the driver's interface includes at least one of the following: the standardization of the driver's handling of interface boundary parameters, the standardization of the handling of state transitions of the processing device, the standardization of interface read / write functions, the standardization of the handling of abnormal interface inputs, and the standardization of the handling of interface errors.

7. The method according to claim 1, characterized in that, The method further includes: In the case where the test task includes a fourth test task for testing the compatibility of the driver, the compatibility between the driver and the target application is tested by calling the target application to simulate a real usage scenario, and the test result of the fourth test task is obtained; wherein, the target application is the application that the user actually runs and uses on the processing device.

8. The method according to claim 7, characterized in that, The target application includes at least one of the following: an application that uses the processing device for input / output, an application that configures the processing device, an application that automatically responds to changes in the state of the processing device, an application that verifies the configuration information of the processing device, and an application that uses the configuration information.

9. The method according to claim 1, characterized in that, The method further includes: When the test task includes a fifth test task for stress testing the driver, the system resources used by the driver are tested by continuously executing the target test task within a preset time period, and the test results of the fifth test task are obtained. The target test task includes at least one of a first test task for testing the hardware event handling function of the driver, a third test task for testing the standardization of the interface of the driver, and a fourth test task for testing the compatibility of the driver. The system resources include at least one of hardware processing resources, storage resources, and process resources.

10. The method according to any one of claims 1-9, characterized in that, The driver includes the audio driver of the processing device, and the hardware event includes at least one of the following: the terminal's output device is connected to the processing device, the output device is disconnected from the processing device, the audio parameters of the output device are changed, and the output device identifier is changed. The audio parameters include at least one of the following: the audio format supported by the output device, the sampling rate, the number of channels, and the speaker position allocation information.

11. A driver testing device, characterized in that, include: A determination module is configured to determine a test instruction corresponding to a driver program for a processing device in a terminal, wherein, if the test task includes a first test task for testing the hardware event handling function of the driver program, the test instruction is configured to simulate hardware events of the processing device. The first execution module is used to execute the first test task according to the test instruction and obtain the test result of the first test task.

12. A driver testing system, characterized in that, The system includes: The test scheduling module is used to schedule test tasks for the drivers of the processing devices in the terminal and obtain the scheduling results; A driver testing device is configured to obtain the test result of the test task by executing the driver testing method as described in any one of claims 1-10, based on the scheduling result.

13. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the driver testing method as described in any one of claims 1-10.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the driver testing method as described in any one of claims 1-10.

Images