Automatic test method based on apitraces

Abstract

The invention provides an automatic test method based on apitraces, which comprises the following steps of: constructing a trace file database in a remote warehouse, and covering all to-be-tested OpenGL (Open Graphics Library) application trace files; mounting remote warehouse deployment trace file data locally; and automatically generating an image database according to the pre-processing parameter text, performing image matching and pixel-level comparison on each group of reference images and target images to obtain an image comparison result, and generating a red gradient difference image. According to the method, the OpenGL application program is simulated by utilizing apitraces, and the trace file testing process which is originally low in efficiency and time-consuming and cannot systematically form regression testing and result analysis is automated, so that whether performance degradation is caused by introduction of a new problem due to version updating during graph-driven iteration or not is determined; or whether some rendering exceptions which cannot be observed by naked eyes affect the output of the OpenGL application program occurs or not is judged, and the efficiency of graph drive development and optimization is improved.

Description

Technical Field

[0001] The present invention relates to the field of testing technology, and more specifically, to an automated testing method based on apitrace. Background Art

[0002] apitrace is a powerful tool for debugging and analyzing graphics applications, especially those using the OpenGL graphics API. It can help developers gain a deep understanding of graphics API usage, discover and fix performance bottlenecks, crashes, and other problems.

[0003] Trace files, generated by the apitrace tool, record all graphics API calls made by an OpenGL application during runtime. apitrace can replay these graphics API calls to help developers reproduce and debug application behavior. During the replay process, apitrace can inspect the graphics API state and identify rendering errors or performance bottlenecks.

[0004] Currently, when optimizing or iterating graphics driver performance, to avoid introducing new issues or causing other performance losses, manual verification using numerous existing trace files is often required. This requires manual observation and comparison, making it difficult to obtain intuitive verification results. This cumbersome task can also overlook rendering errors that are difficult to detect with the naked eye. Therefore, building a trace file database using existing OpenGL application trace files and designing a complete and reliable automated testing method based on the apitrace tool, which automates the entire regression testing process and results analysis, is of great significance to graphics driver testing. Summary of the Invention

[0005] In response to the technical problems existing in the prior art, the present invention provides an automated testing method based on apitrace, which builds a trace file database with reference to the standard and completes automated testing and result verification, thereby solving the problems of low efficiency, time-consuming and labor-intensive manual testing of trace files one by one, and the inability to systematically form regression testing and result analysis.

[0006] The present invention provides an automated testing method based on apitrace, comprising:

[0007] Building a trace file database in a remote warehouse, wherein the trace file database includes a plurality of trace files to be tested that cover all OpenGL applications to be tested;

[0008] Automatically generate an image database for each trace file to be tested based on the preprocessing parameter text, wherein the image database includes a reference image database and a target image database, wherein reference images in the reference image database correspond to target images in the target image database, and each reference image and each corresponding target image form an image group;

[0009] performing image matching and pixel-level comparison on each image group in the reference image database and the target image database to obtain an image comparison result for each image group;

[0010] Based on the image comparison results of each image group, a red gradient difference map of each image group is generated.

[0011] The present invention provides an apitrace-based automated testing method, which addresses the problems of low efficiency, incomplete coverage, and low complexity in programming development test cases, making it difficult to reflect the actual situation of OpenGL programs. The method of the present invention constructs a trace file database in a remote warehouse, including multiple trace files to be tested that cover all OpenGL applications to be tested; mounts the remote warehouse locally to deploy the trace file database; and automatically generates an image database for each trace file to be tested based on preprocessing parameter text. Image matching and pixel-level comparison are performed on each set of reference images and target images to obtain image comparison results and generate a gradient difference map. The present invention uses apitrace to simulate OpenGL programs. Automated testing based on apitrace can fully utilize the advantages of apitrace, such as good simulation performance, simple use case construction, and convenient result verification. The original manual and inefficient OpenGL application trace file verification process is automated to confirm whether performance degradation occurs due to new problems introduced by version updates during graphics driver iterations, or whether certain rendering anomalies that are invisible to the naked eye affect the output of OpenGL applications. By building a trace file database and designing an automated testing process, the robustness of the graphics driver is enhanced, performance is improved, and performance degradation or other problems caused by updates and iterations can be avoided. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A flowchart of an automated testing method based on apitrace is provided for one embodiment of the present invention;

[0013] Figure 2 A flowchart of constructing a trace file database according to an embodiment of the present invention;

[0014] Figure 3 A flowchart of constructing an image database according to an embodiment of the present invention;

[0015] Figure 4 A flow chart of log monitoring according to an embodiment of the present invention;

[0016] Figure 5 A flowchart of image comparison between a reference image and a target image according to an embodiment of the present invention;

[0017] Figure 6 A flowchart for analyzing image comparison results;

[0018] Figure 7 This is an overall flow chart of the automated testing method based on apitrace according to an embodiment of the present invention;

[0019] Figure 8 A flowchart of database management according to an embodiment of the present invention;

[0020] Figure 9 This is a structural block diagram of an automated testing system based on apitrace according to an embodiment of the present invention. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention. In addition, the technical features in the various embodiments or single embodiments provided by the present invention can be arbitrarily combined with each other to form a feasible technical solution. This combination is not restricted by the sequence of steps and / or structural composition mode, but must be based on the ability of ordinary technicians in this field to implement it. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0022] When iterating on a graphics driver, it is necessary to ensure that its functionality is consistent with standard implementations (such as the MESA open source driver). Among them, MESA is an open source 3D graphics library that aims to implement multiple graphics API specifications such as OpenGL and Vulkan, and serves as a translation layer between the graphics API and the graphics hardware driver in the operating system kernel. It supports multiple hardware platforms (such as Intel, AMD and NVIDIA) and provides efficient rendering capabilities. It is widely used in Linux desktop environments and scientific visualization and other fields. The goal of MESA is to provide an open source, cross-platform graphics library that enables developers to use the same code to render graphics on different operating systems. MESA is a project jointly developed and maintained by an open source community of volunteers. Therefore, each version of MESA is developed collaboratively by contributors from the entire community, rather than released by a single individual or entity.

[0023] Traditional manual testing of trace files is inefficient, difficult to cover all test cases, and lacks objective quantitative evaluation criteria. Existing technologies have the following problems:

[0024] (1) Traditional GPU function or performance testing relies primarily on manual visual inspection. Different testers have different perceptions of image quality. This inspection method is highly subjective and inefficient, making it difficult to detect subtle rendering differences, resulting in inconsistent test results. Furthermore, when comparing a large number of frames or different scenes, the human eye has limited sensitivity to color, brightness, contrast, etc. Manual inspection cannot provide objective, quantifiable evaluation criteria, making it difficult to measure performance gaps and functional differences between different drivers.

[0025] (2) The API functionality used by OpenGL applications varies greatly, making it difficult to cover all possible rendering states with a limited number of test cases. Special cases and unusual scenarios, such as complex geometries and large numbers of draw calls, are more likely to expose potential driver issues, but traditional testing methods often struggle to construct and test these scenarios. Edge cases, such as floating-point precision issues and texture sampling boundary conditions, are also easily overlooked, potentially leading to rendering errors or performance degradation.

[0026] (3) GPU testing has high requirements for environmental configuration, mainly including driver version, system library dependencies, environment variable settings, etc. Manual configuration makes it difficult to ensure the consistency of the test environment, resulting in irreproducible test results, unstable test results, and difficulty in conducting effective performance comparisons and problem location.

[0027] (4) Existing testing tools lack systematic testing processes and automated comparison mechanisms, and are unable to accurately measure the differences between different implementations, which brings certain difficulties to problem location and performance optimization.

[0028] Therefore, to solve the above-mentioned problems of existing methods, it is necessary to design an automated testing method with a high degree of automation, accurate result analysis, and easy management and reuse of test results. The embodiment of the present invention provides an automated testing method based on apitrace, which realizes full coverage comparative testing of general or special test cases, automatically compares and analyzes test results, effectively reduces manual input, eliminates the instability and uncertainty caused by manual testing, and improves testing efficiency.

[0029] Figure 1 A flowchart of an automated testing method based on apitrace is provided in an embodiment of the present invention, such as Figure 1 As shown, the automated testing method includes the following steps:

[0030] Step S1: constructing a trace file database in a remote warehouse, wherein the trace file database includes a plurality of trace files to be tested that cover all OpenGL applications to be tested.

[0031] Among them, see Figure 2 , which is a flowchart for establishing a trace file database. The specific steps include:

[0032] Step S11: Place all trace files to be tested in a remote repository;

[0033] Step S12: Since the amount of data in the trace file to be tested is large, in order to avoid copying a large amount of data to the local computer for each test and to achieve efficient construction of the test system, the trace file data is deployed by mounting a remote warehouse.

[0034] It's understandable that setting up a remote repository isn't limited by platform in principle. For example, during testing on Linux, we can mount the remote repository locally using sudo mount -t cifs / / ip / sharing_folder / mount_point -o username="shared_user", password="password", uid=kylin, gid=kylin. Here, / / ip / sharing_folder is the remote repository's shared directory path, and / mount_point is the local mount point path. After mounting, simply point the trace_files_path in the script to the trace file database in the remote repository.

[0035] Step S2: Automatically generate an image database for each trace file to be tested based on the preprocessing parameter text. The image database includes a reference image database and a target image database. The reference images in the reference image database correspond to the target images in the target image database, and each reference image and each corresponding target image form an image group.

[0036] It is understandable that after the trace file database is constructed, an image database is generated for each trace file to be tested, including a reference image database and a target image database. Figure 3 , shows a flowchart of generating a reference image database and a target image database for each trace file to be tested, specifically including the following steps:

[0037] In step S21, the replay function of the apitrace tool is used to manually filter the key frame numbers of each trace file to be tested, and a preprocessing parameter text is constructed for all trace files to be tested. The preprocessing parameter text records the key frame number of each trace file to be tested. Typically, a trace file to be tested has multiple key frame numbers, and a single line in the preprocessing parameter text records all key frame numbers for a trace file to be tested.

[0038] In step S22, the preprocessing parameter text is read line by line as parameter input. According to the key frame number information, the key frames recorded in the trace file are output as PNG images through the apitrace tool to build a reference image database for each trace file (only needs to be built once and can be reused in subsequent tests) and a target image database.

[0039] Wherein, step S22 includes the following steps:

[0040] Step S221, reading the key frame number information set CALLSET corresponding to each trace file to be tested as input;

[0041] Step S222: Set the MESA-related environment variables to point to the MESA driver path, switch the rendering to the MESA driver for software rendering, and obtain the MESA software rendering results of each key frame. The MESA software rendering results can be used as the correct results to facilitate the correctness verification of the results obtained in subsequent tests;

[0042] In step S223, the apitrace dump-images --calls=CALLSET XXX.trace command is used to output the contents of the frame buffer during the corresponding OpenGL interface call as an image, thereby generating reference image data corresponding to the trace file. One reference image is generated for each key frame number. Therefore, multiple reference images are generated for multiple key frame numbers of a trace file to be tested, thereby forming a reference image database.

[0043] Step S224: Setting the environment variables related to the currently used graphics card to point to the corresponding driver path, switching the driver to the currently used graphics card driver for hardware rendering, and obtaining the hardware rendering results of each key frame;

[0044] Step S225: Use the apitrace dump-images --calls=CALLSET XXX.trace command to output the contents of the frame buffer during the corresponding OpenGL interface call as an image, generating target image data corresponding to the trace file. One key frame number corresponds to one target image. Therefore, multiple key frame numbers in a trace file to be tested correspond to multiple target images, forming a target image database.

[0045] Step S226 , after traversing all the trace files to be tested according to the above steps, a reference image database and a target image database are constructed for each trace file to be tested.

[0046] It is understandable that a reference image database is generated for each trace file to be tested through steps S221 to S223, and a target image database is generated for each trace file to be tested through steps S224 to S225. The reference image databases and target image databases of all trace files to be tested constitute an image database.

[0047] See also Figure 4 ,In the process of generating the image database of each trace file to be tested in step 2, ,abnormal monitoring is performed.

[0048] The specific steps of abnormal monitoring include:

[0049] Step S23: when generating image data corresponding to each trace file, obtaining log information, which records driver version information, kernel information when running the trace file, and terminal printing information;

[0050] Step S24: Synchronously perform anomaly detection on the log information corresponding to each trace file, and give a corresponding warning mark and output print when an abnormal error occurs.

[0051] Step S3: performing image matching and pixel-level comparison on each image group in the reference image database and the target image database to obtain an image comparison result for each image group.

[0052] Among them, see Figure 5 , is a flowchart for comparing the reference image and the target image. This step is implemented in Python and utilizes some open source graphics libraries. The specific steps include:

[0053] Step S31: traverse the image database and match the reference image and target image corresponding to each trace file to be tested to form an image group. If the reference image and target image in the image group do not match in size or there is an ungenerated reference image or target image, the image comparison test is considered to be terminated abnormally.

[0054] Step S32: for each set of matched images, the difference value between the reference image and the target image is determined pixel by pixel according to the RGB component, and the pixel difference rate diff_rate between the reference image and the target image is calculated;

[0055] Step S33 , compare the pixel difference rate diff_rate with the difference rate threshold diff_rate_threshold. If the pixel difference rate diff_rate ≥ the difference rate threshold diff_rate_threshold, it is determined that the difference is too large, the image group comparison fails, and the test fails. If the pixel difference rate diff_rate < the difference rate threshold diff_rate_threshold, it is determined that the requirement is met, the image group comparison is successful, and the test passes.

[0056] The Khronos Group allows a certain degree of rendering variability in OpenGL applications across different hardware and drivers. Khronos officially allows a certain range of rendering errors to strike a balance between hardware compatibility, performance optimization, and developer flexibility. This policy is reflected in the graphics API specifications developed by Khronos. Khronos explicitly states in its API specifications that due to hardware variations and implementation differences, rendering results may have some variability. This variability is unavoidable, as different GPU hardware and drivers may produce subtle differences when executing the same rendering instructions due to factors such as floating-point precision, memory layout, and optimization strategies. By setting a certain variability range, Khronos ensures that applications maintain a certain degree of compatibility and consistency when running on different hardware. Furthermore, Khronos defines a variability threshold in the specification to clarify the maximum permissible variability. These mechanisms are designed to ensure that rendering results are within the permissible variability while providing developers with flexibility and room for performance optimization.

[0057] Considering the existence of the difference tolerance, the pixel is confirmed as a difference pixel only when any one of the difference values ​​of the RGB components is greater than the difference threshold diff_threshold.

[0058] Specifically, step S32 includes:

[0059] Step S321, for each image group, respectively calculating the difference between the R component, G component, and B component of each pixel point in the reference image and the R component, G component, and B component of the corresponding pixel point in the target image, to obtain an R component difference value, a G component difference value, and a B component difference value, respectively;

[0060] Step S322: when any one of the R component difference value, the G component difference value, and the B component difference value is greater than the difference value threshold diff_threshold, the pixel is determined to be a difference pixel;

[0061] Step S323 , counting the number of difference pixels in the image group (diff_count) and the number of all pixels in the image group (total_pixels), and then calculating the pixel difference rate of the image group (diff_rate=diff_count / total_pixels).

[0062] Step S4: generating a red gradient difference map for each image group based on the image comparison result of each image group.

[0063] It is understandable that this step generates a red gradient difference map for each image group based on the comparison results of each image group. Step S4 specifically includes the following steps:

[0064] Step S41: For the image group that fails the test, the difference between the reference image and the target image is calculated based on the difference function of the ImageChops module in Python to obtain a difference image diff, and the difference image diff is converted into a grayscale difference image diff_gray based on the convert function;

[0065] Step S42, obtaining the maximum pixel value max_diff in the grayscale difference map diff_gray based on the gettextrema() function of the PIL module in Python;

[0066] Step S43 , calculate the R component of each pixel in the grayscale difference map diff_gray, where red_value = int((diff_value / max_diff)*255), where red_value is the R component. This is converted and mapped to the red channel (red_value, 0, 0), and both the G and B components are set to 0. A red gradient effect is created on the black background image. The red gradient difference map intuitively reflects the difference between the two images. The darker the red, the greater the difference between the two images, and vice versa.

[0067] Among them, step S5 is also included after step S4 to analyze the image comparison results. Figure 6 , specifically including the following steps:

[0068] Step S51: For each reference image and target image in the trace file to be tested, the image groups with successful, failed, and abnormally terminated matching are counted as pass_count, failure_count, and termination_count, respectively. Let total_count = pass_count + failure_count + termination_count.

[0069] Step S52, using pass_count / total_count, failure_count / total_count, termination_count / total_count, calculate the overall pass rate, failure rate and abnormal termination rate;

[0070] Step S53: Mark the trace files to be tested that have failed items or abnormal termination items.

[0071] In step S54, for each trace file to be tested in this round of testing, all matching image group information is recorded. The image group information includes the comparison difference rate of each group of images, the comparison pass status, and the overall test result of the trace file to be tested, so as to facilitate subsequent review with reference to the results.

[0072] See also Figure 7 , which is the overall flow chart of automated testing. First, the test script is run. When there are keywords in the test script (wherein the keywords in the test script are used for distinction), it means that the database management work is performed. If there are no keywords in the test script, the test work is executed, that is, steps S1 to S4.

[0073] in, Figure 8 The flowchart of the database management work is shown, which specifically includes the following steps:

[0074] Step S61, adding specific parameters to call the data management function when running the test script;

[0075] Step S62, specifying or batch deleting image data, log text, and image comparison results according to the specific parameters;

[0076] Step S63: During the data management process, error feedback and exception handling are performed.

[0077] Among them, step S62, specifying or batch deleting image data, log text and image comparison results according to the specific parameters, includes:

[0078] Step S621: If the specific parameter is . / run.sh delete all, all files are deleted, including the image database, log text, and comparison results;

[0079] Step S622: If the specific parameter is . / run.sh delete reference image database name or . / run.sh delete target image database name, then delete all contents in the reference image database or delete all contents in the target image database;

[0080] Step S623: If the specific parameter is . / run.sh delete complete trace file name, all image data and log text related to the trace file in the image database are deleted in batches;

[0081] Step S624: if the specific parameter is . / run.sh delete png name, then delete the specified image file in the image database;

[0082] Step S625: If the specific parameter is . / run.sh delete txt name, the specified log text is deleted.

[0083] In step S63, error feedback and exception handling are performed during the data management process, including:

[0084] Step S631: When no matching file is found, a corresponding error message is output;

[0085] Step S, 632, when the number of input parameters is incorrect, output a corresponding error prompt;

[0086] Step S633: When multiple files are found according to the parameters, a for loop is used to execute the deletion operation one by one to ensure that all matching files are processed.

[0087] See also Figure 9 The embodiment of the present invention also provides an automated testing system based on apitrace, which includes a test case management module 91, an image database construction module 92, a log monitoring module 93, an image comparison module 94, a result analysis module 95 and an image database management module 96.

[0088] The test case management module 91 is used to build a trace file database in a remote warehouse for centralized and unified management, covering all OpenGL applications.

[0089] The image database construction module 92 is used to automatically complete the generation of the reference image database and the target image database according to the preprocessing parameter text.

[0090] The log monitoring module 93 is used to record the logs of the entire test process, monitor and mark all abnormal information in the logs.

[0091] The image comparison module 94 is used to achieve image matching and pixel-level comparison between the reference image database and the target image database.

[0092] The result analysis module 95 is used to perform statistical analysis based on the image comparison results to intuitively reflect the test situation.

[0093] The image database management module 96 is used to specify or batch manage the image data and log information in the reference image database and the target image database according to different parameter settings.

[0094] It can be understood that the automated testing system based on apitrace provided by the present invention corresponds to the automated testing method based on apitrace provided in the aforementioned embodiments. The relevant technical features of the automated testing system based on apitrace can refer to the relevant technical features of the automated testing method based on apitrace, and will not be repeated here.

[0095] An automated testing method based on apitrace provided by an embodiment of the present invention realizes the automated management of the entire test task process, ensures the convenience of testing and the accuracy of test results, improves test efficiency and the reusability of test data, and is conducive to performance analysis and problem location during driver update iterations. At the same time, the method of the present invention has good scalability and can flexibly add trace files and customize test processes. In summary, this patent provides an efficient, reliable and scalable automated testing solution, which effectively solves the pain points of the existing technology and improves the efficiency and quality of graphics driver development and optimization.

[0096] It should be noted that, in the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0097] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0098] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0099] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0100] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0101] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0102] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. An automated testing method based on apitrace, characterized in that: include: Building a trace file database in a remote repository, wherein the trace file database covers trace files of all OpenGL applications to be tested; Automatically generate an image database for each trace file to be tested based on the preprocessing parameter text, wherein the image database includes a reference image database and a target image database, wherein reference images in the reference image database correspond to target images in the target image database, and each reference image and each corresponding target image form an image group; performing image matching and pixel-level comparison on each image group in the reference image database and the target image database to obtain an image comparison result for each image group; Based on the image comparison results of each image group, a red gradient difference map of each image group is generated.

2. The automated testing method according to claim 1, wherein: The construction of the trace file database in the remote warehouse includes: Place the trace files covering all OpenGL applications to be tested in a remote repository; Mount the trace file to be tested deployed in the remote warehouse locally.

3. The automated testing method according to claim 1, wherein: The image database of each trace file to be tested is automatically generated based on the preprocessing parameter text, including: Use the replay function of the apitrace tool to filter out the key frame numbers of each trace file to be tested, and construct a preprocessing parameter text for all trace files to be tested, wherein the preprocessing parameter text includes multiple lines of information, each line of information is all the key frame number information of a trace file to be tested; The preprocessing parameter text is read line by line, and according to all the key frame number information of each trace file to be tested, the key frames recorded in the trace file to be tested are output as PNG images through the apitrace tool to build a reference image database and a target image database for each trace file to be tested.

4. The automated testing method according to claim 3, wherein: The key frames recorded in the trace file to be tested are output as PNG images by the apitrace tool, and a reference image database and a target image database are constructed for each trace file to be tested, including: Read the key frame number information set CALLSET corresponding to each trace file to be tested as input; Set the MESA-related environment variables to point to the MESA driver path, switch the rendering to the MESA driver for software rendering, and obtain the MESA software rendering results for each keyframe; Use the apitrace dump-images --calls=CALLSET XXX.trace command to output the contents of the frame buffer when the corresponding OpenGL interface is called as an image, and generate a reference image database corresponding to each trace file to be tested, where one key frame number corresponds to one reference image; Set the environment variables related to the currently used graphics card to point to its corresponding driver path, switch the driver to the currently used graphics card driver for hardware rendering, and obtain the hardware rendering results of each key frame; Use the apitrace dump-images --calls=CALLSET XXX.trace command to output the contents of the frame buffer when the corresponding OpenGL interface is called as an image, and generate a target image database corresponding to each trace file to be tested, where one key frame number corresponds to one target image; After traversing all the trace files to be tested, the reference image database and the target image database are constructed.

5. The automated testing method according to claim 1 or 4, characterized in that: The image database of each trace file to be tested is automatically generated according to the preprocessing parameter text, and then further includes: When generating a reference image or target image corresponding to each trace file to be tested, log information is obtained, wherein the log information records driver version information, kernel information when running each trace file to be tested, and terminal print information; Synchronously perform anomaly detection on the log information corresponding to each trace file to be tested, and give corresponding warning signs and output printing when an abnormal error occurs.

6. The automated testing method according to claim 1, wherein: The performing image matching and pixel-level comparison on each image group in the reference image database and the target image database to obtain an image comparison result for each image group includes: Traversing the reference image database and the target image database, matching each image group of each trace file to be tested, and determining that the image group comparison test is abnormally terminated when the image sizes of the reference image and the target image in the image group do not match or the reference image or the target image is missing in the image group; For each matched image group, the reference image and the target image in the image group are subjected to pixel-by-pixel difference judgment according to the RGB components, and the pixel difference rate is calculated; The pixel difference rate diff_rate is compared with the difference rate threshold diff_rate_threshold. If diff_rate ≥ diff_rate_threshold, the comparison between the reference image and the target image fails and the test fails; if diff_rate < diff_rate_threshold, the comparison between the reference image and the target image succeeds and the test passes.

7. The automated testing method according to claim 6, wherein: For each matched image group, performing pixel-by-pixel difference judgment on the reference image and the target image in the image group according to the RGB components, and calculating the pixel difference rate, including: For each image group, respectively calculating the difference between the R component, G component, and B component of each pixel point in the reference image and the R component, G component, and B component of the corresponding pixel point in the target image, and obtaining an R component difference value, a G component difference value, and a B component difference value, respectively; When any one of the R component difference value, the G component difference value, and the B component difference value is greater than the difference value threshold diff_threshold, the pixel is determined to be a difference pixel; The number of difference pixels in the image group, diff_count, and the number of all pixels in the image group, total_pixels, are counted, and the pixel difference rate of the image group, diff_rate=diff_count / total_pixels.

8. The automated testing method according to claim 1, wherein: The step of generating a red gradient difference map for each image group based on the image comparison result of each image group includes: For the image group that fails the test, the difference between the reference image and the target image is calculated based on the difference function of the ImageChops module in Python to obtain the difference image diff, and the difference image diff is converted into a grayscale difference image diff_gray based on the convert function; Obtain the maximum pixel value max_diff in the grayscale difference map diff_gray based on the getextrema() function of the PIL module in Python; Calculate the R component of each pixel in the grayscale difference map diff_gray, where red_value=int((diff_value / max_diff)*255), red_value is the R component, Convert it and map it to the red channel (red_value,0,0); Generate a red gradient difference map based on the RGB color value of each pixel (red_value,0,0).

9. The automated testing method according to claim 1, wherein: The image matching and pixel-level comparison are performed on each image group in the reference image database and the target image database to obtain an image comparison result for each image group, and then the following steps are further included: Based on the image comparison results of each image group, the test results of the trace file to be tested are analyzed as a whole; Based on the image comparison results of each image group, the test results of the trace file to be tested are analyzed as a whole, including: For each reference image and target image in the trace file to be tested, the cumulative counts of image groups with successful, failed, and abnormal termination after matching are passed, failed, and terminated, respectively, and total_count = pass_count + failure_count + termination_count; Use pass_count / total_count, failure_count / total_count, and termination_count / total_count to calculate the overall pass rate, failure rate, and abnormal termination rate; Mark the trace files to be tested that have failed items or abnormal termination items; For each trace file to be tested in this round of testing, all matching image group information is recorded. The image group information includes the comparison difference rate of each group of images, the comparison pass status, and the overall test result of the trace file to be tested.

10. The automated testing method according to claim 1, wherein: The image database of each trace file to be tested is automatically generated according to the preprocessing parameter text, and then further includes: Add specific parameters to call data management functions when running test scripts; Specify or batch delete image data, log text, and image comparison results according to the specific parameters; Provide error feedback and exception handling during data management; The step of specifying or batch-deleting the image data, log text, and image comparison results in the image database according to the specific parameters includes: If the specific parameter is . / run.sh delete all, all files will be deleted, including the image database, log text, and comparison results; If the specific parameter is . / run.sh delete reference image database name or . / run.sh delete target image database name, then all contents in the reference image database or all contents in the target image database are deleted; If the specific parameter is . / run.sh delete complete trace file name, all image data and log text related to the trace file in the image database are deleted in batches; If the specific parameter is . / run.sh delete png name, the specified image file in the image database is deleted; If the specific parameter is . / run.sh delete txt name, the specified log text is deleted.

Images