Gpu-driven testing method, system, device, and storage medium

Abstract

This application provides a testing method, system, device, and storage medium for GPU drivers. The GPU driver code repository includes multiple source code libraries. The method includes: responding to a merge instruction, determining a first source code library corresponding to the merge instruction, the merge instruction indicating that the modified code of the first source code library be added to the library; constructing a workflow based on the first source code library, performing access control tests on the modified code of the first source code library through the workflow to check the code's standardization and / or functionality; if the access control test passes, merging the modified code into the first source code library, thus realizing the addition to the library; and performing product integration testing based on the updated code repository. This application can improve the efficiency of code detection.

Description

Technical Field

[0001] This application relates to the field of testing, and more particularly to a GPU driver testing method, system, device, and storage medium. Background Technology

[0002] A Graphics Processing Unit (GPU) is a microprocessor specifically designed for graphics processing in personal computers, workstations, game consoles, and some mobile devices such as tablets and smartphones. A GPU driver is a software program that controls the GPU; it manages the GPU's functions and performance to ensure its proper operation.

[0003] In related technologies, when upgrading GPU drivers, it is necessary to detect the changed code in the update package. Specifically, a unified detection is performed on all driver code to check for problematic code in the updated code. However, GPU driver code is very large and complex, and the code detection efficiency of related technologies is relatively low. Summary of the Invention

[0004] This application relates to a GPU driver testing method, system, device, and storage medium to improve code detection efficiency.

[0005] In a first aspect, this application provides a testing method for a GPU driver, wherein the test code of the GPU driver is stored in multiple source code libraries. The method includes: in response to a merge instruction, determining the source code library to which the modified code belongs; for each source code library, constructing a workflow corresponding to the source code library, and performing access control testing on the modified code of the source code library through the workflow; if the test is qualified, updating the modified code of the source code library to the source code library; and performing testing based on the updated test code in the multiple source code libraries.

[0006] In some embodiments, the workflow built based on the first source code library includes: if the first source code library depends on at least one other second source code library, then building a workflow based on the modified code of the first source code library and the second deployment file of the second source code library to establish the software environment for the access control test.

[0007] In some embodiments, the workflow built based on the modified code of the first source code library and the second deployment file of the second source code library includes: the server of the first source code library pulls the modified code of the first source code library and generates a first deployment file; and the first deployment file is sent to a first test machine; the first test machine is used to perform access control testing on the first source code library; the first test machine obtains the second deployment file and deploys the first deployment file and the second deployment file to a predetermined target test environment to perform the access control test.

[0008] In some embodiments, the first test machine obtains the second deployment file by: obtaining the local second deployment file and determining whether the local second deployment file is the latest version; if it is the latest version, then using the local second deployment file as the second deployment file; otherwise, updating the version from the server of the second source code repository and obtaining the second deployment file.

[0009] In some embodiments, the first test machine obtains the second deployment file by: obtaining the local second deployment file, determining whether the update identifier of the local second deployment file is consistent with the current update identifier of the second source code library; the update identifier is used to characterize whether the code change of the second source code library affects the GPU function; if they are consistent, the local second deployment file is used as the second deployment file; otherwise, the version is updated from the server of the second source code library to obtain the second deployment file.

[0010] In some embodiments, performing access control testing includes: detecting whether the modified code conforms to established code specifications; and / or detecting whether the interfaces in the modified code conform to established interface specifications.

[0011] In some embodiments, the GPU driver is applied to at least one operating system; then, the product integration testing based on the updated plurality of source code libraries includes: in response to a test instruction, determining the test items for the GPU driver; based on the test items, the GPU adapted to the GPU driver, and the operating system applied to the GPU driver, deploying at least one second test machine; the second test machine is used to perform stability testing, performance testing, or functional testing; deploying the code repository to the at least one second test machine; and for each second test machine, executing the corresponding test items in a predetermined operating system on the code to be tested.

[0012] Secondly, the testing system includes a memory, a management platform, and a second testing machine; the memory is a GPU driver code repository, which includes multiple source code libraries; the management platform is used to respond to a merge instruction and determine the first source code library corresponding to the merge instruction, the merge instruction being used to instruct the modification code of the first source code library to be added to the repository; the management platform is also used to build a workflow based on the first source code library, and to perform access control testing on the modification code of the first source code library through the workflow to check the code's standardization and / or functionality; if the access control test passes, the modification code is merged into the first source code library, thus realizing the addition to the repository; the second testing machine is used to perform product integration testing based on the updated code repository.

[0013] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method described above.

[0014] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described above.

[0015] In the GPU driver testing method, testing system, device, and storage medium provided in this application embodiment, the GPU driver code to be tested is stored in multiple source code libraries. During testing, a workflow is established for each source code library, and access control tests are performed individually on the changed code in the source code library. If the test is qualified, the code is updated to that source code library; if a problem exists, the problematic code is identified from the changed code in the source code library. Because this solution stores and tests the updated driver code on a source code library basis, compared with related technologies, when a problem is detected, the problematic part of the driver code can be quickly located, thus improving the code testing efficiency. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] Figure 1 This is an example of the architecture diagram of a GPU driver under a Linux system;

[0018] Figure 2 This is a schematic diagram of the structure of a test system in an example;

[0019] Figure 3 This is a diagram illustrating the correspondence between the architecture layer and the source code library in an example.

[0020] Figure 4 A flowchart illustrating a GPU driver testing method provided in an embodiment of this application;

[0021] Figure 5 A flowchart of a testing method provided in an embodiment of this application;

[0022] Figure 6 A flowchart illustrating another GPU driver testing method provided in this application embodiment;

[0023] Figure 7 A flowchart illustrating yet another GPU driver testing method provided in this application embodiment;

[0024] Figure 8 This is a schematic diagram of the structure of a GPU driver testing device provided in this embodiment;

[0025] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0026] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] A GPU is a microprocessor specifically designed for graphics processing in personal computers, workstations, game consoles, and some mobile devices (such as tablets and smartphones). A GPU driver is a software program that controls the GPU. It is responsible for managing the GPU's functions and performance, and for performing instruction translation, resource scheduling, and state management between the operating system, upper-level applications, and the GPU hardware to ensure the GPU operates normally and is compatible with the operating system and other software.

[0029] Figure 1 Here is an example of a GPU driver architecture diagram under a Linux system, such as... Figure 1As shown, a GPU driver comprises multiple architectural layers, from bottom to top: The kernel driver layer, responsible for low-level interaction with the GPU hardware, such as hardware resource management, video memory management, interrupt handling, and command scheduling; the rendering layer (Direct Rendering Infrastructure, DRI), defining standards for hardware-accelerated graphics rendering on Linux and providing basic support for upper-layer graphics libraries to access the underlying graphics hardware; the graphics library layer, providing OpenGL and / or interactive 3D graphics libraries (OpenGLES) for upper-layer applications to call graphics drawing, rendering, or image processing capabilities; the video card framework layer, defining how to manage graphics hardware on the operating system and providing a unified graphics hardware management interface for upper-layer applications or system components; and the driver layer, provided by the hardware manufacturer, encapsulating hardware-specific implementation details and integrating with the kernel driver and graphics library to enable upper-layer software to adapt to different models or architectures of GPU hardware.

[0030] The functionality of each architectural layer depends on other architectural layers; that is, there are dependencies between the architectural layers. For example, in a Linux system, such as... Figure 1 As shown, upper-level architecture layers depend on lower-level architecture layers, such as the graphics library layer depending on the rendering layer, and the video card framework layer depending on the graphics library layer. In other words, when the code of a certain architecture layer changes, the change may not only affect the functionality of that architecture layer itself, but also the construction, deployment, or testing results of other architecture layers that depend on it.

[0031] It should be noted that the above only illustrates the application of GPU drivers under Linux systems. In practice, GPU drivers can be applied to various operating systems, such as Windows and iOS. The GPU driver architecture, build artifacts, and deployment methods may differ across operating systems, but all may involve multiple software components that depend on each other and work together to implement GPU functionality.

[0032] In related technologies, GPU driver upgrades require the detection of changed code. Specifically, a unified detection is performed on all changed code during each update to check for problematic code. However, GPU drivers involve multiple layers such as graphics rendering, parallel computing, and physics simulation, making the GPU driver code extremely large and complex. Related technologies cannot quickly locate problematic code, resulting in low code detection efficiency.

[0033] To address the aforementioned technical problems, this application proposes the following technical concept: The GPU driver code is stored in multiple source code libraries, each corresponding to an architecture layer. During testing, a workflow is established for each source code library, and the modified code within that library is tested individually. If the test passes, the changes are updated to that source code library. If an anomaly is detected during testing, the problematic code causing the anomaly is identified from the modified code within that source code library. Because this solution performs testing on a source code library basis, compared to related technologies, when a problem is detected, the problematic code can be quickly located through the source code library, thus improving testing efficiency.

[0034] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0035] Example 1

[0036] This application provides a testing method, which can be executed by a testing device, a testing system, or other electronic devices equipped with a testing system. For ease of explanation, the following description uses a testing system as the executing entity.

[0037] Figure 2 Here is a schematic diagram of the structure of a test system in an example, such as Figure 2 As shown, the test system includes a management platform 20, a test machine 30, and a memory 10.

[0038] The management platform 20 manages the testing process of the GPU driver on the test machine 30. The management platform 20 can respond to merge commands, build or trigger workflows using the source code library corresponding to the merge command, and schedule the test machine 30 to execute GPU driver access control tests and / or product integration tests. In some examples, the management platform 20 can be a management tool that supports build, deployment, and automated testing, such as Kubernetes, Jenkins, or other continuous integration / continuous deployment tools; this application does not limit this.

[0039] Test machine 30 can be a server with GPU driver testing capabilities. Test machine 30 can be configured with the GPU to be tested, the corresponding operating system, and the software environment required to execute the test. The number of test machines can be set based on the number of GPU driver test items, the operating system of the GPU driver application, and the type of GPU. It can be understood that the more test machines there are, the faster the testing efficiency. If there are multiple test machines, they can be clustered together for unified scheduling and management. In some embodiments, test machine 30 may include a first test machine and a second test machine. The first test machine is used to perform access control testing before the changed code is added to the repository, and the second test machine is used to perform product integration testing after the changed code is added to the repository.

[0040] The memory is used to store the source code of the GPU driver. This memory can be located on any server in the testing system, or it can be a standalone code management server, a distributed storage system, or a remote code repository; this application does not impose any limitations on this.

[0041] In some embodiments, the memory may include multiple source code libraries, which are used to store the code of different driver components in the GPU driver, and are stored in corresponding architecture layers. Driver components can be understood as software components in the GPU driver divided according to their responsibilities, such as kernel driver components, rendering components, graphics library components, video card framework components, driver components, etc.

[0042] Figure 3 This is a diagram illustrating the correspondence between the architecture layer and the source code library in an example, such as... Figure 3 As shown, and in combination Figure 1 In the example, the storage includes source code libraries A through E, each corresponding to a specific source code library. Figure 1 There are five architectural layers, and each source code repository stores the source code for the corresponding architectural layer. It should be noted that... Figure 3 This example only illustrates one correspondence between source code libraries and architecture layers. In other embodiments, a source code library may correspond to a functional module or multiple interconnected driver components; this application does not limit this. Furthermore, Figure 3 The names of the source code libraries in this document are merely illustrative of the correspondence between different architecture layers and source code libraries; the first source code library in this application refers to the source code library corresponding to this merge instruction, which can be... Figure 3 Any of the source code libraries shown.

[0043] For each source code repository, different access permissions, merging permissions, testing permissions, or management permissions can be set through the management platform, allowing users with the corresponding permissions to manage the source code repository. This enables separate repository management and testing for different driver components in multi-source code repository scenarios, facilitating the rapid identification of problematic source code repositories and their modified code when tests fail.

[0044] For example, the management platform can configure permission parameters for source code repositories A through E. These parameters can include user identifier, source code repository identifier, and operation type. For instance, user A has code submission and merge request initiation permissions for source code repository A, user B has testing permissions for the second source code repository, and user C has merge approval permissions for source code repositories A and B. When a test of modified code in source code repository A fails, the management platform can determine the source code repository A corresponding to the failure based on the source code repository identifier and push the failure information to user A or user C, who has management permissions for source code repository A, to quickly locate and handle the problematic code in source code repository A.

[0045] The testing method for the GPU driver provided in this application will be described below as an example.

[0046] Figure 4 A flowchart of a GPU driver testing method provided in this embodiment is shown below. Figure 4 As shown, the test method may include:

[0047] S401. In response to the merge instruction, determine the first source code library corresponding to the merge instruction. The merge instruction is used to instruct the modified code of the first source code library to be added to the library.

[0048] S402. Build a workflow based on the first source code library, and perform access control tests on the changed code in the first source code library through the workflow to check the code's standardization and / or functionality;

[0049] S403. If the access control test passes, the modified code will be merged into the first source code library and added to the library.

[0050] S404. Perform product integration testing based on the updated code repository.

[0051] In this embodiment, the GPU driver testing process is divided into two stages: pre-inclusion testing and post-inclusion testing. Pre-inclusion testing mainly performs access control testing on the modified code requested for inclusion in the first source code library. This is used to check whether the modified code has any code style or functional issues before merging, thereby reducing the risk of problematic code entering the code repository. Post-inclusion testing mainly performs product integration testing on the updated code repository formed after the modified code is merged. This is used to verify whether the GPU driver formed by combining driver components from multiple source code libraries can run normally under the applied operating system and target GPU environment.

[0052] Since access control testing examines modified code in the primary source code repository, it's relatively easy to pinpoint problematic code when tests fail. However, product integration testing examines the entire updated code repository or its resulting GPU driver deployment files, requiring a broader testing scope. If issues are only discovered at this stage, localization becomes more difficult. Therefore, this embodiment employs a two-stage testing approach: "access control testing before code inclusion + product integration testing after code inclusion." This allows modified code to be identified early through access control testing before inclusion, and also enables the verification of the GPU driver's overall functionality, performance, and stability through integration testing after inclusion, thereby improving the efficiency and accuracy of GPU driver testing.

[0053] S401 to S402 are access control tests before warehousing, while S403 and S404 are product integration tests after warehousing. Further explanation of each step follows.

[0054] In S401, the management platform responds to a merge command by identifying the first source code repository corresponding to the merge command. For example, a merge command can be triggered based on a user action, or it can be automatically triggered at a preset time or under preset conditions. The merge command instructs the developer to merge locally updated code into the code repository.

[0055] In one example, the testing system may also include a code management platform, which can be used for code hosting, version control, merge request management, continuous integration, continuous delivery, and artifact management. For example, the code management platform may include GitLab, which has functions such as code hosting, version control, continuous integration, continuous delivery, and container registry. Taking Jenkins as an example, users can issue merge requests (MRs) through GitLab, triggering a task on the Jenkins platform to create changed code.

[0056] For example, developer A submits an interface adaptation code to the source code repository corresponding to the graphics library layer and initiates a merge request (MR) on GitLab. GitLab can send a trigger request to the Jenkins platform based on the source code repository address, branch information, and commit identifier in the MR. After receiving the trigger request, the Jenkins platform can determine that the merge instruction corresponds to the graphics library layer source code repository and use that graphics library layer source code repository as the first source code repository.

[0057] In this embodiment, since the GPU driver code repository includes multiple source code libraries, and different source code libraries can be maintained by different users, the modified code corresponding to different merge instructions may belong to different source code libraries. In some cases, a merge instruction can correspond to modified code in one source code library; in other cases, a merge instruction can correspond to modified code in multiple source code libraries.

[0058] When a merge instruction corresponds to modified code in multiple source code repositories, the management platform can split the merge instruction into multiple sub-tasks based on the source code repository to which the modified code belongs. For example, if a merge instruction involves two primary source code repositories—the graphics library layer repository and the rendering layer repository—the management platform can create corresponding workflows for each repository, and then create and execute access control test tasks from these two workflows to test the modified code in each repository. For ease of explanation, the following description will primarily use one of the source code repositories as the primary source code repository.

[0059] In some embodiments, the management platform can determine the source code repository corresponding to the changed code based on one or more of the source code repository identifier, branch information, commit information, file path information, and merge request information carried in the merge instruction. For example, the management platform can determine the first source code repository based on the project ID or repository address in the MapReduce; it can also determine the first source code repository based on the changed file path. For example, if the path includes "kernel / gpu", the first source code repository is determined to be the kernel driver layer source code repository; if the path includes "mesa / opengl", the first source code repository is determined to be the graphics library layer source code repository; if the path includes "dri", the first source code repository is determined to be the rendering layer source code repository.

[0060] In some embodiments, the management platform can also determine parameter information such as the identifier of the first source code repository, the branch information corresponding to the changed code, the commit information, the committing user information, the changed file path, and the amount of changed code. This parameter information can be used to subsequently build the workflow corresponding to the first source code repository and perform access control tests.

[0061] By using the above method, the testing system can first determine the source code library and its modified code that need to be tested in a multi-source code library scenario, thereby avoiding indiscriminate testing of all source code libraries in the entire code repository.

[0062] In S402, the management platform builds a workflow for each source code repository. The platform can build workflows for different source code repositories simultaneously or sequentially. A workflow can be understood as a set of automated processes used to complete access control testing of the first source code repository. This workflow may include one or more steps such as code retrieval, code building, deployment file generation, deployment file transfer, test environment setup, access control test execution, and test result generation.

[0063] In some embodiments, the management platform can build a workflow based on information such as the source code repository identifier, code branch, build configuration, test configuration, and dependency configuration of the first source code repository.

[0064] For example, when the first source code repository is the source code repository corresponding to the kernel driver layer, the management platform can select a workflow that includes kernel module building steps, driver loading test steps, and hardware access test steps. When the first source code repository is the source code repository corresponding to the graphics library layer, the management platform can select a workflow that includes user-space library building steps, graphics interface test steps, and compatibility test steps. When the first source code repository is the test tool source code repository, the management platform can select a workflow that includes test tool building steps and test script self-check steps.

[0065] In some embodiments, the management platform uses a predefined configuration template to allow different source code repositories to correspond to different workflow configuration files. When a merge instruction corresponds to the first source code repository, the management platform can read the workflow configuration file corresponding to the first source code repository and construct a workflow for access control testing based on that workflow configuration file.

[0066] In other embodiments, the management platform may also pre-configure multiple workflow templates. Different workflow templates may correspond to different source code libraries, different driver components, different test projects, or different operating systems. The management platform can select the corresponding workflow template from the multiple workflow templates based on the information of the first source code library, and build the workflow based on that workflow template.

[0067] It's important to note that the management platform can create workflows only for source code repositories that include the changed code from this merge command, and not for those repositories. This improves detection efficiency. Alternatively, a workflow can be created for each source code repository, but access control testing can only be performed on the repositories that include the changed code.

[0068] In S402, access control tests are performed on the modified code of the first source code library through a workflow.

[0069] In this embodiment, the access control test is used to check whether the changed code meets the preset entry conditions before the changed code is entered into the database.

[0070] In some examples, access control testing may include: access control testing may include code style checks and / or functional checks.

[0071] The code style check can include verifying whether all modified code conforms to established code style guidelines. These guidelines can include naming conventions, commenting conventions, file directory conventions, and interface declaration conventions. Specifically, for naming conventions, it can check whether the names of newly added functions, variables, or macro definitions conform to preset naming rules; for commenting conventions, it can check whether newly added functions or interfaces contain comments in a preset format; for file directory conventions, it can check whether modified files are located in the source code directory corresponding to their function; and for interface declaration conventions, it can check whether newly added or modified interfaces contain parameter declarations, return value declarations, and error code declarations.

[0072] For example, the management platform can invoke a code style checking script to check the changed code. This script can include functions for name verification (`check_name_rule()`), comment verification (`check_comment_rule()`), directory verification (`check_path_rule()`), and interface declaration verification (`check_interface_rule()`). In one example, the management platform can set a passing threshold of 95% for name style, 80% for comment coverage, and 100% for interface declaration completeness. If the proportion of newly added functions or variables with compliant names in the changed code is not less than 95% of the total number of new functions or variables, the proportion of new functions or interfaces containing compliant comments is not less than 80%, and all new interfaces include parameter, return value, and error code declarations, then the code style check is considered passed; otherwise, the code style check is considered failed, and the failed style items and their corresponding file locations are output.

[0073] Functional testing can include at least one of interface testing, function execution testing, and functional flow testing. Functional testing is used to call the interfaces, functions, or functional flows involved in the changed code in the target test environment, and determine whether the functionality corresponding to the changed code meets expectations based on preset input parameters, output results, return values, error codes, status changes, or log information.

[0074] For example, if the modified code adds a GPU command submission interface `gpu_submit_cmd(buffer, size, flags)`, the access control test can call this interface with normal parameters, empty parameters, boundary parameters, and abnormal parameters, and compare the actual return value with the preset return value for each. If the interface returns a success status under normal parameters and a preset error code under abnormal parameters, and no timeout, abnormal exit, or driver error log occurs during execution, then the functional test is considered passed. If the actual return value of any test case is inconsistent with the preset return value, or if interface call failure or driver exception occurs, then the functional test is considered failed. In some embodiments, the access control test may also include basic functional testing. Basic functional testing can be used to detect whether the modified code of the first source code library can achieve the expected function in the target test environment.

[0075] In some embodiments, access control testing can be performed by an automated testing framework. For example, the testing system can encapsulate multiple test cases into an automated test suite and execute it automatically on a first test machine. After the test is completed, a visual test report can be generated to display information such as test pass rate, failed cases, and failure logs.

[0076] When there are dependencies between multiple source code libraries for GPU drivers, the management platform can also establish a software environment for access control testing when building a workflow based on the first source code library.

[0077] As an example, a workflow built on the first source code library in S402 may include:

[0078] If the first source code library depends on at least one other second source code library, then a workflow is built based on the modified code of the first source code library and the second deployment file of the second source code library to establish the software environment for access control testing.

[0079] The second source code repository is the source code repository that the first source code repository depends on among multiple source code repositories. The second deployment file is the deployment file corresponding to the second source code repository. The second deployment file can be an installation package, dynamic library, static library, driver module, image file, compressed file, or other files that can be deployed to the test environment generated after the second source code repository is built.

[0080] For example, the first source code library is the source code library corresponding to the video card framework layer, and the second source code library may include the source code library corresponding to the graphics library layer and the source code library corresponding to the rendering layer. Since the video card framework layer depends on the graphics library layer, and the graphics library layer depends on the rendering layer, the testing system can obtain the second deployment files corresponding to the graphics library layer source code library and the rendering layer source code library, which serve as the second source code library, respectively. These second deployment files, along with the first deployment file generated from the source code library corresponding to the video card framework layer (which serves as the first source code library), are then deployed together to the target testing environment.

[0081] It should be noted that when the first source code library is the source code library corresponding to the kernel driver layer, since the kernel driver layer can directly interact with the GPU hardware and is located at a relatively low level, it can operate without relying on other source code libraries in most testing scenarios. In this case, the management platform can directly build workflows based on the modified code in the first source code library and execute the corresponding access control tests.

[0082] In some embodiments, the workflow for building a second deployment file based on the modified code of the first source code repository and the second source code repository may include the following process.

[0083] First, the server of the first source code repository pulls the modified code from the first source code repository and generates the first deployment file.

[0084] The first deployment file is a deployment file generated based on the modified code of the first source code repository. The first deployment file can be a generated installation package, library file, image file, or other deployable file. The server for the first source code repository can be a server storing the first source code repository, or a build server or workflow execution node used to build the first source code repository.

[0085] For example, when the first source code library is the source code library corresponding to the kernel driver layer, the generated first deployment file may include kernel module files, installation scripts, and driver configuration files. When the first source code library is a test tool source code library, the generated first deployment file may include test scripts, test case configuration files, and test tool executable files. Then, the first deployment file is sent to the first test machine to execute access control testing. The first test machine separately obtains a second deployment file locally and deploys both the first and second deployment files to the predetermined target test environment to execute access control testing.

[0086] The target test environment can be a physical test environment within the first test machine, or a virtual machine, container, or other isolated test environment within the first test machine; this application does not limit this. For example, when performing access control testing on the graphics library layer source code library, the first test machine can first deploy the rendering layer source code library (i.e., Figure 3 The second deployment file corresponding to source code library B in the middle is then deployed to the graphics library layer source code library (i.e. Figure 3 The first deployment file corresponding to source code library A) is then executed, followed by OpenGL interface testing.

[0087] By deploying both the first and second deployment files to the target test environment, the modified code of the first source code library can be tested for access control in a software environment that satisfies the dependencies, thereby improving the accuracy of the test results.

[0088] In some embodiments, the workflow may include code fetching, building, deployment, and testing phases. The code fetching phase is used to obtain code from a first source code repository; the building phase is used to generate a first deployment file based on the code from the first source code repository; the deployment phase is used to deploy the first deployment file and a second deployment file corresponding to a second source code repository that the first source code repository depends on to the target testing environment of the first test machine; the testing phase is used to perform access control tests in the target testing environment and output the test results. The second deployment file can be the latest build file of the second source code repository, or a deployment file cached locally on the first test machine that meets the test requirements.

[0089] In practical applications, a workflow can be a set of automated task configurations generated or invoked by the platform based on merge instructions. This workflow may include parameters such as source code repository identifier, branch information, commit version, dependent source code repositories, build scripts, deployment targets, test case sets, and result feedback addresses.

[0090] For example, when the first source code library is a graphics library layer source code library, that is... Figure 3 The first source code library is C, and the second source code library is the rendering layer source code library, i.e. Figure 3 When source code library B is used, the management platform can generate the following workflow parameters:

[0091] repo=source_repository_C, branch=feature-opengl, commit=abc123, dependency=source_repository_B, build_script=build_graphics.sh, deploy_target=first_test_machine_01, test_env=container-opengl-01, test_suite=OpenGL_interface_test_set, result_url=MR_page_address.

[0092] Among them, repo is used to identify the first source code repository for which access control testing needs to be performed, branch and commit are used to determine the source code version containing the changed code, dependency is used to indicate the second source code repository that the first source code repository depends on, build_script is used to indicate the script executed during the build phase, deploy_target and test_env are used to indicate the deployment and test environments, test_suite is used to indicate the set of test cases to be executed, and result_url is used to indicate the location where test results are backfilled.

[0093] In this example, the execution entity in the code pull phase can be a build server or a workflow execution node. It pulls the source code library C containing changed code based on the repo, branch, and commit, and records the code version, pull path, and pull logs. The execution entity in the build phase can also be a build server or a workflow execution node. It executes `build_graphics.sh`, generating the first deployment file based on the source code library C, such as a graphics library dynamic library, header files, or an installation package, and caches the build logs, build status, and storage path of the first deployment file. The execution entity in the deployment phase can be a management platform, deployment tool, or the first test machine. It deploys the first deployment file and the second deployment file corresponding to source code library B to the target test environment `container-opengl-01` in the first test machine 01, and records the deployment version, deployment path, and deployment results. The execution entity in the testing phase can be the first test machine, which executes the OpenGL interface test suite in the target test environment and generates test logs, test results, and visualization reports. After each stage is completed, the management platform can cache the execution status, log files, deployment file paths, and test report addresses for the corresponding stage, and populate at least one of these results back to the MapReduce page so that users can view the workflow's execution progress and failure reasons. Therefore, a workflow can be understood as a set of automated tasks to be executed and their parameter configurations, rather than a simple concatenation of code from different source code repositories.

[0094] The following will provide an example of how to obtain the second deployment file.

[0095] In some embodiments, when the first test machine obtains the second deployment file, it can first obtain the local second deployment file and determine whether the local second deployment file is the latest version corresponding to the second source code library.

[0096] If the version information check indicates that the local second deployment file is the latest version corresponding to the second source code repository, then the local second deployment file will be used as the second deployment file. If the local second deployment file is not the latest version corresponding to the second source code repository, then the version will be updated from the server of the second source code repository to obtain the second deployment file.

[0097] The version information may include at least one of the following: version number, build number, source code commit number, file hash value, and generation time.

[0098] For example, the first test machine locally caches a second deployment file corresponding to the rendering layer source code repository. The version information of this second deployment file includes source code commit number abc123 and build number build_001. If the current latest version information recorded by the second source code repository server also contains source code commit number abc123 and build number build_001, the first test machine can determine that the locally cached second deployment file is the latest version and directly use it. If the current latest version information recorded by the second source code repository server is source code commit number def456 or build number build_002, the first test machine can determine that the locally cached second deployment file is not the latest version and obtain the second deployment file corresponding to the latest version from the second source code repository server.

[0099] This example is suitable for scenarios with high requirements for test environment consistency. That is, as long as the source code library being relied upon is updated, the latest version of the second deployment file is used to reduce the risk of inaccurate test results due to outdated dependency files.

[0100] In other embodiments, in order to reduce unnecessary duplicate builds and deployments, when the first test machine obtains the second deployment file, it can also determine whether to reuse the local second deployment file based on the valid version identifier.

[0101] Specifically, the first test machine can obtain the local second deployment file and determine whether the valid version identifier of the local second deployment file is consistent with the current valid version identifier of the second source code repository.

[0102] The valid version identifier is used to identify the version of the code in the second source code library that affects GPU functionality. If the valid version identifier of the local second deployment file matches the current valid version identifier of the second source code library, it means that the version of the code affecting GPU functionality in the second source code library has not changed. In this case, even if the local second deployment file is not the latest version corresponding to the second source code library, the local second deployment file can still be used as the second deployment file.

[0103] If the valid version identifier of the local second deployment file is inconsistent with the current valid version identifier of the second source code repository, it means that the version of the code affecting GPU functionality in the second source code repository has changed. In this case, the version can be updated from the server of the second source code repository to obtain the second deployment file.

[0104] Furthermore, by comparing the values ​​of the first and second valid version identifiers, it can be determined whether the valid version identifier of the local second deployment file is consistent with the current valid version identifier of the second source code library. For example: The first test machine has a local cache of a second deployment file corresponding to version V1 of the source code library for the rendering layer. This second deployment file corresponds to the kernel driver layer, and its valid version identifier is F1=R10-M20-C30. Here, R10 represents the rendering logic version, which can refer to the version of the code related to rendering context creation, rendering state setting, or drawing call processing; M20 represents the video memory management logic version, which can refer to the version of the code related to buffer objects, texture resources, or video memory resource management; and C30 represents the command submission logic version, which can refer to the version of the code related to rendering command encapsulation, queuing, and submission. The above valid version identifiers can be generated based on a preset correspondence between functional items and code scopes, such as the commit number, file hash value, build number, or version number of the code file corresponding to each functional item.

[0105] The second deployment file is used to provide the dependency environment for access control testing of the first source code repository. For example, if the first source code repository is a graphics library layer source code repository, the first deployment file corresponds to the changed code of the graphics library layer, and the second deployment file corresponds to the rendering layer code that it depends on. If it is detected through changes in file path, commit tags, code difference information, or file hash value that the current version V2 of the second source code repository has only modified comments, documentation, or log content, and has not modified the rendering logic, video memory management logic, and command commit logic, then the effective version identifier of version V2 is still F1=R10-M20-C30. In this case, the first test machine can continue to use the second deployment file corresponding to the local version V1. If it is detected that the current version V3 of the second source code repository has modified the code corresponding to the command submission logic, the effective version identifier of version V3 can become F2=R10-M20-C31. At this time, the effective version identifiers are inconsistent. The first test machine needs to obtain the updated second deployment file from the server of the second source code repository by either downloading the updated build artifacts or triggering the build process of the second source code repository to regenerate the deployment file, so that the dependency deployment file in the target test environment is consistent with the version of the code affecting GPU function in the second source code repository.

[0106] In some embodiments, a valid version identifier can be generated based on code files related to GPU functionality by extracting version information corresponding to each code file and combining the version information according to preset rules. For example, a valid version identifier can be generated based on the commit number, file hash value, version number, or build number of memory management code files, command submission code files, rendering interface code files, hardware control code files, through string concatenation, hash calculation, version number mapping, or build number combination.

[0107] In some embodiments, the valid version identifier can also be generated based on a preset list of function-related files. For example, the management platform pre-stores a list of function-related files, which is constructed from code file paths, file types, function module identifiers, and / or source code directory identifiers related to GPU function implementation, including memory management code files, command submission code files, rendering interface code files, hardware control code files, graphics resource management code files, etc. When a code change is detected in the second source code library through the changed file path in the merge request, source code submission record, file difference information, and / or code scanning results, if the changed file belongs to the list of function-related files, the current valid version identifier of the second source code library is updated. The valid version identifier is updated to a new valid version identifier by incrementing the version number, replacing sub-identifiers, recalculating hash values, or updating the build number; if the changed file does not belong to the list of function-related files, the current valid version identifier of the second source code library remains unchanged.

[0108] For example, the list of function-related files includes the paths / render / context / *, / memory / buffer / *, and / command / submit / *, corresponding to rendering logic, video memory management logic, and command submission logic, respectively. If the current valid version identifier of the second source code repository is F1=R10-M20-C30, and the management platform detects that the only changed file is / docs / readme.md or / log / format.txt, since this changed file does not belong to the list of function-related files, the valid version identifier remains F1=R10-M20-C30. If the management platform detects that the changed file is / command / submit / queue.c, which belongs to the function-related file corresponding to the command submission logic, then the sub-identifier corresponding to the command submission logic can be updated from C30 to C31, thereby updating the current valid version identifier of the second source code repository to F2=R10-M20-C31.

[0109] By using the above method, even if the code in the second source code repository is updated, it can be further determined whether the update affects the GPU function; if the GPU function is not affected, the local second deployment file can be reused, thereby reducing unnecessary rebuilding and redeployment.

[0110] In S403, if the access control test passes, the changed code will be merged into the first source code library and put into the library.

[0111] Specifically, when the access control test results indicate that the modified code in the first source code library conforms to the code specifications and / or meets the functional requirements, the management platform can allow the modified code to be merged into the target branch of the first source code library, thereby realizing the entry into the library.

[0112] To illustrate with an example: The first source code repository is the graphics library layer source code repository, the target branch is main, the branch containing the changed code is feature-opengl-001, and the merge request number is MR-1001. After performing access control testing, the management platform generates a test result `gate_result`, where `code_check=pass` indicates that the code style check passed, `interface_test=pass` indicates that the interface test passed, and `basic_function_test=pass` indicates that the basic function test passed. When the management platform detects that `gate_result={code_check:pass,interface_test:pass,basic_function_test:pass}`, it can determine that the changed code in the first source code repository meets the inclusion criteria and merges the changed code in the feature-opengl-001 branch into the main branch of the first source code repository. If any check item in `gate_result` is `fail`, such as `interface_test=fail`, it means that the management platform refuses the merge operation and sends the failed interface name, failed test case number, log address, and other information back to the page corresponding to MR-1001 so that the developers can modify the changed code and re-initiate the access control test.

[0113] In some embodiments, if the access control test fails, the management platform may refuse to merge the changed code into the first source code repository, or suspend the merging operation. The management platform may also output access control test failure information. This information may include the failure stage, failure test cases, failure logs, failure reasons, code style check results, and interface check results.

[0114] For example, if code style check fails, the access control test failure information may include the file path, line number, and style item that does not conform to the style. If interface test fails, the access control test failure information may include the failed interface name, input parameters, expected return value, actual return value, and error log.

[0115] In some embodiments, the management platform can record the code retrieval results, build results, deployment results, and test results during the access control testing process, and output a test report. The test report can be displayed in text, table, web page, or other visual formats.

[0116] In some embodiments, the management platform can also backfill the access control test results to the code management platform. For example, the management platform can backfill the execution results of code pull, build, deployment, and testing phases to the page corresponding to the merge request so that developers can view them.

[0117] In some embodiments, after the access control test passes, the management platform can also send a notification to the user, auditor, or tester corresponding to the merge request. The notification method may include email, instant messaging, platform messages, etc. The user or auditor can confirm the merge of the changed code based on the notification.

[0118] Because this application performs access control testing on a per-source-code-repository basis, when the access control test fails, the problem can be limited to the modified code in the first source code repository. Compared to uniformly testing all modified code in all source code repositories, this application can more quickly locate the problematic source code repository and its modified code, thereby improving code detection efficiency.

[0119] The following is combined with Figure 5 This document provides an exemplary description of the complete execution process of the pre-entry access control test.

[0120] Figure 5 This is a schematic diagram of a pre-entry access control test process provided in an embodiment of this application. Figure 5 As shown, after developers submit changes to the first source code repository and initiate a MapReduce (MR), the MR triggers the Jenkins platform to execute the corresponding Pipeline. During the Pipeline execution, the Jenkins platform compares the version information of the second deployment file on the first test machine with the current version information of the second source code repository, and / or compares the valid version identifier of the second deployment file on the first test machine with the current valid version identifier of the second source code repository to determine whether the access control test needs to update the second deployment file. If it detects that the local second deployment file is the latest version corresponding to the second source code repository, or that the valid version identifier of the local second deployment file matches the current valid version identifier of the second source code repository, it means that no update is needed, and the existing second deployment file on the first test machine is used. If the second deployment file on the local machine is not the latest version corresponding to the second source code repository, or if the valid version identifier of the local second deployment file is inconsistent with the current valid version identifier of the second source code repository, it indicates that an update is needed. In this case, the second deployment file is updated first, and then the second deployment file and the first deployment file corresponding to the first source code repository are deployed to the target test environment of the first test machine. After the first test machine performs access control testing on the changed code, if the test passes, the Jenkins platform will feed back the test pass result to MR and notify the user or reviewer to merge the changed code into the first source code repository. If the test fails, test failure information and a visual report will be output so that developers can locate the problematic code in the changed code of the first source code repository based on the report. Therefore, automated access control testing for a single source code repository can be completed before it is put into the repository, and targeted updates can be performed when the dependent environment needs to be updated, thereby reducing unnecessary duplicate builds and deployments and improving access control testing efficiency.

[0121] The above provides an exemplary description of the access control testing process before warehouse entry. The following will provide an exemplary description of the testing process after warehouse entry.

[0122] After all the changed code in each source code repository is entered into the repository, S404 is executed. In S404, product integration testing is performed based on the updated code repository.

[0123] After the changed code is merged into the first source code repository, the code repository is updated. At this point, the management platform can perform product integration testing based on the updated code repository.

[0124] Product integration testing differs from access control testing. Access control testing primarily checks whether modified code in the primary source code repository can be added to the repository; product integration testing primarily checks whether the GPU driver generated from the updated code repository can run normally in the production environment.

[0125] In some embodiments, the GPU driver is applied to at least one operating system. The operating system may include Linux, Windows, iOS, or other operating systems. The GPU driver deployment files, deployment methods, or test projects may differ for different operating systems.

[0126] Product integration testing based on the updated code repository can include the following: Figure 6 The process is shown.

[0127] First, S4041, in response to the test command, determines the test items for the GPU driver.

[0128] Test commands can be triggered by testers or automatically by the management platform after code changes are committed to the repository. Test items can include stability testing, performance testing, or functional testing.

[0129] Functional testing can be used to check whether the GPU driver functions correctly, such as graphics rendering, API calls, image display, driver loading, GPU device recognition, resolution switching, refresh rate switching, and multi-screen display, to ensure they meet expectations. Performance testing can be used to check the GPU driver's performance in specified scenarios, such as frame rate, response time, throughput, resource utilization, GPU utilization, and video memory utilization. Stability testing can be used to check whether the GPU driver is stable under long-term operation, repeated calls, or high-load operation, such as long-term graphics rendering tests, repeated driver loading and unloading, long-term video playback, or running computational tasks.

[0130] Secondly, based on the test project, the GPU adapted to the GPU driver, and the operating system applied by the GPU driver, deploy at least one second test machine. The second test machine is used to perform stability tests, performance tests, or functional tests.

[0131] The second test machine can be deployed or selected based on the test item, GPU type, and operating system. For example, if the test item is an OpenGL functional test, the GPU driver is adapted to the first model GPU, and the operating system is the first Linux distribution, then a second test machine with the first Linux distribution installed and configured with the first model GPU can be selected. If the test item is a stability test, and the operating system is the second Linux distribution, then a second test machine with the second Linux distribution installed can be selected to continuously run the stability test for a preset duration.

[0132] In some embodiments, if product integration testing needs to cover multiple operating systems, multiple GPU types, and multiple test items simultaneously, multiple second test machines can be configured. These multiple second test machines can form a test cluster to execute different test tasks in parallel.

[0133] For example, the first test machine is used to perform functional tests under the first operating system, the second test machine is used to perform performance tests under the second operating system, and the third test machine is used to perform stability tests under the third operating system. The management platform can distribute different test tasks to the corresponding test machines to improve the efficiency of product integration testing.

[0134] In one implementation, at least one second test machine can be deployed for each GPU and operating system combination, and multiple test items can be executed sequentially on the second test machine. For example, if the GPU driver is compatible with two GPUs and three operating systems, six types of second test machines can be configured, each type corresponding to one GPU and one operating system combination; each type of second test machine can sequentially execute functional tests, performance tests, and stability tests. This approach can reduce the number of test machines and is suitable for scenarios with limited testing resources.

[0135] In another implementation, a second test machine can be deployed for each combination of GPU, operating system, and test item. For example, if the GPU driver is compatible with two GPUs, three operating systems, and three test items, then eighteen types of test tasks can be configured, each corresponding to a different combination of GPU, operating system, and test item. This approach allows for the parallel execution of more test tasks and is suitable for scenarios with ample test resources and a need for rapid completion of product integration testing.

[0136] S4043. Generate a GPU driver deployment file corresponding to the operating system based on the updated code repository, and deploy the GPU driver deployment file to at least one second test machine.

[0137] Specifically, the system can build upon multiple source code repositories in the updated codebase to generate GPU driver deployment files that are installable or runnable on the corresponding operating system. The GPU driver deployment files can differ for different operating systems. For example, different operating systems may correspond to different installation packages, different dependency libraries, or different deployment scripts.

[0138] For example, for operating systems based on deb package management, a deb format GPU driver deployment file can be generated; for operating systems based on rpm package management, an rpm format GPU driver deployment file can be generated; and for operating systems using other package management methods, an installation package or deployment file of the corresponding format can be generated.

[0139] In some embodiments, the management platform can determine the GPU driver deployment file corresponding to the operating system information of the second test machine, and deploy the GPU driver deployment file to the corresponding second test machine.

[0140] For example, the management platform can obtain information such as the operating system type, operating system version, kernel version, processor architecture, and GPU model of the second test machine, and select the corresponding GPU driver deployment file and deployment script based on this information. If the second test machine is running the first operating system, the GPU driver deployment file corresponding to the first operating system will be deployed to the second test machine; if the second test machine is running the second operating system, the GPU driver deployment file corresponding to the second operating system will be deployed to the second test machine.

[0141] In some embodiments, the GPU driver deployment file can be deployed to a second test machine using automated deployment tools. For example, the management platform can install the GPU driver deployment file to the second test machine via remote commands, automated scripts, configuration management tools, or artifact distribution tools.

[0142] In some embodiments, the updated code repository includes the modified code that has passed access control testing and been added to the repository. Therefore, the GPU driver deployment file generated based on the updated code repository may include the new configuration files, library files, driver modules, or interface implementation files corresponding to the modified code. When performing product integration testing, the second test machine can perform testing based on the GPU driver environment containing the aforementioned changes to verify the actual effect of the modified code in the production environment.

[0143] For example, in one scenario, when the GPU driver was performing stability tests under a certain operating system, a loading error occurred during long-term operation due to the lack of a GPU initialization configuration file corresponding to that operating system. The developers submitted modified code to the first source code repository, adding a GPU initialization configuration file for the corresponding operating system, and this code was added to the repository after passing access control tests. Subsequently, the management platform generated a new GPU driver deployment file based on the updated code repository and deployed the newly added GPU initialization configuration file along with the GPU driver deployment file to the corresponding second test machine. The second test machine re-executed stability tests based on the updated GPU driver environment to verify whether the newly added configuration file enabled the GPU driver to run stably under the target operating system.

[0144] For example, if the code changes add or modify graphics interface adapter library files, these library files can be deployed to the second test machine along with the GPU driver deployment files. When performing OpenGL interface function tests, the second test machine can call the updated graphics interface adapter library files to verify whether the interface functionality of the changed code meets expectations in the product integration environment.

[0145] S4044. For each second test machine, execute the corresponding test items in the predetermined operating system on the object to be tested deployed on the second test machine.

[0146] For example, on a second test machine with a first operating system installed, OpenGL functionality tests can be performed on the deployed GPU driver; on a second test machine with a second operating system installed, performance tests can be performed on the deployed GPU driver; and on a second test machine with a third operating system installed, long-term stability tests can be performed on the deployed GPU driver.

[0147] After testing is completed, the management platform can obtain the product integration test results. These results may include test pass rate, failed test cases, performance metrics, stability metrics, log information, report files, and report links. The management platform can also display these results for testers to view.

[0148] Product integration testing can verify whether the driver components corresponding to multiple source code libraries can work together as a whole after the code is put into the library, and verify the functionality, performance and stability of the GPU driver under different operating systems, different GPUs and different test projects.

[0149] Figure 7 A flowchart illustrating yet another testing method provided in an embodiment of this application. Figure 7As shown, after the changed code in each source code repository is added to the repository, the management platform can respond to test commands and trigger the product integration testing process based on the updated code repository. Taking the Jenkins platform as an example, the Jenkins platform can obtain the updated code from multiple source code repositories, such as the first, second, third, and fourth source code repositories, through the code management platform, and generate GPU driver deployment files based on the updated code repositories. Subsequently, the Jenkins platform determines and deploys at least one second test machine based on the test project, the GPU adapted to the GPU driver, and the operating system applied by the GPU driver. Different second test machines can correspond to different test projects, such as performance testing, stability testing, or functional testing; they can also correspond to different operating systems and / or different GPU models. After deployment, each second test machine executes the corresponding test project on the GPU driver deployed on it and executes test cases through the packaged test suite. After the test is completed, the Jenkins platform collects the test results of each second test machine and outputs a visual test report. In this way, product integration tests under different test projects, different operating systems, or different GPU environments can be executed in parallel, thereby improving the overall testing efficiency of the GPU driver.

[0150] In this embodiment, a second test machine is deployed based on the test project, the GPU adapted to the GPU driver, and the operating system applied by the GPU driver. For each second test machine, the test project is executed on the code to be tested under the corresponding operating system and GPU. In this embodiment, the management platform can simultaneously trigger multiple second test machines to work, saving manpower and thus further improving testing efficiency.

[0151] The GPU driver testing method provided in this embodiment determines the corresponding first source code library in response to the merge instruction, and performs access control testing on the first source code library using a workflow, enabling the detection of changed code before it is included in the repository. If the access control test fails, the changed code in the first source code library can be quickly located, thereby improving the efficiency of problem localization. Furthermore, when the first source code library depends on the second source code library, the access control test software environment can be established using the second deployment file of the second source code library to ensure the accuracy of the access control test. Further, determining whether to reuse the local second deployment file using a valid version identifier can reduce unnecessary duplicate builds and deployments, improving testing efficiency. After the code is included in the repository, product integration testing is performed based on the updated code repository, which can improve the overall quality of the GPU driver.

[0152] Example 2

[0153] Figure 8 This is a schematic diagram of the structure of a GPU driver testing device provided in this embodiment, as shown below. Figure 8 As shown, the testing apparatus may include:

[0154] The determination module 81 is used to respond to the merge instruction and determine the first source code library corresponding to the merge instruction. The merge instruction is used to indicate that the changed code of the first source code library should be added to the library.

[0155] Module 82 is used to build a workflow based on the first source code library. The workflow is used to perform access control tests on the changed code in the first source code library to check the code's standardization and / or functionality.

[0156] The merging module 83 is used to merge the changed code into the first source code library if the access control test passes, thus realizing the entry into the library;

[0157] Test module 84 is used for product integration testing based on the updated code repository.

[0158] Optionally, building module 82 is also used for:

[0159] If the first source code library depends on at least one other second source code library, then a workflow is built based on the modified code of the first source code library and the second deployment file of the second source code library to establish the software environment for access control testing.

[0160] Optionally, building module 82 is also used for:

[0161] The server of the first source code repository pulls the modified first source code repository code and generates the first deployment file; and sends the first deployment file to the first test machine; the first test machine is used to perform access control tests on the first source code repository;

[0162] The first test machine obtains the second deployment file and deploys the first and second deployment files to the predetermined target test environment to perform access control testing.

[0163] Optionally, the first test machine acquires the second deployment file, including:

[0164] Retrieve the local second deployment file and determine if the local second deployment file is the latest version;

[0165] If it is the latest version, the local second deployment file will be used as the second deployment file; otherwise, the version will be updated from the server of the second source code repository to obtain the second deployment file.

[0166] Optionally, building module 82 is also used for:

[0167] Obtain the local second deployment file and determine whether the update identifier of the local second deployment file is consistent with the current update identifier of the second source code repository; the update identifier is used to indicate whether the code changes in the second source code repository affect the GPU function.

[0168] If they match, the local second deployment file will be used as the second deployment file; otherwise, the version will be updated from the server of the second source code repository to obtain the second deployment file.

[0169] Optionally, performing access control tests includes:

[0170] Check whether the changed code conforms to the established code specifications; and / or, check whether the interfaces in the changed code conform to the established interface specifications.

[0171] Optionally, the GPU driver is applied to at least one operating system;

[0172] Test module 84 is also used for:

[0173] In response to test commands, determine the test items for the GPU driver;

[0174] Based on the test project, the GPU adapted to the GPU driver, and the operating system applied by the GPU driver, deploy at least one second test machine; the second test machine is used to perform stability tests, performance tests, or functional tests.

[0175] Deploy the code repository to at least one second test machine;

[0176] For each second test machine, execute the corresponding test items in the predetermined operating system for the code to be tested.

[0177] The GPU driver testing apparatus provided in this application embodiment is used to execute the GPU driver testing method provided in the foregoing embodiment, and will not be described again here.

[0178] Example 3

[0179] This embodiment also provides a testing system, such as Figure 2 As shown, the test system includes a memory 10, a management platform 20, and a test machine 30; the test machine 30 may include a first test machine and a second test machine. The memory 10 stores the GPU driver code repository, which includes multiple source code libraries, each corresponding to a different architectural layer of the GPU driver.

[0180] The management platform 20 is used to respond to the merge command and determine the first source code library corresponding to the merge command. The merge command is used to instruct the modified code of the first source code library to be added to the library.

[0181] The management platform 20 is also used to build workflows based on the first source code library, and to perform access control tests on the changed code in the first source code library through the workflow to check the code's standardization and / or functionality;

[0182] The second test machine is used for product integration testing based on the updated code repository.

[0183] The testing system in this embodiment can be applied to the testing methods in any of the above embodiments. For the specific applications of the management platform, the second testing machine, and the memory, please refer to the above embodiments, which will not be repeated here.

[0184] Example 4

[0185] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 As shown, the electronic device may include: transceiver 121, processor 122, and memory 123.

[0186] Processor 122 executes computer execution instructions stored in memory, causing processor 122 to perform the scheme in the above embodiments. Processor 122 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0187] The memory 123 is connected to the processor 122 via the system bus and completes communication between them. The memory 123 is used to store computer program instructions.

[0188] Transceiver 121 can be used to obtain the task to be run and its configuration information.

[0189] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.

[0190] The electronic device provided in this application embodiment can be the terminal device described in the above embodiments.

[0191] This application also provides a chip for executing instructions, which is used to execute the technical solutions of the methods shown in the above embodiments.

[0192] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the technical solution of the method shown in the above embodiments.

[0193] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the method shown in the above embodiments.

[0194] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0195] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0196] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A GPU driver testing method, characterized in that, The GPU driver code repository includes multiple source code libraries; the method includes: In response to a merge instruction, a first source code library corresponding to the merge instruction is determined, wherein the merge instruction is used to instruct the modified code of the first source code library to be added to the library; A workflow is built based on the first source code library, and access control tests are performed on the modified code of the first source code library through the workflow to check the code's standardization and / or functionality. If the access control test passes, the modified code will be merged into the first source code library and added to the library. And, product integration testing is performed based on the updated code repository.

2. The method according to claim 1, characterized in that, The workflow built based on the first source code library includes: If the first source code library depends on at least one other second source code library, a workflow is built based on the modified code of the first source code library and the second deployment file of the second source code library to establish the software environment for the access control test.

3. The method according to claim 2, characterized in that, The workflow for building the modified code based on the first source code repository and the second deployment file based on the second source code repository includes: The server of the first source code repository pulls the modified code of the first source code repository and generates a first deployment file; and sends the first deployment file to a first test machine; the first test machine is used to perform access control testing on the first source code repository; The first test machine obtains the second deployment file and deploys the first deployment file and the second deployment file to the predetermined target test environment to perform the access control test.

4. The method according to claim 3, characterized in that, The first test machine acquires the second deployment file, including: Obtain the local second deployment file and determine whether the local second deployment file is the latest version corresponding to the second source code library; If it is the latest version, the local second deployment file will be used as the second deployment file; otherwise, the version will be updated from the server of the second source code repository to obtain the second deployment file.

5. The method according to claim 3, characterized in that, The first test machine acquires the second deployment file, including: Obtain the local second deployment file and determine whether the valid version identifier of the local second deployment file is consistent with the current valid version identifier of the second source code library; the valid version identifier is used to characterize the version of the code in the second source code library that affects GPU functionality; If they match, the local second deployment file is used as the second deployment file; otherwise, the version is updated from the server of the second source code repository to obtain the second deployment file.

6. The method according to claim 1, characterized in that, The access control test includes: Check whether the changed code conforms to the established code specifications; and / or check whether the interfaces in the changed code conform to the established interface specifications.

7. The method according to any one of claims 1-5, characterized in that, The GPU driver is applied to at least one operating system; Then, the product integration testing based on the updated code repository includes: In response to the test command, determine the test items for the GPU driver; Based on the test items, the GPU adapted to the GPU driver, and the operating system applied by the GPU driver, at least one second test machine is deployed; the second test machine is used to perform stability tests, performance tests, or functional tests. Based on the updated code repository, a GPU driver deployment file corresponding to the operating system is generated, and the GPU driver deployment file is deployed to the at least one second test machine; for each second test machine, the corresponding test project in the predetermined operating system is executed on the code to be tested.

8. A GPU-driven testing system, characterized in that, The testing system includes a memory, a management platform, and a second testing machine; the memory includes a GPU driver code repository, which includes multiple source code libraries. The management platform is used to respond to a merge instruction and determine the first source code library corresponding to the merge instruction. The merge instruction is used to instruct the modified code of the first source code library to be added to the library. The management platform is also used to build a workflow based on the first source code library, and to perform access control tests on the modified code of the first source code library through the workflow to check the code's standardization and / or functionality. The management platform is also used to merge the changed code into the first source code library if the access control test passes, and to realize the entry into the library; The second test machine is used to perform product integration testing based on the updated code repository.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images