Software test report generation method and device, storage medium and computer equipment

Abstract

The invention discloses a software test report generation method and device, a storage medium and computer equipment, and the method comprises the steps: responding to a test report generation instruction of target software for a target scene, and obtaining test index data of different data sources through a unified multi-data source adaptation layer interface, the different data sources comprise a Prometheus time sequence data source, a Grafana visual data source and a YAML test case data source; obtaining a test report generation template corresponding to the target scene, and determining an index association rule and a rendering type in the test report generation template; performing association analysis on the test index data of the different data sources on the basis of an index association rule, determining test conclusion data of the target software on the basis of an association analysis result, and rendering the test index data in the Grafana visual data source on the basis of a rendering type to obtain a rendered picture; and embedding the test index data, the test conclusion data and the rendering picture into a test report generation template to obtain a test report corresponding to the target software.

Description

Methods, apparatus, storage media, and computer equipment for generating software test reports Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method, apparatus, storage medium, and computer equipment for generating software test reports. Background Technology

[0002] As a core deliverable of software testing activities, the test report is a crucial link in the software development process that directly connects test execution with quality assessment, risk decision-making, and process improvement.

[0003] Currently, in the field of software testing, the collection of metric data in test reports often suffers from a discretization problem. Testers need to collect single types of test data from different tools and populate the test report data. This cross-tool, single-source, and manual data collection method reduces the accuracy of test report metric data and the efficiency of test report generation. Summary of the Invention

[0004] This invention provides a method, apparatus, storage medium, and computer equipment for generating software test reports, which mainly improves the accuracy of test report indicator data and systematically solves the problem of low efficiency in integrating existing test data.

[0005] According to a first aspect of the present invention, a method for generating a software test report is provided, comprising: responding to a test report generation instruction from a target software for a target scenario; acquiring test indicator data from different data sources through a unified multi-data source adaptation layer interface, wherein the different data sources include a Prometheus time-series data source, a Grafana visualization data source, and a YAML test case data source; acquiring a test report generation template corresponding to the target scenario, and determining the indicator association rules and rendering type in the test report generation template; performing association analysis on the test indicator data from different data sources based on the indicator association rules; determining the test conclusion data of the target software based on the association analysis results; and rendering the test indicator data from the Grafana visualization data source based on the rendering type to obtain a rendered image; and embedding the test indicator data, the test conclusion data, and the rendered image into the test report generation template to obtain a test report corresponding to the target software.

[0006] Optionally, the test indicator data from different data sources includes performance test indicator data obtained from the Prometheus time-series data source, visual test indicator data graphs obtained from the Grafana visualization data source, and functional test indicator data obtained from the YAML test case data source. The indicator association rules include performance-functional indicator association rules between performance test indicator data and functional test indicator data, and performance-visual indicator association rules between performance test indicator data and visual test indicator data graphs. Based on the indicator association rules, the test indicator data from different data sources are analyzed for correlation. Based on the correlation analysis results, the test conclusion data of the target software is determined, including: based on the performance-functional indicator association rules, performing a correlation analysis on the performance test indicator data and the functional test indicator data to locate the problems of the target software, and determining the problem location data of the target software based on the problem location correlation analysis results; based on the performance-visual indicator association rules, performing an optimization suggestion analysis on the performance test indicator data and the visual test indicator data graphs to determine the optimization suggestion data of the target software based on the optimization suggestion analysis results, and using the problem location data and the optimization suggestion data as the test conclusion data.

[0007] Optionally, before obtaining the test report generation template corresponding to the target scenario, the method further includes: determining the test objectives and test scope of the target software in the target scenario; determining test indicator classification and indicator association rules based on the test objectives and test scope; determining the test report indicator context based on the test indicator classification and indicator association rules; and constructing the test report generation template based on the test report indicator context.

[0008] Optionally, a PromeQL statement can be constructed in the unified multi-data source adaptation layer interface, and the PromeQL statement can be used to call the Prometheus metric query API to obtain test metric data from the Prometheus time-series data source; test metric data from the Grafana visualization data source can be obtained through the image call API in the unified multi-data source adaptation layer interface; a Python fs library can be constructed in the unified multi-data source adaptation layer interface, and the Python fs library can be used to parse the test cases in the YAML test case data source, and the test metric data in the YAML test case data source can be determined based on the parsing results.

[0009] Optionally, the step of embedding the test indicator data, the test conclusion data, and the rendered image into the test report generation template to obtain a test report corresponding to the target software includes: determining key test indicator items for the target software based on the test indicator data, the test conclusion data, and the rendered image; determining the display priority of each title item in the test report generation template based on the key test indicator items; dynamically sorting each title item in the test report generation template based on the display priority; and embedding the test indicator data, the test conclusion data, and the rendered image into the dynamically sorted test report generation template to obtain a test report corresponding to the target software.

[0010] Optionally, after embedding the test indicator data, the test conclusion data, and the rendered image into the test report generation template to obtain the test report corresponding to the target software, the method further includes: determining a list of expected key fields for the expected test report corresponding to the target scenario, and determining the actual key fields contained in the test report; determining the data coverage of the test report based on the list of expected key fields and the actual key fields; extracting textual description information, chart information, and numerical information from the test report, and performing at least one logical rule detection on the test report based on the textual description information, the chart information, and the numerical information, including preset result constraint rules, preset data integrity rules, and preset anomaly labeling rules; determining the logical consistency of the test report based on the logical rule detection results; identifying the chart data in the test report, and determining the clarity and chart element completeness of the chart data; determining the chart quality of the test report based on the clarity and chart element completeness; and determining the report quality detection result of the test report based on the data coverage, the logical consistency, and the chart quality.

[0011] Optionally, determining the rendering type in the test report generation template includes: determining key indicator data from the test indicator data and determining the report type of the test report to be generated; determining the data feature vector corresponding to the key indicator data and determining the type feature vector corresponding to the report type; performing feature-level cross processing on the data feature vector and the type feature vector to obtain a feature cross vector; performing element-level cross processing on the data feature vector and the type feature vector to obtain an element cross vector; performing low-order cross processing on the data feature vector and the type feature vector to obtain a low-order cross vector; performing transformation processing on the feature cross vector, the element cross vector, and the low-order cross vector to obtain a rendering type cross vector; and inputting the rendering type cross vector into a preset rendering type prediction model to predict the rendering type and obtain the rendering type in the test report generation template.

[0012] According to a second aspect of the present invention, a software test report generation apparatus is provided, comprising: an acquisition unit, configured to, in response to a test report generation instruction from a target software for a target scenario, acquire test indicator data from different data sources through a unified multi-data source adaptation layer interface, wherein the different data sources include a Prometheus time-series data source, a Grafana visualization data source, and a YAML test case data source; a determination unit, configured to acquire a test report generation template corresponding to the target scenario, and determine the indicator association rules and rendering type in the test report generation template; an analysis unit, configured to, based on the indicator association rules, perform association analysis on the test indicator data from different data sources, determine the test conclusion data of the target software based on the association analysis results, and render the test indicator data from the Grafana visualization data source based on the rendering type to obtain a rendered image; and an embedding unit, configured to embed the test indicator data, the test conclusion data, and the rendered image into the test report generation template to obtain a test report corresponding to the target software.

[0013] According to a third aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described method for generating a software test report.

[0014] According to a fourth aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described method for generating a software test report.

[0015] According to the present invention, a method, apparatus, storage medium, and computer device for generating software test reports, compared with the current method of generating software test reports solely based on software log data, the present invention can seamlessly integrate test indicator data from different data sources (such as Prometheus time-series data sources, Grafana visualization data sources, and YAML test case data sources) through a unified multi-data source adaptation layer interface. This integration method improves the flexibility and accessibility of data, avoids data processing difficulties caused by different data sources, and makes the acquisition of test data more efficient and accurate. By acquiring test indicator data from different data sources to generate test reports, the comprehensiveness of the test report information can be guaranteed. By generating test reports through pattern report generation templates, the standardization and automation of test report generation are achieved. By performing correlation analysis on test indicator data from different data sources, the inherent relationships between data can be deeply explored, thereby drawing more comprehensive and accurate test conclusions, and thus improving the accuracy and comprehensiveness of the generated test reports. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with the description thereof, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings: Figure 1 shows a flowchart of a method for generating a software test report according to an embodiment of the present invention; Figure 2 shows a flowchart of another method for generating a software test report according to an embodiment of the present invention; Figure 3 shows a schematic structural diagram of a device for generating a software test report according to an embodiment of the present invention; Figure 4 shows a schematic structural diagram of another device for generating a software test report according to an embodiment of the present invention; Figure 5 shows a schematic structural diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0017] The present invention will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the present application can be combined with each other.

[0018] Currently, the collection of test indicator data through a single data source is based on a relatively limited set of data, resulting in incomplete information in the generated test reports. Furthermore, the limited data leads to inaccurate analysis of the test results, resulting in low accuracy in the generated test reports.

[0019] To address the aforementioned issues, this invention provides a method for generating software test reports, as shown in Figure 1. The method includes: 101. Responding to a test report generation instruction from the target software for a target scenario, obtaining test indicator data from different data sources through a unified multi-data source adaptation layer interface, wherein the different data sources include Prometheus time-series data source, Grafana visualization data source, and YAML test case data source.

[0020] The target software can be any software; the target scenarios include user login, product search, shopping cart checkout, order payment, and refund processes in e-commerce systems; account opening, money transfer, wealth management purchase, and risk assessment in financial systems; and user registration, friend addition, message sending, dynamic posting, and comment interaction in social platforms. Test metrics include, but are not limited to, response time, error rate, CPU utilization, throughput, test case steps, test case execution results, expected test results, and interface response time trend charts. For example, if testing the "order payment" function of an e-commerce system, the test metrics would include the average response time of the payment interface, P99 response time, error rate, payment test case pass rate, failure reason statistics, response time trend chart, and error rate heatmap. Prometheus is an open-source monitoring and alerting system designed for cloud-native environments. Its core function is to collect monitoring data from the target service through a pull mode and store it in time-series format. Data is tagged in multiple dimensions for easy and flexible querying; Grafana is an open-source monitoring data visualization and analysis platform that supports the transformation of time-series data from various data sources (such as Prometheus) into intuitive charts, dashboards, and alarm rules; YAML (YAML Ain't Markup Language) is a readable data serialization format that is often used to write configuration files or test cases.

[0021] In this embodiment of the invention, upon receiving a test report generation instruction, the system interacts with different data sources (Prometheus time-series data source, Grafana visualization data source, and YAML test case data source) through a unified multi-data source adaptation layer interface, obtaining test metric data through a unified interface specification. Specifically, performance metric data such as average interface response time and 5xx error count can be obtained from the Prometheus time-series data source. For example, requirement metric data can be queried from the time-series database of the Prometheus time-series data source, and aggregate functions can be used to calculate the metric values ​​to obtain performance metric data. Performance metric data such as response time trend charts and 5xx error rate heatmaps can be obtained from the Grafana visualization data source. Performance metric data such as expected response time, actual response time, and test case pass rate obtained from executing test cases can be obtained from the YAML test case data source. This embodiment of the invention, by constructing a unified multi-data source adaptation layer interface, achieves standardized data acquisition and processing across data sources, solving the technical challenge of integrating multi-source heterogeneous data.

[0022] 102. Obtain the test report generation template corresponding to the target scenario, and determine the indicator association rules and rendering type in the test report generation template.

[0023] The test metric data from different data sources includes performance test metric data (such as response time, error rate, etc.) obtained from the Prometheus time-series data source, visualization test metric data charts (response time trend chart, heatmap, etc.) obtained from the Grafana visualization data source, and functional test metric data (test case pass rate, test case execution results, etc.) obtained from the YAML test case data source. The metric association rules include performance-functionality metric association rules between performance test metric data and functional test metric data, and performance-visualization metric association rules between performance test metric data and visualization test metric data charts. Rendering type refers to the rendering method and style of the chart.

[0024] In this embodiment of the invention, different software corresponds to different test report generation templates under different target scenarios. The test report generation template contains information such as the morning / afternoon information of the metrics, metric association rules, and rendering type. Based on the metric association rules, test metric data obtained from different data sources are analyzed to obtain test result data. Based on the rendering type, charts obtained from the Grafana visualization data source are rendered to obtain rendered icons. Finally, the performance metric data, test result data, and rendered charts are inserted into the test report generation template according to the morning / afternoon information of the metrics to obtain the test report. This embodiment of the invention generates test reports by obtaining test metric data from different data sources, ensuring the comprehensiveness of the test report information; and by using a pattern report generation template, it achieves standardized and automated generation of test reports.

[0025] 103. Based on the indicator association rules, perform association analysis on the test indicator data from different data sources. Based on the association analysis results, determine the test conclusion data of the target software. Based on the rendering type, render the test indicator data in the Grafana visualization data source to obtain the rendered image.

[0026] In this embodiment of the invention, to increase the comprehensiveness of the test report, in addition to reflecting the test indicator data in the test report, it is also necessary to perform correlation analysis on the test indicator data from different data sources. Based on this, step 103 specifically includes: based on the performance-functional indicator correlation rules, performing correlation analysis on the performance test indicator data and the functional test indicator data to locate the problem of the target software, and determining the problem location data of the target software based on the correlation analysis results of the problem location; based on the performance-visualization indicator correlation rules, performing optimization suggestion analysis on the performance test indicator data and the visual test indicator data graph to analyze the optimization suggestions of the target software, and determining the optimization suggestion data of the target software based on the optimization suggestion analysis results; and using the problem location data and the optimization suggestion data as the test conclusion data.

[0027] Specifically, for example, if testing the "order payment" function of an e-commerce system and generating a comprehensive test report containing performance, functionality, and visualization data, then performance test metrics such as payment interface response time, P99 response time, and error rate are obtained from the Prometheus time-series data source; visualization test metrics such as trend charts showing payment interface response time are obtained from the Grafana visualization data source; and functional test metrics such as expected response time, actual response time, payment test case pass rate, and failure reason statistics are obtained from the YAML test case data source. After obtaining test metric data from different data sources, further, the performance-functionality metric correlation rule refers to associating the Prometheus "average response time of the payment interface" with the YAML test case's "expected response time < 500ms" to determine whether it meets the standard; and if the YAML test case is marked as "failed," then it is associated with the Prometheus "error rate" data to locate whether it is a systemic problem; the performance-visualization metric correlation rule refers to overlaying the Grafana "response time trend chart" with the Prometheus "P99 response time" to analyze whether the peak values ​​are abnormal. For example, in a correlation analysis based on performance-functionality metric association rules, Prometheus data shows an average response time of 480ms (meets the standard), but a P99 response time of 650ms (timeout). YAML use case data shows an actual response time of 650ms, marked as "failed." The correlation analysis result for problem localization is: "P99 response time exceeding the standard causes use case failure." Therefore, "P99 response time exceeding the standard causes use case failure" is the problem localization data for the target software. Another example: YAML use cases are marked as "failed" (timeout). Prometheus data shows: 5xx errors occurred twice in the same period, with an error rate of 1.2%. The correlation analysis result for problem localization is: "Use case failure may be related to a systemic increase in error rate (20:00 error rate peak)." Therefore, "Use case failure may be related to a systemic increase in error rate (20:00 error rate peak)" is the problem localization data for the target software. When establishing root systems for metrics based on performance-visualization metric association rules, the Grafana trend chart shows a peak response time of 650ms between 20:00 and 21:00; Prometheus data confirms a P99 response time of 650ms during the same period; the optimization suggestion analysis results are as follows: overlay the trend chart and P99 values ​​in the report, and mark "Peak value is consistent with P99, interface performance needs to be optimized", then "optimize interface performance" is the optimization suggestion data.

[0028] Furthermore, based on rendering styles and other rendering types, the test metric data in the Grafana visualization data source is rendered to obtain rendered images. This embodiment of the invention, by performing correlation analysis on test metric data from different data sources, can deeply explore the inherent relationships between data, thereby deriving more comprehensive and accurate test conclusions, and ultimately improving the accuracy and comprehensiveness of the generated test reports.

[0029] 104. Embed the test indicator data, test conclusion data, and rendered images into the test report generation template to obtain the test report corresponding to the target software.

[0030] In this embodiment of the invention, the test report generation template includes title items such as test indicator classification items, test conclusion items, and chart items. By inserting the test indicator data, test conclusion data, and rendered images into the corresponding title item positions in the corresponding test report generation template, a test report of the target software can be obtained.

[0031] According to the software test report generation method provided by this invention, compared with the current method of generating software test reports solely based on software log data, this invention seamlessly integrates test indicator data from different data sources (such as Prometheus time-series data sources, Grafana visualization data sources, and YAML test case data sources) through a unified multi-data source adaptation layer interface. This integration method improves data flexibility and accessibility, avoids data processing difficulties caused by different data sources, and makes test data acquisition more efficient and accurate. Generating test reports by acquiring test indicator data from different data sources ensures the comprehensiveness of the test report information. Generating test reports using pattern report generation templates achieves standardized and automated test report generation. By performing correlation analysis on test indicator data from different data sources, the inherent relationships between data can be deeply explored, thereby drawing more comprehensive and accurate test conclusions, and further improving the accuracy and comprehensiveness of the generated test reports.

[0032] Furthermore, to better illustrate the above process of generating a software test report, as a refinement and extension of the above embodiments, this embodiment of the invention provides another method for generating a software test report, as shown in Figure 2. The method includes: 201. In response to the test report generation instruction of the target software for the target scenario, obtaining test indicator data from different data sources through a unified multi-data source adaptation layer interface, wherein the different data sources include Prometheus time-series data source, Grafana visualization data source, and YAML test case data source.

[0033] In this embodiment of the invention, to ensure the comprehensiveness of the test report information, it is necessary to obtain the test indicator data of the target software from different data sources. Therefore, step 201 specifically includes: constructing a PromeQL statement in the unified multi-data source adaptation layer interface, and using the PromeQL statement to call the Prometheus indicator query API to obtain the test indicator data from the Prometheus time-series data source through the indicator query API; obtaining the test indicator data from the Grafana visualization data source through the image call API in the unified multi-data source adaptation layer interface; constructing a Python fs library in the unified multi-data source adaptation layer interface, and using the Python fs library to parse the test cases in the YAML test case data source, and determining the test indicator data in the YAML test case data source based on the parsing results.

[0034] Specifically, the unified multi-data source adaptation layer interface involved in this embodiment of the invention serves as an intermediate layer, providing upper-layer applications with a unified interface to access various types of data sources. This interface encapsulates the details of interaction with each data source, allowing upper-layer applications to obtain the required data simply by using a unified interface call method, without needing to concern themselves with the specific differences between data sources. In this embodiment of the invention, three main data sources are involved: Prometheus time-series data source, Grafana visualization data source, and YAML test case data source. In the unified multi-data source adaptation layer interface, corresponding PromeQL statements are constructed according to the needs of the upper-layer application. PromeQL is the query language of Prometheus, used to query specific test metric data from the Prometheus time-series data source. After constructing the PromeQL statement, the HTTP request function encapsulated in the unified multi-data source adaptation layer interface is used to call the metric query API provided by Prometheus. The address of this API is usually the access address of the Prometheus server plus / api / v1 / query (for real-time queries) or / api / v1 / query_range (for range queries). After receiving the query request, the Prometheus server parses the PromeQL statement, retrieves the corresponding data from the time-series data source, and returns the result in JSON format. After receiving the returned JSON data, the unified multi-data source adaptation layer interface parses it, extracts the required test metric data, such as metric values, timestamps, etc., and encapsulates it into a unified data structure for use by the upper-layer application.

[0035] Meanwhile, in the unified multi-data source adaptation layer interface, the parameters required to call the Grafana image API are determined based on the needs of the upper-layer application. These parameters typically include the Grafana panel ID, time range, and theme. For example, to obtain the visualization images of a specific panel within the last hour, the panel's unique identifier ID needs to be determined, and the time range needs to be set to one hour prior to the current time. Then, using the HTTP request function encapsulated in the unified multi-data source adaptation layer interface, an image request is sent to the Grafana server. The Grafana image API address is typically the Grafana server's access address plus ` / render / d-solo / ` and parameters such as the panel ID. After receiving the image request, the Grafana server generates the corresponding visualization image based on the request parameters and returns it as binary data. Upon receiving the returned binary data, the unified multi-data source adaptation layer interface can save it as an image file or other test metric data, or directly return it as data to the upper-layer application.

[0036] Meanwhile, within the unified multi-data source adaptation layer interface, a Python `fs` library environment is built. The `fs` library is an abstraction layer for file system operations, providing a unified interface to access different types of file systems, including local and remote file systems. The `fs` library is used to open the storage location of the YAML test case file and read its contents. Then, Python's `yaml` library is used to parse the read YAML file content. After parsing the YAML file, the required test metrics data are extracted from the parsing results based on the YAML file's structure and the needs of the upper-layer application.

[0037] 202. Determine the test objectives and test scope of the target software in the target scenario, and based on the test objectives and test scope, determine the test index classification and index association rules.

[0038] 203. Based on the test indicator classification and indicator association rules, determine the test report indicator context, and construct a test report generation template based on the test report indicator context.

[0039] The testing objectives include performance, compatibility, and security goals. For example, for an e-commerce payment system, the performance objectives are: support for 10,000 concurrent users, a payment success rate of ≥99.9%, and an average response time of ≤1.5 seconds. The compatibility objectives are: the e-commerce payment system must function normally on the top 5 iOS 15-17 and Android 10-13 devices without UI glitches. The security objectives are: the user login interface must resist brute-force attacks, and an account lockout mechanism must be triggered after 5 incorrect password attempts. The testing scope includes functional scope, data scope, and environmental scope. For example, the testing scope of an e-commerce system includes the entire process of product search, shopping cart, payment, and logistics tracking. The data scope includes testing the differentiated processing logic for small transfers (1-1,000 yuan) and large transfers (over 10,000 yuan) in an e-commerce payment system. The environmental scope includes weak network testing covering 3G / 4G / 5G, Wi-Fi, elevators, and other network conditions with signal strength ranging from -110dBm to -50dBm.

[0040] Specifically, test metrics are categorized based on the test objectives and scope. Common categorization methods include functional metrics, performance metrics, compatibility metrics, interface metrics, and security metrics. For example, for an online shopping platform, specific test metric categories include: Functional metrics: User registration / login success rate (the ratio of successful registration / login to the total number of users attempting to register / login); Product search accuracy (the ratio of the number of search results matching user needs to the total number of search results); Order payment success rate (the ratio of successful payment to the total number of users attempting to pay); Promotional activity participation rate (the ratio of users participating in promotional activities to the total number of target users); Performance metrics: Average response time (the average processing time for user requests); Maximum concurrent users (the maximum number of users the system can handle simultaneously); Throughput (the number of requests the system processes per unit of time); Resource utilization (the efficiency of resource utilization during system operation). The metrics include: CPU, memory, and disk resource usage; compatibility metrics: browser compatibility (platform display and functional completeness on different browsers), operating system compatibility (platform stability on different operating systems), and device compatibility (platform adaptability and ease of use on different devices); interface metrics: interface response time (average processing time for third-party interface requests to the platform), interface success rate (ratio of successful interface calls to total calls), and data transmission accuracy (consistency between transmitted data and expected data); security metrics: user information leakage incidents (number of times user information was leaked during testing), and malicious attack interception rate (ratio of successfully intercepted malicious attacks to total attacks). Furthermore, based on the testing objectives and scope, correlation rules for the metrics are determined. For example, for an online shopping platform: the order payment success rate in the functional metrics is correlated with the average response time and maximum concurrent users in the performance metrics. When the average response time is too long or the maximum concurrent users reach a certain threshold, the order payment success rate may decrease. Promotional activity participation rate is related to the accuracy of promotional activity display and the success rate of coupon redemption and usage in functional metrics. Inaccurate promotional activity display or problems with coupon redemption and usage will affect user participation, thus reducing the promotional activity participation rate. Interface response time and success rate in API metrics will affect the implementation of related functions in functional metrics. For example, if the response time of a third-party payment interface is too long or the success rate is low, it will cause problems with the order payment function, affecting the order payment success rate.

[0041] Furthermore, based on the test metric classification and metric association rules, the test report metric context is determined. The test report metric context refers to the presentation environment and related background information of the test metric in the test report. It includes the test metric classification, metric association rules, the definition of the test metric, the calculation method, the test environment, and the test data source. For example, for the metric of order payment success rate, its metric context can be described as follows: Metric Definition: The ratio of the number of users who successfully completed payment to the total number of users who attempted payment. Calculation Method: Order Payment Success Rate = Number of Successfully Paid Orders / Number of Attempted Payment Orders × 100%. Test Environment: The test environment includes server configuration (such as CPU model, memory size, hard disk capacity, etc.), network environment (such as bandwidth, latency, etc.), and software environment (such as operating system version, database version, etc.). Test Data Source: Test data comes from order data generated by simulated users, including different types of orders such as normal orders and abnormal orders. Finally, based on the test report metric context, a test report generation template is constructed. The test report generation template should include the report title, report summary, test objectives, test scope, test environment, list of test metrics, test result analysis, conclusions and recommendations, and metric association rules.

[0042] 204. Obtain the test report generation template corresponding to the target scenario, and determine the indicator association rules and rendering type in the test report generation template.

[0043] In this embodiment of the invention, after obtaining the test report generation template corresponding to the target scene, since the test report generation template contains indicator association rules, the indicator association rules can be directly obtained from the test report generation template. Simultaneously, it is also necessary to determine the rendering type corresponding to the test report generation template. Based on this, step 204 specifically includes: determining key indicator data from the test indicator data and determining the report type to be generated; determining the data feature vector corresponding to the key indicator data and determining the type feature vector corresponding to the report type; performing feature-level cross processing on the data feature vector and the type feature vector to obtain a feature cross vector; performing element-level cross processing on the data feature vector and the type feature vector to obtain an element cross vector; performing low-order cross processing on the data feature vector and the type feature vector to obtain a low-order cross vector; performing transformation processing on the feature cross vector, the element cross vector, and the low-order cross vector to obtain a rendering type cross vector; and inputting the rendering type cross vector into a preset rendering type prediction model for rendering type prediction to obtain the rendering type in the test report generation template.

[0044] Key performance indicators (KPIs) refer to core data metrics used to quantitatively evaluate the core capabilities of software under high concurrency scenarios. They directly reflect the software's stability, response speed, and reliability under extreme loads, serving as a crucial basis for determining whether the software meets business requirements. For example, during stress testing of a financial trading system, KPIs include: transactions per second, system latency, and error rate. Report types include comprehensive test reports, specialized test reports, and comparative test reports. A comprehensive test report is a summary report after comprehensive testing of the target software under target scenarios. It covers test results in various aspects such as functionality, performance, compatibility, and security. Specialized test reports, focusing on software performance, can generate performance-specific test reports. These reports analyze in detail the software's response time, throughput, resource utilization, and other performance metrics under different concurrent user counts. Comparative test reports can be generated by testing and comparing different versions or configurations of the target software. These reports clearly list the differences in key performance indicators across different software versions or configurations, evaluating the advantages and disadvantages of different versions or configurations through data comparison and analysis.

[0045] Specifically, the data feature vectors corresponding to the key indicator data are determined by word embedding and feature extraction models (such as CNN), and the type feature vectors corresponding to the report type are determined. Then, the feature vectors are cross-processed. For example, if the data feature vector is (a1, a2) and the type feature vector is (b1, b2). The specific cross-processing method includes: combining different feature vectors by feature dimension, i.e., performing a Hadamard product on all elements of the vectors, followed by a convolution transformation with a certain weight w1, to obtain the feature cross vector f(w1×(a1×b1,a2×b2)); simultaneously, combining all feature vector data at the point level, i.e., performing a Hadamard product on each element (component) of the vectors, assigning different weight values ​​to each product result, and then performing a linear transformation, to obtain the element cross vector f(w2×a1×b1,w3×a2×b2); furthermore, performing low-order cross processing on all feature vectors, assigning weight coefficients to the cross processing result, and then performing a linear transformation, to obtain the low-order cross vector f(w4(a1,a2,b1,b2)); finally, combining the above feature cross vectors, element cross vectors, and low-order cross vectors using a preset transformation function, such as horizontal concatenation, to obtain the rendering type cross vector. It should be noted that the above examples are only illustrative and do not limit the embodiments of this application. Therefore, by cross-processing data feature vectors and type feature vectors, different features can be automatically or explicitly combined to generate new feature combinations. These combined features may contain complex nonlinear relationships between the original features, enabling the model to capture more refined and richer information in the data. In other words, it can make full use of the relationships between various data, extract more latent features, and take into account both high-order and low-order processing, making the data utilization more efficient and the subsequent predictions and evaluations more accurate, thus meeting the needs of practical application scenarios.

[0046] Furthermore, in order to improve the prediction accuracy of the preset rendering type prediction model, it is also necessary to train and construct the preset rendering type prediction model. Based on this, the method includes: constructing a preset initial rendering type prediction model; obtaining a sample dataset, wherein the sample dataset includes test index data of sample software with rendering type labels and the report type of the test report corresponding to the sample software; dividing the sample dataset into a training set and a test set, using the training set to train the preset initial rendering type prediction model, and using the test set to test the tested preset initial rendering type prediction model, and finally using the trained preset initial rendering type prediction model that meets the test conditions as the preset rendering type prediction model.

[0047] Specifically, during model training, a pre-defined initial rendering type prediction model is first constructed, followed by the acquisition of a sample dataset. The dataset is ensured to contain all necessary files. The data is then converted to a format understandable by the pre-defined initial rendering type prediction model. Finally, the model is trained and tested. Specifically, the dataset can be divided first: using random or specific strategies (such as stratified sampling), the sample dataset is divided into training and test sets. The training set is then used to train the model, and the test set is used to test the trained model, evaluating its performance on unseen data. Precision, recall, and other metrics on the test set are calculated and recorded. If the model performance does not meet requirements, it can return to the training phase for further iterations or adjustments. This process yields a pre-defined rendering type prediction model that meets the requirements. Finally, the rendering type cross vector is directly input into the pre-defined rendering type prediction model, which then directly outputs the rendering type corresponding to the chart in the test report.

[0048] 205. Based on the indicator association rules, perform association analysis on the test indicator data from different data sources. Based on the association analysis results, determine the test conclusion data of the target software. Based on the rendering type, render the test indicator data in the Grafana visualization data source to obtain the rendered image.

[0049] Specifically, based on the business logic and testing objectives of the target software, association rules are defined between different test indicator data. For example, in payment interface testing, the following association rules can be defined: the payment amount of a successfully paid order should be equal to the order amount; the payment time of a payment request should have a certain temporal order relationship with the order creation time, i.e., the payment request time should be after the order creation time; system performance indicators (such as CPU utilization and memory usage) should be correlated with the processing time of payment requests, and when system performance indicators exceed a certain threshold, the processing time of payment requests may be prolonged. Then, appropriate association analysis algorithms are used to perform association analysis on test indicator data from different data sources. For example, rule-based inference algorithms can be used to match and analyze test indicator data item by item according to the defined indicator association rules. In practice, test indicator data can be read, and then judgments and inferences can be performed according to the association rules. For example, for the association rule of whether the payment amount of a successfully paid order is equal to the order amount, the payment amount and order amount can be obtained from the payment request information table and the order information table respectively, and then compared and judged. Based on the association analysis results, it is determined whether each test indicator meets the preset requirements. For example, regarding the association rule for verifying whether the payment amount of a successfully paid order is equal to the order amount, if a discrepancy is found, it indicates that the test metric fails to meet the requirements. The test conclusion data for the target software is determined by combining the results of various test metrics. For instance, if all key test metrics meet the requirements, the test conclusion data can be determined as "Test passed"; if some key test metrics fail, the test conclusion data can be determined as "Test failed, specifying the non-compliant test metrics."

[0050] Furthermore, based on the characteristics and display requirements of the test metric data, corresponding visualization panels are created in Grafana. For example, for numerical data such as payment amount and order amount in payment interface testing, line charts or bar charts can be created to show their changing trends; for categorical data such as payment status, pie charts can be created to show the proportion of different payment statuses. The charts are then rendered according to the rendering type; for example, different colors, fonts, and line styles can be selected to beautify the charts, making them more intuitive and easier to understand.

[0051] 206. Embed the test indicator data, test conclusion data, and rendered images into the test report generation template to obtain the test report corresponding to the target software.

[0052] In this embodiment of the invention, after determining the test indicator data, test conclusion data, and rendered image, the above information needs to be filled into the test report generation template. Based on this, step 206 specifically includes: determining the key test indicator items of the target software based on the test indicator data, the test conclusion data, and the rendered image; determining the display priority of each title item in the test report generation template based on the key test indicator items; dynamically sorting each title item in the test report generation template based on the display priority; and embedding the test indicator data, the test conclusion data, and the rendered image into the dynamically sorted test report generation template to obtain the test report corresponding to the target software.

[0053] Among them, key test indicators refer to those test indicators that have a significant impact on the quality, performance, functionality, and stability of the target software, and can directly reflect whether the software meets user needs, business objectives, and expected standards.

[0054] Specifically, key test metrics are identified from the test metric data, test conclusion data, and rendered images. For example, if a rendered image is a key test metric, its corresponding title should have a higher display priority and be placed near the beginning of the test report generation template. Similarly, if test metric data is a key test metric, its corresponding title should have a higher display priority and be placed near the beginning of the test report generation template. Furthermore, taking test metric data as an example, key test metric data is identified within the test metric data. If this key test metric data has a higher display priority, it should be placed near the beginning of the test report generation template. Following this method, the test metric data, test conclusion data, rendered images, and their sub-data within the test metric data, test conclusion data, and rendered images can be sorted within the test report generation template. Finally, the test metric data, test conclusion data, and rendered images are embedded into the test report generation template according to their sorted positions to obtain the test report for the target software. By dynamically sorting the data, headings closely related to key test metrics are placed in prominent positions, such as at the beginning of the report or in important sections, allowing readers to quickly focus on the most critical information in software testing.

[0055] Furthermore, to ensure the quality of the generated test report, quality inspection of the test report is also required. Based on this, the method includes: determining a list of expected key fields for the expected test report corresponding to the target scenario, and determining the actual key fields contained in the test report; determining the data coverage of the test report based on the expected key field list and the actual key fields; extracting textual description information, chart information, and numerical information from the test report, and performing at least one logical rule inspection on the test report based on the textual description information, the chart information, and the numerical information, including preset result constraint rules, preset data integrity rules, and preset anomaly labeling rules; determining the logical consistency of the test report based on the logical rule inspection results; identifying chart data in the test report, and determining the clarity and chart element completeness of the chart data; determining the chart quality of the test report based on the clarity and chart element completeness; and determining the report quality inspection result of the test report based on the data coverage, the logical consistency, and the chart quality.

[0056] Specifically, firstly, for different target scenarios, analyze the key information that the test report needs to cover in that scenario. For example, if the target scenario is functional testing of a mobile application, the expected test report needs to reflect the testing status of each function of the software. The expected list of key fields might include "functional module name," "test case number," "test steps," "expected results," "actual results," and "test conclusions." These fields comprehensively describe the testing process and results of each functional module, providing necessary information for evaluating the quality of the software's functions. As another example, if the target scenario is performance testing of an online game, the expected list of key fields might include "test scenario (e.g., login scenario, combat scenario)," "response time," "frame rate," "server load," and "network latency." These fields help evaluate the game's performance in different scenarios, ensuring smooth gameplay. Extract the actual key fields from the generated test report. This can be done using text parsing techniques, such as regular expression matching and named entity recognition in natural language processing, to identify the field names in the report. For example, for the aforementioned mobile application functional test report, by parsing the report text, extract the actual fields included, such as "functional module," "test case number," "test step description," "expected output," "actual output," and "pass / fail." The actual key fields are compared with the expected key field list to calculate data coverage. For example, in a mobile application functional testing scenario, if the expected key field list contains 6 fields, and the actual report shows 5 fields matching the list, then the data coverage is 100%. The higher the data coverage, the more comprehensive the information contained in the test report, and the better it meets the needs of the target scenario.

[0057] Further, the text description information is extracted using text extraction algorithms, such as keyword matching or text segmentation, to extract the text descriptions from the test report. For example, this includes extracting descriptions of test cases and explanations of test conclusions. Chart information extraction utilizes image recognition technology, such as Optical Character Recognition (OCR), to identify the text information in the charts. It also analyzes the chart type (e.g., bar chart, line chart, pie chart), axis labels, legends, and other elements to extract the data and trend information expressed by the charts. Numerical information extraction uses regular expression matching to extract specific numerical data from the text descriptions and charts, such as response time and performance metrics in the test results. Preset result constraint rule detection is performed based on the test objectives and requirements. For example, in performance testing, the response time may not exceed a certain threshold. The extracted numerical information is compared with the preset constraint rules to check if the requirements are met. If the response time of a function exceeds the preset threshold, it is marked as not meeting the result constraint rules. Preset data integrity rule detection checks the completeness of the extracted information. For example, for each test case, do it include both the expected and actual results? For charts, do they include the necessary axis labels and legends? If missing information is found, it is marked as not conforming to data integrity rules. Pre-defined anomaly labeling rules are used to identify potential anomalies in the test report. For example, when numerical information shows abnormal fluctuations (such as a sudden and significant drop in performance metrics) or when contradictory information appears in the text description (such as inconsistent expected results described in different parts of the same test case), it is marked as an anomaly. Finally, based on the logical rule detection results, the number of pieces of information that conform to and do not conform to the rules is counted. The ratio of the number of pieces of information that conform to the rules to the total number of pieces of information is used as logical consistency. The higher the logical consistency, the more accurate and reliable the information in the test report is, and the fewer obvious logical errors there are.

[0058] Furthermore, image recognition technology is used to identify the charts in the test report, determining their type, the data series they contain, and the location of the data points. For example, for bar charts, the category and corresponding value of each bar are identified; for line charts, the trend of the line and the coordinates of each data point are identified. Clarity assessment: Image analysis algorithms are used to evaluate the clarity of the charts, such as the chart resolution, the sharpness of text and graphics, and color contrast. For example, image sharpness detection algorithms are used to determine whether the edges of the charts are clear and whether the text is easily legible. Chart element completeness assessment: The chart is checked to see if it contains necessary elements, such as a title, axis labels, legend, and data labels. For example, a complete bar chart should include a title explaining the chart's theme, X and Y axis labels indicating the data category and value range, and a legend explaining the meaning of different colored bars. The chart quality is scored by comprehensively considering both the clarity of the chart data and the completeness of the chart elements. Different scoring criteria can be set; for example, clarity and element completeness can each account for 50% of the weight, and a score of 0-10 can be given based on the evaluation results. For example, a chart might score 8 for clarity and 7 for element completeness, resulting in a weighted sum of 7.5. Higher chart quality indicates a more accurate and clearer communication of information.

[0059] Finally, based on the data coverage, logical consistency, and chart quality calculated above, the quality of the test report is comprehensively evaluated. Different weights can be set, for example, data coverage 40%, logical consistency 40%, and chart quality 20%. Then, based on these weights, a weighted sum is calculated to determine the overall quality of the test report. If the report quality meets the requirements, it is stored and used; if it does not meet the requirements, the test report for the target software needs to be regenerated.

[0060] According to another method for generating software test reports provided by this invention, compared with the current method of generating software test reports solely based on software log data, this invention can seamlessly integrate test indicator data from different data sources (such as Prometheus time-series data sources, Grafana visualization data sources, and YAML test case data sources) through a unified multi-data source adaptation layer interface. This integration method improves the flexibility and accessibility of data, avoids data processing difficulties caused by different data sources, and makes the acquisition of test data more efficient and accurate. Generating test reports by acquiring test indicator data from different data sources ensures the comprehensiveness of the test report information. Generating test reports through pattern report generation templates achieves the standardization and automation of test report generation. By performing correlation analysis on test indicator data from different data sources, the intrinsic relationships between data can be deeply explored, thereby drawing more comprehensive and accurate test conclusions, and thus improving the accuracy and comprehensiveness of the generated test reports.

[0061] Furthermore, as a specific implementation of FIG1, this embodiment of the invention provides a software test report generation device, as shown in FIG3, the device including: an acquisition unit 31, a determination unit 32, an analysis unit 33, and an embedding unit 34.

[0062] The acquisition unit 31 can be used to respond to the test report generation instruction of the target software for the target scenario, and acquire test indicator data from different data sources through a unified multi-data source adaptation layer interface. The different data sources include Prometheus time series data source, Grafana visualization data source, and YAML test case data source.

[0063] The determining unit 32 can be used to obtain the test report generation template corresponding to the target scene, and determine the indicator association rules and rendering type in the test report generation template.

[0064] The analysis unit 33 can be used to perform correlation analysis on test indicator data from different data sources based on the indicator correlation rules, determine the test conclusion data of the target software based on the correlation analysis results, and render the test indicator data in the Grafana visualization data source based on the rendering type to obtain a rendered image.

[0065] The embedding unit 34 can be used to embed the test indicator data, the test conclusion data, and the rendered image into the test report generation template to obtain the test report corresponding to the target software.

[0066] In specific application scenarios, test indicator data from different data sources include performance test indicator data obtained from the Prometheus time-series data source, visualization test indicator data graphs obtained from the Grafana visualization data source, and functional test indicator data obtained from the YAML test case data source. The indicator association rules include performance-functional indicator association rules between performance test indicator data and functional test indicator data, and performance-visual indicator association rules between performance test indicator data and visualization test indicator data graphs. To determine the test conclusion data of the target software, the analysis unit 33 can specifically be used to perform a correlation analysis on the performance test indicator data and the functional test indicator data for problem localization of the target software based on the performance-functional indicator association rules, and determine the problem localization data of the target software based on the problem localization correlation analysis results; perform optimization suggestion analysis on the performance test indicator data and the visualization test indicator data graphs for optimization of the target software based on the performance-visual indicator association rules, and determine the optimization suggestion data of the target software based on the optimization suggestion analysis results, and use the problem localization data and the optimization suggestion data as the test conclusion data.

[0067] In specific application scenarios, in order to build a test report generation template, as shown in Figure 4, the device also includes a construction unit 35.

[0068] The construction unit 35 can be used to determine the test objectives and test scope of the target software in the target scenario, and based on the test objectives and test scope, determine the test indicator classification and indicator association rules; based on the test indicator classification and indicator association rules, determine the test report indicator context, and based on the test report indicator context, construct the test report generation template.

[0069] In specific application scenarios, in order to obtain test indicator data from different data sources, the acquisition unit 31 includes an acquisition module 311 and a parsing module 312.

[0070] The acquisition module 311 can be used to construct a PromeQL statement in the unified multi-data source adaptation layer interface, and use the PromeQL statement to call the Prometheus metric query API to obtain test metric data in the Prometheus time series data source through the metric query API.

[0071] The acquisition module 311 can also be used to obtain test metric data from the Grafana visualization data source through the image call API in the unified multi-data source adaptation layer interface.

[0072] The parsing module 312 can be used to build a Python fs library in the unified multi-data source adaptation layer interface, and use the Python fs library to parse the test cases in the YAML test case data source, and determine the test metric data in the YAML test case data source based on the parsing results.

[0073] In specific application scenarios, in order to generate test reports, the embedding unit 34 includes a first determining module 341 and an embedding module 342.

[0074] The first determining module 341 can be used to determine the key test indicators of the target software based on the test indicator data, the test conclusion data, and the rendered image.

[0075] The embedding module 342 can be used to determine the display priority of each title item in the test report generation template based on the key test indicators, and dynamically sort the title items in the test report generation template based on the display priority, and embed the test indicator data, the test conclusion data, and the rendered image into the dynamically sorted test report generation template to obtain the test report corresponding to the target software.

[0076] In specific application scenarios, in order to perform quality inspection on test reports, the device also includes a detection unit 36.

[0077] The detection unit 36 ​​can be used to determine a list of expected key fields for an expected test report corresponding to the target scenario, and to determine the actual key fields contained in the test report. Based on the list of expected key fields and the actual key fields, it determines the data coverage of the test report. It extracts textual description information, chart information, and numerical information from the test report, and based on the textual description information, chart information, and numerical information, it performs a test on the test report using at least one of the following logical rules: preset result constraint rules, preset data integrity rules, and preset anomaly labeling rules. Based on the logical rule test results, it determines the logical consistency of the test report. It identifies chart data in the test report and determines the clarity and chart element completeness of the chart data. Based on the clarity and chart element completeness, it determines the chart quality of the test report. Based on the data coverage, the logical consistency, and the chart quality, it determines the report quality test result of the test report.

[0078] In specific application scenarios, in order to determine the rendering type, the determining unit 32 includes a second determining module 321, a cross-processing module 322, and a prediction module 323.

[0079] The second determining module 321 can be used to determine key indicator data from the test indicator data and determine the report type of the test report to be generated.

[0080] The second determining module 321 can also be used to determine the data feature vector corresponding to the key indicator data and the type feature vector corresponding to the report type.

[0081] The cross-processing module 322 can be used to perform feature-level cross-processing on the data feature vector and the type feature vector to obtain a feature cross vector, perform element-level cross-processing on the data feature vector and the type feature vector to obtain an element cross vector, perform low-order cross-processing on the data feature vector and the type feature vector to obtain a low-order cross vector, and perform transformation processing on the feature cross vector, the element cross vector, and the low-order cross vector to obtain a rendering type cross vector.

[0082] The prediction module 323 can be used to input the rendering type cross vector into a preset rendering type prediction model to predict the rendering type and obtain the rendering type in the test report generation template.

[0083] It should be noted that other corresponding descriptions of the functional modules involved in the software test report generation device provided in this embodiment of the invention can be found in the corresponding description of the method shown in Figure 1, and will not be repeated here.

[0084] Based on the method shown in Figure 1, this embodiment of the invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, the program performs the following steps: In response to a test report generation instruction from the target software for a target scenario, test indicator data from different data sources are obtained through a unified multi-data source adaptation layer interface. These different data sources include Prometheus time-series data sources, Grafana visualization data sources, and YAML test case data sources. A test report generation template corresponding to the target scenario is obtained, and the indicator association rules and rendering type in the test report generation template are determined. Based on the indicator association rules, the test indicator data from different data sources are analyzed for correlation. Based on the correlation analysis results, the test conclusion data of the target software is determined. Based on the rendering type, the test indicator data in the Grafana visualization data source is rendered to obtain a rendered image. The test indicator data, the test conclusion data, and the rendered image are embedded into the test report generation template to obtain a test report corresponding to the target software.

[0085] Based on the embodiments of the method shown in Figure 1 and the device shown in Figure 3, this embodiment of the invention also provides a physical structure diagram of a computer device, as shown in Figure 5. The computer device includes: a processor 41, a memory 42, and a computer program stored on the memory 42 and executable on the processor. Both the memory 42 and the processor 41 are mounted on a bus 43. When the processor 41 executes the program, it performs the following steps: In response to a test report generation instruction from the target software for a target scenario, it obtains test indicator data from different data sources through a unified multi-data source adaptation layer interface. These different data sources include Prometheus time-series data sources, Grafana visualization data sources, and YAML test case data sources. It obtains a test report generation template corresponding to the target scenario and determines the indicator association rules and rendering type in the test report generation template. Based on the indicator association rules, it performs association analysis on the test indicator data from different data sources. Based on the association analysis results, it determines the test conclusion data of the target software. Based on the rendering type, it renders the test indicator data from the Grafana visualization data source to obtain a rendered image. It embeds the test indicator data, the test conclusion data, and the rendered image into the test report generation template to obtain a test report corresponding to the target software.

[0086] Through the technical solution of this invention, a unified multi-data source adaptation layer interface can seamlessly integrate test indicator data from different data sources (such as Prometheus time-series data sources, Grafana visualization data sources, and YAML test case data sources). This integration method improves the flexibility and accessibility of data, avoids data processing difficulties caused by different data sources, and makes test data acquisition more efficient and accurate. By acquiring test indicator data from different data sources to generate test reports, the comprehensiveness of the test reports can be guaranteed. By generating test reports using pattern report generation templates, the standardization and automation of test report generation are achieved. By performing correlation analysis on test indicator data from different data sources, the intrinsic relationships between data can be deeply explored, thereby drawing more comprehensive and accurate test conclusions, and further improving the accuracy and comprehensiveness of the generated test reports.

[0087] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0088] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for generating a software test report, characterized in that, include: In response to the target software's instruction to generate a test report for a target scenario, test indicator data from different data sources are obtained through a unified multi-data source adaptation layer interface. These different data sources include Prometheus time-series data sources, Grafana visualization data sources, and YAML test case data sources. A test report generation template corresponding to the target scenario is obtained, and the indicator association rules and rendering type within the template are determined. Based on the indicator association rules, the test indicator data from different data sources are analyzed for correlation. Based on the correlation analysis results, the test conclusion data for the target software is determined. Based on the rendering type, the test indicator data from the Grafana visualization data source is rendered to obtain a rendered image. The test indicator data, the test conclusion data, and the rendered image are embedded into the test report generation template to obtain the test report corresponding to the target software.

2. The method according to claim 1, characterized in that, The test metric data from different data sources include performance test metric data obtained from the Prometheus time-series data source, visualization test metric data graphs obtained from the Grafana visualization data source, and functional test metric data obtained from the YAML test case data source; the metric association rules include performance-functionality metric association rules between performance test metric data and functional test metric data, and performance-visualization metric association rules between performance test metric data and visualization test metric data graphs; Based on the aforementioned indicator association rules, test indicator data from different data sources are correlated and analyzed. Based on the correlation analysis results, the test conclusion data of the target software is determined, including: based on the aforementioned performance-functionality indicator association rules, the performance test indicator data and the functional test indicator data are correlated and analyzed to locate the problems of the target software. Based on the correlation analysis results of the problem location, the problem location data of the target software is determined. Based on the performance-visualization metric association rules, the performance test metric data and the visual test metric data graph are used to perform optimization suggestion analysis on the target software. Based on the optimization suggestion analysis results, optimization suggestion data for the target software is determined, and the problem location data and the optimization suggestion data are used as the test conclusion data.

3. The method according to claim 1, characterized in that, Before obtaining the test report generation template corresponding to the target scenario, the method further includes: determining the test objectives and test scope of the target software in the target scenario; determining test indicator classification and indicator association rules based on the test objectives and test scope; determining the test report indicator context based on the test indicator classification and indicator association rules; and constructing the test report generation template based on the test report indicator context.

4. The method according to claim 1, characterized in that, The process involves obtaining test metric data from different data sources through a unified multi-data source adaptation layer interface, including: constructing a PromeQL statement in the unified multi-data source adaptation layer interface and using the PromeQL statement to call the Prometheus metric query API to obtain test metric data from the Prometheus time-series data source; obtaining test metric data from the Grafana visualization data source through the image call API in the unified multi-data source adaptation layer interface; constructing a Python fs library in the unified multi-data source adaptation layer interface and using the Python fs library to parse test cases in the YAML test case data source, and determining the test metric data in the YAML test case data source based on the parsing results.

5. The method according to claim 1, characterized in that, The step of embedding the test indicator data, the test conclusion data, and the rendered image into the test report generation template to obtain the test report corresponding to the target software includes: determining the key test indicator items of the target software based on the test indicator data, the test conclusion data, and the rendered image; determining the display priority of each title item in the test report generation template based on the key test indicator items; dynamically sorting each title item in the test report generation template based on the display priority; and embedding the test indicator data, the test conclusion data, and the rendered image into the dynamically sorted test report generation template to obtain the test report corresponding to the target software.

6. The method according to claim 1, characterized in that, After embedding the test indicator data, the test conclusion data, and the rendered image into the test report generation template to obtain the test report corresponding to the target software, the method further includes: determining a list of expected key fields for the expected test report corresponding to the target scenario, and determining the actual key fields contained in the test report; determining the data coverage of the test report based on the list of expected key fields and the actual key fields; extracting textual description information, chart information, and numerical information from the test report, and performing at least one logical rule detection on the test report based on the textual description information, the chart information, and the numerical information, including preset result constraint rules, preset data integrity rules, and preset anomaly labeling rules; determining the logical consistency of the test report based on the logical rule detection results; identifying the chart data in the test report, and determining the clarity and chart element completeness of the chart data; determining the chart quality of the test report based on the clarity and chart element completeness; and determining the report quality detection result of the test report based on the data coverage, the logical consistency, and the chart quality.

7. The method according to claim 1, characterized in that, Determining the rendering type in the test report generation template includes: identifying key indicator data from the test indicator data and determining the report type of the test report to be generated; determining the data feature vector corresponding to the key indicator data and determining the type feature vector corresponding to the report type; performing feature-level cross processing on the data feature vector and the type feature vector to obtain a feature cross vector; performing element-level cross processing on the data feature vector and the type feature vector to obtain an element cross vector; performing low-order cross processing on the data feature vector and the type feature vector to obtain a low-order cross vector; performing transformation processing on the feature cross vector, the element cross vector, and the low-order cross vector to obtain a rendering type cross vector; and inputting the rendering type cross vector into a preset rendering type prediction model to predict the rendering type and obtain the rendering type in the test report generation template.

8. A software test report generation device, characterized in that, include: The system comprises the following components: an acquisition unit, which responds to the target software's test report generation instruction for a target scenario by acquiring test indicator data from different data sources through a unified multi-data source adaptation layer interface, including Prometheus time-series data sources, Grafana visualization data sources, and YAML test case data sources; a determination unit, which acquires the test report generation template corresponding to the target scenario and determines the indicator association rules and rendering type in the test report generation template; an analysis unit, which performs association analysis on the test indicator data from different data sources based on the indicator association rules, determines the test conclusion data of the target software based on the association analysis results, and renders the test indicator data from the Grafana visualization data source based on the rendering type to obtain a rendered image; and an embedding unit, which embeds the test indicator data, the test conclusion data, and the rendered image into the test report generation template to obtain the test report corresponding to the target software.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images