Test method and device of report system and electronic equipment

Abstract

The invention discloses a report system testing method and device and electronic equipment. The method relates to the field of big data, and comprises the following steps: inputting test data into a to-be-tested report system to obtain a first data processing result; comparing the first data processing result of the test data with the first standard data processing result to obtain a first test result; obtaining a sub-data processing result of the test data in each detection node in a preset processing path in the to-be-tested report system, and obtaining a second data processing result; obtaining a second standard data processing result set of the test data in the preset processing path, and determining a second test result of the test data according to the second standard data processing result set and the second data processing result; and determining a target test result of the to-be-tested report system according to the first test result and the second test result. Through the method and the device, the problem of relatively low efficiency of testing the report system by adopting a black box test method in related technologies is solved.

Description

Technical Field

[0001] This application relates to the field of big data, and more specifically, to a testing method, apparatus, and electronic device for a reporting system. Background Technology

[0002] In financial institutions, in order to ensure the validity and accuracy of the data stored in various business reports in the reporting system, the reporting system needs to be able to accurately receive and process the data sent by the upstream system.

[0003] To improve the accuracy of data processing operations performed by the reporting system, it is necessary to test the reporting system regularly. The test results are used to determine whether there are any anomalies in the reporting system. Currently, most reporting systems are tested using black-box testing methods. This method mainly compares the consistency between the upstream source data input and the final output of the report to determine the correctness of the report results.

[0004] However, this method has obvious limitations. Because bank reporting systems generally adopt a multi-layered architecture, data needs to undergo multiple processing operations such as cleaning, transformation, association, and aggregation before the raw data transmitted from the upstream system can be processed into valid data stored in the business reports. Therefore, when using black-box testing methods for system testing and verification, the system test results can only be determined based on the final output data. It is impossible to delve into the multi-layered data processing flow to check the transformation and calculation logic of data between different levels in the reporting system. It is difficult to effectively detect problems that occur at each data processing level during the data processing process. As a result, when encountering abnormal report data, it is difficult to quickly locate the root cause of the problem, which affects the efficiency of testing and the quality control of reports.

[0005] There is currently no effective solution to the problem of low efficiency in testing reporting systems using black-box testing methods in related technologies. Summary of the Invention

[0006] The main objective of this application is to provide a testing method, apparatus, and electronic device for a reporting system, in order to solve the problem of low efficiency in testing reporting systems using black-box testing methods in related technologies.

[0007] To achieve the above objectives, according to one aspect of this application, a testing method for a reporting system is provided. The method includes: receiving test data sent by an upstream system of the reporting system under test, and inputting the test data into the reporting system under test to obtain a first data processing result; acquiring a first standard data processing result of the test data, and comparing the first data processing result with the first standard data processing result to obtain a first test result; acquiring a preset processing path of the test data in the reporting system under test, and acquiring the sub-data processing results of each detection node in the preset processing path to obtain a second data processing result; acquiring the second standard data processing results of each detection node in the preset processing path to obtain a set of second standard data processing results, and determining a second test result of the test data based on the set of second standard data processing results and the second data processing result; and determining a target test result of the reporting system under test based on the first test result and the second test result.

[0008] Optionally, comparing the first data processing result with the first standard data processing result to obtain the first test result includes: obtaining the field values ​​of each field contained in the first standard data processing result to obtain N first field values, where N is a positive integer; obtaining the corresponding second field value of each first field value in the first data processing result to obtain N second field values; comparing the corresponding first field values ​​and second field values ​​to obtain N first comparison results, and determining that the first test result is without anomalies if all N first comparison results are consistent; and determining that the first test result has anomalies if at least one first comparison result is inconsistent.

[0009] Optionally, determining the second test result of the test data based on the second standard data processing result set and the second data processing result includes: performing node consistency detection on the second standard data processing result set and the second data processing result to obtain a first detection result; performing content consistency detection on the second standard data processing result set and the second data processing result to obtain a second detection result; and determining the second test result based on the first detection result and the second detection result.

[0010] Optionally, performing node consistency checks on the second standard data processing result set and the second data processing result to obtain a first detection result includes: obtaining standard nodes associated with the second standard data processing result set to obtain M1 standard nodes, and determining whether the M1 standard nodes are the same as M2 detection nodes in the preset processing path, where M1 and M2 are both positive integers; if the M1 standard nodes are the same as the M2 detection nodes, the first detection result is determined to be that there is no node consistency anomaly; if the M1 standard nodes are different from the M2 detection nodes, the first detection result is determined to be that there is a node consistency anomaly.

[0011] Optionally, performing content consistency checks on the second standard data processing result set and the second data processing result to obtain the second detection result includes: obtaining the standard nodes associated with the second standard data processing result set to obtain M1 standard nodes, and obtaining the output data of each standard node to obtain M1 standard output data; comparing the corresponding standard output data and sub-data processing results to obtain M1 second comparison results; if all M1 second comparison results are consistent, the second detection result is determined to be content consistency without anomalies; if any one of the second comparison results is inconsistent, the second detection result is determined to be content consistency with anomalies.

[0012] Optionally, determining the target test result of the reporting system under test based on the first test result and the second test result includes: if both the first test result and the second test result indicate no abnormality, determining the target test result as having no abnormality; if the first test result and / or the second test result indicate an abnormality, determining the target test result as having an abnormality.

[0013] Optionally, test data is generated as follows: obtain the test requirements of the report system to be tested, and generate edge test data based on the test requirements; add a tracing field to the edge test data, and add tracing codes to the extended fields of the edge test data to obtain the test data.

[0014] Optionally, if the target test result is abnormal, the method further includes: determining the abnormal detection node based on the first test result and the second test result, and obtaining the abnormal sub-data processing result under the abnormal detection node; obtaining the normal sub-data processing result of the previous node of the abnormal detection node from the preset processing path, and determining the cause of the abnormality based on the normal sub-data processing result and the abnormal sub-data processing result.

[0015] To achieve the above objectives, according to another aspect of this application, a testing apparatus for a reporting system is provided. The apparatus includes: a receiving unit for receiving test data sent from an upstream system of the reporting system under test, and inputting the test data into the reporting system under test to obtain a first data processing result; a comparison unit for acquiring a first standard data processing result of the test data, and comparing the first data processing result with the first standard data processing result to obtain a first test result; a first acquisition unit for acquiring a preset processing path of the test data in the reporting system under test, and acquiring the sub-data processing results of each detection node in the preset processing path to obtain a second data processing result; a first determination unit for acquiring the second standard data processing results of each detection node in the preset processing path to obtain a set of second standard data processing results, and determining a second test result of the test data based on the set of second standard data processing results and the second data processing result; and a second determination unit for determining a target test result of the reporting system under test based on the first test result and the second test result.

[0016] To achieve the above objectives, according to another aspect of this application, an electronic device is provided, comprising a memory storing an executable program; and a processor for running the program, wherein the program executes the above-described test method for the reporting system during runtime.

[0017] To achieve the above objectives, according to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the above-described test method for the reporting system.

[0018] In this embodiment, test data is received from the upstream system of the report system under test, and the test data is input into the report system under test to obtain a first data processing result; a first standard data processing result of the test data is obtained, and the first data processing result and the first standard data processing result are compared to obtain a first test result; a preset processing path of the test data in the report system under test is obtained, and the sub-data processing results of each detection node of the test data in the preset processing path are obtained to obtain a second data processing result; the second standard data processing results of each detection node of the test data in the preset processing path are obtained to obtain a set of second standard data processing results, and a second test result of the test data is determined based on the set of second standard data processing results and the second data processing result; and the test result is determined based on the first test result and the first standard data processing result. The method of determining the target test result of the reporting system under test through two test results is as follows: First test result is obtained by comparing the output results; second test result is obtained by using probes configured at each node to collect the sub-data processing results of each detection node and detecting the sub-data processing results; and finally, the test result of the reporting system is determined by combining the first and second test results. This achieves the goal of judging whether there is anomaly in the system through two detection dimensions, and when the detection results indicate that there is anomaly in the system, the location of the anomaly can be quickly located based on the detection results of each detection node. This achieves the technical effect of improving the overall testing efficiency and problem tracing efficiency of the reporting system under test, and solves the technical problem of low efficiency in testing reporting systems using black-box testing methods in related technologies. Attached Figure Description

[0019] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 A hardware structure block diagram of a computer terminal for implementing a testing method for a reporting system is shown.

[0021] Figure 2 This is a flowchart of a testing method for a reporting system provided in Embodiment 1 of this application;

[0022] Figure 3 This is a schematic diagram of a test apparatus for a reporting system provided in Embodiment 2 of this application;

[0023] Figure 4 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] It should be noted that the testing methods, devices, and electronic equipment for the reporting system defined in this disclosure can be used in the field of big data, or in any field other than big data. The application fields of the testing methods, devices, and electronic equipment for the reporting system defined in this disclosure are not limited.

[0028] It should be noted that all information, user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) used in this application are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse use. If the user chooses to refuse, the process will proceed to the expert decision-making process. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface. After receiving consent from the aforementioned user or organization, the relevant information is obtained. Users can view the purpose of data use in real time through the authorization interface and have the right to withdraw authorization or delete data at any time. After the authorization is withdrawn, the system will terminate the relevant data processing within 24 hours.

[0029] The embodiments or examples disclosed herein are not exhaustive, but merely illustrative of some embodiments or examples, and are not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment or example can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment or example can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment or example can be arbitrarily interchanged. Furthermore, optional methods or examples in a particular embodiment or example can be arbitrarily combined; moreover, embodiments or examples can be arbitrarily combined. For example, some or all steps of different embodiments or examples can be arbitrarily combined, and a particular embodiment or example can be arbitrarily combined with optional methods or examples of other embodiments or examples.

[0030] For ease of description, the following explains some of the nouns or terms used in the embodiments of this application:

[0031] ETL process: Extract, Transform, Load Process, which involves extracting, transforming, and loading data.

[0032] ODS layer: Operational Data Store, the operational data storage layer.

[0033] DW layer: Data Warehouse.

[0034] DM layer: Data Mart.

[0035] Example 1

[0036] According to an embodiment of this application, an embodiment of a testing method for a reporting system is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing a testing method for a reporting system is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, processing devices such as microprocessors or programmable logic devices), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface, a universal serial bus port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0038] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0039] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the test method of the reporting system in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned test method of the reporting system. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0040] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0041] The display may be, for example, a touchscreen LCD display that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0042] Under the aforementioned operating environment, this application provides the following: Figure 2 The testing method for the reporting system is shown. Figure 2 This is a flowchart of a testing method for a reporting system provided in Embodiment 1 of this application, as shown below. Figure 2 As shown, the method includes:

[0043] Step S201: Receive test data sent by the upstream system of the report system to be tested, and input the test data into the report system to be tested to obtain the first data processing result.

[0044] The execution entity in this embodiment can be a test system for a reporting system. This system can detect the processing flow and results when the reporting system under test processes the test data, thereby determining whether there are any abnormalities in the reporting system under test.

[0045] It should be noted that the test data is used to verify the accuracy and stability of the reporting system under test during the processing. It can include various boundary values ​​and outliers, as well as normal data under business scenarios. The first data processing result is the output of the reporting system under test after actually processing the test data, reflecting the actual situation of report generation.

[0046] For example, when testing a reporting system under test, test data is first received from an upstream system (such as a core banking system or a credit system), and then sent to the reporting system under test. The reporting system under test then processes the received test data according to a preset ETL process. This process involves data extraction, cleaning, transformation, aggregation, and loading, and finally generates the first data processing result, which is the output data of the reporting system.

[0047] It should be noted that the test data can cover all possible scenarios of data processing in the reporting system under test, including but not limited to normal values, boundary values, null values, abnormal format values, and specific values ​​in historical business scenarios.

[0048] Step S202: Obtain the first standard data processing result of the test data, and compare the first data processing result with the first standard data processing result to obtain the first test result.

[0049] It should be noted that the first standard data processing result can be the correct data processing result corresponding to the test data, serving as a comparison benchmark.

[0050] For example, after obtaining the first data processing result, a first standard data processing result can be obtained, and the first data processing result can be compared with the first standard data processing result. If the values, contents, etc. of the two are completely consistent, then the first test result is passed; otherwise, it is a failure. This verifies the accuracy of the report system output at a macro level. If a difference is found, it means that there may be logical errors or improper configurations in some parts of the data processing of the report system, resulting in errors in the results.

[0051] Step S203: Obtain the preset processing path of the test data in the report system under test, and obtain the sub-data processing results of each detection node of the test data in the preset processing path to obtain the second data processing result.

[0052] It should be noted that the preset processing path is a predetermined flow for the report system's data processing test data, encompassing the entire process from the upstream system to the final report generation. Detection nodes are key checkpoints within the preset processing path, used to monitor the data processing status at different levels. Sub-data processing results are the processing results of the test data after processing at each detection node, which may include the data status and content of that detection node.

[0053] For example, in order to test each detection node in the data processing flow, it is first necessary to determine the preset processing path of the test data in the reporting system, that is, the entire data link from the upstream data source (such as host file or external data interface) to the report presentation. For example, upstream file → ODS layer → DW layer deposit subject table → DM layer customer deposit table → report. In this link, the test data needs to undergo dozens of processing operations such as cleaning, transformation, association, and aggregation to form a complete value chain from raw data to business report.

[0054] Furthermore, by setting detection nodes at key locations along the preset processing path, the system captures the processing status of test data at each node in real time, including field mapping, data transformation, table joins, and filtering conditions, generating a series of sub-data processing results. These results are combined to form the second data processing result, which reflects the state of the data at different stages along the preset path. For example, during the transformation of test data from the ODS layer to the DW layer, the system should correctly apply field mapping rules and data cleaning logic.

[0055] It should be noted that when setting up detection nodes, lightweight lineage collection probes can be deployed at each detection node in the data processing flow, including upstream system exit, ODS layer entry / exit, DW layer entry / exit, DM layer entry / exit, and report generation entry. The probes are deployed non-intrusively, do not affect the performance of the business system, and can also collect the data processing results of each detection node.

[0056] It should be noted that the preset processing path can be generated through the following process:

[0057] To construct a pre-defined lineage graph (i.e., a pre-defined processing path) at the field and rule levels, providing a basis for subsequent consistency comparisons, the following steps are taken: First, using a metadata collection tool, the configuration file of the target report corresponding to the test data and the report design model of the query script are read to extract the core indicators (such as deposit balance and loan default rate), dimension fields (such as customer type and statistical period), calculation logic (such as SUM, AVG, etc.), and data source paths of the report. Simultaneously, the job scheduling configuration file (such as job number.xml) is parsed to extract the upstream file information recorded in the configuration file (file name, whether it is required, and the corresponding ODS table name).

[0058] Based on this, starting from the target report, we trace back to the ODS layer and the upstream file layer, parsing the ETL job scripts, stored procedures, and view definitions between each layer, and extracting the data processing rules for each layer, including field mapping relationships (such as the acct_bal field in the upstream file src_cust.bin corresponding to the ods_acct_bal field in the ODS layer) and data transformation rules (such as ods_acct_bal). Convert 100 to cents), table join conditions (such as a.cust_id=b.cust_id), and filter conditions (such as wheredel_flag=0).

[0059] Based on the analysis results, a three-level pre-defined lineage relationship graph is constructed: the first-level graph represents the mapping relationship between report and DM layer table fields (e.g., the "Personal Deposit Balance" indicator in the report corresponds to the total_bal field of the DM layer dm_cust_deposit table); the second-level graph represents the mapping and calculation relationship between DM layer table fields and DW layer table fields (e.g., total_bal=sum(dw_acct_bal.bal_amount)); and the third-level graph represents the mapping and conversion relationship between DW layer table fields and ODS layer and upstream file layer fields.

[0060] For example: bal_amount=ods_acct_bal.ori_bal-ods_acct_bal.freeze_bal);

[0061] The preset lineage graph (i.e., the preset processing path) constructed through the above process can be: Report "Personal Deposit Balance" → dm_cust_deposit.total_bal → sum(dw_acct_deposit.bal_amount) → ods_acct_bal.ori_bal - ods_acct_bal.freeze_bal → core_acct.ori_bal / freeze_bal.

[0062] The constructed preset bloodline relationship map is stored in the bloodline database, and a bloodline relationship topology map is generated. The processing rules and field attributes of each node are marked. When obtaining the preset processing path, the corresponding preset processing path can be directly queried in the bloodline database according to the report corresponding to the test data. If there is no existing preset processing path, the processing path can be generated through the above process, thereby completing the acquisition operation of the preset processing path.

[0063] Step S204: Obtain the second standard data processing results of each detection node in the preset processing path, obtain the second standard data processing result set, and determine the second test result of the test data based on the second standard data processing result set and the second data processing results.

[0064] It should be noted that the second standard data processing result is the result of each detection node when the data processing operation is correctly executed. The second data processing result is an overview of the intermediate processing status obtained by integrating the sub-data processing results of all detection nodes. The second test result is the conclusion of the data consistency test obtained by comparing the second data processing result with the set of second standard data processing results.

[0065] Exemplarily, after obtaining the second data processing result, the second standard data processing result of each key detection point can be obtained, and the second standard data processing results of all detection nodes can be collected to form a set of second standard data processing results, and then it is compared with the actually obtained second data processing result one by one to obtain the second test result, that is, the conclusion of the data consistency test.

[0066] Step S205, determine the target test result of the report system to be tested according to the first test result and the second test result.

[0067] Exemplarily, after obtaining the first test result and the second test result, the first test result and the second test result can be comprehensively analyzed, and based on this, the target test result of the report system is determined. If both indicate that there are no major deviations in data processing, it can be considered that the report system runs stably and outputs accurately; otherwise, any problem in any link directly affects the final test evaluation. Through this comprehensive evaluation, the health status of the report system can be comprehensively understood, not only limited to the final result output, but also including the entire process of data processing. For example, even if the final report output looks correct, but if a field mapping error is found at a certain detection node, it indicates that there is an abnormality in the data processing flow, resulting in an abnormal final test result, and the cause of the abnormality can be quickly located according to the data test result of the detection node, thereby improving the execution efficiency of the entire test process of anomaly discovery - anomaly location - anomaly handling.

[0068] The reporting system testing method provided in this application embodiment involves receiving test data sent by the upstream system of the reporting system under test, inputting the test data into the reporting system under test, and obtaining a first data processing result; obtaining a first standard data processing result of the test data, and comparing the first data processing result with the first standard data processing result to obtain a first test result; obtaining a preset processing path of the test data in the reporting system under test, and obtaining the sub-data processing results of each detection node of the test data in the preset processing path to obtain a second data processing result; obtaining the second standard data processing results of each detection node of the test data in the preset processing path to obtain a set of second standard data processing results, and determining a second test result of the test data based on the set of second standard data processing results and the second data processing result; and determining a second test result of the test data based on the first... The method of determining the target test result of the reporting system under test by comparing the output results to obtain the first test result, and using probes configured at each node to collect the sub-data processing results of each detection node and detect the sub-data processing results to obtain the second test result, and then comprehensively determining the test result of the reporting system by combining the first test result and the second test result, achieves the goal of judging whether there is anomaly in the system through two detection dimensions, and when the detection results indicate that there is anomaly in the system, the location of the anomaly can be quickly located based on the detection results of each detection node. This achieves the technical effect of improving the overall testing efficiency and problem tracing efficiency of the reporting system under test, and solves the technical problem of low efficiency in testing reporting systems using black-box testing methods in related technologies.

[0069] To accurately obtain the first test result, optionally, in the testing method of the reporting system provided in this application embodiment, comparing the first data processing result with the first standard data processing result to obtain the first test result includes: obtaining the field values ​​of each field contained in the first standard data processing result to obtain N first field values, where N is a positive integer; obtaining the second field value corresponding to each first field value in the first data processing result to obtain N second field values; comparing the corresponding first field values ​​and second field values ​​to obtain N first comparison results, and determining that the first test result is without anomalies if all N first comparison results are consistent; and determining that the first test result is abnormal if at least one first comparison result is inconsistent.

[0070] It should be noted that the first data processing result refers to the actual output result generated by the reporting system after processing the test data, which includes multiple fields. The first standard data processing result is the correct output result corresponding to the test data.

[0071] For example, when determining the first test result, the output result obtained by the report system under test after processing the test data can be compared with the correct processing result that should theoretically be output. Based on the comparison result, it can be determined whether the output result of the report system under test is correct, thereby determining the first test result from the output result dimension.

[0072] First, extract the expected values ​​of all fields from the first standard data processing results, i.e., N first field values. For example, in the test of the personal deposit balance report, the first standard data processing results may include the field "cust_id" with the expected value "TEST_20241231", the field "total_bal" with the expected value "100000.00", etc., for a total of N fields and their expected values.

[0073] Furthermore, from the first data processing result, i.e., the actual output generated by the reporting system based on the test data, extract N second field values ​​corresponding to the N first field values. This process requires precise matching of field names to improve the accuracy of the comparison. Taking a personal deposit balance report as an example, the values ​​matching the "cust_id" and "total_bal" fields can be found in the first data processing result. If found, they are extracted as the second field values, i.e., "TEST_20241231" and the actually calculated "total_bal" value.

[0074] Furthermore, the values ​​of the first and second fields are compared one by one to obtain N first comparison results. The comparison includes the accuracy of the values ​​and the standardization of the format. For example, it can be checked whether the second field value of each field matches the corresponding first field value. For example, it can be checked whether the actual value of "total_bal" in the first data processing result is indeed "100000.00".

[0075] If all first comparison results show consistency, meaning all second field values ​​perfectly match their corresponding first field values, then the first test result can be determined to be without anomalies. This indicates that the reporting system can correctly process the test data and generate output that matches expectations, demonstrating that, at a macro level, the reporting function and data processing logic are correct. Conversely, if any first comparison result shows inconsistency, the first test result is marked as having an anomaly, indicating a potential problem in the reporting system's data processing, requiring further investigation.

[0076] For example, the test subject was a reporting system involving customer loan information. This system had three key fields: "cust_id" (customer ID), "loan_amount" (loan amount), and "interest_rate" (interest rate). Test data with lineage tracking was sent via the upstream system, including a loan record for customer ID "TEST_123456," with an expected loan amount of "50000.00" and an interest rate of "3.5%." In the first standard data processing result, "cust_id" was "TEST_123456," "loan_amount" was "50000.00," and "interest_rate" was "3.5%." The actual values ​​of "cust_id," "loan_amount," and "interest_rate" were also obtained from the first data processing result. After comparison, it was found that the actual "loan_amount" was incorrectly calculated as "45000.00," while the values ​​of the other fields matched the expectations. Therefore, although the comparison results for “cust_id” and “interest_rate” are consistent, the mismatch for “loan_amount” causes the first test result to be marked as an anomaly.

[0077] This embodiment achieves the technical effect of accurately determining the first test result by comparing the first data processing result and the first standard data processing result at the field level.

[0078] To accurately obtain the second test result, optionally, in the testing method of the reporting system provided in this application embodiment, determining the second test result of the test data based on the second standard data processing result set and the second data processing result includes: performing node consistency detection on the second standard data processing result set and the second data processing result to obtain a first detection result; performing content consistency detection on the second standard data processing result set and the second data processing result to obtain a second detection result; and determining the second test result based on the first detection result and the second detection result.

[0079] It should be noted that node consistency testing ensures that when test data flows along a preset processing path, the actual processing nodes encountered match the preset node list, with no omissions or redundancies. Content consistency testing checks whether the actual processing status of the test data at each testing node matches the content of the preset standard processing result, including field values, data volume, and data type. The first and second test results are the conclusions of node consistency and content consistency testing, respectively, used to determine whether the structure and function of the data processing process meet expectations.

[0080] For example, when determining the second test result, it is necessary to perform node consistency detection and content consistency detection separately, and then determine the second test result based on the combined results of the two detections.

[0081] During the node consistency detection phase, the processing node list involved in the second standard data processing result set and the second data processing result can be compared to confirm whether the test data completely matches the preset processing path during the flow. This includes comparing the number and type of nodes the data flows through to ensure they match the preset values, and identifying missing or added nodes (such as test data not flowing into the DW layer). For example, for a multi-level processing path including upstream data extraction, data cleaning, data integration, data calculation, and report generation, the system checks whether the test data was successfully extracted from the upstream system, whether it underwent the specified cleaning rules, whether corresponding data processing was performed at the preset integration and calculation nodes, and whether it ultimately reached the report generation layer correctly. This detection process can identify potentially missed nodes or extra paths during data flow, and promptly point out structural errors in the data link, such as missing links in ETL operations or unnecessary data flows.

[0082] During the content consistency detection phase, it is necessary to compare the specific data content on the detection nodes, including comparing whether the mapping relationship of each level of fields is consistent with the preset, identifying field mapping errors (e.g., the ori_bal field is incorrectly mapped to the freeze_bal field), the correctness of data transformation, the logical matching of aggregation calculations, and the consistency of data filtering conditions. For example, comparing whether the calculation rules and filtering conditions of each node are consistent with the preset, and identifying rule execution anomalies (e.g., the sum() function is incorrectly executed as the count() function, and the filtering condition del_flag=0 is incorrectly executed as del_flag=1).

[0083] Taking field mapping as an example, it's first necessary to confirm whether the "ori_bal" field in the upstream system is accurately mapped to "ods_acct_bal" in the ODS layer. Then, it's checked whether the conversion logic of this field in the subsequent DW and DM layers (such as multiplying by 100 to convert to cent units) is executed according to the preset rules. Furthermore, it's necessary to detect details such as changes in data volume, field value changes, and data type conversions to ensure that data is neither lost nor incorrectly modified throughout the entire processing chain. The purpose of content consistency detection is to verify the correctness of the data processing logic, improve the accuracy of data at each processing node, and promptly identify and locate problems caused by incorrect field mapping, inaccurate data conversion, or deviations in calculation rules.

[0084] Finally, the second test result can be obtained by combining the first test result of the node consistency test phase and the second test result of the content consistency test phase.

[0085] For example, in testing a reporting system involving personal account balances, four testing nodes were set up according to the system's preset processing path: upstream system data extraction, data cleaning, data aggregation, and report rendering. The second standard data processing result set includes the following expectations: the account balance field "balance" in the upstream system should be mapped to "ori_balance" in the ODS layer, and then converted to "total_balance" in the DM layer (i.e., the original value multiplied by 100, converted to cents). Simultaneously, it is expected that data cleaning should remove all abnormal balance values ​​less than 0, and data aggregation should correctly summarize the total balance of each account, including current and time deposits.

[0086] In the node consistency check, the system confirmed that the test data successfully passed through all preset nodes, and no abnormal paths or missing nodes were found. The first check result was "Node path consistent". In the content consistency check, although most field mapping and conversion rules were executed correctly, during the conversion from the ODS layer to the DM layer, it was found that the "total_balance" value of some accounts was not multiplied by 100, but was directly passed, resulting in an incorrect balance unit displayed in the report. In addition, the data cleaning step did not completely remove all balance values ​​less than 0, and a small number of negative balance records were mixed in. The second check result was marked as "Field conversion inconsistent, data cleaning rules partially ineffective".

[0087] This embodiment achieves the technical effect of accurately determining the second test result by detecting the output results of each node in the test process in two dimensions: node consistency and content consistency.

[0088] Optionally, in the testing method of the reporting system provided in this application embodiment, performing node consistency detection on the second standard data processing result set and the second data processing result to obtain the first detection result includes: obtaining the standard nodes associated with the second standard data processing result set to obtain M1 standard nodes, and determining whether the M1 standard nodes are the same as the M2 detection nodes in the preset processing path, wherein M1 and M2 are both positive integers; if the M1 standard nodes are the same as the M2 detection nodes, the first detection result is determined to be that there is no abnormality in node consistency; if the M1 standard nodes are different from the M2 detection nodes, the first detection result is determined to be that there is an abnormality in node consistency.

[0089] For example, before performing node consistency testing, all preset standard nodes, denoted as M1 standard nodes, must first be extracted from the second standard data processing result set. These standard nodes encompass all key data processing steps from data extraction from the upstream system to the completion of report data preparation, such as data cleaning, field mapping, data integration, and aggregation calculation. For instance, in a test case of a personal account deposit balance report, the M1 standard nodes might include: upstream file reading, ODS layer data cleaning, DW layer data integration, DM layer aggregation calculation, and report rendering layer data preparation.

[0090] Furthermore, the M1 standard nodes are compared with the M2 detection nodes obtained during actual test execution to assess whether the actual data flow path matches expectations. Before comparison, it is necessary to first determine the detection nodes traversed during data flow and record the status of the test data at each processing layer to ensure that no unexpected jumps or omissions of important processing steps occur during data flow. For example, it is checked whether the data indeed flows from the upstream file reading node to the ODS layer data cleaning node, then sequentially through the DW layer data integration node, the DM layer aggregation calculation node, and finally arrives at the report rendering layer data preparation node.

[0091] If the M1 standard nodes and M2 detection nodes match perfectly, with no missing nodes or extra paths, then the first detection result can be determined as node consistency without anomalies. This means the data flow strictly followed the preset processing path without any deviation, verifying the integrity of the data processing structure. For example, all preset processing steps, such as data cleaning, field mapping, data integration, and aggregation calculations, were accurately performed by the test data, and the structure and sequence of the data flow were consistent with the processing flow defined in the design document.

[0092] If a mismatch is found between the M1 standard nodes and the M2 detection nodes, whether due to missing nodes, additions, or incorrect sorting, it indicates an anomaly in node consistency in the first detection result. This disrupts the structural integrity and standardization of the data processing, potentially due to reasons including, but not limited to, job scheduling errors, ETL script logic flaws, and incorrect data routing configurations. For example, if test data fails to reach the preset data integration node or lingers at a branch node where it shouldn't, it can lead to logical chaos in data processing, ultimately affecting the accuracy and reliability of the reports.

[0093] This detection method can identify structural anomalies in the data flow path, such as data unexpectedly skipping a necessary data cleaning step, or being incorrectly directed to another branch path at a certain processing node, thereby determining whether there are node consistency issues.

[0094] Taking a personal deposit balance report as an example, the M1 standard nodes in the preset processing path can include: upstream file reading, ODS layer field mapping, DW layer data cleaning, DM layer summary calculation, and report data preparation. In actual testing, the M2 detection nodes should also reflect the same path sequence. Suppose that during testing, it is discovered that test data, when flowing from the ODS layer to the DW layer, is unexpectedly imported into a non-preset temporary data integration node, causing the data cleaning step to be skipped. In this case, this event needs to be marked, the first detection result is determined to be an anomaly in node consistency, and further investigation of the data cleaning job's status and scheduling logic is needed to improve the standardization and completeness of the data processing flow.

[0095] This embodiment achieves the technical effect of accurately determining whether there are node inconsistency issues by comparing the nodes in the data processing flow.

[0096] Optionally, in the testing method of the reporting system provided in this application embodiment, the second standard data processing result set and the second data processing result are subjected to content consistency detection to obtain the second detection result, which includes: obtaining the standard nodes associated with the second standard data processing result set to obtain M1 standard nodes, and obtaining the output data of each standard node to obtain M1 standard output data; comparing the standard output data with corresponding relationships and the sub-data processing results to obtain M1 second comparison results; if all M1 second comparison results are consistent, the second detection result is determined to be content consistency without abnormality, and if any one of the second comparison results is inconsistent, the second detection result is determined to be content consistency abnormality.

[0097] For example, when performing content consistency testing, firstly, all standard nodes related to the entire preset processing path are identified from the second standard data processing result set, denoted as M1 standard nodes. These nodes cover the entire data pipeline from data extraction from the upstream system to report generation, including key steps such as data cleaning, field mapping, data integration, and calculation logic. For each standard node i (i∈[1,M1]), the associated standard output data Oi is extracted from the second standard data processing result set, that is, ideally, the test data should present the data state and processing result at node i.

[0098] For example, in the test case of a personal deposit balance report, the M1 standard nodes may include processing steps such as upstream file reading, ODS layer data cleaning, DW layer field mapping, and DM layer summary calculation. Correspondingly, the standard output data Oi reflects the expected state of the test data at node i. For example, in the ODS layer data cleaning node O1, theoretically all abnormal and null values ​​should be removed.

[0099] Furthermore, the standard output data Oi is compared with the actual sub-data processing result at the corresponding detection node i in the second data processing result, resulting in M1 second comparison results. The comparison content is not limited to numerical accuracy, but also includes field values, data volume, data type, etc., to ensure that the processing logic of the test data at each processing node conforms to the preset business logic.

[0100] For example, in the ODS layer data cleaning node O1, it checks whether all fields in the test data have been processed correctly, such as outlier removal and cleaning of the "ori_bal" field. If outliers are still found in the "ori_bal" field, or if the data cleaning rules are not executed accurately, they are marked as outliers.

[0101] Finally, after comprehensively analyzing the M1 second comparison results, if all node data comparison results show no anomalies, meaning all data states and processing results conform to the preset standards, then the second detection result is judged to have no content consistency anomalies. Conversely, if any node's comparison result shows a deviation in data state or processing logic, then the second detection result is marked as having content consistency anomalies.

[0102] For example, in the test process of a personal account deposit balance report, assume there are five key nodes (M1=5) in the preset processing path: upstream file reading, ODS layer data cleaning, DW layer field mapping, DM layer summary calculation, and report data preparation. Ideally, after the test data passes through the ODS layer data cleaning node (standard node O2), all outliers and null values ​​should be removed, improving the cleanliness of the "ori_bal" field. In actual execution, the sub-data processing results at node O2 were collected and compared with the standard output data O2. The results show that all data has been correctly cleaned, with no outliers remaining, and the data volume and type match the preset. Therefore, the second comparison result of node O2 is consistent, confirming that this part of the processing is correct.

[0103] However, when performing the same comparison at the DM layer summary calculation node (standard node O4), it was found that the summary calculation result of the "total_bal" field deviated from the preset calculation rules. That is, the actual summary calculation logic did not fully follow the preset standard, resulting in the value of the "total_bal" field being slightly lower than expected. In this case, the second comparison result of node O4 is inconsistent, which determines that the second detection result is an anomaly in content consistency, clearly indicating that there is a defect in the DM layer summary calculation logic, requiring further debugging and correction.

[0104] This embodiment achieves the technical effect of accurately determining content consistency by checking the matching degree between the actual state of the data at each key processing node and the preset standard.

[0105] Optionally, in the testing method for the reporting system provided in this application embodiment, determining the target test result of the reporting system to be tested based on the first test result and the second test result includes: if both the first test result and the second test result indicate no abnormality, determining the target test result as having no abnormality; if the first test result and / or the second test result indicate an abnormality, determining the target test result as having an abnormality.

[0106] For example, after obtaining the first and second test results, the system first checks whether both results show no anomalies. That is, the reporting system under test must not only be able to generate report outputs that are completely consistent with the preset standards, but also ensure that the data status and processing logic at each step of the data processing process are as expected. Only when both test results indicate that the system functions normally and no errors are found in data processing or report generation can the target test result be determined to be without anomalies.

[0107] Furthermore, if the first test result indicates an anomaly, it means that the output of the reporting system differs from the preset standard, potentially involving numerical inaccuracies or formatting discrepancies. If the second test result indicates an anomaly, it suggests that in one or more stages of the data processing, the data's state or logical processing is inconsistent with the preset, possibly stemming from issues in data cleaning, field mapping, data integration, or calculation logic. Once one or both of the first and / or second test results are marked as an anomaly, the target test result is determined to be anomaly. This judgment emphasizes a holistic testing perspective, ensuring that even if a single test stage appears normal, other potential problems are not overlooked, thus comprehensively guaranteeing the data quality and functional integrity of the reporting system.

[0108] Taking the test of a personal large deposit account report as an example, the test data included key fields such as "cust_id" (customer ID) and "deposit_amount" (deposit amount), as well as some special scenario data, such as duplicate account IDs and empty amounts. After the test was completed, by comparing the actual output of the reporting system with the preset ideal state, it was found that the "deposit_amount" field of all test accounts was consistent with the preset value, and the format, classification, and statistical caliber of the report also fully complied with the standard settings, with no differences or errors found. Therefore, the first test result indicates no anomalies, indicating that the report output results are consistent with expectations. Furthermore, through content consistency detection, the entire chain processing process of data from the upstream system to report generation was checked. At the data cleaning node of the ODS layer, it was found that all records with empty "deposit_amount" were correctly filtered out, and the field mapping was correct; at the data integration node of the DW layer, the association conditions were executed accurately, and there was no data loss; the calculation logic of the DM layer was also consistent with the preset, and no lineage drift occurred. Therefore, the second test result indicates no anomalies. Based on the above two test results, it can be determined that the target test result is without anomalies.

[0109] This embodiment determines the target test result by combining the first test result and the second test result, thereby achieving the technical effect of improving the accuracy of the target test result.

[0110] Optionally, in the testing method for the reporting system provided in this application embodiment, the test data is generated in the following manner: obtaining the test requirements of the reporting system to be tested, and generating edge test data according to the test requirements; adding a tracking field to the edge test data, and adding tracking codes to the extended fields of the edge test data to obtain the test data.

[0111] It should be noted that test requirements refer to a set of functions, performance indicators, and specific scenarios that the reporting system needs to verify during the testing phase, including but not limited to verifying data accuracy, testing computational logic, and measuring response speed. Edge test data refers to test datasets generated based on test requirements, targeting boundary conditions, extreme inputs, or special situations that the reporting system may encounter. The purpose is to explore and verify the system's behavior and processing capabilities under unconventional conditions. Tracking fields are one or more new fields added to the test data to identify the test nature and source of the data, facilitating the tracking of data flow and processing throughout the data processing chain. Tracking codes are codes or tags embedded in extended fields.

[0112] For example, before performing test operations, test data needs to be generated. First, the business logic and data processing flow of the reporting system need to be analyzed to clarify its testing requirements in terms of functionality, performance, and security. This includes, but is not limited to, verifying the data source, testing data cleaning rules, checking field mapping relationships, verifying the accuracy of calculation logic, and the system's ability to handle abnormal data. For instance, for a reporting system involving personal bank account balances, testing requirements might include verifying whether data can be correctly extracted from the upstream system, whether the cleaning logic has removed outliers, whether field mapping is accurate, and whether the summary calculation logic conforms to business rules.

[0113] For example, based on the preset processing path, the key data flow path corresponding to the core indicators of the report is selected (such as the path "upstream file → ODS layer → DW layer deposit theme table → DM layer customer deposit table → report" corresponding to the personal large deposit indicator), so as to determine the test requirements.

[0114] Furthermore, based on the acquired testing requirements, multi-dimensional feature test data is generated according to the field attributes and calculation rules of the critical path. This includes normal boundary values, extreme values, null values, abnormal format values ​​(such as incorrect delimiters), and values ​​for special business scenarios, aiming to comprehensively cover various data processing situations that the reporting system may encounter. For example, to verify whether the personal deposit balance reporting system can correctly handle large transactions, a deposit record with an amount up to the upper limit can be created.

[0115] Furthermore, based on the generated edge test data, it is necessary to embed tracking fields and tracking codes. That is, two tracking markers are added to the test data. The first-level marker is a unique tracking ID (e.g., cust_id='TEST_'||UUID()) embedded in the key fields of the test data to identify the main body of the test data. The second-level marker is a lineage tracking code (e.g., trace_id='TEST_20241231_001', trace_code='SOURCE_ODS_DW_DM_REPORT') embedded in the extended fields of the data (e.g., memo fields, reserved fields) to record the expected data flow path. The test data can be represented as: cust_id='TEST_20241231', ori_bal=100000.00, freeze_bal=0.00, del_flag=0. Using a data injection tool, the test data with these two levels of tags is injected into the test database of the upstream file, ensuring that the test data has the same format as the real business data and does not interfere with it.

[0116] This embodiment improves the coverage of test results by setting test data and adding identifiers to the test data, and enables probes in each node to accurately identify test data based on the identifiers, thereby improving the accuracy of test result collection.

[0117] Optionally, in the testing method of the reporting system provided in the embodiments of this application, when the target test result is abnormal, the method further includes: determining the abnormal detection node based on the first test result and the second test result, and obtaining the abnormal sub-data processing result under the abnormal detection node; obtaining the normal sub-data processing result of the previous node of the abnormal detection node from the preset processing path, and determining the cause of the abnormality based on the normal sub-data processing result and the abnormal sub-data processing result.

[0118] For example, when the target test result is determined to be abnormal, i.e., an inconsistency is found between the first test result and / or the second test result, it is necessary to locate the anomaly detection node. When determining the anomaly point, a reverse tracing analysis is performed based on the processing path used when the test data is actually executed: first, starting from the node with the difference in the report result, the actual processing path is traversed in reverse to locate the last normal flow node of the difference data, and the node preceding the last normal flow node is determined as the anomaly detection node, and the abnormal sub-data processing result of the anomaly detection node is obtained.

[0119] Furthermore, it is necessary to obtain the normal sub-data processing results of the node preceding the anomaly detection node. Based on the execution of data processing rules between the normal and abnormal sub-data processing results, the defect type can be determined: if test data disappears during inter-node flow, it is determined to be a data filtering anomaly (e.g., test data is incorrectly filtered); if test data field values ​​change unexpectedly, it is determined to be a calculation rule anomaly (e.g., incorrect conversion formula); if field mapping relationships do not match the preset, it is determined to be a field association anomaly (e.g., incorrect Join condition); if the actual processing path lacks a certain level node, it is determined to be an ETL task execution anomaly (e.g., job scheduling error). Finally, by combining the processing rule execution information recorded by the lineage acquisition probe, the specific defect location can be pinpointed.

[0120] For example, when comparing the processing results of the DW layer (reference node) and the DM layer (anomaly detection node), it was found that the summation calculation of the "bal_amount" field was incorrectly replaced by a counting operation in the DM layer. This is the cause of the anomaly, and the calculation logic of the DM layer needs to be repaired.

[0121] It should be noted that when upstream data changes (such as file name adjustment, field addition, or field length modification), a positive impact analysis is performed based on the preset processing path: the source node where the changed field is located in the preset processing path is located; the preset processing path is traversed forward to filter out all downstream nodes that have a direct or indirect mapping relationship with the changed field, including ODS layer, DW layer, DM layer table fields and report indicators; a list of the scope of change impact is generated, specifying the affected report names, indicator names, and test case sets.

[0122] This embodiment improves testing efficiency by identifying the cause of the anomaly based on the anomaly node when encountering abnormal report data, thus quickly locating the root cause of the problem.

[0123] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0124] Example 2

[0125] This application also provides a testing apparatus for a reporting system. It should be noted that the testing apparatus for the reporting system in this application can be used to execute the testing methods for the reporting system provided in the above embodiments. The testing apparatus for the reporting system provided in this application is described below.

[0126] According to an embodiment of this application, an apparatus for implementing the testing method of the above-described reporting system is also provided. Figure 3 This is a schematic diagram of a test apparatus for a reporting system provided in Embodiment 2 of this application, as shown below. Figure 3 As shown, the device includes:

[0127] The receiving unit 31 is used to receive test data sent by the upstream system of the report system under test, and input the test data into the report system under test to obtain the first data processing result.

[0128] The comparison unit 32 is used to obtain the first standard data processing result of the test data, and compare the first data processing result with the first standard data processing result to obtain the first test result.

[0129] The first acquisition unit 33 is used to acquire the preset processing path of the test data in the report system under test, and to acquire the sub-data processing results of each detection node of the test data in the preset processing path, so as to obtain the second data processing result.

[0130] The first determining unit 34 is used to acquire the second standard data processing results of each detection node in the preset processing path of the test data, obtain the second standard data processing result set, and determine the second test result of the test data based on the second standard data processing result set and the second data processing result.

[0131] The second determining unit 35 is used to determine the target test result of the report system to be tested based on the first test result and the second test result.

[0132] The testing apparatus for the reporting system provided in this application compares the output results to obtain a first test result, and uses probes configured at each node to collect the sub-data processing results of each detection node, and detects the sub-data processing results to obtain a second test result. Then, the test result of the reporting system is determined by combining the first test result and the second test result. This achieves the goal of judging whether there is an anomaly in the system through two detection dimensions, and when the detection results indicate that there is an anomaly in the system, the location of the anomaly can be quickly located based on the detection results of each detection node. This achieves the technical effect of improving the overall testing efficiency and problem tracing efficiency of the reporting system under test, and solves the technical problem of low efficiency in testing reporting systems using black-box testing methods in related technologies.

[0133] Optionally, in the testing apparatus of the reporting system provided in this application embodiment, the comparison unit 32 includes: a first acquisition module, used to acquire the field values ​​of each field contained in the first standard data processing result, to obtain N first field values, where N is a positive integer; a second acquisition module, used to acquire the second field value corresponding to each first field value in the first data processing result, to obtain N second field values; a comparison module, used to compare the first field values ​​and second field values ​​with corresponding relationships, to obtain N first comparison results, and to determine that the first test result is without anomalies when all N first comparison results are consistent; and a first determination module, used to determine that the first test result is abnormal when at least one first comparison result is inconsistent.

[0134] Optionally, in the testing apparatus of the reporting system provided in the embodiments of this application, the first determining unit 34 includes: a first detection module, used to perform node consistency detection on the second standard data processing result set and the second data processing result to obtain a first detection result; a second detection module, used to perform content consistency detection on the second standard data processing result set and the second data processing result to obtain a second detection result; and a second determining module, used to determine a second test result based on the first detection result and the second detection result.

[0135] Optionally, in the testing device of the reporting system provided in this application embodiment, the first detection module includes: a judgment submodule, used to obtain standard nodes associated with the second standard data processing result set, obtain M1 standard nodes, and determine whether the M1 standard nodes are the same as M2 detection nodes in the preset processing path, wherein M1 and M2 are both positive integers; a first determination submodule, used to determine that the first detection result is no abnormality in node consistency when the M1 standard nodes are the same as the M2 detection nodes; and a second determination submodule, used to determine that the first detection result is abnormality in node consistency when the M1 standard nodes are different from the M2 detection nodes.

[0136] Optionally, in the testing device of the reporting system provided in this application embodiment, the second detection module includes: an acquisition submodule, used to acquire standard nodes associated with the second standard data processing result set, to obtain M1 standard nodes, and acquire the output data of each standard node, to obtain M1 standard output data; a comparison submodule, used to compare the standard output data and the sub-data processing results with corresponding relationships, to obtain M1 second comparison results; and a third determination submodule, used to determine that the second detection result is content consistency without abnormality when all M1 second comparison results are consistent, and to determine that the second detection result is content consistency abnormality when any one of the second comparison results is inconsistent.

[0137] Optionally, in the testing apparatus of the reporting system provided in the embodiments of this application, the second determining unit 35 includes: a third determining module, used to determine that the target test result is without abnormality when both the first test result and the second test result indicate no abnormality; and a fourth determining module, used to determine that the target test result has an abnormality when the first test result and / or the second test result indicate an abnormality.

[0138] Optionally, in the testing apparatus for the reporting system provided in this application embodiment, the test data is generated by the following apparatus: a second acquisition unit, used to acquire the test requirements of the reporting system to be tested, and generate edge test data according to the test requirements; and a processing unit, used to add a tracking field to the edge test data and add tracking codes to the extended field of the edge test data to obtain the test data.

[0139] Optionally, in the testing device of the reporting system provided in the embodiments of this application, when the target test result is abnormal, the device further includes: a third determining unit, used to determine the abnormal detection node based on the first test result and the second test result, and obtain the abnormal sub-data processing result under the abnormal detection node; and a fourth determining unit, used to obtain the normal sub-data processing result of the previous node of the abnormal detection node from the preset processing path, and determine the cause of the abnormality based on the normal sub-data processing result and the abnormal sub-data processing result.

[0140] It should be noted that the receiving unit 31, comparison unit 32, first acquisition unit 33, first determination unit 34, and second determination unit 35 mentioned above correspond to steps S201 to S205 in Embodiment 1. The instances and application scenarios implemented by each of the above units and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of a device and can run in the computer terminal 10 provided in Embodiment 1.

[0141] Example 3

[0142] Embodiments of this application may provide an electronic device. Figure 4 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 4 As shown, the electronic device may include: one or more ( Figure 4 (Only one is shown) processor 1002, memory 1004, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0143] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0144] Those skilled in the art will understand that Figure 4 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 4 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.

[0145] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0146] Example 4

[0147] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the testing method of the reporting system provided in Embodiment 1.

[0148] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0149] Embodiments of this application also provide a computer program product, which, when executed on a data processing device, is a program adapted to perform the steps of a test method for a reporting system.

[0150] Embodiments of this application also provide a computer-readable storage medium, which includes a stored executable program, wherein the executable program controls the device where the computer-readable storage medium is located to execute the above-described test method for the reporting system when it runs.

[0151] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0152] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

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

[0155] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0157] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A testing method for a reporting system, characterized in that, include: Receive test data sent by the upstream system of the report system under test, and input the test data into the report system under test to obtain the first data processing result; Obtain the first standard data processing result of the test data, and compare the first data processing result with the first standard data processing result to obtain the first test result; Obtain the preset processing path of the test data in the report system under test, and obtain the sub-data processing results of each detection node of the test data in the preset processing path to obtain the second data processing result; The second standard data processing results of the test data at each detection node in the preset processing path are obtained to obtain a set of second standard data processing results, and the second test result of the test data is determined based on the set of second standard data processing results and the second data processing results. The target test result of the report system to be tested is determined based on the first test result and the second test result.

2. The method according to claim 1, characterized in that, The first test result is obtained by comparing the first data processing result with the first standard data processing result, including: Obtain the field values ​​of each field contained in the first standard data processing result to obtain N first field values, where N is a positive integer; Obtain the corresponding second field value for each first field value in the first data processing result to obtain N second field values; The first field value and the second field value that have a corresponding relationship are compared to obtain N first comparison results. If all N first comparison results are consistent, the first test result is determined to be without anomaly. If at least one first comparison result shows inconsistency, the first test result is determined to be abnormal.

3. The method according to claim 1, characterized in that, The second test result of the test data determined based on the second standard data processing result set and the second data processing result includes: Perform node consistency checks on the second standard data processing result set and the second data processing result to obtain the first detection result; The second standard data processing result set and the second data processing result are subjected to content consistency detection to obtain the second detection result; The second test result is determined based on the first test result and the second test result.

4. The method according to claim 3, characterized in that, Perform node consistency checks on the second standard data processing result set and the second data processing result to obtain the first detection result, which includes: Obtain the standard nodes associated with the second standard data processing result set to get M1 standard nodes, and determine whether the M1 standard nodes are the same as the M2 detection nodes in the preset processing path, where M1 and M2 are both positive integers; If the M1 standard nodes are the same as the M2 detection nodes, the first detection result is determined to be that there is no abnormality in node consistency; If the M1 standard nodes are different from the M2 detection nodes, the first detection result is determined to be an anomaly in node consistency.

5. The method according to claim 3, characterized in that, The second standard data processing result set and the second data processing result are subjected to content consistency detection to obtain the second detection result, which includes: Obtain the standard nodes associated with the second standard data processing result set to get M1 standard nodes, and obtain the output data of each standard node to get M1 standard output data; The standard output data with corresponding relationships and the sub-data processing results are compared to obtain M1 second comparison results; If all M1 second comparison results are consistent, the second detection result is determined to be consistent with no abnormality in content. If any one of the second comparison results is inconsistent, the second detection result is determined to be inconsistent with content.

6. The method according to claim 1, characterized in that, Based on the first test result and the second test result, the target test result for the reporting system under test is determined as follows: If both the first test result and the second test result indicate no abnormality, the target test result is determined to be without abnormality. If the first test result and / or the second test result indicate an anomaly, the target test result is determined to be anomaly.

7. The method according to claim 1, characterized in that, The test data is generated in the following manner: Obtain the test requirements of the report system to be tested, and generate edge test data based on the test requirements; A tracking field is added to the edge test data, and tracking codes are added to the extended field of the edge test data to obtain the test data.

8. The method according to claim 1, characterized in that, If the target test result is abnormal, the method further includes: Based on the first test result and the second test result, an anomaly detection node is determined, and the anomaly sub-data processing result under the anomaly detection node is obtained; Obtain the normal sub-data processing result of the previous node of the anomaly detection node from the preset processing path, and determine the cause of the anomaly based on the normal sub-data processing result and the anomaly sub-data processing result.

9. A testing device for a reporting system, characterized in that, include: The receiving unit is used to receive test data sent by the upstream system of the report system under test, and input the test data into the report system under test to obtain a first data processing result; The comparison unit is used to obtain a first standard data processing result of the test data, and compare the first data processing result with the first standard data processing result to obtain a first test result; The first acquisition unit is used to acquire the preset processing path of the test data in the report system under test, and to acquire the sub-data processing results of each detection node of the test data in the preset processing path, so as to obtain the second data processing result. The first determining unit is used to acquire the second standard data processing results of each detection node of the test data in the preset processing path, obtain the second standard data processing result set, and determine the second test result of the test data based on the second standard data processing result set and the second data processing result. The second determining unit is used to determine the target test result of the report system to be tested based on the first test result and the second test result.

10. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, executes the test method of the reporting system according to any one of claims 1 to 8.

Images