Test method and device, electronic device, storage medium and program product

Abstract

This disclosure provides a testing method, apparatus, electronic device, storage medium, and program product. The method includes: receiving a call request from an application, to be sent via a driver layer to a graphics kernel layer; responding to determining that a test configuration file contains preset configuration information for the interface corresponding to the call request; determining a test result corresponding to the call request based on the preset configuration information; and feeding back the test result to the application. This method can flexibly and controllably obtain any desired test response, i.e., test result, based on a pre-set test configuration file, achieving comprehensive simulation of the required test response, thereby enabling efficient and comprehensive testing.

Description

Technical Field

[0001] This disclosure relates to the field of graphics rendering technology, and particularly to the field of testing and verification technology within the field of graphics rendering technology, specifically to a testing method, testing device, electronic device, computer storage medium, and program product. Background Technology

[0002] In graphics rendering systems, the interaction between software and hardware follows a hierarchical collaboration model.

[0003] Applications (APPs) can initiate graphics operation commands by calling standard graphics application programming interfaces (APIs). These commands are verified and state-managed by dynamic-link libraries (DLLs) provided by the operating system, and then forwarded to the user-mode driver (UMD) layer provided by the hardware manufacturer. The UMD translates and compiles high-level API commands into corresponding instruction sequences executable by the graphics processing unit (GPU). This instruction sequence can then be passed to the kernel-mode driver (KMD) layer by directly extending the DirectX Graphics Kernel (DXGK) layer, where the KMD schedules the GPU hardware to execute the corresponding image operations.

[0004] Currently, testing and verification of this graphics rendering system typically relies on running test cases directly in its corresponding production environment, which results in issues such as incomplete test coverage and dependence on specific environments. Summary of the Invention

[0005] This disclosure provides a test method, a test apparatus, an electronic device, a computer-readable storage medium, and a computer program product.

[0006] In a first aspect, embodiments of this disclosure propose a testing method, comprising: receiving a call request from an application to be sent to the graphics kernel layer via a driver layer; in response to determining that a test configuration file contains preset configuration information for the interface corresponding to the call request, determining a test result corresponding to the call request based on the preset configuration information; and feeding back the test result to the application.

[0007] In some optional implementations of the embodiments of this disclosure, the above testing method may further include: in response to detecting a target identifier corresponding to the application being in test mode, determining whether the test configuration file contains preset configuration information for the interface corresponding to the call request.

[0008] In some optional implementations of the embodiments of this disclosure, the target identifier includes at least one of the following: an application identifier, an environment variable identifier corresponding to the test mode, and a registry entry corresponding to the test mode.

[0009] In some optional implementations of the embodiments of this disclosure, the above-mentioned determination of the test result corresponding to the call request based on preset configuration information includes: determining the test type for the interface based on preset configuration information, wherein the test type includes at least one of functional testing, performance testing and concurrency testing; and determining the first response result corresponding to the test type contained in the preset configuration information as the test result.

[0010] In some optional implementations of the embodiments of this disclosure, when the above test type includes functional testing, the functional test includes at least one of baseline testing and exception testing; when the above test type includes performance testing, the performance test includes delayed call testing; when the above test type includes concurrency testing, the concurrency test includes tests executed based on a reordered call sequence.

[0011] In some optional implementations of the embodiments of this disclosure, the above-mentioned receiving of a call request from an application to be sent to the graphics kernel layer via the driver layer includes: intercepting the call request from the application to be sent to the graphics kernel layer via the driver layer through a hook layer; and determining the test result corresponding to the call request based on preset configuration information includes: determining the test result corresponding to the call request based on preset configuration information through a hook layer.

[0012] In some optional implementations of the embodiments of this disclosure, the preset configuration information includes: an interface identifier and configuration parameters associated with the interface identifier, wherein the configuration parameters include test results to be fed back.

[0013] In some optional implementations of the embodiments of this disclosure, the above testing method may further include: in response to determining that the test configuration file does not contain preset configuration information for the interface corresponding to the call request, determining the second response result fed back by the graphics kernel layer corresponding to the call request as the test result.

[0014] In some optional implementations of the embodiments of this disclosure, the above testing method may further include: performing an update operation on the test configuration file in response to detecting an update instruction for the test configuration file.

[0015] Secondly, embodiments of this disclosure provide a testing apparatus, comprising: a receiving module, a processing module, and a sending module. The receiving module is configured to receive a call request from an application, to be sent via the driver layer to the graphics kernel layer; the processing module is configured to, in response to determining that a test configuration file contains preset configuration information for the interface corresponding to the call request, determine a test result corresponding to the call request based on the preset configuration information; and the sending module is configured to feed back the test result to the application.

[0016] In some optional implementations of the embodiments of this disclosure, the above processing module may also be used to: in response to detecting a target identifier corresponding to the application being in test mode, determine whether the test configuration file contains preset configuration information for the interface corresponding to the call request.

[0017] In some optional implementations of the embodiments of this disclosure, the target identifier includes at least one of the following: an application identifier, an environment variable identifier corresponding to the test mode, and a registry entry corresponding to the test mode.

[0018] In some optional implementations of the embodiments of this disclosure, the above processing module is further configured to: determine the test type for the interface based on preset configuration information, wherein the test type includes at least one of functional testing, performance testing and concurrency testing; and determine the first response result corresponding to the test type contained in the preset configuration information as the test result.

[0019] In some optional implementations of the embodiments of this disclosure, when the above test type includes functional testing, the functional test includes at least one of baseline testing and exception testing; when the above test type includes performance testing, the performance test includes delayed call testing; when the above test type includes concurrency testing, the concurrency test includes tests executed based on a reordered call sequence.

[0020] In some optional implementations of the embodiments of this disclosure, the receiving module is further configured to: intercept a call request from the application to be sent to the graphics kernel layer via the driver layer through a hook layer; and the processing module is further configured to: determine the test result corresponding to the call request based on preset configuration information through the hook layer.

[0021] In some optional implementations of the embodiments of this disclosure, the preset configuration information includes: an interface identifier and configuration parameters associated with the interface identifier, wherein the configuration parameters include test results to be fed back.

[0022] In some optional implementations of the embodiments of this disclosure, the above processing module may also be used to: in response to determining that the test configuration file does not contain preset configuration information for the interface corresponding to the call request, determine the second response result fed back by the graphics kernel layer corresponding to the call request as the test result.

[0023] In some optional implementations of the embodiments of this disclosure, the above processing module may also be used to: perform an update operation on the test configuration file in response to detecting an update instruction for the test configuration file.

[0024] Thirdly, embodiments of this disclosure provide an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the test method described in any of the implementations of the first aspect above.

[0025] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that enable a processor to implement the test method described in any of the implementations in the first aspect.

[0026] Fifthly, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, can implement the test method as described in any implementation of the first aspect.

[0027] According to the solution provided in this disclosure, upon receiving a call request from an application to be sent to the graphics kernel layer via the driver layer, if it is determined that the test configuration file pre-sets the configuration information for the interface corresponding to the current call request, the test result for the call request can be directly and efficiently determined based on the pre-set configuration information and fed back to the application. In this way, any desired test response, i.e., the test result, can be obtained flexibly and controllably based on the pre-set test configuration file, achieving comprehensive simulation of the required test response. This makes the acquisition of the test result not limited by the production environment, thus supporting the simulation of complex test scenarios. Furthermore, precise control of the test configuration facilitates problem reproduction and debugging, such as reproducing boundary conditions and abnormal states, achieving efficient and comprehensive testing.

[0028] 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

[0029] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of the architecture of a graphics rendering system provided in related technologies; Figure 2 This is a flowchart of a testing method provided in an embodiment of this disclosure; Figure 3 A flowchart of another testing method provided in this disclosure embodiment; Figure 4 A flowchart of a testing method in an application scenario provided by an embodiment of this disclosure; Figure 5 A structural block diagram of a testing device provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of the structure of an electronic device suitable for performing a test method, provided as an embodiment of the present disclosure. Detailed Implementation

[0030] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding; these should be considered merely exemplary. Therefore, those skilled in the art will 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 brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0031] It should be noted that the collection, acquisition, storage, processing, transmission, provision, disclosure, and application of user personal information (such as user verification information required during testing) involved in the technical solution disclosed herein are all carried out with the user's knowledge and explicit authorization, comply with the provisions of relevant laws and regulations, and do not violate public order and good morals.

[0032] In a graphics rendering system, an application (APP) can initiate graphics operation requests by calling standard graphics APIs. These requests are then converted and passed to the user-mode driver UMD layer via the Direct3D Runtime (D3D Runtime). The UMD layer responds by calling the D3D Runtime's commit callback function. The D3D Runtime switches from user mode to kernel mode and further requests the kernel-mode driver KMD layer to schedule GPU hardware interactions, such as memory allocation and rendering command submission, to obtain the graphics operation result. The KMD layer then returns the graphics operation result to the DXGK subsystem, which in turn returns it to the D3D Runtime. At this point, the D3D Runtime switches back from kernel mode to user mode and returns the graphics operation result as the result of the callback function to the UMD layer. The UMD layer then feeds the graphics operation result back to the APP via the D3D Runtime. This process can be referenced in [reference needed]. Figure 1 The content shown. Accordingly, when performing testing and verification on this graphics rendering system, it is necessary to run the corresponding test cases directly in the production environment and add test logic by modifying the UMD source code.

[0033] In the aforementioned testing and verification process, the production environment typically refers to the online operational environment where the final, officially released software system, service, or application is deployed, providing continuous services to external real users and processing real business data. Therefore, testing and verification relying on a specific environment—the production environment—depends on its stable configuration. This makes it difficult to reproduce tests and verifications for boundary conditions and abnormal states such as resource exhaustion and hardware failures, and it cannot comprehensively simulate all possible response states of DXGK, resulting in incomplete test coverage.

[0034] Moreover, since the above-mentioned testing and verification process requires adding test logic by modifying the UMD source code, it will affect the stability and maintainability of the code, increase the maintenance complexity of the code, and lead to problems such as high labor costs and low testing efficiency. It also makes it difficult to flexibly configure and manage test cases.

[0035] Therefore, how to implement a flexible and controllable testing scheme without modifying the production environment has become an urgent technical problem to be solved.

[0036] The following description of several optional embodiments illustrates the technical solutions of this disclosure and the technical effects produced by these solutions. It should be noted that the following embodiments can be referenced, learned from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0037] Please refer to Figure 2 , Figure 2 A flowchart of a testing method provided for embodiments of this disclosure, wherein process 200 includes the following steps: Step 201: Receive a call request from the application that is to be sent to the graphics kernel layer via the driver layer.

[0038] This step aims to allow the testing method's execution entity, such as a server, to continuously listen for or wait for call requests from the application, which are to be sent from the driver layer to the graphics kernel layer, via a predefined and exposed API. This application can include, but is not limited to, applications with graphics rendering requirements, such as games, map navigation applications, and applications involving remote desktop sharing; no specific limitations are imposed here. Optionally, this application can be an application running in a production environment.

[0039] It should be noted that the number of applications and invocation requests can be one or more. For example, receiving an invocation request from an application, to be sent from the driver layer to the graphics kernel layer, can be understood as receiving and processing one invocation request from one application, or it can also be understood as receiving and processing multiple concurrent invocation requests from the same application, or it can also be understood as receiving and processing multiple concurrent invocation requests from multiple different applications. In some optional implementations of this disclosure, the invocation request can also be represented as an interface invocation request, wherein the type of invocation request can include, but is not limited to, video memory allocation requests, graphics rendering requests, etc.

[0040] In this embodiment of the disclosure, the driver layer may include a user-mode driver layer, namely the UMD layer, and the graphics kernel layer may include the DXGK layer. The aforementioned call request from the application may be a call request that needs to be passed from user mode to kernel mode in order to request the KMD layer to perform operations that the kernel is authorized to complete, such as the final hardware submission of the graphics computing task, the application and management of GPU virtual and physical resources, etc.

[0041] Step 202: In response to the determination that the test configuration file contains preset configuration information for the interface corresponding to the call request, determine the test result corresponding to the call request based on the preset configuration information.

[0042] In this step, upon receiving the call request from step 201 above and determining that the test configuration file contains preset configuration information for the interface corresponding to the call request, the test result for the call request can be determined directly and efficiently based on the preset configuration information. That is, for call requests from applications running in the production environment that are to be sent from the driver layer to the graphics kernel layer, the corresponding test result is obtained based on the corresponding preset configuration information only when it is necessary to determine the corresponding response, i.e., the test result, based on the preset configuration information in the test configuration file.

[0043] In some optional implementations of the embodiments of this disclosure, the aforementioned preset configuration information can at least be used to indicate each interface and its corresponding test-related configuration parameters, so as to realize flexible configuration and management of the test for the interface corresponding to the call request, thereby improving test efficiency.

[0044] In some optional implementations of the embodiments of this disclosure, the test results corresponding to the call request can be used to indicate the response status to the call request, including but not limited to timeout, insufficient resources, and other exceptions, as well as success and failure response statuses.

[0045] Step 203: Feedback the test results to the application.

[0046] In this step, the test results, determined by the preset configuration information in the pre-set test configuration file, need to be fed back to the application so that the application can obtain the pre-configured test results corresponding to the call request.

[0047] According to the testing method provided in this disclosure, when a call request is received from an application and is to be sent to the graphics kernel layer via the driver layer, the test result for the call request can be directly and efficiently determined based on the pre-set configuration information of the interface corresponding to the current call request in the test configuration file, and then fed back to the application. In this way, any desired test response, i.e., the test result, can be obtained flexibly and controllably based on the pre-set test configuration file, achieving comprehensive simulation of the required test response. This makes the acquisition of the test result not limited by the production environment, thus supporting the simulation of complex test scenarios. Furthermore, precise control of the test configuration facilitates problem reproduction and debugging, such as reproducing boundary conditions and abnormal states, achieving efficient and comprehensive testing.

[0048] Please refer to Figure 3 , Figure 3 A flowchart of another testing method provided in this disclosure embodiment, wherein process 300 includes the following steps: Step 301: Receive a call request from the application that is to be sent to the graphics kernel layer via the driver layer.

[0049] The above steps 301 and as follows Figure 2 The steps shown in step 201 are the same. For the same parts, please refer to the corresponding parts of the previous embodiment. They will not be repeated here.

[0050] Step 302: In response to detecting a target identifier corresponding to the application being in test mode, determine whether the test configuration file contains preset configuration information for the interface corresponding to the call request.

[0051] This step aims to determine, when the execution entity of the testing method, such as a server, receives a call request from an application to be sent from the driver layer to the graphics kernel layer, it must first determine whether the application is currently in test mode rather than normal running mode, or in other words, whether it is in a test environment rather than a production environment. Optionally, this can be achieved by determining whether a target identifier indicating that the application is currently in test mode can be detected. Only when the corresponding target identifier is detected will the operation of determining the test result corresponding to the call request from the application to be sent from the driver layer to the graphics kernel layer based on the test configuration file be activated or enabled. That is, only when the target identifier is detected will it be determined whether the pre-set test configuration file contains preset configuration information for the interface corresponding to the call request. Optionally, the target identifier corresponding to the application being in test mode can be used to indicate whether the application can switch from running in the production environment to the test environment. Thus, by clearly defining the conditional activation mechanism for determining the test result based on the pre-set test configuration file, the test environment and the production environment can be effectively isolated, further ensuring that the acquisition of test results is not limited by the production environment, and further improving the flexibility, controllability, and security of the test.

[0052] In some optional implementations of the embodiments of this disclosure, the target identifier includes, but is not limited to, at least one of the following: an application identifier, an environment variable identifier corresponding to the test mode, and a registry entry corresponding to the test mode.

[0053] In this embodiment, if at least one of the following is detected: the application's identifier, the environment variable identifier corresponding to the test mode, and the registry key corresponding to the test mode, the application's test mode can be accurately and efficiently determined. For example, the target identifier can be detected by reading and parsing whether the target identifier is recorded in the test configuration file; alternatively, the target identifier can be detected from its specific source, such as the operating system, without further specific limitations.

[0054] Optionally, if the target identifier includes the identifier of an application, the application is the object designated or selected for performing the test. The identifier of the application can be a unique identifier of the application, and can be one or a combination of the application's name, version information, ID, etc., without specific limitations.

[0055] Optionally, if the target identifier includes an environment variable identifier or a registry entry corresponding to the test mode, the environment variable identifier or registry entry can be used to indicate that the application is currently in a specific test environment. For example, the value of the environment variable identifier in the operating system or the configuration content of the registry entry can be read. If the value or configuration content of the registry entry matches the test mode, it can be considered that the application is currently in test mode.

[0056] Step 303: In response to the determination that the test configuration file contains preset configuration information for the interface corresponding to the call request, determine the test result corresponding to the call request based on the preset configuration information.

[0057] Step 304: Feedback the test results to the application.

[0058] Steps 303-304 above and as follows Figure 2 Steps 202-203 shown are the same. For the same parts, please refer to the corresponding parts of the previous embodiment. They will not be repeated here.

[0059] According to the testing method provided in this disclosure embodiment, when a call request is received from an application to be sent to the graphics kernel layer via the driver layer, it is first necessary to determine whether the application is currently in test mode rather than normal running mode. Only when the corresponding target identifier is detected will the operation of determining the test result corresponding to the call request from the application to be sent to the graphics kernel layer via the driver layer be activated or enabled based on the test configuration file. That is, only when the target identifier is detected will the following operation be performed: if it is determined that the test configuration file has pre-set configuration information for the interface corresponding to the current call request, the test result for the call request can be determined directly and efficiently based on the pre-set configuration information and fed back to the application.

[0060] In this way, under the condition that the activation conditions of the test are met, that is, under the condition that the test environment is effectively isolated from the production environment, any required test response or test result can be obtained flexibly and controllably based on the pre-set test configuration file. This enables a comprehensive simulation of the required test response, so that the test result is not limited by the production environment. This allows for the simulation of complex test scenarios, and the precise control of the test configuration facilitates problem reproduction and debugging, enabling the reproduction of boundary conditions and abnormal states, thus achieving efficient, comprehensive and safe testing.

[0061] In some optional implementations of the embodiments of this disclosure, the preset configuration information described above, which can be used to indicate each interface and its corresponding test-related configuration parameters, may include, but is not limited to, the interface test type and response result corresponding to the call request from the application to be sent to the graphics kernel layer via the driver layer, so as to realize the response simulation of the corresponding test type for the current interface call. In this way, flexible configuration and management of the test type and the response result corresponding to the test type for the interface corresponding to the call request can be achieved, thereby improving testing efficiency. Further, in the above... Figure 2 or Figure 3 Based on the corresponding embodiments, in some optional implementations of the embodiments of this disclosure, the process of determining the test result corresponding to the call request based on the preset configuration information in step 202 or step 303 can be executed as follows: determining the test type for the interface based on the preset configuration information, wherein the test type includes at least one of functional testing, performance testing and concurrency testing; and determining the first response result corresponding to the test type contained in the preset configuration information as the test result.

[0062] In this embodiment, if it is determined that the test configuration file pre-sets configuration information for the interface corresponding to the call request, the test type for the interface call can be accurately determined based on the pre-set configuration information. Furthermore, the first response result corresponding to the test type contained in the pre-set configuration information can be determined as the test result that needs to be fed back. In this way, the required response result, i.e., the test result, can be accurately and efficiently determined based on the test strategies corresponding to each test type contained in the test configuration file.

[0063] In the above Figure 2 or Figure 3Based on the corresponding embodiments, in some other optional implementations of the embodiments of this disclosure, corresponding test configuration files can be set for different test types, that is, the relationship between test types and test configuration files can be set as a one-to-one correspondence. Based on this, the process of determining the test result corresponding to the call request based on the preset configuration information in step 202 or step 303 above can be executed as follows: when the test type of the interface corresponding to the call request is determined, the preset configuration information in the test configuration file corresponding to the test type is read, and the response result of the call to the interface contained therein is determined as the test result that needs to be fed back.

[0064] In some optional implementations of the embodiments of this disclosure, the above-mentioned test types may include, but are not limited to, at least one of functional testing, performance testing, and concurrency testing. For example, functional testing can be used to verify whether a behavior or operation meets functional requirements, such as verifying whether API calls such as creating resources or submitting drawing commands can be executed correctly, without specific limitations. For example, performance testing can be used to verify whether the system meets performance requirements, such as latency and throughput requirements, without specific limitations. For example, concurrency testing can be used to verify the system's operational stability for multiple operations, such as reordering the call sequence, without specific limitations. In this way, a comprehensive simulation of the required test response matching any of the above test types can be achieved.

[0065] In some optional implementations of the embodiments of this disclosure, when the above-mentioned test types include functional testing, the functional testing includes, but is not limited to, at least one of baseline testing and anomaly testing.

[0066] In this embodiment, when the functional test includes baseline testing, baseline testing can refer to performing the corresponding operation under standard, normal, and interference-free conditions. The first response result corresponding to the baseline test included in the aforementioned preset configuration information may include, but is not limited to, a successful response, thus enabling simulated feedback of a successful response after normal operation. For example, in this baseline test mode, the current call is not modified in any way, the call request continues to be transmitted, and normal call logs, such as successful response results and operation time, can be recorded.

[0067] In this embodiment, when functional testing includes anomaly testing, the anomaly testing can also be called fault tolerance testing or negative testing to verify whether the behavior is correct and controllable when faced with unexpected inputs, erroneous conditions, or fault states. The first response result corresponding to the anomaly test included in the aforementioned preset configuration information may include, but is not limited to, timeouts, insufficient resources, or other abnormal or failure responses. Thus, by flexibly setting test types to cover the response results corresponding to anomaly testing, the acquisition of test results is not limited to the production environment. Boundary conditions and abnormal states can be reproduced in the test, transforming them into repeatable, flexible, and controllable test scenarios to achieve a more comprehensive simulation of the required test responses. For example, in this anomaly testing mode, in response to the detection of a call request, the system simulates returning the pre-configured abnormal or failure response state in the test configuration file to achieve error injection, such as simulating insufficient resources.

[0068] In some optional implementations of the embodiments of this disclosure, when the above-mentioned test type includes performance testing, the performance test includes, but is not limited to, delayed call testing. For example, in this delayed call testing mode, in response to the detection of a call request, a controllable delay exceeding a preset timeout threshold can be injected into the normal function call process, and the response to the call with the added delay can be simulated to simulate operation timeouts, etc.

[0069] In some optional implementations of the embodiments of this disclosure, when the above-mentioned test type includes concurrency testing, the concurrency testing includes, but is not limited to, tests based on reordered call sequences, which can also be called order sensitivity tests. For example, in this test mode based on reordered call sequences, the logical order of the timeline when a call request is detected can be strategically disrupted, and the response to the disrupted call sequence can be simulated to simulate the concurrent execution result in that scenario.

[0070] In some optional implementations of the embodiments of this disclosure, the preset configuration information used to indicate each interface and its corresponding test-related configuration parameters includes, in addition to the interface test type and response result corresponding to the call request from the application to be sent from the driver layer to the graphics kernel layer, the identifier of the interface may also include the identifier of the interface, and the identifier of the interface is associated with the test type and response result for that interface. Thus, based on the identifier of each interface, each test type for the same interface and its corresponding response result can be associated, so as to achieve effective management of the test type for the interface corresponding to the call request and the response result corresponding to that test type. For example, the identifier of the interface can be used as an index to achieve rapid retrieval and location of the required test type and response result.

[0071] Optionally, the identifier that can be used to uniquely distinguish different interfaces may include the interface name and / or number, etc.

[0072] Optionally, the aforementioned preset configuration information may also include test cases corresponding to the aforementioned test types and / or response results. Optionally, the response result can be obtained through the following process: in response to receiving the aforementioned call request, the test case is simulated and run to obtain the desired result. In this way, flexible configuration and management of test cases corresponding to the desired test results can be achieved, and by pre-configuring test cases in the test configuration file, a large number of test cases can be executed quickly, thereby improving testing efficiency.

[0073] Based on any of the above embodiments, in some optional implementations, step 201 or step 301 can be executed as follows: intercepting the call request from the application to be sent to the graphics kernel layer via the driver layer through the hook layer; and the process of step 202 or step 303 can be executed as follows: determining the test result corresponding to the call request based on preset configuration information through the hook layer.

[0074] In this embodiment, a hook layer can intercept call requests from the application that need to be initiated from the driver layer to the graphics kernel layer. Upon detecting a corresponding target identifier, the hook layer activates or enables the operation of determining the test result corresponding to the call request from the application based on a test configuration file. The hook layer reads the test configuration file upon detecting the target identifier; that is, it only activates the function of intercepting call requests when the test mode is determined to be hit. This allows it to determine whether the pre-set test configuration file contains preset configuration information for the interface corresponding to the call request. If the test configuration file contains preset configuration information for the interface corresponding to the call request, the test result for the call request can be determined directly and efficiently based on this preset configuration information, thus avoiding impact on the normal production chain. In this way, by setting a lightweight interception layer between the driver layer and the graphics kernel layer, efficient and non-intrusive testing can be achieved without modifying the driver or UMD source code to add test logic, obtaining various required test results, thereby ensuring code quality and maintainability. The hook layer described above can also be called an interception layer or an injection layer.

[0075] Based on any of the above embodiments, in some optional implementations, step 203 or step 304 can be specifically executed as follows: the test results corresponding to the call request are fed back to the driver layer through the hook layer, and then fed back to the application by the driver layer. Thus, by feeding back the comprehensive simulation results of the required test response, i.e., the test results, to the driver layer, such as the UMD layer, and particularly by feeding back the test results corresponding to one or more of the exception tests, performance tests, and concurrency tests, the driver layer's ability to handle the corresponding response states can be further evaluated or tested to determine whether driver optimization is necessary.

[0076] In some optional implementations of any embodiment of this disclosure, the above testing method may further include the following: in response to determining that the test configuration file does not contain preset configuration information for the interface corresponding to the call request, the second response result fed back by the graphics kernel layer corresponding to the call request is determined as the test result.

[0077] In this embodiment, when it is determined that the test configuration file has not pre-set the corresponding configuration information for the current interface call, the hook layer can act as a relay, directly forwarding the intercepted call request to the graphics kernel layer. After the KMD layer and GPU interact to obtain the corresponding response, the response from the graphics inner layer is directly sent back as the required test result to achieve the normal graphics processing flow. Optionally, the application will continue to run in the production environment at this time.

[0078] In some optional implementations of any embodiment of this disclosure, the testing method may further include: in response to detecting an update instruction for the test configuration file, performing an update operation on the test configuration file. This enables dynamic and flexible updating of preset configuration information in the pre-set test configuration file, thereby achieving dynamic updates to test strategies and test behaviors, and further improving the flexibility and controllability of the test.

[0079] It should be noted that the response status indicated by the first and second response results above for the call request is of the same type as the content indicated by the test results, including but not limited to exceptions such as timeout and insufficient resources, as well as response statuses such as success and failure.

[0080] In some optional implementations of any embodiment of this disclosure, the above testing method may further include the following: generating a test report based on the test results corresponding to the call request determined by the above preset configuration information, so as to provide a query basis for subsequent problem tracing.

[0081] To deepen understanding, this disclosure also provides a specific implementation scheme for a testing method, using a concrete application scenario. This scheme offers a controllable testing system, such as the UMD testing system, whose core software architecture can include a test control layer and a hook layer. The test control layer can use languages ​​including Python to write test scripts, enabling dynamic configuration of test behaviors and supporting complex test scenario simulations via external scripts. Optionally, it supports defining rich test behaviors to form test configuration files to determine testing strategies. Thus, flexible, controllable, and non-intrusive testing can be achieved without modifying the UMD production code or source code, ensuring code quality and maintainability. Furthermore, by pre-configuring test strategies based on the aforementioned test configuration files—such as pre-configuring test types, the correspondence between interface calls and test / response results, etc.—a large number of test cases can be executed quickly, achieving efficient testing. Moreover, by providing precisely controllable test conditions, it facilitates problem reproduction and debugging.

[0082] Optionally, in this implementation, the test strategy corresponding to the test configuration file can be dynamically modified via script during the testing process, enabling updates to the test strategy without restarting the application.

[0083] Optionally, the aforementioned test control layer can communicate with the hook layer via shared memory or a file system. Specifically, test configuration files can be transferred to the hook layer via shared memory or the file system for the hook layer to read the corresponding test configuration. The test process controlled by the aforementioned test script, corresponding to this implementation scheme, can be found in the following example: Figure 4 The process 400 shown includes the following: Step 401: The test script controls the start of the test.

[0084] Step 402: Load the test configuration file.

[0085] Step 403: Update or load the test behaviors in the test configuration file into shared memory.

[0086] Step 404: Launch the test application (APP).

[0087] Step 405: After startup, the application initiates a call request to load the user-mode driver UMD.

[0088] Step 406: The hook layer detects whether it is in test mode. If a test mode identifier (corresponding to the target identifier in the above embodiment) is detected, it means that it is in test mode, and step 407 can be activated; otherwise, if the test mode identifier is not detected, the normal graphics rendering process can be executed based on the production environment.

[0089] The hook layer in this implementation can be represented as a lightweight interception layer located between the UMD layer and the DXGK layer of the graphics rendering system. It is activated or enabled only for a specific application in test mode. Optionally, it can be activated only when a test mode identifier, such as a specific environment variable, registry key, and / or application identifier, is detected, thus achieving conditional activation.

[0090] Step 407: The hook layer reads the preset test behaviors in the test configuration file and analyzes the current test strategy.

[0091] Step 408: Based on the test strategy obtained from the hook layer parsing in step 407, determine the matching response mode when the UMD layer calls the DXGK layer (corresponding to the graphics kernel layer in the above embodiment) based on the call request.

[0092] Optionally, if the test type corresponding to the test strategy obtained by the hook layer is baseline testing, the call request is normally transmitted to the DXGK layer through the hook layer, and steps 409 and 410 are executed. If the test type corresponding to the test strategy obtained by the hook layer is exception testing, an error is injected, and steps 411 and 412 are executed. If the test type corresponding to the test strategy obtained by the hook layer is performance testing, performance simulation is performed, and steps 413 and 414 are executed. If the test type corresponding to the test strategy obtained by the hook layer is concurrency testing, steps 415 and 416 are executed. In this way, the comprehensiveness of the test can be ensured to cover all possible response states of DXGK, including success, failure, timeout, insufficient resources, etc.

[0093] Step 409: Based on the scheduling request, directly call the DXGK layer to continue executing subsequent graphics operations and obtain the corresponding graphics operation results (corresponding to the second response result in the above embodiment).

[0094] Optionally, the DXGK layer can also feed back the result of the graphics operation to the hook layer, which can then feed back the result of the graphics operation as the test result corresponding to the call request to the UMD layer.

[0095] Step 410: Record the normal call logs corresponding to this baseline test.

[0096] Step 411: The hook layer responds to the scheduling request, simulates the error response status corresponding to the error injected by the abnormal test based on the configuration in the test configuration file, and returns it to the UMD layer.

[0097] Step 412: Record the exception handling log corresponding to this exception test.

[0098] Step 413: The hook layer responds to the scheduling request, simulates the response status of the call after adding delay based on the configuration in the test configuration file (corresponding to the first response result in the above embodiment), and returns it to the UMD layer.

[0099] Step 414: Record the logs corresponding to this performance test.

[0100] Step 415: The hook layer responds to the scheduling request, simulates and reorders the response status corresponding to the call sequence based on the configuration in the test configuration file (corresponding to the first response result in the above embodiment), and returns it to the UMD layer.

[0101] Step 416: Record the logs corresponding to this concurrent test.

[0102] Optionally, the hook layer may include, but is not limited to, a communication module, an interception module, a simulation module, and a logging module. Specifically, the communication module can be used to read the test behaviors configured by the test control layer; the interception module can be used to intercept calls from the UMD layer to the DXGK layer; the simulation module can be used to simulate the aforementioned response states of DXGK according to the test strategy; and the logging module can be used to record key information during the test process, forming a log.

[0103] In this embodiment, the hook layer can be understood as adding extra auxiliary test code to the UMD source code, and enabling the auxiliary test logic when the test conditions are met. This does not affect the original driving logic and does not require manual modification of the UMD source code. Optionally, the hook layer can be set inside or outside the UMD layer.

[0104] Step 417: Collect test results based on the above logs.

[0105] Step 418: Generate a test report based on the collected test results.

[0106] Further reference Figure 5 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a testing apparatus, which is similar to... Figure 2 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices (e.g., servers).

[0107] like Figure 5 As shown, the testing apparatus 500 of this embodiment may include: a receiving module 501, a processing module 502, and a sending module 503.

[0108] The receiving module 501 is configured to receive a call request from an application; the processing module 502 is configured to determine the test result corresponding to the call request based on the preset configuration information of the interface corresponding to the call request in response to determining that the test configuration file contains preset configuration information for the interface corresponding to the call request; and the sending module 503 is configured to send the test result back to the application.

[0109] In this embodiment of the disclosure, the specific processing of the receiving module 501, processing module 502, and sending module 503 in the testing device 500, and the resulting technical effects, can be found by referring to [reference needed]. Figure 2 The relevant descriptions of steps 201-203 in the corresponding embodiments will not be repeated here.

[0110] In some optional implementations of the embodiments of this disclosure, the processing module 502 may also be used to: in response to detecting a target identifier corresponding to the application being in test mode, determine whether the test configuration file contains preset configuration information for the interface corresponding to the call request.

[0111] In some optional implementations of the embodiments of this disclosure, the target identifier includes at least one of the following: an application identifier, an environment variable identifier corresponding to the test mode, and a registry entry corresponding to the test mode.

[0112] In some optional implementations of the embodiments of this disclosure, the preset configuration information includes the test type and response result for the interface; and the processing module 502 is further configured to: determine the test type for the interface based on the preset configuration information, wherein the test type includes at least one of functional testing, performance testing and concurrency testing; and determine the first response result corresponding to the test type contained in the preset configuration information as the test result.

[0113] In some optional implementations of the embodiments of this disclosure, the aforementioned preset configuration information may further include: an identifier of the interface, and the association between the identifier of the interface and the test type and response result for the interface.

[0114] In some optional implementations of the embodiments of this disclosure, when the above test type includes functional testing, the functional test includes at least one of baseline testing and exception testing; when the above test type includes performance testing, the performance test includes delayed call testing; when the above test type includes concurrency testing, the concurrency test includes tests executed based on a reordered call sequence.

[0115] In some optional implementations of the embodiments of this disclosure, the receiving module 501 is further configured to: intercept the call request from the application to be sent to the graphics kernel layer via the driver layer through the hook layer; and the processing module 502 is further configured to: determine the test result corresponding to the call request based on the preset configuration information through the hook layer.

[0116] In some optional implementations of the embodiments of this disclosure, the processing module 502 may also be used to: in response to determining that the test configuration file does not contain preset configuration information for the interface corresponding to the call request, determine the second response result fed back by the graphics kernel layer corresponding to the call request as the test result.

[0117] In some optional implementations of the embodiments of this disclosure, the processing module 502 may also be used to: perform an update operation on the test configuration file in response to detecting an update instruction for the test configuration file.

[0118] This embodiment exists as a device embodiment corresponding to the above method embodiment. The key steps or equivalent technical means that can be implemented by each component in the test device 500 embodiment provided in this embodiment, as well as the technical effects brought about by this device embodiment, can be referred to the relevant descriptions in the above method embodiments, and will not be repeated here.

[0119] According to embodiments of this disclosure, this disclosure also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the test method described in any of the above embodiments.

[0120] According to embodiments of this disclosure, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions that enable a computer to perform the test methods described in any of the above embodiments when executed.

[0121] According to embodiments of this disclosure, this disclosure also provides a computer program product, which includes a computer program that, when executed by a processor, can implement the testing methods described in any of the above embodiments.

[0122] Figure 6A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0123] like Figure 6 As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the electronic device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0124] Multiple components in electronic device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of displays, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0125] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as test methods. For example, in some embodiments, the test method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the test method described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform test methods by any other suitable means (e.g., by means of firmware).

[0126] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0127] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0128] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0129] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0130] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0131] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, distributed system servers, or servers incorporating blockchain technology. Cloud servers, also known as cloud computing servers or cloud hosts, are a hosting product within the cloud computing service ecosystem, designed to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) services, such as high management difficulty and weak business scalability.

[0132] According to the technical solution of this disclosure, when a call request is received from an application and is to be sent to the graphics kernel layer via the driver layer, if it is determined that the configuration information of the interface corresponding to the current call request is pre-set in the test configuration file, the test result for the call request can be directly and efficiently determined based on the pre-set configuration information and fed back to the application. In this way, any required test response, i.e., test result, can be obtained flexibly and controllably based on the pre-set test configuration file, achieving comprehensive simulation of the required test response. This makes the acquisition of the test result not limited by the production environment, thereby supporting the simulation of complex test scenarios. Furthermore, through precise control of the test configuration, it is beneficial for problem reproduction and debugging, such as reproducing boundary conditions and abnormal states, achieving efficient and comprehensive testing.

[0133] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0134] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A testing method, characterized in that, include: Receive call requests from applications that are to be sent from the driver layer to the graphics kernel layer; In response to determining that the test configuration file contains preset configuration information for the interface corresponding to the call request, the test result corresponding to the call request is determined based on the preset configuration information; The test results are then fed back to the application.

2. The test method according to claim 1, wherein, The testing method also includes: In response to detecting a target identifier corresponding to the application being in test mode, it is determined whether the test configuration file contains preset configuration information for the interface corresponding to the call request.

3. The test method according to claim 2, wherein, The target identifier includes at least one of the following: the identifier of the application, the environment variable identifier corresponding to the test mode, and the registry entry corresponding to the test mode.

4. The test method according to claim 1, wherein, The preset configuration information includes the test type and response result for the interface; as well as The step of determining the test result corresponding to the call request based on the preset configuration information includes: The test type for the interface is determined based on the preset configuration information, wherein the test type includes at least one of functional testing, performance testing, and concurrency testing; The first response result corresponding to the test type contained in the preset configuration information is determined as the test result.

5. The test method according to claim 4, wherein, The preset configuration information also includes: the identifier of the interface, and the association between the identifier of the interface and the test type and response result for the interface.

6. The test method according to claim 4, wherein, When the test type includes the functional test, the functional test includes at least one of baseline test and exception test; If the test type includes the performance test, the performance test includes a delayed call test; When the test type includes the concurrent test, the concurrent test includes tests executed based on a reordered sequence of calls.

7. The test method according to any one of claims 1-6, wherein, The receiving of a call request from an application, to be sent from the driver layer to the graphics kernel layer, includes: The hook layer intercepts the call request from the application, which is to be sent to the graphics kernel layer via the driver layer; and The step of determining the test result corresponding to the call request based on the preset configuration information includes: The hook layer determines the test result corresponding to the call request based on the preset configuration information.

8. The test method according to claim 1, wherein, The testing method also includes: In response to determining that the test configuration file does not contain preset configuration information for the interface corresponding to the call request, the second response result fed back by the graphics kernel layer corresponding to the call request is determined as the test result.

9. The test method according to any one of claims 1-6, wherein, The testing method also includes: In response to the detection of an update instruction for the test configuration file, an update operation is performed on the test configuration file.

10. A testing apparatus, characterized in that, include: The receiving module is configured to receive call requests from the application that are to be sent from the driver layer to the graphics kernel layer; The processing module is configured to determine the test result corresponding to the call request based on the preset configuration information in response to determining that the test configuration file contains preset configuration information for the interface corresponding to the call request; The sending module is configured to send the test results back to the application.

11. 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 instructions that can be executed by the at least one processor to enable the at least one processor to perform the test method according to any one of claims 1-9.

12. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the processor to execute the test method according to any one of claims 1-9.

13. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the test method according to any one of claims 1-9.

Images