A method for test report automation generation and distribution

Abstract

This invention relates to the field of computer software testing technology, and in particular to a method for automated generation and distribution of test reports. The method includes: collecting multi-source data for test reports; preprocessing the data to obtain standardized raw data; extracting core configuration parameters based on the standardized raw data; combining the core configuration parameters, using a state transition identification algorithm to filter and statistically analyze valid activation events within corresponding time intervals; employing a deduplication mechanism to statistically analyze valid activation events for the same defect; calculating the activation rate by combining the number of valid activation events with the total number of corresponding defects; and obtaining and outputting standardized report data after time node completion and invalid value filling; generating target reports based on the standardized report data and core configuration parameters, naming and storing them according to preset rules, and outputting the report storage path and generation completion identifier. This solution achieves fully automated generation and accurate statistics of test reports through multi-module collaboration, thereby improving efficiency and accuracy.

Description

Technical Field

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

[0002] In the field of software and system testing, test reports are the core carrier for presenting the testing process, defect statistics and results. The efficiency and accuracy of their generation and distribution directly affect the progress of testing and project decision-making.

[0003] As software systems become more complex and test data volumes explode, existing report generation methods suffer from numerous pain points. Data collection and preprocessing rely on manual processes, which are prone to errors due to inconsistent data formats and the inclusion of invalid data. Core parameter extraction lacks standardized processes, leading to non-standard parameters and logical contradictions. Effective activation event filtering and deduplication lack precise algorithm support, resulting in low reliability of statistical results. Report generation and storage are not highly automated, inefficient, and lack robust log traceability and security mechanisms.

[0004] To address the aforementioned shortcomings, there is an urgent need for an automated, standardized, and precise method for generating and distributing test reports, which can resolve existing technical pain points and provide reliable support for testing work and project decision-making. Summary of the Invention

[0005] This invention achieves fully automated generation and accurate statistics of test reports through multi-module collaboration, thereby improving efficiency and accuracy.

[0006] The technical solution proposed in this invention is: a method for automatically generating and distributing test reports, the method comprising: Collect multi-source data from test reports, preprocess it to obtain standardized raw data, and extract core configuration parameters based on the standardized raw data; Based on the core configuration parameters, the valid activation events within the corresponding time interval are screened and statistically analyzed through the state transition identification algorithm. The valid activation events of the same defect are statistically analyzed using the deduplication marking mechanism. The activation rate is calculated by combining the number of valid activation events with the total number of corresponding defects. After time node completion and invalid value filling, standardized report data is obtained and output. Based on standardized report data and core configuration parameters, the target report is generated and named and stored according to preset rules, and the report storage path and generation completion identifier are output.

[0007] Preferably, the specific process for obtaining the standardized raw data is as follows: The system collects three types of multi-source data: configuration data, test defect data, and defect status flow records. It employs a differentiated preprocessing strategy for the collected multi-source data, identifies and deletes duplicate data, unifies and standardizes data of different formats, converts non-standard format data into standard format, filters and removes invalid data with missing key information and logical errors, and standardizes and fills in missing data fields to obtain standardized raw data.

[0008] Preferably, the specific process for obtaining the core configuration parameters is as follows: Call the parameter extraction algorithm, input standardized raw data, and filter out the key parameters related to report generation from the standardized raw data; Extract three core parameters: report generation time range, report storage path, and report type. Perform format validation on the extracted core parameters, check the parameter value range and format standardization, and standardize and correct parameters that do not meet the requirements. After the correction is completed, the core configuration parameters are output and synchronously stored in the temporary cache area.

[0009] Preferably, the screening and statistical process for the effective activation events is as follows: Call the state transition recognition algorithm and input the core configuration parameters and defect state transition records; Set defect state transition judgment conditions, filter out defect state transition events within the specified time interval of the core configuration parameters, and exclude invalid events and duplicate transition records that exceed the time interval or whose state transition does not meet the judgment conditions. The selected events are categorized and labeled to distinguish between valid activation events and invalid circulation events. The number of valid activation events is counted to form a statistical list of valid activation events.

[0010] Preferably, the specific implementation process of the deduplication marking mechanism is as follows: Extract the unique identifier of the defect from the defect data, assign a unique tag code to each defect, and establish the correspondence between the unique identifier of the defect and the tag code; Multiple state transition events corresponding to the same defect identifier are associated and marked, the first valid activation event of the defect is recorded, and other transition events of the same defect are marked and masked. Only the first valid activation event is included in the statistical scope, thus completing the deduplication of valid activation events of the same defect.

[0011] Preferably, the activation rate is calculated as follows: From the deduplicated valid activation event statistics, extract the total number of valid activation events. From the preprocessed defect data, count the total number of defects in the corresponding statistical dimension within the time interval specified by the core configuration parameters. The preset activation rate calculation algorithm is invoked to verify the validity based on the total number of valid activation events and the total number of defects. Abnormal values ​​are removed and standardized corrections are performed to obtain the activation rate result. The calculated activation rate results are associated with the corresponding statistical dimensions and time points to output standardized activation rate data.

[0012] Preferably, the specific process for obtaining the time node completion and the invalid value filling is as follows: Extract the report generation time range from the core configuration parameters, determine all natural day time nodes within the time range, and generate a complete list of time nodes; The time node list is compared with the effective activation event statistics to identify time nodes without corresponding defective data, and invalid values ​​are assigned to these time nodes. Invalid values ​​are filled into the data fields of the corresponding time nodes, and the time dimension information of the standardized report data is updated synchronously.

[0013] Preferably, the process for establishing the target report is as follows: Call the report generation tool, input standardized report data and core configuration parameters, match the corresponding report generation template according to the report type in the core configuration parameters, and fill the corresponding fields of the template with standardized report data; Extract report type and current timestamp information, generate report name according to preset rules; read storage path in core configuration parameters, create report storage directory, save the generated target report to the storage path, and output report storage path and generation completion identifier after storage is completed.

[0014] The present invention also provides a computer-readable storage medium storing a computer program, which is executed by a processor to implement the aforementioned method for automated generation and distribution of test reports.

[0015] The beneficial effects of this invention are: 1. By uniformly organizing, deduplicating, cleaning, and standardizing multi-source heterogeneous test data, the quality of raw data is improved. By automatically extracting, verifying, and correcting core configuration parameters, errors caused by manual settings are avoided, thereby improving the stability and reliability of the entire process and reducing manual intervention and error rate.

[0016] 2. By accurately defining the effective activation state transition rules of defects, erroneous operations and invalid transitions are eliminated. A deduplication marking mechanism is adopted to only count the first activation event of the same defect, avoiding duplicate statistics, significantly improving the accuracy of activation rate calculation, and making the statistical results true and reliable.

[0017] 3. By automatically completing time nodes and standardizing the filling of invalid data, the time dimension of the report is ensured to be complete and the display is consistent. The report can automatically match templates, name, store and encrypt, which greatly improves the efficiency of report generation and makes the whole process traceable and reproducible. Attached Figure Description

[0018] Figure 1 A flowchart of a method for automating the generation and distribution of test reports; Figure 2 A flowchart of multi-source data preprocessing for a method of automated generation and distribution of test reports; Figure 3 A flowchart for effective activation event filtering and deduplication in a method for automating test report generation and distribution; Figure 4 This is a flowchart illustrating the activation rate calculation and report generation process for an automated test report generation and distribution method. Detailed Implementation

[0019] The following description is intended to disclose the present invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art. The basic principles of the invention defined in the following description can be applied to other embodiments, modifications, improvements, equivalents, and other technical solutions that do not depart from the spirit and scope of the invention.

[0020] It is understood that the term "a" should be understood as "at least one" or "one or more," that is, in one embodiment, the number of an element can be one, while in another embodiment, the number of the element can be multiple, and the term "a" should not be understood as a limitation on the number.

[0021] like Figure 1 As shown, a method for automatically generating and distributing test reports is characterized by the following steps: Collect multi-source data from test reports, preprocess it to obtain standardized raw data, and extract core configuration parameters based on the standardized raw data; Based on the core configuration parameters, the valid activation events within the corresponding time interval are screened and statistically analyzed through the state transition identification algorithm. The valid activation events of the same defect are statistically analyzed using the deduplication marking mechanism. The activation rate is calculated by combining the number of valid activation events with the total number of corresponding defects. After time node completion and invalid value filling, standardized report data is obtained and output. Based on standardized report data and core configuration parameters, the target report is generated and named and stored according to preset rules, and the report storage path and generation completion identifier are output.

[0022] The automated generation and distribution process of this solution adopts a modular design throughout, consisting of seven core modules: data acquisition and preprocessing module, core configuration parameter extraction module, effective activation event filtering and statistics module, deduplication and marking module, activation rate calculation module, time node completion and invalid value filling module, and target report generation and storage module. Each module interacts with the other through standardized data interfaces to ensure smooth process connection and accurate data transmission.

[0023] The specific details of the collaborative working mechanism of each module are as follows: the standardized raw data output by the data acquisition and preprocessing module serves as the input to the core configuration parameter extraction module; the core configuration parameters output by the core configuration parameter extraction module are synchronously transmitted to the effective activation event filtering and statistics module, the activation rate calculation module, the time node completion and invalid value filling module, and the target report generation and storage module, providing basic configuration for the operation of each module; the effective activation event statistics list output by the effective activation event filtering and statistics module is passed to the deduplication marking module for deduplication processing, and the deduplicated effective activation event data is then transmitted to the activation rate calculation module.

[0024] The standardized activation rate data output by the activation rate calculation module is merged with the data processed by the time node completion and invalid value filling modules to form standardized report data. This standardized report data is then transmitted to the target report generation and storage module to complete the generation, naming, storage, and output of the report. The entire process requires no manual intervention, automating the entire chain from data collection to report distribution. This significantly improves the efficiency and accuracy of test report generation while ensuring the reproducibility and traceability of each step, addressing the technical pain points of existing technologies such as low test report generation efficiency, non-standardized data, inaccurate statistical results, and the inability to automate batch processing.

[0025] Furthermore, the specific process for obtaining standardized raw data is as follows: The system collects three types of multi-source data: configuration data, test defect data, and defect status flow records. It employs a differentiated preprocessing strategy for the collected multi-source data, identifies and deletes duplicate data, unifies and standardizes data of different formats, converts non-standard format data into standard format, filters and removes invalid data with missing key information and logical errors, and standardizes and fills in missing data fields to obtain standardized raw data.

[0026] like Figure 2As shown, the specific details of the differentiated preprocessing strategy are as follows: The duplicate data identification rule uses the primary key as the core criterion. Configuration data uses the parameter ID as the primary key, test defect data uses the defect ID as the primary key, and defect status transfer records use the transfer ID as the primary key. Data with duplicate primary keys is considered duplicate data. Data without a primary key is identified using a similarity threshold; a similarity of ≥95% is considered duplicate data. The similarity calculation uses the cosine similarity method. Pure text fields are processed through word segmentation before similarity is calculated. Numerical fields are similarity determined by calculating the relative error; a relative error ≤5% is considered acceptable. For mixed fields, the similarity of the text and numerical parts is calculated separately, and the average of the two is taken as the final similarity, ensuring the accuracy of duplicate data identification.

[0027] The data format is standardized and clearly defined. Dates are formatted as YYYY-MM-DD, times as HH:MM:SS, and date-time combinations as YYYY-MM-DD HH:MM:SS. Enumeration values ​​are uniformly represented in uppercase (e.g., "VALID", "INVALID", "PASS", "FAIL"). Numerical data is uniformly rounded to two decimal places. If the original data has more than two decimal places, it is rounded to two decimal places; if it has fewer than two decimal places, trailing zeros are added to make two decimal places, ensuring consistency. String data is uniformly encoded in UTF-8, removing leading and trailing spaces, tabs, and other irrelevant characters. Character case is standardized (except for enumeration values, all other strings are lowercase), ensuring the standardization of string data.

[0028] The non-standard format conversion logic is as follows: XML format data is mapped to standard key-value pairs by parsing tag nodes. During parsing, child nodes under the root node are extracted first. The tag name of each child node is used as the key, and the content of the child node is used as the value. If nested child nodes exist, the format "parent node tag - child node tag" is used as the key to ensure the uniqueness of key-value pairs. CSV format data is converted according to the one-to-one correspondence between the header fields and standard fields. If the CSV header fields and standard field names are inconsistent, a preset field mapping table is used for matching and conversion. The mapping table contains three core elements: CSV header fields, standard field names, and matching priority. Fields that are completely consistent are matched first. If no field is completely consistent, fuzzy matching (matching degree ≥ 80%) is used. Data with no matching fields is considered invalid data and is discarded.

[0029] TXT format data is split into fields by a preset delimiter (comma) and then converted. If the TXT file does not have an explicit delimiter, a fixed-length splitting method is used. The length of each field is preset according to the field type, and the standard field is matched after splitting by length. All non-standard formats are finally converted into JSON format. The key names of the JSON format are completely consistent with the standard field names, and the key-value types correspond to the standard field types, ensuring that the converted data format is uniform and can be directly used for subsequent processing.

[0030] The criteria for determining invalid data are as follows: missing key information specifically includes parameter ID, parameter name, and parameter type for configuration data; defect ID, defect name, defect severity, and creation time for test defect data; and transfer ID, defect ID, pre-transfer status, post-transfer status, and transfer time for defect status transfer records. If any of the above key fields are missing, the data is determined to be invalid data with missing key information.

[0031] Examples of logical errors include: the defect creation time being later than the circulation time; the defect severity not matching the processing priority (e.g., a defect with a severity of "fatal" has a processing priority of "low"); non-numeric content appearing in numeric fields (e.g., the defect quantity field containing characters such as "abc"); the status before circulation being the same as the status after circulation (e.g., circulation from "pending" to "pending"); and the defect closure time being earlier than the creation time. Any of the above situations will be considered as invalid data with logical errors.

[0032] The standardized filling rules for missing fields are as follows: Numeric fields (such as number of defects, processing time, activation rate, etc.) are filled with 0 by default. If the numeric field has a clear and reasonable range (such as defect severity being coded as 1-4), then the minimum value of that range is filled; Character fields (such as defect name, parameter name, etc.) are filled with "none" by default. If the character field has a preset optional value (such as defect status), then the "unknown" option from the optional values ​​is filled; Date and time fields (such as creation time, circulation time, etc.) are filled with the start time of the statistical interval by default. If the statistical interval is not specified, then the current system time is filled.

[0033] No interpolation is required; the filled values ​​all come from a pre-defined, unified configuration and are independent of the source system. After filling, the data remarks field is marked "This field contains missing filled values," facilitating subsequent data tracing. Simultaneously, a preprocessing log is generated during the preprocessing process. The log contains core information such as data collection time, data source, total data volume, number of duplicate data, number of invalid data, number of missing field fillers, preprocessing completion time, and preprocessing status. The log is named with a timestamp and stored in a specified path for easy troubleshooting and process tracing.

[0034] Furthermore, the specific process for obtaining the core configuration parameters is as follows: Call the parameter extraction algorithm, input standardized raw data, and filter out the key parameters related to report generation from the standardized raw data; Extract three core parameters: report generation time range, report storage path, and report type. Perform format validation on the extracted core parameters, check the parameter value range and format standardization, and standardize and correct parameters that do not meet the requirements. After the correction is completed, the core configuration parameters are output and synchronously stored in the temporary cache area.

[0035] The specific implementation of the above parameter extraction algorithm is as follows: A rule-based filtering algorithm is adopted, and a key parameter feature library related to report generation is preset, which includes 12 core parameter features such as report type, time interval, storage path, statistical dimension, defect severity, processing priority, report format, output method, cache time, number of retries, log level, and permission information. Each parameter feature includes five core attributes: feature name, feature description, data type, value range, and matching rule. Key parameters are filtered by fuzzy matching of field names (matching degree ≥ 80%), and redundant fields unrelated to report generation (such as tester contact information, device model, operating system version, etc.) are excluded.

[0036] The core execution steps of the parameter extraction algorithm are as follows: First, load the preset key parameter feature library and initialize the filtering rules and matching thresholds; Second, input standardized raw data, perform word segmentation on each field in the data, and extract the core features of the fields; Third, match the core features of the fields with the features in the parameter feature library, calculate the matching degree, and determine the relevant key parameters if the matching degree is ≥80%; Fourth, classify the filtered key parameters, distinguishing between core parameters and auxiliary parameters. Core parameters are the report generation time interval, report storage path, and report type, while auxiliary parameters are the other 10 types of parameters; Fifth, output the filtered key parameters and pass them to the subsequent parameter extraction, verification, and correction steps.

[0037] The storage and retrieval mechanism for core configuration parameters is as follows: the temporary cache is implemented using memory variables, and is also backed up with local files to prevent parameter loss due to memory overflow or system abnormalities. The storage capacity of the memory variables is set to be dynamically adjustable, supporting a maximum of 100 sets of core configuration parameters. The storage duration of each set of parameters is 24 hours by default. Parameters that have not been retrieved after the storage duration are automatically cleaned up to release memory resources.

[0038] The parameter data structure is a JSON object containing six core fields: parameter name, parameter value, extraction time, correction record, data source, and verification status. The correction record field records the original value of the parameter, the reason for correction, the correction method, the correction time, and the person who corrected it (marked "System" if the system corrects automatically), which facilitates the subsequent traceability of the parameter correction process. Subsequent steps access the cached data by calling the preset read interface of the cache area. The interface uses a key-value pair query method to quickly retrieve the corresponding parameter value by parameter name, with a query response time of ≤100ms. The interface also supports both batch query and single query modes. Batch queries can query up to 10 parameters at the same time, ensuring that parameter transmission is transparent and traceable.

[0039] The specific rules for parameter format verification are as follows: The format of the report generation time interval must conform to the format from YYYY-MM-DD HH:MM:SS to YYYY-MM-DD HH:MM:SS. The start time must be earlier than the end time, and the span of the time interval must not exceed 30 days. If it exceeds 30 days, it is judged as a non-standard format. The report storage path must conform to the system file path specification. The path format for Windows system is "disk drive letter:\folder path\", and the path format for Linux system is " / folder path / ". The path must have read and write permissions. If the path does not exist or does not have read and write permissions, it is judged as a non-standard format. The value range of the report type is only "daily report", "weekly report", and "monthly report". If other values ​​appear, it is judged as a non-standard format.

[0040] The specific method for standardization correction is as follows: If the start time of the report generation time interval is later than the end time, the start time will be corrected to 7 days before the end time, and the correction record will be marked "Start time is later than end time, automatically corrected to 7 days before end time"; if the time interval spans more than 30 days, the end time will be corrected to 30 days after the start time, and the record will be marked "Time interval spans more than 30 days, automatically corrected to 30-day span"; if the time format is not standardized, it will be corrected according to the YYYY-MM-DD HH:MM:SS format, and missing time parts will be filled with "00:00:00".

[0041] If the report storage path does not exist, it will be created automatically. If there is no read / write permission, it will be corrected to the system default storage path (the default path for Windows is "C:\Test Reports\", and the default path for Linux is " / test / report / "), and marked "Invalid path, automatically corrected to the system default path"; if the report type is not a preset value, it will be corrected to "Daily Report" and marked "Invalid report type, automatically corrected to Daily Report".

[0042] In addition, after the core configuration parameters are extracted, a second verification is required. The second verification adopts a cross-validation method to check the logical consistency between the core parameters. For example, when the report type is "Daily Report", the time interval span should be 1 day. If the time interval span is not 1 day, it needs to be corrected to ensure the rationality and accuracy of the core configuration parameters. The pass rate of the second verification must reach 100%. If the verification fails, the parameter extraction, verification and correction process will be re-executed. A maximum of 3 retries will be made. If the retries still fail after 3 retries, a system alarm will be triggered and the alarm information will be recorded in the log.

[0043] Furthermore, the screening and statistical process for effective activation events is as follows: Call the state transition recognition algorithm and input the core configuration parameters and defect state transition records; Set defect state transition judgment conditions, filter out defect state transition events within the specified time interval of the core configuration parameters, and exclude invalid events and duplicate transition records that exceed the time interval or whose state transition does not meet the judgment conditions. The selected events are categorized and labeled to distinguish between valid activation events and invalid circulation events. The number of valid activation events is counted to form a statistical list of valid activation events.

[0044] The core logic of the aforementioned state transition identification algorithm is as follows: The specific enumeration set of defect states includes seven types: New, Pending, Processing, Repairing, Retesting, Loop Closure, and Abandoned. The specific definitions of each state are as follows: New means the defect has just been discovered and entered into the system, but has not yet been processed; Pending means the defect has been assigned to a handler and is waiting to be processed; Processing means the handler is processing the defect, but it has not yet been completed; Repaired means the defect has been processed and has passed preliminary verification; Retesting means that after the defect is repaired, it needs to be retested to verify whether the defect has been truly resolved; Loop Closure means the defect has been tested and verified to be resolved and is officially closed; Abandoned means the defect has been determined to be an invalid defect (such as a false alarm or duplicate report), does not need to be processed, and is closed.

[0045] The explicit definition of a valid activation event is as follows: only the transitions from the "closed-loop" state to the "pending processing" state and from the "closed-loop" state to the "retest" state are considered valid activation events. All other state transitions are not considered valid activations. Specifically, the transition from the "closed-loop" state to the "pending processing" state means that after the defect has been closed, new problems or incomplete solutions are discovered, requiring reassignment for processing. The transition from the "closed-loop" state to the "retest" state means that after the defect has been closed, retesting is required to confirm whether the defect has been completely resolved.

[0046] The details of the conditions for determining state transitions are as follows: the preceding state must be a "closed loop", and the time interval between two state transitions must be no less than 10 seconds, with no other additional restrictions. The time interval is calculated by subtracting the time of occurrence of the state before the transition from the time of occurrence of the state after the transition. If the time interval is less than 10 seconds, it is determined to be an invalid transition, considered as a state transition caused by erroneous operation, and is not included in the statistics of valid activation events.

[0047] The implementation guidelines for the state transition identification algorithm are as follows: Using a time-series analysis method, the defect state transition records are parsed item by item. The state values ​​and timestamps of adjacent records are compared to determine whether they meet the definition and judgment conditions of a valid activation event, and events that meet the requirements are selected. The specific execution steps are: First, load the time interval in the core configuration parameters to determine the time range for filtering; Second, read the defect state transition records, group them by defect ID, and sort the transition records of the same defect in ascending order of timestamp. The third step is to analyze adjacent flow records of the same defect one by one, extract the post-flow state of the previous record (i.e., the current pre-flow state), the post-flow state of the next record (i.e., the current post-flow state), and the timestamps of the two records; the fourth step is to determine whether the pre-flow state is "closed loop", whether the post-flow state is "pending processing" or "retest", and whether the time interval is not less than 10 seconds. If all three conditions are met, it is determined to be a valid activation event; otherwise, it is determined to be an invalid flow event. The fifth step is to analyze all the circulation records one by one and summarize all the valid activation events to form a preliminary list of valid activation events. The sixth step is to deduplicate the preliminary list (this is preliminary deduplication; subsequent deduplication will be carried out through a deduplication marking mechanism) to remove duplicate circulation records. The criteria for determining duplicate circulation records are that the defect ID, the previous state, the subsequent state, and the timestamp are completely consistent to ensure the accuracy of the preliminary list.

[0048] In addition, the state transition recognition algorithm also includes an anomaly handling mechanism. If there are anomalies such as missing state values ​​or missing timestamps in the defect state transition record, the transition record is considered invalid and will not be included in the screening and statistics. At the same time, the anomaly information is recorded in the log to facilitate subsequent problem investigation. The execution efficiency of the algorithm must meet the requirement that the screening time for every 1,000 transition records is ≤1 second to ensure efficient operation in scenarios with large amounts of data.

[0049] Furthermore, the specific implementation process of the deduplication marking mechanism is as follows: Extract the unique identifier of the defect from the defect data, assign a unique tag code to each defect, and establish the correspondence between the unique identifier of the defect and the tag code; Multiple state transition events corresponding to the same defect identifier are associated and marked, the first valid activation event of the defect is recorded, and other transition events of the same defect are marked and masked in the future. Only the first valid activation event is included in the statistics, and duplicate valid activation events of the same defect are deduplicated.

[0050] like Figure 3 As shown, the first valid activation event in the above deduplication marking mechanism is clearly defined as follows: the time reference for the first time is the actual occurrence time of the valid activation event, not the defect creation time. The actual occurrence time is based on the occurrence time of the post-transfer state in the defect state transition record, accurate to the second level. If the same defect is activated multiple times within the statistical interval, the first time is defined as the earliest valid activation event that occurs within the statistical interval. The events are sorted in ascending order by their timestamps, and the event with the smallest timestamp is taken as the first valid activation event.

[0051] If there are multiple valid activation events with the same timestamp (i.e., multiple activations within the same second), they are sorted in ascending order by the ID of the transfer record, and the event with the smallest ID is taken as the first valid activation event. If the same defect has only one valid activation event within the statistical interval, then that event is the first valid activation event. If the same defect has no valid activation events within the statistical interval, it is not marked and is not included in the statistical scope.

[0052] The technical implementation of the mark-and-mask method uses database mark bits. A mark bit field is added to the defect status flow record table. The field name is "is_first_activate", the field type is boolean, and the value is "yes" or "no". The mark bit corresponding to the first valid activation event is assigned the value "yes", and the mark bit corresponding to other valid activation events of the same defect is assigned the value "no". During the statistics, only the events with the mark bit set to "yes" are filtered to achieve mark-and-mask.

[0053] Meanwhile, a correlation table is established in the temporary database for "Defect Unique Identifier - Tag Code - First Activation Time". The correlation table contains five core fields: Defect Unique Identifier, Tag Code, First Activation Event ID, First Activation Time, and Tag Time, which facilitates quick querying and verification of the first valid activation event.

[0054] The extraction rule for the unique defect identifier is as follows: the unique defect identifier is the defect ID in the defect data. The defect ID is a 32-bit string automatically generated by the system, containing numbers, uppercase letters, lowercase letters, and special symbols (such as "-" and "_"), ensuring that the unique identifier of each defect is not repeated. The allocation rule for the tag code is as follows: a hash encoding method is used to perform a hash operation on the unique defect identifier to generate a 64-bit hash value as the tag code. The hash algorithm uses the SHA-256 algorithm to ensure the uniqueness and security of the tag code and avoid the duplication of tag codes for different defects.

[0055] The correspondence between the unique defect identifier and the tag code is stored in key-value pairs in a temporary database. The corresponding tag code can be quickly queried through the unique defect identifier, and the corresponding unique defect identifier can be queried in reverse through the tag code. The query response time is ≤50ms.

[0056] The specific steps of the deduplication tagging mechanism are as follows: First, extract the unique identifiers of all defects from the preliminary statistical list of valid activation events; Second, assign a unique tag code to each defect unique identifier, establish a correspondence, and store it in a temporary database; Third, group by defect unique identifier, and sort all valid activation events of the same defect in ascending order by occurrence timestamp; Fourth, determine the first valid activation event in each group, set its tag bit to "yes", and record it in the association table. Fifth, set the flag of other valid activation events of the same defect to "No" to complete the marking and masking; Sixth, filter out the valid activation events with the flag "Yes" to form a list of valid activation events after deduplication; Seventh, verify the list of deduplication events to ensure that each defect has only one first valid activation event. The verification pass rate must reach 100%. If the verification fails, the deduplication marking process is re-executed, with a maximum of 2 retries.

[0057] In addition, the deduplication marking mechanism also includes a marking update function. If the statistical interval is adjusted, or if the defect status flow record is supplemented or modified, the deduplication marking process needs to be re-executed to update the marking bits and related tables to ensure that the deduplication results are consistent with the latest data. At the same time, a deduplication marking log is generated, which includes information such as deduplication time, total number of defects, total number of valid activation events, total number of valid activation events after deduplication, total number of marked and masked events, and verification results, which facilitates subsequent traceability and problem investigation.

[0058] Furthermore, the activation rate is calculated as follows: From the deduplicated valid activation event statistics, extract the total number of valid activation events. From the preprocessed defect data, count the total number of defects in the corresponding statistical dimension within the time interval specified by the core configuration parameters. The preset activation rate calculation algorithm is invoked to verify the validity based on the total number of valid activation events and the total number of defects. Abnormal values ​​are removed and standardized corrections are performed to obtain the activation rate result. The calculated activation rate results are associated with the corresponding statistical dimensions and time points to output standardized activation rate data.

[0059] like Figure 4 As shown, the specific basis for validity verification and standardization correction in the above activation rate calculation is as follows: The criteria for judging abnormal values ​​are that the activation rate value is greater than 100% or less than 0%, the total number of valid activation events is greater than the total number of defects in the corresponding statistical dimension, and the total number of valid activation events or the total number of defects is negative.

[0060] Among them, an activation rate greater than 100% means that the total number of valid activation events exceeds the total number of defects in the corresponding statistical dimension, which does not conform to the actual statistical logic; an activation rate less than 0% means that a negative result occurs during the calculation process, which does not meet the basic requirements of proportional statistics; a negative total number of valid activation events or a negative total number of defects means that data anomalies occur during the statistical process, which may be due to problems in the data collection or preprocessing stages, and all of these must be judged as abnormal values.

[0061] The specific method for standardization correction is as follows: If the activation rate is greater than 100%, it is corrected to 100%, and the correction record is marked "Activation rate greater than 100%, automatically corrected to 100%"; if the activation rate is less than 0%, it is corrected to 0%, and the record is marked "Activation rate less than 0%, automatically corrected to 0%"; if the total number of valid activation events is greater than the total number of defects, the total number of valid activation events is corrected to the total number of defects, and the record is marked "Total number of valid activation events is greater than the total number of defects, automatically corrected to the total number of defects"; if the total number of valid activation events is negative, it is corrected to 0, and the record is marked "Total number of valid activation events is negative, automatically corrected to 0"; if the total number of defects is negative, it is corrected to 1, and the record is marked "Total number of defects is negative, automatically corrected to 1", to avoid division by zero.

[0062] The implementation guidelines for the preset activation rate calculation algorithm are as follows: It uses basic division combined with proportional conversion. The core calculation logic is to divide the total number of deduplicated valid activation events by the total number of defects in the corresponding statistical dimension, then multiply by 100 to obtain the activation rate in percentage form, while retaining two decimal places to obtain the initial activation rate. The specific execution steps are as follows: First, extract the list of deduplicated valid activation events, count the total number of valid activation events, and group them by statistical dimension, counting the total number of valid activation events separately for each statistical dimension. The second step is to filter out defect data within the specified time interval of the core configuration parameters from the preprocessed defect data, group them by statistical dimensions, and count the total number of defects for each statistical dimension. The statistical dimensions include the module to which the defect belongs, the severity of the defect, and the processing priority. One or more of these dimensions can be selected for statistics according to the requirements of the core configuration parameters. The third step is to divide the total number of valid activation events for each statistical dimension by the total number of defects for that dimension. If the total number of defects is 0, the activation rate is corrected to 0%. The fourth step is to multiply the calculation result by 100 to obtain the initial activation rate in percentage form, and round it to two decimal places. The fifth step is to verify the validity of the initial activation rate, remove outliers and perform standardization correction to obtain the final activation rate result. The sixth step is to associate the activation rate result of each statistical dimension with the corresponding statistical dimension and time node to form standardized activation rate data.

[0063] The specific rules for dividing the statistical dimensions are as follows: the module to which the defect belongs is divided into four categories: module A, module B, module C, and module D, which can be expanded according to actual testing needs; the severity of the defect is divided into four categories: fatal, severe, moderate, and minor, corresponding to codes 1-4; the processing priority is divided into three categories: high, medium, and low, corresponding to codes 1-3; when conducting statistics, the statistical dimensions specified by the core configuration parameters must be strictly followed for grouping to ensure consistency in statistical criteria.

[0064] In addition, a calculation log is generated synchronously during the activation rate calculation process. The log contains information such as calculation time, statistical dimensions, total number of valid activation events, total number of defects, initial activation rate, correction records, and final activation rate, which facilitates subsequent traceability of the calculation process and verification of the accuracy of the calculation results. The computational efficiency of the algorithm must meet the requirement that the calculation time for each 100 statistical dimensions is ≤500ms, ensuring that it can still run efficiently in multi-statistical-dimensional scenarios.

[0065] Meanwhile, to ensure the accuracy of the activation rate calculation, cross-validation is required. The calculated activation rate result is compared with the manually counted result. The comparison error should be ≤1%. If the comparison error exceeds 1%, the activation rate calculation process is re-executed to investigate problems in the data statistics or calculation process and ensure the reliability of the calculation result.

[0066] Furthermore, the specific process for obtaining time node completion and invalid value filling is as follows: Extract the report generation time range from the core configuration parameters, determine all natural day time nodes within the time range, and generate a complete list of time nodes; The time node list is compared with the effective activation event statistics to identify time nodes without corresponding defective data, and invalid values ​​are assigned to these time nodes. Invalid values ​​are filled into the data fields of the corresponding time nodes, and the time dimension information of the standardized report data is updated synchronously.

[0067] The specific definitions of invalid values ​​in the above time node completion are as follows: Invalid values ​​are represented as follows: numeric fields are filled with 0, character fields are filled with "no data", and date / time fields are filled with the date of the corresponding time node. Among them, numeric fields include the number of valid activation events, the total number of defects, activation rate, etc. Filling with 0 ensures the consistency of numerical calculations and avoids calculation errors due to missing data. Character fields include statistical dimension descriptions, data status, etc. Filling with "no data" clearly indicates that there is no corresponding data for the time node, making it easy for users to identify. Date / time fields are filled with the date of the corresponding time node in the format YYYY-MM-DD to ensure the integrity of the time dimension.

[0068] Invalid values ​​are displayed in the report as follows: numeric invalid values ​​of 0 are displayed normally in black font, consistent with normal data; character invalid values ​​"No Data" are displayed in the center and marked in light gray (RGB color value 200, 200, 200), distinguishing them from the black font of normal data, making it easy for users to quickly identify time points with no data; invalid values ​​are not included in chart plotting, and the corresponding positions in the chart are displayed as blank. If it is a line chart, the node is not connected to the line; if it is a bar chart, the node does not display the bar; if it is a pie chart, the node does not include the data, ensuring the accuracy and readability of the chart display.

[0069] The specific implementation process for time node completion is as follows: First, extract the report generation time interval from the core configuration parameters, specifying the start and end dates of the time interval in YYYY-MM-DD format. Second, use a date increment algorithm, starting from the start date and incrementing daily until the end date, to generate all natural day time nodes within the time interval. Each time node is in YYYY-MM-DD format, ensuring no omissions or duplicates. Third, sort the generated time node list in ascending date order to form a complete time node list. The list includes two fields: "Time Node" and "Whether There is Corresponding Data." Initially, the "Whether There is Corresponding Data" field is always "No." The fourth step is to read the deduplicated valid activation event statistics, extract the occurrence date of each valid activation event (in YYYY-MM-DD format), group by date, and count the number of valid activation events, the total number of defects, the activation rate, and other data for each date. The fifth step is to compare the statistically analyzed dates with the time nodes in the time node list. If a time node in the time node list has corresponding data in the statistics, the "Does it have corresponding data?" field for that node is changed to "Yes," and the statistics are filled into the corresponding field. If a time node does not have corresponding data in the statistics, it is determined to be a time node without corresponding defect data, and an invalid value is assigned to that node. Step 6: Fill invalid values ​​into the data fields of the corresponding time nodes to ensure that each time node has complete data records without any missing values. Step 7: Synchronously update the time dimension information of the standardized report data, and integrate the completed time nodes and corresponding data into the standardized report data to ensure that the time dimension of the standardized report data is complete and the data is standardized.

[0070] The specific implementation of the date increment algorithm is as follows: the year, month, and day of the starting date are obtained through the system's built-in date processing function, and the number of days is increased day by day. If the number of days in a month reaches the maximum number of days in that month, the number of months is incremented by 1 and the number of days is reset to 1. If the number of months reaches 12, the number of years is incremented by 1 and the number of months is reset to 1, until the end date is reached, ensuring the accuracy of the date increment and preventing skipped or repeated dates.

[0071] In addition, a completion log is generated synchronously during the time node completion process. The log includes information such as completion time, report generation time range, total number of time nodes, number of nodes with corresponding data, number of nodes without corresponding data, number of invalid values ​​filled, and completion status, which facilitates subsequent traceability of the completion process and troubleshooting. The completion efficiency must meet the requirement that when the time range spans 30 days, the completion time should be ≤1 second to ensure that the completion process is efficient and fast.

[0072] At the same time, if the report generation time range in the core configuration parameters is adjusted, the time node completion and invalid value filling process needs to be re-executed to update the time dimension information of the standardized report data and ensure that the data is consistent with the time range.

[0073] Furthermore, the process for establishing the target report is as follows: Call the report generation tool, input standardized report data and core configuration parameters, match the corresponding report generation template according to the report type in the core configuration parameters, and fill the corresponding fields of the template with standardized report data; Extract report type and current timestamp information, generate report name according to preset rules; read storage path in core configuration parameters, create report storage directory, save the generated target report to the storage path, and output report storage path and generation completion identifier after storage is completed.

[0074] The specific details of the above report generation tool and template matching mechanism, as well as the naming of preset rules, are as follows: The report generation tool uses a self-developed report engine, supports Excel and PDF report formats, provides a standardized call interface, the input parameters of which are standardized report data and core configuration parameters, and the output parameter is the generated report file; the core functions of the self-developed report engine include four modules: template loading, data filling, format rendering, and file generation. The template loading module is responsible for loading preset report templates, supports loading templates from local or network paths, and the loading response time is ≤200ms.

[0075] The data filling module is responsible for filling standardized report data into the corresponding fields of the template, supporting batch filling and single field filling, with a filling accuracy of ≥99.9%; the format rendering module is responsible for rendering the font, color, border, alignment, etc. of the report to ensure that the report style is standardized and aesthetically pleasing; the file generation module is responsible for generating the corresponding Excel or PDF file from the filled and rendered template, with a generation efficiency of ≤1 second per 100 data entries. After the file is generated, it automatically performs integrity verification to ensure that the file is not damaged and the data is not missing.

[0076] The template matching rule is as follows: each report type corresponds one-to-one with a template ID. Daily reports correspond to template ID 001, weekly reports to template ID 002, and monthly reports to template ID 003. The system automatically matches the template with the corresponding ID based on the report type in the core configuration parameters. Templates are stored in the template directory specified by the system. Each template has a unique template ID and template name. The template name format is "report type_template ID_version number", for example, "daily report_001_V1.0". The template version number is used to distinguish different versions of the template, facilitating template updates and maintenance. If the report type in the core configuration parameters does not match a corresponding template ID, the default template (template ID 000) is automatically called. The default template is a general report template that contains all core fields, ensuring uninterrupted report generation.

[0077] The field mapping relationship for data population to the template is as follows: the field names in the standardized report data are completely consistent with the template placeholders. The field name exact matching method is used to populate the corresponding data into the corresponding position in the template. Placeholders without field matching are filled with invalid values. The specific mapping rules are as follows: the time node field in the standardized report data corresponds to the date placeholder in the template, the statistical dimension field corresponds to the statistical dimension placeholder in the template, the total number of defects field corresponds to the total number of defects placeholder in the template, the number of valid activation events field corresponds to the number of valid activations placeholder in the template, the activation rate field corresponds to the activation rate (%) placeholder in the template, and the data status field corresponds to the data status placeholder in the template.

[0078] During the data population process, if any field value in the standardized report data is invalid, the data will be populated according to the invalid value display rules to ensure that the populated report data is standardized and readable. The specific naming rules are as follows: the report name includes three elements: project name, report type, and timestamp, concatenated in the order of project name_report type_timestamp, with underscores used as separators between elements. The project name is fixed as "Test Project". If a custom project name is specified in the core configuration parameters, that custom project name will be used. The timestamp precision is accurate to the minute, and the format is YYYYMMDDHHMM, for example, "Test Project_Daily Report_202603221430.xlsx" or "Test Project_Weekly Report_202603241015.pdf".

[0079] If multiple reports of the same type and with the same timestamp exist, add a serial number after the timestamp (e.g., "Test Project_Daily Report_202603221430_01.xlsx"). The serial number starts from 01 and increments to avoid file overwriting. Meanwhile, the standardized report data has a clear structure, including six core fields: time node, statistical dimension, total number of defects, number of valid activation events, activation rate, and data status. The specific specifications for each field are as follows: the time node field is in date format (YYYY-MM-DD), cannot be empty, and its value range is the report generation time interval specified by the core configuration parameters.

[0080] The statistical dimension field is a character type and cannot be empty. Its value range is one or more of the following: the module to which the defect belongs (Module A, Module B, Module C, Module D), the severity of the defect (fatal, severe, moderate, minor), and the processing priority (high, medium, low). The specific value is specified by the core configuration parameters. The total number of defects field is a positive integer type and cannot be empty. Its value range is 0 and above. If the value is invalid, it is filled with 0. The number of valid activation events field is a positive integer type and cannot be empty. Its value range is 0 and above. If the value is invalid, it is filled with 0. The activation rate field is a numeric type and cannot be empty. Its value range is 0-100, with two decimal places. If the value is invalid, it is filled with 0. The data status field is a character type and cannot be empty. Its value is "valid" or "invalid". Valid means that the data is normal statistical data, and invalid means that the data contains invalid values, which helps users quickly identify the data status.

[0081] The physical data storage format is CSV, with column headers corresponding one-to-one with the aforementioned field names. The encoding format is UTF-8, with each row corresponding to one data entry. Data entries are separated by commas, and missing values ​​are filled according to invalid value rules, facilitating downstream system reading and processing. The specific mechanism for report storage is as follows: it reads the storage path from the core configuration parameters, first verifying the path's validity and read / write permissions. If the path is valid and has read / write permissions, it is used directly; if the path is invalid or lacks read / write permissions, it is automatically corrected to the system default storage path, and the log is marked "Invalid storage path, automatically corrected to the system default path".

[0082] Then, it checks if the storage directory exists. If not, it automatically creates the directory, ensuring that the directory name conforms to the system file naming conventions and contains no special characters. The generated target report is saved to this storage path using an encrypted storage method with the AES-128 encryption algorithm. The encryption key is automatically generated and stored by the system to ensure the security of the report file and prevent data leakage. After saving, the system automatically verifies the integrity of the file by comparing information such as file size and number of data entries to confirm that the file is not damaged and the data is not missing, with a verification pass rate of ≥99.8%.

[0083] After successful verification, the system outputs the report storage path and a completion identifier. The completion identifier is a 16-character random string automatically generated by the system, containing numbers and uppercase letters. Each report has a unique completion identifier, which can be used for subsequent report distribution, querying, verification and other processes. An example identifier is "8A3F5B7D9E2C4G6H".

[0084] In addition, operation logs are generated synchronously during report generation and storage. The logs include information such as report generation time, report name, report format, storage path, generation completion identifier, number of data rows, and operation status. The logs are named by timestamp and stored in a specified log directory for easy traceability and troubleshooting. At the same time, the system supports batch generation and storage of reports, and can handle report generation needs for multiple statistical dimensions and multiple time intervals at the same time. The efficiency of batch generation is consistent with that of single report generation, ensuring the high efficiency of batch processing.

[0085] The processes described above with reference to the flowcharts in the embodiments disclosed in this invention can be implemented as computer software programs. The embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit (CPU), it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wire segments, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless segments, wire segments, optical fibers, RF, etc., or any suitable combination thereof.

[0086] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0087] Those skilled in the art should understand that the embodiments of the present invention described above and shown in the accompanying drawings are merely examples and do not limit the present invention. The purpose of the present invention has been fully and effectively achieved. The functions and structural principles of the present invention have been shown and explained in the embodiments. Without departing from the stated principles, the implementation of the present invention may have any variations or modifications.

Claims

1. A method for automatically generating and distributing test reports, characterized in that, The method includes: Collect multi-source data from test reports, preprocess it to obtain standardized raw data, and extract core configuration parameters based on the standardized raw data; Based on the core configuration parameters, the valid activation events within the corresponding time interval are screened and statistically analyzed through the state transition identification algorithm. The valid activation events of the same defect are statistically analyzed using the deduplication marking mechanism. The activation rate is calculated by combining the number of valid activation events with the total number of corresponding defects. After time node completion and invalid value filling, standardized report data is obtained and output. Based on standardized report data and core configuration parameters, the target report is generated and named and stored according to preset rules, and the report storage path and generation completion identifier are output.

2. The method for automatically generating and distributing test reports according to claim 1, characterized in that, The specific process for obtaining the standardized raw data is as follows: The system collects three types of multi-source data: configuration data, test defect data, and defect status flow records. It employs a differentiated preprocessing strategy for the collected multi-source data, identifies and deletes duplicate data, unifies and standardizes data of different formats, converts non-standard format data into standard format, filters and removes invalid data with missing key information and logical errors, and standardizes and fills in missing data fields to obtain standardized raw data.

3. The method for automatically generating and distributing test reports according to claim 2, characterized in that, The specific process for obtaining the core configuration parameters is as follows: Call the parameter extraction algorithm, input standardized raw data, and filter out the key parameters related to report generation from the standardized raw data; Extract three core parameters: report generation time range, report storage path, and report type. Perform format validation on the extracted core parameters, check the parameter value range and format standardization, and standardize and correct parameters that do not meet the requirements. After the correction is completed, the core configuration parameters are output and synchronously stored in the temporary cache area.

4. The method for automatically generating and distributing test reports according to claim 3, characterized in that, The screening and statistical process for the valid activation events is as follows: Call the state transition recognition algorithm and input the core configuration parameters and defect state transition records; Set defect state transition judgment conditions, filter out defect state transition events within the specified time interval of the core configuration parameters, and exclude invalid events and duplicate transition records that exceed the time interval or whose state transition does not meet the judgment conditions. The selected events are categorized and labeled to distinguish between valid activation events and invalid circulation events. The number of valid activation events is counted to form a statistical list of valid activation events.

5. The method for automatically generating and distributing test reports according to claim 4, characterized in that, The specific implementation process of the deduplication marking mechanism is as follows: Extract the unique identifier of the defect from the defect data, assign a unique tag code to each defect, and establish the correspondence between the unique identifier of the defect and the tag code; Multiple state transition events corresponding to the same defect identifier are associated and marked, the first valid activation event of the defect is recorded, and other transition events of the same defect are marked and masked. Only the first valid activation event is included in the statistical scope, thus completing the deduplication of valid activation events of the same defect.

6. The method for automatically generating and distributing test reports according to claim 5, characterized in that, The activation rate is calculated as follows: From the deduplicated valid activation event statistics, extract the total number of valid activation events. From the preprocessed defect data, count the total number of defects in the corresponding statistical dimension within the time interval specified by the core configuration parameters. The preset activation rate calculation algorithm is invoked to verify the validity based on the total number of valid activation events and the total number of defects. Abnormal values ​​are removed and standardized corrections are performed to obtain the activation rate result. The calculated activation rate results are associated with the corresponding statistical dimensions and time points to output standardized activation rate data.

7. The method for automatically generating and distributing test reports according to claim 6, characterized in that, The specific process for obtaining the time node completion and the invalid value filling is as follows: Extract the report generation time range from the core configuration parameters, determine all natural day time nodes within the time range, and generate a complete list of time nodes; The time node list is compared with the effective activation event statistics to identify time nodes without corresponding defective data, and invalid values ​​are assigned to these time nodes. Invalid values ​​are filled into the data fields of the corresponding time nodes, and the time dimension information of the standardized report data is updated synchronously.

8. The method for automatically generating and distributing test reports according to claim 7, characterized in that, The process of establishing the target report is as follows: Call the report generation tool, input standardized report data and core configuration parameters, match the corresponding report generation template according to the report type in the core configuration parameters, and fill the corresponding fields of the template with standardized report data; Extract report type and current timestamp information, generate report name according to preset rules; read storage path in core configuration parameters, create report storage directory, save the generated target report to the storage path, and output report storage path and generation completion identifier after storage is completed.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement a method for automatically generating and distributing test reports as described in any one of claims 1-8.

Images