Adaptive scheduling and abstract report generation method and device for image test

Abstract

Embodiments of the present application provide a kind of for image test adaptive scheduling and abstract report generation method and device.This application relates to the field of intelligent image analysis and task scheduling, which comprises: receiving batch image files to be tested, obtaining the image information and image type of each image file in batch image files to be tested, determining the task level of each image file based on image information and image type;Based on the task level of each image file, the task test order of batch image files to be tested is obtained;Collect the running state parameters of image test system, generate the task scheduling strategy of image test system based on running state parameters;Based on task scheduling strategy and task test order, image test is carried out to batch image files to be tested.The method is used to improve the technical effect of the processing efficiency of batch image test.

Description

Technical Field

[0001] This application relates to the field of adaptive scheduling and report generation, and in particular to an adaptive scheduling and summary report generation method and apparatus for image testing. Background Technology

[0002] In the research, development, testing, and mass production stages of smart terminal devices, image quality assessment is a crucial step in ensuring product performance meets standards. Image testing typically involves batch analysis of hundreds to thousands of images taken by the device in different scenarios to detect defects in core functions such as automatic exposure, automatic white balance, image signal processing, and autofocus.

[0003] However, traditional batch image testing processes mostly execute all tasks concurrently. Since API calls need to balance concurrency and stability, fixed concurrency strategies are difficult to adapt to dynamic fluctuations in APIs. Therefore, batch image testing suffers from low efficiency. Summary of the Invention

[0004] This application provides an adaptive scheduling and summary report generation method and apparatus for image testing. By considering the content characteristics, type differences, and current available resource status of the test system for batch image testing scenarios, the batch image tasks are dynamically sorted and adaptively scheduled, thereby taking into account the priority of task processing, the matching of resource utilization, and the stability of the overall testing process during image testing.

[0005] In a first aspect, embodiments of this application provide an adaptive scheduling method for image testing, applied to an image testing system, comprising:

[0006] Receive a batch of image files to be tested, obtain the image information and image type of each image file in the batch of image files to be tested, and determine the task level of each image file based on the image information and image type; wherein, the image information includes at least the image complexity, the severity of image defects and the historical performance parameters of similar files;

[0007] Based on the task level of each image file, the task testing order of the batch of image files to be tested is obtained;

[0008] The system collects the operational status parameters of the image testing system and generates a task scheduling strategy based on these parameters. The operational status parameters characterize the available resources of the image testing system.

[0009] Based on the task scheduling strategy and task testing order, image tests are performed on a batch of image files to be tested.

[0010] In one possible embodiment, the task level of each image file is determined based on image information and image type, including:

[0011] Obtain basic image information for each image file and determine image complexity based on the basic image information; the basic image information includes at least image gradient, image size, and text detection results;

[0012] Histogram analysis is performed on the image files to obtain the image defect severity index, and the image defect severity of the image files is determined based on the image defect severity index; wherein, the image defect severity index includes at least the dark pixel ratio, the overexposed pixel ratio, and the Laplacian variance;

[0013] Obtain similar files to the image file and obtain historical performance parameters of the similar files; among them, the historical performance parameters of the similar files include at least historical time consumption and detection defect detection rate;

[0014] The task level of each image file is determined by a weighted algorithm based on image complexity, image defect severity, historical performance parameters of similar files, and image type.

[0015] In one possible embodiment, a weighted algorithm is used to determine the task level of each image file based on image complexity, image defect severity, historical performance parameters of similar files, and image type, including:

[0016] Based on the historical performance parameters of similar files, the weights of image complexity, image defect severity, and image type are dynamically adjusted respectively.

[0017] The task level of an image file is determined based on its complexity, severity of defects, and type, along with their corresponding weights.

[0018] In one possible embodiment, a task scheduling strategy for the image testing system is generated based on runtime status parameters, including:

[0019] Obtain the actual average response time, standard deviation of response time, and error rate trend of the API interface in the image testing system;

[0020] Based on the target average response time and the actual average response time, determine the deviation information of the API interface;

[0021] Based on the deviation information, response time standard deviation, and error rate trend, a new concurrency level for the API interface is obtained; the new concurrency level is used to characterize the number of batch image files that the image testing system can send to the API interface for testing.

[0022] Based on the new concurrency level and the historical concurrency level of the API interface, generate the target concurrency level of the API interface;

[0023] Based on the target concurrency, a task scheduling strategy is determined; wherein, the task scheduling strategy is used to characterize the number of batch image files to be tested that the API interface can receive each time.

[0024] In one possible embodiment, the method further includes:

[0025] Obtain the error rate and error frequency of the API interface; the error rate is used to characterize the proportion of files that fail to be detected after the API interface receives a number of files, and the error frequency is the number of times the API stops detecting due to excessive concurrency per unit time;

[0026] If the error rate is greater than the preset threshold or the error frequency is greater than 0, the new concurrency level will be dynamically adjusted to obtain the adjusted concurrency level.

[0027] Based on the adjusted concurrency level and the historical concurrency level of the API interface, the target concurrency level of the API interface is generated.

[0028] In one possible embodiment, the method further includes:

[0029] If the image testing system fails to execute image testing on a batch of image files to be tested via API interface call, then generate an analysis of the reasons for the API interface call failure.

[0030] Based on the mapping relationship and cause analysis, a retry strategy for image testing of the image testing system is generated; where the mapping relationship is the correspondence between the cause analysis and the retry strategy.

[0031] Secondly, embodiments of this application provide a method for generating summary reports for image testing, applied to an image testing system, including:

[0032] The system generates image test results for each image file, performs single-group structured compression on the image test results for each image file, and extracts key test information for each image file. The key test information includes at least the defect level determination for each dimension, core defect description, comprehensive score, and optimization suggestions.

[0033] Based on the feature dimension type of each image file, the key test information of all image files is clustered into problem patterns to obtain multiple groups; among them, the feature dimension type includes scene type, defect type and severity level;

[0034] Based on the clustering results of multiple groups, cross-group trend insight analysis is performed to generate trend insight information; the trend insight information includes problem coverage, scenario relevance, severity distribution and cross-scenario consistency;

[0035] Using trend insights as input context, a large language model is invoked to generate image test reports for batch image files.

[0036] In one possible embodiment, problem coverage is used to characterize the proportion of the target problem in all image files. Problems with a coverage greater than a preset threshold are marked as systemic problems or high-frequency problems. Scene relevance is used to characterize the strength of the association between the target problem and a specific scene, and is calculated by conditional probability ratio. Severity distribution is used to characterize the statistical distribution of the target problem's severity level. Problems with a high severity level proportion greater than a preset threshold are marked as high severity problems. Cross-scene consistency is used to characterize whether the target problem occurs in multiple scene types. Problems that occur in all scene types are marked as global problems.

[0037] Thirdly, embodiments of this application provide an adaptive scheduling device for image testing, applied to an image testing system, comprising:

[0038] The first processing module is used to receive a batch of image files to be tested, obtain the image information and image type of each image file in the batch of image files to be tested, and determine the task level of each image file based on the image information and image type; wherein, the image information includes at least image complexity, image defect severity and historical performance parameters of similar files;

[0039] The second processing module is used to obtain the task testing order of the batch of image files to be tested based on the task level of each image file.

[0040] The third processing module is used to collect the operating status parameters of the image testing system and generate a task scheduling strategy for the image testing system based on the operating status parameters; the operating status parameters are used to characterize the callable resources of the image testing system.

[0041] The fourth processing module is used to perform image testing on a batch of image files to be tested based on the task scheduling strategy and the task testing order.

[0042] In one possible embodiment, the first processing module is further configured to:

[0043] Obtain basic image information for each image file and determine image complexity based on the basic image information; the basic image information includes at least image gradient, image size, and text detection results;

[0044] Histogram analysis is performed on the image files to obtain the image defect severity index, and the image defect severity of the image files is determined based on the image defect severity index; wherein, the image defect severity index includes at least the dark pixel ratio, the overexposed pixel ratio, and the Laplacian variance;

[0045] Obtain similar files to the image file and obtain historical performance parameters of the similar files; among them, the historical performance parameters of the similar files include at least historical time consumption and detection defect detection rate;

[0046] The task level of each image file is determined by a weighted algorithm based on image complexity, image defect severity, historical performance parameters of similar files, and image type.

[0047] In one possible embodiment, the first processing module is further configured to:

[0048] Based on the historical performance parameters of similar files, the weights of image complexity, image defect severity, and image type are dynamically adjusted respectively;

[0049] The task level of an image file is determined based on its complexity, the severity of its defects, its type, and the corresponding weights.

[0050] In one possible embodiment, the third processing module is further configured to:

[0051] Obtain the actual average response time, standard deviation of response time, and error rate trend of the API interface in the image testing system;

[0052] Based on the target average response time and the actual average response time, determine the deviation information of the API interface;

[0053] Based on the deviation information, response time standard deviation, and error rate trend, a new concurrency level for the API interface is obtained; the new concurrency level is used to characterize the number of batch image files that the image testing system can send to the API interface for testing.

[0054] Based on the new concurrency level and the historical concurrency level of the API interface, generate the target concurrency level of the API interface;

[0055] Based on the target concurrency, a task scheduling strategy is determined; wherein, the task scheduling strategy is used to characterize the number of batch image files to be tested that the API interface can receive each time.

[0056] In one possible embodiment, the first processing module is further configured to:

[0057] Obtain the error rate and error frequency of the API interface; the error rate is used to characterize the proportion of files that fail to be detected after the API interface receives a number of files, and the error frequency is the number of times the API stops detecting due to excessive concurrency per unit time;

[0058] If the error rate is greater than the preset threshold or the error frequency is greater than 0, the new concurrency level will be dynamically adjusted to obtain the adjusted concurrency level.

[0059] Based on the adjusted concurrency level and the historical concurrency level of the API interface, the target concurrency level of the API interface is generated.

[0060] In one possible embodiment, the first processing module is further configured to:

[0061] If the image testing system fails to execute image testing on a batch of image files to be tested via API interface call, then generate an analysis of the reasons for the API interface call failure.

[0062] Based on the mapping relationship and cause analysis, a retry strategy for image testing of the image testing system is generated; where the mapping relationship is the correspondence between the cause analysis and the retry strategy.

[0063] Fourthly, embodiments of this application provide a summary report generation apparatus for image testing, applied to an image testing system, comprising:

[0064] The fifth processing module generates image test results for each image file, performs single-group structured compression on the image test results for each image file, and extracts key test information for each image file; among which, key test information includes at least the defect level judgment for each dimension, core defect description, comprehensive score, and optimization suggestions;

[0065] The sixth processing module is used to perform problem pattern clustering on the key test information of all image files based on the feature dimension type of each image file, resulting in multiple groups; among which, the feature dimension type includes scene type, defect type, and severity level;

[0066] The seventh processing module is used to perform cross-group trend insight analysis based on the clustering results of multiple groups, and generate trend insight information; among which, trend insight information includes problem coverage, scenario relevance, severity distribution and cross-scenario consistency;

[0067] The eighth processing module is used to generate image test reports for batch image files by calling a large language model, using trend insight information as input context.

[0068] In one possible embodiment, problem coverage is used to characterize the proportion of the target problem in all image files. Problems with a coverage greater than a preset threshold are marked as systemic problems or high-frequency problems. Scene relevance is used to characterize the strength of the association between the target problem and a specific scene, and is calculated by conditional probability ratio. Severity distribution is used to characterize the statistical distribution of the target problem's severity level. Problems with a high severity level proportion greater than a preset threshold are marked as high severity problems. Cross-scene consistency is used to characterize whether the target problem occurs in multiple scene types. Problems that occur in all scene types are marked as global problems.

[0069] Fifthly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0070] The memory stores the instructions that the computer executes;

[0071] The processor executes computer execution instructions stored in memory, causing the processor to perform the methods described above.

[0072] Sixthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided above.

[0073] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method provided above.

[0074] The adaptive scheduling and summary report generation method and apparatus for image testing provided in this application receive a batch of image files to be tested, obtain the image information and image type of each image file and determine the corresponding task level, combine the task levels of each image file to obtain the task testing order of the batch of image files, collect the operating status parameters of the image testing system and generate a task scheduling strategy based on the operating status parameters, and then execute the image testing of the batch of image files to be tested based on the task scheduling strategy and the task testing order. This enables the execution order of image testing tasks to be adapted to the importance of tasks and the status of system callable resources, thereby improving the processing efficiency and operational stability of batch image testing, and helping to reduce the throughput limitations and increased error rate caused by static processing methods. Attached Figure Description

[0075] 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.

[0076] Figure 1 A flowchart illustrating the adaptive scheduling method for image testing provided in this application. Figure 1 ;

[0077] Figure 2 A flowchart illustrating the adaptive scheduling method for image testing provided in this application. Figure 2 ;

[0078] Figure 3 A schematic diagram of the method for generating summary reports for image testing provided in this application;

[0079] Figure 4 A schematic diagram of the structure of the adaptive scheduling device for image testing provided in this application;

[0080] Figure 5 A schematic diagram of the device for generating summary reports for image testing provided in this application;

[0081] Figure 6 A hardware schematic diagram of the adaptive scheduling and summary report generation device for image testing provided in this application.

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

[0083] The R&D and testing of intelligent terminal images involves batch image analysis and task scheduling control technologies, which are commonly used to verify the imaging effects of devices such as mobile phones, action cameras, drones, and vehicle cameras. In practical applications, image testing systems typically receive multiple sets of image files to be tested, call analysis interfaces such as visual language models to detect exposure, white balance, sharpness, and defects, and summarize the analysis results to form a quality assessment basis.

[0084] In existing batch image testing solutions, image files are typically processed according to preset queue rules or static concurrency methods. After a task enters, the system distributes them to the analysis interface in a fixed order, with the concurrency scale or waiting order mainly determined by manual experience. For report generation, the analysis results of each group are usually directly summarized and processed uniformly to complete the overall evaluation of the batch images.

[0085] The problem with this type of solution is that the task processing lacks adaptability to fluctuations in interface response time, rate limiting, and changes in resource usage. When available resources are scarce, tasks may continue to be deployed at the original pace, leading to increased failure rates and processing delays. Conversely, when resources are idle, it is difficult to increase throughput in a timely manner, resulting in wasted computing power. At the same time, different image files vary significantly in complexity, defect severity, and historical performance. If a uniform sorting method is still used, high-risk or high-value tasks may not be prioritized, affecting the timeliness of discovering critical issues.

[0086] As the batch size increases further, the above-mentioned defects will overlap, not only reducing the overall testing efficiency and stability, but also causing problems such as excessive input content, quality fluctuations and increased processing costs in subsequent summary analysis, making it difficult to meet the requirements of rapid testing and stable output of large-scale images in the R&D stage.

[0087] In light of this, balancing task prioritization with system resource changes during batch image testing has become a pressing technical challenge. To address this issue, an adaptive scheduling method for image testing is proposed. Upon receiving a batch of image files to be tested, the method first acquires the image information and type of each file. Then, based on parameters such as image complexity, image defect severity, and historical performance of similar files, the task level of each image file is determined. Next, a task testing order is formed according to the task level. Simultaneously, the operating status parameters of the image testing system are collected, and a task scheduling strategy is generated based on these parameters. Finally, the batch image files are executed by combining the task testing order and the task scheduling strategy.

[0088] This method is applicable to distributed image testing architectures, which may include a task scheduling center, a visual language model service cluster, and a report generation engine. This enables more rational task allocation based on changes in available resources during batch image analysis. By combining task priority ranking with a runtime-driven scheduling strategy, the processing efficiency and execution stability of batch image testing can be improved.

[0089] Figure 1 The flowchart of the adaptive scheduling for image testing provided in this application Figure 1 ,like Figure 1 As shown, the method includes:

[0090] S101. Receive the batch of image files to be tested, obtain the image information and image type of each image file in the batch of image files to be tested, and determine the task level of each image file based on the image information and image type.

[0091] In this embodiment, the image information includes at least image complexity, image defect severity, and historical performance parameters of similar files. The image testing system serves as the execution environment for this method, carrying out the entire process of batch image file access, feature extraction, scheduling decisions, and test execution. The batch image files to be tested are a set of data to be analyzed received by the image testing system in a single test task, which can originate from terminal device uploads, test client pushes, shared storage directory scans, or message queue subscriptions. An image file is the smallest processing unit for system scheduling and testing; it can be a single image file or a group of related images organized according to a shooting sequence. Image information describes the processing attributes of each image file, including at least image complexity, image defect severity, and historical performance parameters of similar files. Image type is used to distinguish different scene categories, test categories, or analysis link categories. Task level is a quantitative representation of the system's priority in processing image files, used to generate the subsequent task test order.

[0092] In practice, the task access module of the image testing system first receives the batch of image files to be tested and generates a unique task identifier for each image file, writing the file path, upload time, source device identifier, shooting batch number, and basic metadata into the task cache table. For image files uploaded via the network interface, the system performs file integrity verification after reception; for image files imported via a shared storage directory, the system reads newly added files based on a directory listening mechanism and performs integrity verification; for tasks delivered via a message queue, the system retrieves the corresponding image file based on the object storage address in the message body and enters a unified processing flow. After reception, the system calls the metadata parsing component to extract the basic attribute information of each image file and determines the image type based on preset type mapping rules. Image types can be divided according to scene category, test category, or analysis link category. In one possible embodiment, the image type is jointly determined by the file directory label, shooting script tag, and metadata fields. When multiple labels conflict, they are normalized according to a predefined priority.

[0093] When extracting image information, the system performs pre-analysis on each image file. Image complexity characterizes the processing difficulty of the image file in subsequent image testing and can be determined based on basic image features. Image defect severity characterizes the impact of defect signs in the image on the test results and can be determined based on image quality features. Historical performance parameters of similar files are derived from sample records similar to the current image file in the historical test database, including at least historical processing time and defect detection rate. Similarity can be determined based on image type, shooting device information, resolution, scene tags, and image features. The system selects similar samples from the historical database and calculates the average processing time, defect detection rate, and processing performance of these samples in historical tests, thereby generating historical performance parameters of similar files for the current image file.

[0094] During the task level determination phase, the system comprehensively determines the task level based on image complexity, image defect severity, historical performance parameters of similar files, and image type. The system can classify image files into high, medium, and low levels according to the task level, or retain consecutive sorting results for subsequent sorting. Based on the above analysis, by simultaneously constructing image complexity, image defect severity, and historical performance parameters of similar files during the receiving phase, the task level no longer relies on a static queue or a single rule, but can reflect the processing difficulty, potential problem intensity, and historical processing characteristics of each image file, thus establishing an input basis for subsequent sequential arrangement. It should be understood that the above example is for demonstration purposes only and is not limiting.

[0095] S102. Based on the task level of each image file, obtain the task test order of the batch of image files to be tested.

[0096] In this embodiment, the task testing order is used to indicate the order in which batch image files enter the image testing process, and is the process of converting task levels into an actual execution sequence. Image files with higher task levels are placed earlier in the task testing order so that the system can prioritize their selection during subsequent resource allocation. The task testing order is not simply arranged according to the reception time, but is organized primarily based on the task level obtained for each image file in S101.

[0097] In practice, after the task levels are determined, the image testing system generates a set of tasks to be sorted. Each element in the set contains at least a task identifier, task level, image type, and reception time. The system sorts the batch of image files to be tested according to their task levels, generating a task testing order. When multiple image files have the same task level or fall within the same level range, the system can adjust the sorting based on reception time, task status, or other scheduling-related information. In terms of output, the system saves the task testing order as an ordered task table that can be read by the scheduler. This ordered task table records the sorting position and current status of each task. Based on the above analysis, this step maps task levels to an executable sequential structure, allowing image files requiring priority processing to enter the execution window first in batch testing, and providing input for subsequent adaptive deployment based on resource status. It should be understood that the above example is for demonstration purposes only and is not a limitation.

[0098] S103. Acquire the operating status parameters of the image testing system, and generate a task scheduling strategy for the image testing system based on the operating status parameters; wherein, the operating status parameters are used to characterize the callable resources of the image testing system.

[0099] In this embodiment, the running status parameters reflect the current resource status of the image testing system that can be used to perform image testing, and serve as the direct basis for generating the task scheduling strategy. Available resources include the concurrency capacity allocated by the scheduling center, available instances of processing services, interface response capabilities, network resources, and task queue status. The task scheduling strategy characterizes the number of tasks deployed, the deployment rhythm, and the resource allocation method under the current resource status.

[0100] In practice, the image testing system collects operational status parameters according to a set cycle and processes the collected results to obtain the status information of currently available resources. Based on the operational status parameters, the system determines whether the current resources are in a relatively sufficient, relatively strained, or relatively stable state, and generates corresponding task scheduling strategies accordingly. When available resources are relatively abundant, the system can increase the number of tasks deployed and parallel processing capabilities; when available resources are relatively strained, the system can reduce the number of tasks deployed and control the pace of task entry; when the resource status changes, the system adjusts the task scheduling strategy accordingly. Based on the above analysis, this step transforms resource monitoring results into task deployment rules, enabling the scheduling center to dynamically adjust the task scheduling process based on changes in currently available resources, thereby ensuring that the task scheduling process remains consistent with the system's real-time carrying capacity. It should be understood that the above example is for demonstration purposes only and is not limiting.

[0101] S104. Based on the task scheduling strategy and task testing order, perform image testing on the batch of image files to be tested.

[0102] In this embodiment, the task scheduling strategy limits the number of tasks that can be executed at any given time and the method of task deployment, while the task testing order limits the order in which candidate tasks are selected. Both factors work together in the image testing execution process. Under the control of the scheduling center, the image testing system selects image files that conform to the current task scheduling strategy from the front end of the task testing order, sends them to the corresponding processing unit for analysis, and receives the analysis results.

[0103] In practice, the scheduling center maintains the current available execution capacity according to the task scheduling strategy. When available execution capacity exists, it reads the top-ranked tasks with a pending status from the ordered task table formed in S102 and puts the selected image files into the test execution process. During execution, the system controls the pace and number of task deployments according to the current task scheduling strategy. When changes in running status parameters cause the task scheduling strategy to be updated, the system adjusts the subsequent task deployments according to the updated task scheduling strategy. After the test is completed, the system records the test results and execution information corresponding to each image file. Based on the above analysis, this step, by simultaneously implementing the priority relationship in the task test order and the resource constraints in the task scheduling strategy into the task deployment process, enables the test execution of batch image files to both follow priority management and dynamically adjust with changes in resource status, thereby achieving adaptive scheduling for large-scale image testing scenarios. It should be understood that the above example is only for demonstration and not a limitation.

[0104] Based on the above analysis, this application provides an adaptive scheduling method for image testing, comprising: receiving a batch of image files to be tested; obtaining image information and image type of each image file in the batch of image files to be tested; determining the task level of each image file based on the image information and image type; obtaining the task testing order of the batch of image files to be tested based on the task level of each image file; collecting the operating status parameters of the image testing system; generating a task scheduling strategy for the image testing system based on the operating status parameters; and executing image testing on the batch of image files to be tested based on the task scheduling strategy and the task testing order. In this application, by incorporating image complexity, image defect severity, and historical performance parameters of similar files into the task level determination process, and linking the task level ranking results with the operating status parameters representing callable resources, the image testing system can control the task sequence and task deployment rhythm during batch image testing. When the resource status changes, the task scheduling strategy is updated accordingly, and the scale of subsequent tasks and the system's carrying capacity change accordingly; when different image files differ in image complexity, image defect severity, and historical performance parameters of similar files, the task testing order can prioritize image files that need to be processed first. Therefore, batch image testing can continuously output execution plans that match the current resource status in large-scale scenarios. It should be understood that the above example is for illustrative purposes only and is not a limitation.

[0105] Figure 2 A flowchart illustrating the adaptive scheduling method for image testing provided in this application. Figure 2 ,like Figure 2 As shown, in this embodiment... Figure 1 Based on the embodiments, the adaptive scheduling method for image testing is described in detail, wherein steps S201 to S202 are used to determine the task level of each image file based on image information and image type; step S203 generates the task scheduling strategy of the image testing system; the method includes:

[0106] S201. Receive a batch of image files to be tested, obtain the image information and image type of each image file in the batch of image files to be tested, obtain the basic image information of each image file, and determine the image complexity based on the basic image information; perform histogram analysis on the image files to obtain the image defect severity index of the image files, and determine the image defect severity of the image files based on the image defect severity index; obtain similar files of the image files and obtain the historical performance parameters of the similar files.

[0107] In its implementation, the basic image information includes at least image gradient, image size, and text detection results; the image defect severity index includes at least the proportion of dark pixels, the proportion of overexposed pixels, and the Laplacian variance; and the historical performance parameters of similar files include at least historical processing time and defect detection rate. After receiving a single image file, the system first calculates the gradient of the image matrix, forming gradient intensity parameters based on the statistical values ​​of the horizontal and vertical gradients. This is then combined with the image width and height, total number of pixels, and the text region confidence score output by the text detection module to construct a basic image information vector. Subsequently, the system performs grayscale histogram statistics on the image file, calculating the proportion of dark pixels and the proportion of overexposed pixels based on brightness thresholds. After performing Laplacian convolution on the image, the variance value is calculated to form the image defect severity index. The system also searches the historical database for similar files based on filename, resolution, color mode, shooting source type, and detected defect tags, extracting their average historical processing time and defect detection rate as historical performance parameters for similar files. Then, the image complexity, image defect severity, historical performance parameters of similar files, and image type are input into the weighted scoring model, and the task level is calculated according to the preset weights. The task level can be divided into high, medium, and low levels for subsequent scheduling and use.

[0108] In this method, the system first performs lightweight feature extraction on the image files, and then combines the severity of image defects with the performance of similar historical samples to generate a comprehensive score. This allows files in the same batch that are more difficult to analyze, have a higher defect risk, or have a longer historical processing time to receive a higher task level. After the task level is output, it can be directly used as the sorting basis in batch image testing, ensuring that the task testing order is consistent with the file characteristics.

[0109] With this specific implementation method, the determination of task level no longer depends solely on a single image attribute, but rather on a joint evaluation of image complexity, image defect severity, historical performance parameters of similar files, and image type. This makes the priority division of different image files more in line with the actual analysis load and defect detection requirements, thereby improving the sorting accuracy and execution stability of batch image testing.

[0110] S202. Based on the historical performance parameters of similar files, dynamically adjust the weights of image complexity, image defect severity, and image type respectively; based on image complexity, image defect severity, and image type and their corresponding weights, obtain the task level of the image file.

[0111] In its implementation, the system first extracts basic image information and generates an image complexity score for each image file. Then, it calculates the image defect severity score based on the proportion of dark pixels, the proportion of overexposed pixels, and the Laplacian variance. Simultaneously, it retrieves historical files similar to the current image file, calculating their average processing time and defect detection rate to form historical performance parameters for similar files. Subsequently, the system inputs these historical performance parameters into a weight correction model, dynamically updating the weights for image complexity, image defect severity, and image type. Specifically, when historical processing time is long and the defect detection rate is high, the image defect severity weight is increased, and the remaining weight proportions are adjusted accordingly. Conversely, when historical processing time is short and the defect detection rate is low, the weights for image complexity and image type are increased, ensuring that the task level better reflects the current file's characteristics in line with historical performance. The weight correction model can be implemented using a normalized weighting method, keeping the sum of all weights a preset constant for ease of subsequent calculations.

[0112] After weighting, the system multiplies the image complexity score, image defect severity score, and image type code by their respective weights and then sums them to obtain the task level of the image file. A higher task level indicates that the file should be prioritized for analysis and processing. This task level serves as the basis for generating the order of subsequent task tests and is used in conjunction with a task scheduling strategy driven by runtime parameters. Because the weights dynamically change based on the historical performance parameters of similar files, the calculated task level reflects the correlation between historical processing time, defect detection rate, and current image features, thus giving higher priority to high-risk image files. Using this method, task sorting becomes more adaptable to different file types, the allocation results of batch image tests are more stable, and it is easier to quickly locate image files with severe defects in complex scenarios.

[0113] S203. Based on the task level of each image file, obtain the task test order of the batch of image files to be tested; obtain the actual average response time, response time standard deviation, and error rate trend of the API interface in the image testing system; determine the deviation information of the API interface based on the target average response time and the actual average response time; obtain the new concurrency of the API interface based on the deviation information, response time standard deviation, and error rate trend; generate the target concurrency of the API interface based on the new concurrency and the historical concurrency of the API interface; determine the task scheduling strategy according to the target concurrency.

[0114] In the specific implementation, the new concurrency level is used to characterize the number of batch image files to be tested that the image testing system can send to the API interface; the task scheduling strategy is used to characterize the number of batch image files to be tested that the API interface can receive each time.

[0115] The image testing system can summarize API (Application Programming Interface) call records according to a preset statistical window, calculating the actual average response time, response time standard deviation, and error rate trend. The system then calculates the difference between the target average response time and the actual average response time to obtain deviation information. This deviation information, along with the response time standard deviation and error rate trend, is input into the concurrency calculation module to generate a new concurrency level. This new concurrency level reflects the number of batch image files that the system can currently submit to the API interface for testing. The system then merges this concurrency level with historical concurrency levels to obtain the target concurrency level. The fusion process can employ weighted averaging, amplitude limiting correction, or historical backtracking correction to ensure continuous and stable concurrency adjustment results. Based on the target concurrency level, the task scheduling module limits the number of batch image files submitted to the API interface each time to within the target concurrency range and organizes the delivery rhythm of the image files to be tested accordingly.

[0116] This method considers interface response deviation, fluctuation level and error trend during the scheduling process, and combines historical concurrency records to form the final reception scale, so that task distribution is consistent with the interface carrying capacity, thereby making the batch image test deployment control more stable and facilitating timely adjustment of the number of files received each time when the running status changes.

[0117] In one possible implementation, the error rate and error frequency of the API interface can affect the concurrency of the API interface. Specific methods include: obtaining the error rate and error frequency of the API interface; the error rate characterizes the proportion of files that fail to be detected after the API interface receives a number of files, and the error frequency is the number of times the API interface stops detecting due to excessive concurrency per unit time; if the error rate is greater than a preset threshold or the error frequency is greater than 0, the new concurrency is dynamically adjusted to obtain the adjusted concurrency; based on the adjusted concurrency and the historical concurrency of the API interface, the target concurrency of the API interface is generated.

[0118] In implementation, after submitting batch image files to the API interface, the system synchronously collects the interface's returned status codes, failure receipts, and timeout records. It calculates the percentage of failed files to form the error rate and the number of times detection is interrupted per unit time due to rate limiting, denial of service, or resource exhaustion to form the error frequency. When the error rate exceeds a preset threshold or the error frequency is greater than 0, the task scheduling module dynamically adjusts the new concurrency level. This adjustment may involve proportionally reducing the concurrency or recalculating the concurrency control value to match the current load. The adjusted concurrency level is then weighted and merged with historical concurrency levels to output a target concurrency level, which is used to update the number of subsequent batch files to be submitted.

[0119] This approach uses both error rate and error frequency to characterize the actual load state of the API interface and directly feeds the anomaly detection results back into the concurrency control process. This allows the target concurrency level to adjust according to changes in the interface's health status, ensuring that subsequent image detection tasks remain consistent with the interface's available capacity. With this approach, the API interface can promptly reduce concurrency deployment intensity under high load, and after resource recovery, it can gradually revert to historical concurrency levels, thereby improving the continuity of batch image testing and the stability of task scheduling.

[0120] In one possible implementation, if the image testing system fails to call the API interface during image testing of a batch of image files to be tested, a cause analysis of the API interface call failure is generated; based on the mapping relationship and the cause analysis, a retry strategy for the image testing system is generated; wherein, the mapping relationship is the correspondence between the cause analysis and the retry strategy.

[0121] In its implementation, when the image testing system sends batch image files to the visual language model service or other image analysis interfaces, if the interface returns a failure response, connection interruption response, or timeout response, the system can write the status code, error message, return duration, and the number of concurrent requests at that time into the failure record and perform attribution analysis on the failure record. The attribution analysis can combine interface rate limiting thresholds, response latency thresholds, network connectivity status, and task queue backlog to categorize the failure reasons into types such as rate limiting triggering, interface timeout, short-term service unavailability, abnormal request parameters, or insufficient upstream resources, and output the corresponding cause analysis results.

[0122] After obtaining the cause analysis, the system retrieves the retry method matching the cause analysis from the preset mapping relationship, and then generates a retry strategy. The mapping relationship can be stored as a rule table or a key-value pair structure, where the key is the failure cause category and the value is the corresponding retry control parameter. The retry control parameter includes at least the retry interval, the number of retries, whether to pause and wait, whether to reduce concurrency and resend, and whether to switch to a backup interface. For the case of rate limiting triggering, the retry strategy can be set to resubmit the task after a preset cooldown time and use exponential backoff for subsequent requests; for the case of interface timeout, the retry strategy can be set to retain the current task priority and reduce the concurrent sending density; for the case of abnormal parameters, the retry strategy can be set to stop automatic retry and output the parameter information to be corrected. In this way, the system can establish a stable correspondence between failure causes and recovery strategies. For example, when the image testing system triggers an API call failure during the testing of batch image files, the system will automatically start a closed-loop process of cause analysis-strategy matching-retry execution. Specifically, the system first identifies the cause of failed requests by distinguishing the failure type through HTTP status codes (such as 429, 504, 500, etc.). For example, 429 corresponds to "rate limiting", 504 corresponds to "timeout", 500 / 502 / 503 corresponds to "server error", 402 / 403 corresponds to "quota exhaustion", and network abnormalities are classified as "connection failure". Then, the system dynamically generates an appropriate retry strategy based on the predefined mapping relationship between failure reasons and retry strategies (this mapping relationship clarifies the optimal response logic under different failure scenarios). For example, if the failure reason is "rate limit" (status code 429), the system will adopt a retry strategy of "exponential backoff + global backoff lock"; if the failure reason is "timeout" (status code 504 / 524), the system will execute a "limited retry (maximum 2 times)" strategy; if the failure reason is "quota exhaustion" (status code 402 / 403), the system will pause all test tasks and notify the user (e.g., by sending an email or pop-up notification), and the task will be restarted manually or automatically after the quota is restored; if the failure reason is "network error" (e.g., connection failure), the system will also adopt an "exponential backoff (maximum 3 times)" strategy, with the backoff time being the same as in the "server error" scenario. Through this dynamic policy generation mechanism driven by the mapping relationship, the system can adaptively adjust retry behavior (such as the number of retries, backoff time, and whether to pause the task) according to the specific reasons for failure. This avoids invalid retries (such as blindly retrying in the case of quota exhaustion) and alleviates transient failures (such as server overload) through exponential backoff. At the same time, it prevents multiple concurrent tasks from aggravating the risk of API rate limiting due to synchronous retries, and ultimately significantly improves the robustness, efficiency and success rate of image testing.

[0123] After adopting the above implementation, the image testing system can first complete the cause attribution when the interface fails, and then generate retry control parameters that match the failure type according to the corresponding relationship, so that the recovery behavior is consistent with the fault type, thereby improving the test continuity and task recovery efficiency under abnormal conditions, and reducing the resource consumption caused by invalid repeated calls.

[0124] Figure 3 A flowchart illustrating the method for generating summary reports for image testing provided in this application is shown below. Figure 3 As shown, a detailed explanation of the method for generating summary reports for image testing is provided.

[0125] S301. Generate image test results for each image file, perform single-group structured compression on the image test results of each image file, and extract key test information from each image file.

[0126] In this embodiment, the key test information includes at least the defect level determination for each dimension, the core defect description, the comprehensive score, and optimization suggestions. The core of step S301 lies in performing single-group structured compression on the original analysis results of each image file to extract key test information, thereby significantly compressing the data volume while preserving the core semantics, laying the foundation for subsequent multi-level processing.

[0127] Its design principle is based on a structured understanding of image test results: the original analysis results usually contain a lot of redundant descriptions, repetitive statements and low information density content, such as multi-angle descriptions of the same defect, lengthy descriptions of normal performance and intermediate reasoning records of the analysis process. These contents are readable in a single perspective, but become the main source of information noise in batch aggregation scenarios.

[0128] Therefore, this step uses preset field templates to extract defect level judgments, core defect descriptions, comprehensive scores, and optimization suggestions for each dimension from the original results. It also merges repetitive statements, low-information-density statements, and synonymous expressions to form shorter but semantically complete key test information. For example, in an image test targeting mobile phone camera imaging quality, the original analysis results might contain detailed descriptions of approximately 600 tokens, covering item-by-item analysis of four dimensions: AE exposure, AWB white balance, ISP noise reduction, and AF focusing, including the reasoning and intermediate conclusions for each analysis. After structured compression, the results are refined into a summary of approximately 100 tokens, such as "AE: Major – Obvious exposure deviation of the subject, highlights cannot be suppressed; AWB: Critical – Image severely yellowish, triggering the rule of light skin tones not being yellowish; ISP: Minor – Slight noise in dark areas; AF: No defects; Suggestion: Optimize the AE target brightness curve; Fine-tune the AWB light skin color temperature mapping," achieving a compression ratio of 6:1. This compression method is not a simple text truncation, but rather based on an understanding of the knowledge in the field of image testing, it identifies and retains the core information that is most valuable for subsequent analysis and report generation, while discarding procedural descriptions and redundant expressions.

[0129] This step transforms the detailed analysis results, originally scattered across various image files, into structured key test information. This information maintains the semantic integrity of the original results while significantly reducing the data volume, providing high-quality input for subsequent problem pattern clustering and trend insight analysis. Simultaneously, structured compression ensures that the key test information across different image files has a unified field structure and expression standard, facilitating subsequent cross-file comparison, statistical, and correlation analysis.

[0130] Furthermore, the compressed key test information reduces storage and transmission overhead, enabling efficient processing of test results from large batches of image files even in resource-constrained environments. This step transforms the raw, massive analysis results into refined, structured information, laying a solid foundation for the efficiency and accuracy of the entire batch image analysis process.

[0131] S302. Based on the feature dimension type of each image file, perform problem pattern clustering on the key test information of all image files to obtain multiple groups.

[0132] In this embodiment, based on the feature dimension type of each image file, problem pattern clustering is performed on the key test information of all image files. This groups image files with the same or similar characteristics together, laying a structural foundation for subsequent cross-group trend insight analysis. The design principle stems from a deep understanding of data organization methods in batch image analysis scenarios: when the number of image files is large, directly mixing the analysis results of all files together not only makes it difficult to identify common problems and differences, but also leads to fragmentation and information redundancy in the report. Therefore, this step first encodes the shooting environment label, analysis task label, defect pattern label, and complexity label of each image file through the feature dimension acquisition module, forming a feature vector that can be used for clustering calculations.

[0133] In practical implementation, scene type, analysis type, defect pattern, and complexity level can be represented by discrete encoding or vector embedding, respectively. For example, "outdoor sunny day" can be encoded as a vector [1,0,0,0], "indoor low light" as [0,1,0,0], or the "AE overexposure" defect pattern can be mapped to a specific embedding vector for subsequent grouping of similar files. The clustering module calculates the distance or similarity between files based on these feature vectors and groups image files with similar features into the same group.

[0134] For example, in a batch test of mobile phone camera image quality, the system collected 25 sets of image files under different scenarios, including outdoor sunny days, indoor mixed lighting, cloudy outdoor days, and backlighting scenes. Through feature encoding and clustering calculations, the system divided these files into four groups. The five sets of outdoor sunny day scenes were grouped into one group, the eight sets of indoor mixed lighting scenes were grouped into another group, and so on. This feature-dimensional clustering method does not use traditional machine learning clustering algorithms, but rather a rule-based multi-dimensional cross-grouping method to ensure the interpretability and consistency of the clustering results.

[0135] The clustering dimensions specifically include three levels: scene-based clustering, defect-based clustering, and severity clustering. Scene-based clustering groups problems by scene label, analyzing the commonalities among groups within the same scene. Defect-based clustering groups problems by defect type, statistically analyzing the frequency of the same defect type in different scenes. Severity clustering groups problems by defect level, grouping high-severity issues (Blocker and Critical levels) together, medium-severity issues (Major level) together, and low-severity issues (Minor level) together. Through this multi-dimensional cross-grouping approach, the system can examine the distribution patterns of problems in batch image files from different perspectives.

[0136] After grouping, the cluster analysis module then statistically analyzes, compares, and extracts key test information within each group, generating an image test report that includes common defects, group differences, and rectification suggestions. For example, in the outdoor sunny scene group, the system found that 4 out of 5 groups had an AWB yellow tint issue, with severity ranging between Major and Critical. In the indoor mixed lighting scene group, 6 out of 8 groups had the same AWB yellow tint issue, but the severity was mainly Major. This grouping analysis allows the system to identify the high incidence of AWB yellow tint issues in warm color temperature scenes, providing important input for subsequent trend analysis.

[0137] This step effectively organizes and structures key test information previously scattered across various image files. Files with similar scenarios, defect patterns, and similar complexities are processed centrally, enabling subsequent trend analysis to be based on clear group characteristics and avoiding misjudgments and omissions caused by mixed information. Simultaneously, the rule-based multi-dimensional cross-grouping method ensures the interpretability and consistency of clustering results, allowing researchers to understand the basis and logic behind each grouping, enhancing the transparency and credibility of the entire analysis process. Furthermore, by centralizing image files with similar characteristics, the system reduces the semantic context switching overhead between adjacent calls in subsequent large language model calls, lowers inference latency, and improves output quality, thereby enhancing the overall efficiency and accuracy of the batch image analysis process.

[0138] S303. Based on the clustering results of multiple groups, perform cross-group trend insight analysis to generate trend insight information.

[0139] In this embodiment, cross-group trend insight analysis is performed based on the clustering results of multiple groups to generate trend insight information, thereby revealing hidden systemic problems, high-frequency problems, and the correlation patterns between problems and scenes in batch image files. Its design principle stems from the pursuit of depth in batch test data analysis: simply grouping image files and identifying common problems within each group still remains at the "intra-group perspective" and cannot answer higher-level questions such as "Does a certain defect occur in all scenarios?", "Is a certain defect particularly serious in a specific scenario?", and "Which problems are global and require firmware-level optimization?"

[0140] Therefore, this step involves cross-sectional comparison and statistical analysis of common issues across groups to construct trend insights from four dimensions: issue coverage, scenario relevance, severity distribution, and cross-scenario consistency, providing highly structured input for the final LLM report generation.

[0141] In its implementation, after grouping batches of image files, the system sequentially reads key test information within each group and identifies recurring anomalies through text similarity, grade consistency, and defect label matching, thus forming a set of common problems for that group. For example, in the outdoor sunny scene group, the system identified an AWB yellowing problem in 4 out of 5 groups, with severity ranging from Major to Critical; in the indoor mixed light scene group, the system identified the same AWB yellowing problem in 6 out of 8 groups, with severity mainly at Major; in the cloudy outdoor scene group, the AWB yellowing problem appeared in only 2 out of 6 groups, with severity ranging from Minor to Major. Subsequently, the system performs a horizontal comparison of the common problems across groups, extracting the frequency of occurrence, scene type, grade label, and total number of groups for the same target problem in different groups, and calculates problem coverage, correlation, severity distribution, and cross-scene consistency accordingly.

[0142] Taking the AWB yellowing issue as an example, its coverage rate is 12 / 25 groups, or 48%. According to the preset rules, coverage rates greater than 30% are marked as "high-frequency issues." Its scene correlation is calculated using conditional probability ratios. The probability of AWB yellowing in outdoor sunny scenes is 4 / 5, while the probability in other scenes is 8 / 20, with a ratio of (4 / 5) / (8 / 20)=2.0, which just reaches the strong correlation threshold, indicating that the AWB yellowing issue is strongly correlated with outdoor sunny scenes. In its severity distribution, the Critical level accounts for 1 / 12, the Blocker level is 0, and the Blocker+Critical level accounts for approximately 8.3%, which does not exceed the 30% threshold, so it is not marked as a "high-severity issue." Regarding its cross-scene consistency, the AWB yellowing issue appears in outdoor sunny, indoor mixed light, and cloudy outdoor scenes, but not in all scene types, so it is not marked as a "global issue."

[0143] Through these calculations, the structured trend insights generated by the system clearly reveal that the yellowish AWB issue is a common problem that occurs frequently in warm color temperature scenes, is strongly correlated with outdoor sunny scenes, and is mainly of Major severity but occasionally reaches Critical severity, providing the R&D team with a clear direction for optimization.

[0144] Similarly, regarding the AE exposure deviation issue, the system calculated its coverage rate to be 32%, classifying it as a "high-frequency issue." Scene correlation calculations showed that the probability of AE exposure deviation occurring in backlit scenes was 4 / 4, while in other scenes it was 4 / 21, a ratio of (4 / 4) / (4 / 21) = 5.25, far exceeding the strong correlation threshold of 2.0, indicating a very strong correlation between AE exposure deviation and backlit scenes. In terms of cross-scene consistency, AE exposure deviation only occurred in backlit scenes and was almost non-existent in other scenes, thus it is a scene-specific issue requiring scene-level parameter tuning rather than firmware-level optimization. As for the AF defocus issue, its coverage rate was only 4%, classifying it as an "occasional issue," and it only appeared in one group, possibly due to accidental factors. The system suggests paying attention but not urging immediate action.

[0145] Through this step, the previously scattered discrete test results across various groups are systematically summarized into statistically significant trend insights. These insights not only encompass the prevalence and severity of the problems but also reveal the correlation between problems and scenarios, as well as the cross-scenario propagation characteristics of the problems. These trend insights can be stored in the statistical tables of the report generation module, serving as the core input for subsequent LLM report generation. Compared to directly using raw analysis results or group summaries, trend insights have higher information density and stronger structure, enabling LLM to directly organize and express data based on pre-extracted statistical patterns and relationships when generating reports. This avoids the uncertainty and token consumption associated with LLM's need to manually summarize from large amounts of raw data. Thus, step S303 achieves a qualitative leap from "data" to "information" and then to "insight," enabling the final image test report to not only present single-group problems but also reflect the prevalence, concentration, and hierarchical structure of problems across different scenarios, providing the R&D team with more valuable test conclusions for decision-making.

[0146] In one possible implementation, problem coverage is used to characterize the proportion of the target problem in all image files. Problems with a coverage greater than a preset threshold are marked as systemic problems or high-frequency problems. Scene relevance is used to characterize the strength of the association between the target problem and a specific scene, which is calculated by the conditional probability ratio. Severity distribution is used to characterize the statistical distribution of the target problem's severity level. Problems with a high severity level proportion greater than a preset threshold are marked as high severity problems. Cross-scene consistency is used to characterize whether the target problem occurs in multiple scene types. Problems that occur in all scene types are marked as global problems.

[0147] S304. Using trend insight information as input context, call the large language model to generate a batch of image test reports for image files.

[0148] In this embodiment, traditional methods directly use the original analysis results or group summaries as input to LLM. When the number of batch image files is large, the length of the input text increases linearly with the number of analysis groups. For example, when there are 100 analysis groups and each group's original result is about 500 tokens, the total input will reach 50,000 tokens, far exceeding the effective attention range of LLM (approximately 8,000 to 16,000 tokens). This leads to the loss of intermediate information in the model, a sharp decrease in attention to intermediate group analysis results, and excessively long inputs can easily induce the illusion enhancement problem, causing the model to produce conclusions that do not conform to reality. Furthermore, the token cost consumed in generating each report also increases linearly with the number of analysis groups. This step, however, fundamentally solves the above problems by using the trend insight information from the third-level output as the input context for LLM. The trend insights information is already highly structured and compressed. After the first three levels of processing, the original results of 100 sets of analysis are compressed into trend insights information of about 800 to 1,500 tokens, with a compression ratio of 30:1 to 60:1. This ensures that the input length of LLM is always within its effective range of concern, thereby avoiding the problems of intermediate information loss and illusion enhancement, while significantly reducing token consumption.

[0149] In its implementation, the system organizes the trend insights generated at the third level into structured input text according to a preset template. This input text typically includes four core parts: issue coverage statistics, scenario correlation analysis, severity distribution, and cross-scenario consistency assessment. Each part is presented with quantified data and clear classification labels. For example, the trend insights might include the following: "AWB yellowish tint issue, issue coverage 48%, marked as a high-frequency issue; strongly correlated with outdoor sunny scenarios, scenario correlation coefficient 2.0; in severity distribution, Critical accounts for 8.3%, not reaching the high severity threshold; regarding cross-scenario consistency, it appears in three scenarios: outdoor sunny, indoor mixed light, and cloudy outdoor, not covering all scenario types, marked as a scenario-specific issue." This structured input allows LLM to avoid manually summarizing from large amounts of raw data, instead directly organizing reports and expressing them based on pre-extracted statistical patterns and relationships. LLM receives not messy raw analysis results, but structured insights processed by human expert knowledge systems, thus enabling a more accurate understanding of the essence and patterns of the issues and generating higher-quality test reports. Taking a batch test of mobile phone camera image quality as an example, the system performed a complete four-level processing on 25 sets of image files, and the final trend insight information generated was about 1,200 tokens. Based on this input, LLM generated a comprehensive test report that included the overall test conclusions, detailed analysis of each problem pattern, description of scene correlation, and optimization suggestions. The entire process consumed about 2,500 tokens. In contrast, if the traditional full-volume stitching scheme were used, the total input of the 25 sets of original results would be about 15,000 tokens, and the token consumption would be about one-sixth of that of the original scheme.

[0150] This step significantly improves both the quality and efficiency of LLM report generation. Regarding report quality, because the input context already includes statistically validated trend insights, LLM-generated reports are no longer simple summaries of listed groups, but rather comprehensive analyses with in-depth insights. They clearly identify which problems are systemic, which are scenario-specific, which require firmware-level optimization, and which can be resolved through scenario-level parameter tuning, providing development teams with more valuable test conclusions for decision-making. In terms of token costs, the significantly reduced input length lowers the token consumption per report generation by approximately 80% to 90%, which translates to significant cost savings for development teams that frequently conduct batch tests. Regarding generation efficiency, the shorter input length also reduces LLM inference latency, shortening report generation time from minutes to seconds, thus improving the efficiency and responsiveness of the entire testing process. Furthermore, using trend insights rather than raw analysis results as input context enhances the controllability and interpretability of the report generation process. Researchers can review and adjust the analysis results during the trend insights stage, ensuring that the factual basis upon which the LLM report is based is accurate and reliable, avoiding the uncertainties that may arise from black-box models. Thus, step S304 achieves a complete closed loop from data to insights to report, enabling the batch image analysis workflow to achieve an optimal balance in terms of efficiency, quality, and cost.

[0151] This application applies to an image testing system that can be deployed during the R&D testing phase of smart terminal devices such as mobile phones, action cameras, and vehicle cameras. It is used to perform quality analysis on batches of image files acquired under different lighting conditions, such as "outdoor sunny day," "indoor mixed light," and "backlight." For example, a device R&D team receives 100 sets of images at a time, each set containing the results from both the test and comparison cameras. Subsequently, the VLM API is used to complete defect detection, parameter evaluation, and optimization suggestion generation. After receiving the batch of image files to be tested, the system extracts the image information and image type of each image file. For each image file, basic image information is first obtained, including at least image gradient, image size, and text detection results. The image complexity of the image file is determined based on the changes in image gradient, image size, and the content density reflected by the text detection results. For example, for multi-image comparisons in backlight scenes, if the edge gradient changes are large, the resolution is high, and there is a large amount of superimposed test label text, the corresponding complexity is high.

[0152] During pre-analysis of a single image file, the system also performs histogram analysis to calculate the proportion of dark pixels, the proportion of overexposed pixels, and the Laplacian variance, forming an image defect severity index. The severity of the image defect is then determined based on this index. For example, if a backlit image shows a high proportion of overexposed pixels in the highlight area, significant loss of detail in the shadows, and fluctuating sharpness, the file can be identified as having a high defect severity, corresponding to issues such as AE overexposure and AF instability. Simultaneously, the system searches for historical files similar to the image file to obtain historical performance parameters. These parameters include at least historical processing time and defect detection rate. For instance, the system retrieves past processing records from historical backlit images and multi-image comparison analysis tasks. If such files generally have long historical processing times and high defect detection rates, this historical performance is used for subsequent task severity calculations.

[0153] After obtaining image complexity, image defect severity, historical performance parameters of similar files, and image type, the system uses a weighted algorithm to determine the task level of each image file. Based on the historical performance parameters of similar files, the weights corresponding to image complexity, image defect severity, and image type are dynamically adjusted. When the historical processing time of similar files is long, the weight related to complexity is increased; when the detection defect rate of similar files is high, the weight related to defect severity is increased. Then, image complexity, image defect severity, and image type are comprehensively calculated according to their adjusted corresponding weights to obtain the task level of each image file. In a set of backlighting multi-image comparison tasks, if the scene complexity is set to 0.8, the defect severity to 1.0, and the task type weight base value to 0.9, and then comprehensively calculated using 0.3, 0.5, and 0.2, the task level can be calculated as 0.91, which is higher than that of a typical outdoor sunny single-image task. The image testing system arranges the batch of image files to be tested according to the task level of each image file, forming the task testing order.

[0154] While establishing the task testing sequence, the system collects the operational status parameters of the image testing system to characterize the currently available resources and obtains the actual average response time, standard deviation of response time, and error rate trend of the API interface from the system. The actual average response time is compared with the target average response time to determine the deviation information of the API interface. Then, combining the deviation information, standard deviation of response time, and error rate trend, a new concurrency level for the API interface is calculated. The new concurrency level represents the number of batch image files that the image testing system can send to this API interface. In a set of VLM API calls, the target average response time can be set to 25 seconds. When the actual average response time increases from 25 seconds to 40 seconds, and the error rate increases from 2% to 7%, the system calculates a new concurrency level based on the deviation, fluctuation level, and error rate trend. For example, if the initial concurrency level is 12, the new concurrency level can be adjusted to 6 to match the current interface capacity.

[0155] Meanwhile, the system acquires the error rate and error frequency of the API interface. The error rate represents the percentage of files that failed to be detected after the API interface received multiple files, and the error frequency is the number of times the API stopped detecting due to excessive concurrency per unit time. When the error rate exceeds a preset threshold or the error frequency is greater than zero, a dynamic adjustment is performed on the new concurrency level to obtain the adjusted concurrency level. The new or adjusted concurrency level is then combined with the historical concurrency level of the API interface to generate the target concurrency level. Based on the target concurrency level, a task scheduling strategy is determined. The task scheduling strategy represents the number of image files that the API interface can receive in each batch for testing. For example, when the system detects a 429 error and the number of rate limiting triggers per unit time is greater than zero, the concurrency can be further reduced based on the new concurrency level, and the target concurrency level can be formed by combining it with the historical stable operating concurrency level. This controls the number of image file batches sent to the API interface each time.

[0156] The image testing system executes batch image tests on the images to be tested according to the task testing order and controls the number of image files sent to the API interface each time based on the task scheduling strategy. Tasks involving backlighting scenes, high defect severity, and long historical analysis times are given priority access to interface resources. When an API interface call fails during testing, the system generates a cause analysis for that failure and, based on the pre-established mapping relationship between the cause analysis and retry strategies, generates a retry strategy for the image testing system. Then, it re-initiates test requests for the failed image files according to the retry strategy. For example, when the failure cause analysis result is an HTTP 429 rate limiting error, the system can trigger a global backoff lock and pause retrying for 30 seconds; when the failure cause analysis result is an HTTP 504 timeout error, the system can initiate retrying using an exponential backoff method, with request intervals of 1 second, 2 seconds, and 4 seconds respectively.

[0157] After completing the image testing for each image file, the system generates image test results for each image file and performs structural compression on the image test results to obtain key test information. This key test information includes at least multi-dimensional image defect level judgment, multi-dimensional core image defect description text, comprehensive score, and optimization suggestions. Taking a backlight scene test group as an example, the original analysis results may be approximately 500 tokens. After structural compression, approximately 120 tokens of key test information are formed, including a score of 45 / 100, AE at Blocker level with highlight overexposure and target brightness curve mismatch, AWB at Major level with color temperature deviation ΔE>8, and provides adjustments to the AE dynamic range expansion algorithm and calibration of AWB color temperature mapping parameters. Subsequently, the system obtains the feature dimension type of each image file, including scene type, analysis type, defect mode, and complexity level. Based on the feature dimension type of each image file, the system clusters the batch of image files, obtaining multiple groups, such as grouping by backlight, indoor mixed light, outdoor sunny day, and features such as AE overexposure, AWB yellowish tint, and AF defocus.

[0158] For each group, the system identifies key test information within that group and extracts common problems. It then acquires correlation information between multiple groups, including problem coverage, correlation degree, severity distribution, and cross-scene consistency. Problem coverage represents the proportion of the target problem appearing across multiple groups; correlation degree represents the correlation between the target problem and different scene types; severity distribution represents the grade distribution of multiple common problems; and cross-scene consistency represents whether the target problem appears in all scene types. For example, in the backlight-related group, the system can identify "AE overexposure" as a common problem, with a coverage rate of 80% in the correlation analysis group, a correlation strength of 2.5 with backlight scenes, and a severity level primarily at Blocker. In the indoor mixed light group, the system can identify AWB yellowing problem coverage at 60%; AF defocus coverage across multiple groups is approximately 5%. Based on the common problems and correlation information of each group, the system generates batch image test reports for image files. These reports include defect level determination for each scene, core problem descriptions, comprehensive scores, optimization suggestions, and cross-group trend information.

[0159] Figure 4 A schematic diagram of the adaptive scheduling device for image testing provided in this application is shown below. Figure 4 As shown, the adaptive scheduling device 40 for image testing provided in this embodiment includes:

[0160] The first processing module 401 is used to receive a batch of image files to be tested, obtain the image information and image type of each image file in the batch of image files to be tested, and determine the task level of each image file based on the image information and image type; wherein, the image information includes at least image complexity, image defect severity and historical performance parameters of similar files;

[0161] The second processing module 402 is used to obtain the task testing order of the batch of image files to be tested based on the task level of each image file.

[0162] The third processing module 403 is used to collect the operating status parameters of the image testing system and generate a task scheduling strategy for the image testing system based on the operating status parameters; wherein, the operating status parameters are used to characterize the callable resources of the image testing system.

[0163] The fourth processing module 404 is used to perform image testing on a batch of image files to be tested based on the task scheduling strategy and the task testing order.

[0164] In one possible embodiment, the first processing module 401 is further configured to:

[0165] Obtain basic image information for each image file and determine image complexity based on the basic image information; the basic image information includes at least image gradient, image size, and text detection results;

[0166] Histogram analysis is performed on the image files to obtain the image defect severity index, and the image defect severity of the image files is determined based on the image defect severity index; wherein, the image defect severity index includes at least the dark pixel ratio, the overexposed pixel ratio, and the Laplacian variance;

[0167] Obtain similar files to the image file and obtain historical performance parameters of the similar files; among them, the historical performance parameters of the similar files include at least historical time consumption and detection defect detection rate;

[0168] The task level of each image file is determined by a weighted algorithm based on image complexity, image defect severity, historical performance parameters of similar files, and image type.

[0169] In one possible embodiment, the first processing module 401 is further configured to:

[0170] Based on the historical performance parameters of similar files, the weights of image complexity, image defect severity, and image type are dynamically adjusted respectively;

[0171] The task level of an image file is determined based on its complexity, severity of defects, and type, along with their corresponding weights.

[0172] In one possible embodiment, the third processing module 403 is further configured to:

[0173] Obtain the actual average response time, standard deviation of response time, and error rate trend of the API interface in the image testing system;

[0174] Based on the target average response time and the actual average response time, determine the deviation information of the API interface;

[0175] Based on the deviation information, response time standard deviation, and error rate trend, a new concurrency level for the API interface is obtained; the new concurrency level is used to characterize the number of batch image files that the image testing system can send to the API interface for testing.

[0176] Based on the new concurrency level and the historical concurrency level of the API interface, generate the target concurrency level of the API interface;

[0177] Based on the target concurrency, a task scheduling strategy is determined; wherein, the task scheduling strategy is used to characterize the number of batch image files to be tested that the API interface can receive each time.

[0178] In one possible embodiment, the first processing module 401 is further configured to:

[0179] Obtain the error rate and error frequency of the API interface; the error rate is used to characterize the proportion of files that fail to be detected after the API interface receives a number of files, and the error frequency is the number of times the API stops detecting due to excessive concurrency per unit time;

[0180] If the error rate is greater than the preset threshold or the error frequency is greater than 0, the new concurrency level will be dynamically adjusted to obtain the adjusted concurrency level.

[0181] Based on the adjusted concurrency level and the historical concurrency level of the API interface, the target concurrency level of the API interface is generated.

[0182] In one possible embodiment, the first processing module 401 is further configured to:

[0183] If the image testing system fails to execute image testing on a batch of image files to be tested via API interface call, then generate an analysis of the reasons for the API interface call failure.

[0184] Based on the mapping relationship and cause analysis, a retry strategy for image testing of the image testing system is generated; where the mapping relationship is the correspondence between the cause analysis and the retry strategy.

[0185] In one possible embodiment, the fourth processing module 404 is further configured to:

[0186] Image test results are generated for each image file. The image test results are then structurally compressed to obtain key test information. The key test information includes at least the following: multi-dimensional image defect level determination, multi-dimensional core image defect description text, comprehensive score, and optimization suggestions.

[0187] Obtain the feature dimension type for each image file; where the feature dimensions include scene type, analysis type, defect pattern, and complexity level;

[0188] Based on the feature dimension type, batch image files are clustered and divided into multiple groups;

[0189] Cluster analysis is performed on each group to generate a batch of image test reports.

[0190] The first processing module 401 comprehensively considers image complexity, image defect severity, and historical performance parameters of similar files, and determines the task level based on image type. This allows for the accurate identification of high-risk, high-value, or more problematic image files, thus establishing a priority basis that better meets actual needs for subsequent testing. The second processing module 402 generates a task testing order based on the task level, prioritizing critical images in the testing process and improving the timeliness of problem discovery. The third processing module 403 continuously collects operational status parameters representing callable resources and generates a task scheduling strategy accordingly, enabling the scheduling process to dynamically adjust based on interface response, resource usage, and rate limiting changes. The fourth processing module 404 then combines the task testing order and task scheduling strategy to execute batch image testing. This suppresses disordered deployment and reduces the failure rate when resources are scarce, while increasing throughput when resources are idle. Therefore, it simultaneously improves the processing efficiency, execution stability, and resource utilization of batch image testing.

[0191] Figure 5 A schematic diagram of the image testing summary report generation device provided in this application is shown below. Figure 5 As shown, the image test summary report generation device 50 provided in this embodiment includes:

[0192] The fifth processing module 501 generates image test results for each image file, performs single-group structured compression on the image test results for each image file, and extracts key test information for each image file; among which, key test information includes at least the defect level judgment of each dimension, core defect description, comprehensive score and optimization suggestions;

[0193] The sixth processing module 502 is used to perform problem pattern clustering on the key test information of all image files based on the feature dimension type of each image file, and obtain multiple groups; wherein, the feature dimension type includes scene type, defect type and severity level;

[0194] The seventh processing module 503 is used to perform cross-group trend insight analysis based on the clustering results of multiple groups and generate trend insight information; wherein, the trend insight information includes problem coverage, scenario relevance, severity distribution and cross-scenario consistency;

[0195] The eighth processing module 504 is used to call a large language model to generate image test reports for batch image files, using trend insight information as input context.

[0196] In one possible embodiment, problem coverage is used to characterize the proportion of the target problem in all image files. Problems with a coverage greater than a preset threshold are marked as systemic problems or high-frequency problems. Scene relevance is used to characterize the strength of the association between the target problem and a specific scene, and is calculated by conditional probability ratio. Severity distribution is used to characterize the statistical distribution of the target problem's severity level. Problems with a high severity level proportion greater than a preset threshold are marked as high severity problems. Cross-scene consistency is used to characterize whether the target problem occurs in multiple scene types. Problems that occur in all scene types are marked as global problems.

[0197] Figure 6 This is a hardware schematic diagram of the adaptive scheduling and summary report generation device for image testing provided in this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the electronic device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0198] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0199] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0200] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0201] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0202] The electronic device 60 can be deployed as a scheduling node, analysis node, or integrated control node in the R&D and testing of intelligent terminal images. The memory 602 is used to store the batch image file processing flow, task level determination rules, running status acquisition rules, and scheduling strategy generation rules. After the processor 601 executes the instructions, it can process the image information, image type, complexity, defect severity, and historical performance parameters of the image to be tested, and generate an adaptive scheduling strategy by combining the system interface response time, flow limiting status, and resource usage changes. This enables the task testing order to be matched with the real-time resource status of the system, avoiding resource waste or increased failure rate caused by fixed concurrency and static queues. This improves the priority processing capability of high-risk and high-value image tasks and the overall test throughput stability, thus better meeting the application needs of large-scale image rapid testing, stable analysis, and subsequent report generation.

[0203] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0204] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0205] Once deployed in an image testing system, this computer program product can solidify the processing logic—which involves acquiring image information and types from each image file, determining task levels, establishing task testing order, and generating task scheduling strategies based on runtime parameters—into an executable program. This allows the processor to automatically perform task sorting and resource scheduling during batch image testing. Because the program considers image complexity, defect severity, historical performance, and system resource changes simultaneously during execution, it can suppress disordered deployment when resources are scarce and improve task throughput when resources are idle. This prioritizes testing high-risk or high-value images, thereby improving batch image analysis efficiency, test stability, and report input quality. Therefore, it is more suitable for large-scale image R&D testing scenarios.

[0206] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0207] By storing the computer execution instructions used to implement the above method in a computer-readable storage medium, the processor can directly call the corresponding program logic on intelligent terminal image R&D testing equipment or distributed testing nodes to complete the acquisition of image information under test, task level determination, task test sequence formation, collection of running status parameters, generation of task scheduling strategies, and execution of batch image tests. This allows the method to be stably deployed, reused, and migrated in software form, thus adapting to different image testing scenarios such as mobile phones, action cameras, drones, and vehicle-mounted cameras. Simultaneously, by combining task level with system running status for scheduling, the task deployment rhythm can be adaptively adjusted according to resource changes, thereby improving the throughput efficiency, execution stability, and timeliness of key issue discovery in batch image testing. Therefore, it is beneficial to meet the needs of large-scale rapid image testing and stable output.

[0208] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0209] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0210] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components 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, methods, or units, and may be electrical, mechanical, or other forms.

[0211] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0212] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0213] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0214] 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.

[0215] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. An adaptive scheduling method for image testing, characterized in that, Applications in image testing systems include: Receive a batch of image files to be tested, obtain the image information and image type of each image file in the batch of image files to be tested, and determine the task level of each image file based on the image information and the image type; wherein, the image information includes at least image complexity, image defect severity and historical performance parameters of similar files; Based on the task level of each image file, the task testing order of the batch of image files to be tested is obtained; The system collects the operating status parameters of the image testing system and generates a task scheduling strategy for the image testing system based on the operating status parameters; wherein, the operating status parameters are used to characterize the callable resources of the image testing system. Based on the task scheduling strategy and the task testing order, image testing is performed on the batch of image files to be tested; The step of generating a task scheduling strategy for the image testing system based on the operating status parameters includes: The system obtains the actual average response time, response time standard deviation, and error rate trend of the API interface in the image testing system; determines the deviation information of the API interface based on the target average response time and the actual average response time; obtains a new concurrency level for the API interface based on the deviation information, the response time standard deviation, and the error rate trend; wherein the new concurrency level characterizes the number of batch image files to be tested that the image testing system can send to the API interface; generates a target concurrency level for the API interface based on the new concurrency level and the historical concurrency level of the API interface; and determines the task scheduling strategy according to the target concurrency level; wherein the task scheduling strategy characterizes the number of batch image files to be tested that the API interface can receive each time. Obtain the error rate and error frequency of the API interface; the error rate is used to characterize the proportion of files that fail to be detected after the API interface receives multiple files, and the error frequency is the number of times the API stops detecting due to excessive concurrency per unit time; if the error rate is greater than a preset threshold or the error frequency is greater than 0, then the new concurrency level is dynamically adjusted to obtain the adjusted concurrency level; based on the adjusted concurrency level and the historical concurrency level of the API interface, generate the target concurrency level of the API interface.

2. The method according to claim 1, characterized in that, The process of determining the task level of each image file based on the image information and the image type includes: Obtain basic image information for each image file, and determine the image complexity based on the basic image information; wherein, the basic image information includes at least image gradient, image size, and text detection results; Histogram analysis is performed on the image file to obtain an image defect severity index, and the image defect severity of the image file is determined based on the image defect severity index; wherein, the image defect severity index includes at least the dark pixel ratio, the overexposed pixel ratio, and the Laplacian variance; Obtain similar files to the image file to obtain historical performance parameters of the similar files; wherein, the historical performance parameters of the similar files include at least historical time consumption and detection defect detection rate; The task level of each image file is determined by a weighted algorithm based on the image complexity, the severity of image defects, the historical performance parameters of similar files, and the image type.

3. The method according to claim 2, characterized in that, The process of determining the task level of each image file using a weighted algorithm, based on the image complexity, the severity of image defects, historical performance parameters of similar files, and the image type, includes: Based on the historical performance parameters of the similar files, the weights of the image complexity, the image defect severity, and the image type are dynamically adjusted respectively. The task level of the image file is obtained based on the image complexity, the image defect severity, the image type, and the corresponding weight.

4. The method according to claim 1, characterized in that, The method further includes: If the image testing system fails to perform an API interface call when performing an image test on the batch of image files to be tested, an analysis of the reasons for the API interface call failure will be generated. Based on the mapping relationship and the cause analysis, a retry strategy for image testing by the image testing system is generated; wherein, the mapping relationship is the correspondence between the cause analysis and the retry strategy.

5. A method for generating summary reports for image testing, characterized in that, Applications in image testing systems include: After performing image testing on a batch of image files to be tested according to the adaptive scheduling method for image testing as described in any one of claims 1-4, image test results for each image file are generated, and the image test results for each image file are subjected to single-group structured compression to extract key test information for each image file; wherein, the key test information includes at least the defect level determination of each dimension, core defect description, comprehensive score and optimization suggestions; Based on the feature dimension type of each image file, the key test information of all image files is clustered into problem patterns to obtain multiple groups; wherein, the feature dimension type includes scene type, defect type and severity level; Based on the clustering results of multiple groups, cross-group trend insight analysis is performed to generate trend insight information; wherein, the trend insight information includes problem coverage, scenario relevance, severity distribution and cross-scenario consistency; Using the trend insight information as input context, a large language model is invoked to generate image test reports for batch image files.

6. The method according to claim 5, characterized in that, The problem coverage rate is used to characterize the proportion of the target problem in all image files. Problems with a coverage rate greater than a preset threshold are marked as systematic problems or high-frequency problems. The scene correlation is used to characterize the correlation strength between the target problem and a specific scene, and is calculated by the conditional probability ratio. The severity distribution is used to characterize the statistical distribution of the target problem's severity level. Problems with a high severity level proportion greater than a preset threshold are marked as high severity problems. The cross-scenario consistency is used to characterize whether the target problem occurs in multiple scenario types. Problems that occur in all scenario types are marked as global problems.

7. An adaptive scheduling device for image testing, characterized in that, Applications in image testing systems include: The first processing module is used to receive a batch of image files to be tested, obtain the image information and image type of each image file in the batch of image files to be tested, and determine the task level of each image file based on the image information and the image type; wherein, the image information includes at least image complexity, image defect severity and historical performance parameters of similar files; The second processing module is used to obtain the task testing order of the batch of image files to be tested based on the task level of each image file; The third processing module is used to collect the operating status parameters of the image testing system and generate a task scheduling strategy for the image testing system based on the operating status parameters; wherein, the operating status parameters are used to characterize the callable resources of the image testing system; The fourth processing module is used to perform image testing on the batch of image files to be tested based on the task scheduling strategy and the task testing order. The third processing module is also used for: The system obtains the actual average response time, response time standard deviation, and error rate trend of the API interface in the image testing system; determines the deviation information of the API interface based on the target average response time and the actual average response time; obtains a new concurrency level for the API interface based on the deviation information, the response time standard deviation, and the error rate trend; wherein the new concurrency level characterizes the number of batch image files to be tested that the image testing system can send to the API interface; generates a target concurrency level for the API interface based on the new concurrency level and the historical concurrency level of the API interface; and determines the task scheduling strategy according to the target concurrency level; wherein the task scheduling strategy characterizes the number of batch image files to be tested that the API interface can receive each time. The first processing module is also used for: Obtain the error rate and error frequency of the API interface; the error rate is used to characterize the proportion of files that fail to be detected after the API interface receives multiple files, and the error frequency is the number of times the API stops detecting due to excessive concurrency per unit time; if the error rate is greater than a preset threshold or the error frequency is greater than 0, then the new concurrency level is dynamically adjusted to obtain the adjusted concurrency level; based on the adjusted concurrency level and the historical concurrency level of the API interface, generate the target concurrency level of the API interface.

8. A summary report generation device for image testing, characterized in that, Applications in image testing systems include: The fifth processing module, after executing the image test of the batch of image files to be tested according to the adaptive scheduling method for image testing as described in any one of claims 1-4, generates the image test result for each image file, performs single-group structured compression on the image test result of each image file, and extracts the key test information of each image file; wherein, the key test information includes at least the defect level judgment of each dimension, the core defect description, the comprehensive score and optimization suggestions; The sixth processing module is used to perform problem pattern clustering on the key test information of all image files based on the feature dimension type of each image file, and obtain multiple groups; wherein, the feature dimension type includes scene type, defect type and severity level; The seventh processing module is used to perform cross-group trend insight analysis based on the clustering results of multiple groups, and generate trend insight information; wherein, the trend insight information includes problem coverage, scenario relevance, severity distribution and cross-scenario consistency; The eighth processing module is used to call the large language model to generate image test reports for batch image files, using the trend insight information as input context.

Images