Software test quality monitoring system and method based on database data comparison

Abstract

The invention provides a software test quality monitoring system and method based on database data comparison. The system comprises a case management module used for storing and managing structured test cases; the rule management module is used for configuring a data verification rule for a specific project, and the data verification rule comprises a database field comparison rule; the test quality monitoring module is used for responding to the test execution instruction and generating and storing a test execution record corresponding to the at least one structured test case; based on a test case associated with the test execution record, calling a corresponding data verification rule in the rule management module, connecting to a service database for automatic data comparison, and generating a data verification result; performing associative storage on the data verification result and the corresponding test execution record; and when the data verification result indicates that the data are inconsistent or the test coverage rate calculated according to the test execution record does not reach a threshold value, alarm information is automatically generated.

Description

Technical Field

[0001] This application mainly relates to the field of software testing technology, and in particular to a software testing quality monitoring system and method based on database data comparison. Background Technology

[0002] In the process of software iterative development, regression testing is an indispensable part of ensuring software quality. It verifies whether new code changes have introduced defects or caused existing functions to malfunction by re-executing existing test cases.

[0003] Currently, monitoring the execution of regression tests primarily relies on quality assurance (QA) personnel manually questioning testers. This approach has significant drawbacks: First, it is highly subjective and lacks objective verification. Testers may claim to have completed a full regression test, but in reality, only some core test cases were executed, making it difficult for management to effectively verify. Second, the process is opaque and lacks audit evidence. Whether testing activities actually occurred and whether the results were accurate lacks objective and traceable records. Third, coverage assessment is biased. Even if the test case design itself is incomplete, resulting in some scenarios not being covered, the aforementioned manual monitoring method cannot effectively identify this risk.

[0004] Therefore, the industry urgently needs a technical solution that can automatically and objectively monitor the regression test execution process and results, and provide a credible chain of evidence. Summary of the Invention

[0005] This invention aims to overcome the shortcomings of existing technologies and provide a software testing quality monitoring system and method based on database data comparison to solve the problems of unmonitored regression testing execution process, unreliable results, and difficulty in evaluating coverage.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a software testing quality monitoring system based on database data comparison, the system comprising: The test case management module is used to store and manage structured test cases; The rules management module is used to configure data verification rules for specific projects, including database field comparison rules; The test quality monitoring module, connected to the test case management module and the rule management module, is used to: generate and store test execution records corresponding to at least one of the structured test cases in response to test execution instructions; call the corresponding data verification rules in the rule management module based on the test cases associated with the test execution records, connect to the business database for automated data comparison, and generate data verification results; associate and store the data verification results with the corresponding test execution records; and automatically generate alarm information when the data verification results indicate data inconsistency or the test coverage calculated based on the test execution records does not reach a threshold.

[0007] Secondly, the present invention provides a software testing quality monitoring method based on database data comparison. The method includes: storing and managing structured test cases through a test case management module; configuring data verification rules for specific projects through a rule management module, the data verification rules including database field comparison rules; generating and storing test execution records corresponding to at least one of the structured test cases through a test quality monitoring module in response to a test execution instruction; calling the corresponding data verification rules in the rule management module based on the test cases associated with the test execution records, connecting to the business database for automated data comparison, and generating data verification results; associating and storing the data verification results with the corresponding test execution records; and automatically generating alarm information when the data verification results indicate data inconsistency or the test coverage calculated based on the test execution records does not reach a threshold.

[0008] Compared with the prior art, this application has the following advantages: This application presents a software test quality monitoring system and method based on database data comparison. Through a rule management module, executable data verification rules are pre-configured, and the test quality monitoring module automatically invokes these rules to perform field-level data comparisons on the business database. This transforms subjective human assertions of test results into objective, machine-executed judgments based on data consistency, fundamentally eliminating erroneous confirmations of test pass status due to human false reporting or misjudgment. The system generates test execution records bound to specific test cases and automatically associates these records with subsequent data verification results, forcibly establishing a unique correspondence between "test execution activities" and "automated verification results." This forms a complete, chronologically clear, and tamper-proof chain of evidence, greatly improving the transparency and auditability of the entire regression testing process. The system does not merely count the number of test cases executed; rather, it dynamically calculates test coverage metrics for a preset target set (such as core data fields) based on test execution records and their associated test cases. This provides deep insights into test coverage adequacy beyond the number of executions, simultaneously exposing the dual quality risks of "use case design not covering key objects" and "designed use cases not being executed". Attached Figure Description

[0009] The accompanying drawings are included to provide a further understanding of this application. They are incorporated into and constitute a part of this application. The drawings illustrate embodiments of this application and, together with this specification, serve to explain the principles of this application.

[0010] Figure 1 This is an architectural block diagram of a software testing quality monitoring system based on database data comparison according to an embodiment of this application.

[0011] Figure 2 This is a flowchart illustrating the execution process of the login and permission management module according to an embodiment of this application.

[0012] Figure 3 This is a flowchart illustrating the execution process of a project management module according to an embodiment of this application.

[0013] Figure 4 This is a flowchart illustrating the execution process of a configuration management module according to an embodiment of this application.

[0014] Figure 5 This is a flowchart illustrating the execution process of a use case management module according to an embodiment of this application.

[0015] Figure 6 This is a flowchart illustrating the execution process of a rule management module according to an embodiment of this application.

[0016] Figure 7 This is a flowchart illustrating the execution process of a test quality monitoring module according to an embodiment of this application.

[0017] Figure 8 This is a flowchart illustrating the execution process of a report management module according to an embodiment of this application.

[0018] Figure 9 This is a flowchart of a software testing quality monitoring method based on database data comparison according to an embodiment of this application. Detailed Implementation

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

[0020] Figure 1 This is an architectural block diagram of a software testing quality monitoring system based on database data comparison, according to an embodiment of this application. Figure 1 As shown, the software test quality monitoring system 100 based on database data comparison includes: login and permission management module 1, project management module 2, configuration management module 3, test case management module 4, rule management module 5, test quality monitoring module 6, and report management module 7.

[0021] The login and permission management module 1 is used for user authentication and authorization. This module provides a login interface, receives the user's entered username and password, and verifies them against pre-stored account information. The system predefines at least two user roles: administrator and test member. Users with the administrator role are authorized to access and operate all functions of the rule management module 5, configuration management module 3, and report management module 7. Users with the test member role are authorized to access the test case management module 4 and execute test tasks and view corresponding test results and reports according to their project permissions.

[0022] Figure 2 This is a flowchart illustrating the execution process of the login and permission management module according to an embodiment of this application. Figure 2 As shown, the login and permission management module supports login for both administrators and regular testers. After entering their login username and password and clicking login, the platform will automatically verify the user's identity. After logging in, administrators have the highest level of access to the platform and can perform project configuration, database configuration, rule configuration, and report management. After logging in, regular project members can participate in corresponding testing work according to their roles and permissions, and view the test results and reports related to themselves.

[0023] Project management module 2 is used to create and maintain test projects. It allows users with the administrator role to create independent configuration spaces for each test project and set at least one test coverage risk threshold for that project. Project management module 2 is also used to associate each test project with configured database connection information and assign project members with appropriate permissions. After performing test coverage analysis, test quality monitoring module 6 compares the calculated coverage metrics with the risk thresholds set for the test project and uses this comparison as one of the bases for generating alarm information.

[0024] Figure 3 This is a flowchart illustrating the execution process of a project management module according to an embodiment of this application. Figure 3 As shown, after logging into the system, testers can configure their relevant projects through the project management module. Administrators can create new projects and set test coverage risk thresholds for each project. Administrators also need to assign corresponding project members to each project and set their roles and permissions; testers can view the projects under their names.

[0025] Configuration management module 3 is primarily responsible for configuring the database information of relevant projects. It receives and stores database connection configuration information for at least one project, including database type, network address, database port, and authentication information. Through configuration management module 3, testers can easily set up a suitable database environment for each project for subsequent data comparison and monitoring. Specifically, when performing automated data comparison, the test quality monitoring module 6 retrieves the corresponding database connection configuration information stored in configuration management module 3 based on the project information to establish a connection with the business database.

[0026] Figure 4 This is a flowchart illustrating the execution process of a configuration management module according to an embodiment of this application. Figure 4 As shown, the configuration management module is primarily responsible for configuring the database information for relevant projects. In this module, testers need to provide database connection parameters, such as database type, IP address, database port, database instance, data, and password. Through the configuration management module, testers can easily set up a suitable database environment for each project to facilitate subsequent data comparison and monitoring.

[0027] The main configuration steps are as follows: Step S41: Click the database configuration field to bring up the Add Database Information page, and enter the relevant database information.

[0028] Step S42: Click on the system field, a drop-down list will pop up, select the corresponding item; Step S43: Configure the connection information for the project's associated database, including: Click the database type field to bring up a drop-down menu, then select the corresponding database type. Enter the database IP address; Enter the database port; Input a database instance; Enter the database user; Enter the database password.

[0029] Step S44: Click the link to test.

[0030] Step S45: Check if the data is entered correctly. If the data is entered incorrectly, a connection failure message will be displayed. Step S46: Click Submit. Database connection successful. The page will redirect to the database configuration homepage.

[0031] The test case management module 4 is used to store and manage structured test cases.

[0032] Optionally, the test case management module 4 includes a template import unit. The template import unit provides a standard template, receives test case files filled out by the user according to the standard template, and parses the file to generate the structured test cases, which contain association information with database fields and / or business requirements.

[0033] Figure 5 This is a flowchart illustrating the execution process of a use case management module according to an embodiment of this application. Figure 5 As shown, the test case management module allows testers to upload, delete, and maintain regression test cases. The main steps for using this function are as follows: Step S51: First, download the test case template and write regression test cases according to the template.

[0034] Step S52: Click Upload to import the regression test cases into the system.

[0035] Step S521: Determine whether the test case is written according to the template. If yes, proceed to step S522; otherwise, proceed to step S523.

[0036] Step S522: The test case format matches the template; upload successful. Step S523: The test case format is inconsistent with the template. Clicking upload will result in an error. You need to modify the test case and upload it again until there is no error message.

[0037] Step S53: Delete test cases. Click Delete to remove obsolete test cases.

[0038] Step S54: Test Case Maintenance. Click "Maintain" to modify a value of the uploaded test case.

[0039] The rule management module 5 is used to configure data verification rules for specific projects, including database field comparison rules.

[0040] Optionally, the rule management module 5 includes a rule configuration unit and a rule storage unit. The rule configuration unit provides an interactive interface for users to select database table fields and configure expected values ​​or value range rules corresponding to those fields to form the database field comparison rules (such as equality, range, and regular expression matching). The rule storage unit is used to associate and store the configured data validation rules with the corresponding projects and database table fields.

[0041] Optionally, the data validation rules may further include at least one of the following: a table creation time field rule, used to verify whether the record creation timestamp of a specified data table meets preset conditions; and a field enumeration value rule, used to verify whether the actual value of a specified field falls within a preset enumeration value set.

[0042] Figure 6 This is a flowchart illustrating the execution process of a rule management module according to an embodiment of this application. Figure 6 As shown, the rule management module allows testers to configure data comparison rules for specific projects. The rule management module includes selecting a project, selecting a database, retrieving table field information, maintaining the table creation time field, maintaining field enumeration values, configuring field rules, and maintaining field rule values. The main implementation steps of this module are as follows: Step S61: First, the tester selects the project and the database for which rules need to be configured. Then the platform retrieves the table and field information of the database under the project name.

[0043] Step S62: Testers choose whether to maintain the table creation time field as needed.

[0044] The table creation time field refers to a standard timestamp field in the database table specifically used to record the insertion time of each row of data. Knowing this field, the system can perform automated verifications based on time logic, rather than simply comparing static values. This is crucial for verifying the timeliness and sequence of data generation. For example, verifying the timeliness of "user registration information being synchronized to the analysis system." The requirement is that after user registration, their information should be synchronized to the downstream user analysis table within 10 minutes. The system can then be configured with a rule like: "For any record in the user analysis table, its creation time should not be later than the registration time of the corresponding record in the upstream user registry by more than 10 minutes."

[0045] Step S621: Maintenance required. Click to download the template and fill in the creation time field of the table that needs maintenance according to the template. Step S622: Click "Upload File," and click "Next" after the upload is successful.

[0046] Step S63: If maintenance is not required, the tester can choose whether to maintain the field enumeration value as needed.

[0047] A field enumeration value refers to a fixed set of all possible values ​​that a database field is allowed to have in terms of business logic. For example, in the "Maintain Field Enumeration Values" step, testers configure an enumeration value set for the order status field in the order table: ['Pending Payment', 'Paid', 'Shipped', 'Completed', 'Cancelled']. During data comparison or special scanning, if the status of an order is found to have changed to 'Completed' or 'Delivering' (not in the enumeration list), the system will immediately determine it as a data anomaly and issue an alert. This may mean that an illegal value was passed to the front end, there is a code logic error, or the database has been accidentally tampered with.

[0048] Step S631: Maintenance required. Click to download the template and fill in the enumerated values ​​of the fields that need to be maintained according to the template. Step S632: Click "Upload File," and click "Next" after the upload is successful.

[0049] Step S64: If no maintenance is required, the tester configures the fields and selects rules. The data validation rules mainly consist of three parts: Field rules: Click to select the field you want to configure, select the corresponding rule, and click save; For test coverage rules, select the test cases uploaded from the test case management module and click save; To set up the API scanning rules, first select the corresponding project, then select the version time and project package, click Query, and then save.

[0050] Step S65: Testers select whether to maintain field rule values ​​as needed.

[0051] The "field rule" defines a check type (such as "equal to", "between", or "regular expression match"), while the "rule value" is the specific comparison object or threshold required to perform this check. Maintaining it means translating business logic into concrete, comparable values. For example, in a scenario verifying whether a coupon has been used correctly, in the template, for a specific "spend 100, get 20 off" test coupon, the rule value for its discount is set to 20. This complete rule means "verify coupon usage records; the discount amount must equal 20 yuan." Optionally, the "rule value" can not be a fixed number, but an expression or query result. For example, "rule value" = order amount. 20%.

[0052] Step S651: Maintenance required. Click to download the template and fill in the field rule values ​​that need to be maintained according to the template. Step S652: Click "Upload File," and click "Next" after the upload is successful.

[0053] Furthermore, by uploading the fields and files to the platform through the above steps, the platform automatically parses the file content and stores the data field information into the table.

[0054] The test quality monitoring module 6 is connected to the test case management module 4 and the rule management module 5. The test quality monitoring module 6 is used to respond to test execution instructions by generating and storing test execution records corresponding to at least one of the structured test cases; based on the test cases associated with the test execution records, it calls the corresponding data verification rules in the rule management module, connects to the business database for automated data comparison, and generates data verification results; it associates and stores the data verification results with the corresponding test execution records; and it automatically generates alarm information when the data verification results indicate data inconsistency or the test coverage calculated based on the test execution records does not reach a threshold.

[0055] Figure 7 This is a flowchart illustrating the execution process of a test quality monitoring module according to an embodiment of this application. Figure 7 As shown, the test quality monitoring module is the core of the system, used to automatically monitor the execution effect of regression tests. It includes three parts: field scanning, test coverage scanning, and interface coverage scanning.

[0056] Field scanning automatically extracts actual data from the database based on the test data and comparison rules configured by the tester in the rule management module, and performs database field comparison according to the rules configured in the rule management module. If the test result is consistent with the configured data value, it means that the regression test of the field has passed; otherwise, it has failed.

[0057] After selecting the test cases uploaded to the platform from the test case management module, click "Scan" to automatically scan the test cases and compare them with the database fields.

[0058] The interface coverage scan selects the version time and the packages to be scanned, and compares them with database fields.

[0059] If any anomalies are found during data comparison, test scenario coverage scanning, or interface scanning, such as data inconsistencies or insufficient test scenario coverage, the test quality monitoring module will automatically record the relevant information and generate alarms or prompts so that administrators and testers can promptly identify and resolve the issues.

[0060] The report management module 7 is used to generate a visual test quality report based on the test execution records, associated data verification results, and test coverage metrics. The report supports drill-down to view specific test execution evidence.

[0061] Figure 8 This is a flowchart illustrating the execution process of a report management module according to an embodiment of this application. Figure 8 As shown, the report management module 7 is used for report querying and downloading. Test reports will include comparison results from the test quality monitoring module, test scenario coverage scan results, interface coverage scan results, alarms or prompts, etc., providing testers with comprehensive feedback on the test situation. Administrators can download and view test reports for all projects, and testers can view and download test reports for their specific project to comprehensively analyze and improve the effectiveness of regression testing.

[0062] To facilitate understanding of the working principle of the software testing quality monitoring system based on database data comparison in this application, the following description is provided in conjunction with several specific embodiments: Example 1: Test Coverage Verification Users enter their username and password through the system's login interface. After successful system verification, different permissions and a list of visible projects are loaded based on the user's role (administrator, project manager, tester).

[0063] After logging in, a user with the administrator role can access the project management module. They can create a new project named "E-commerce System V2.5" and set test coverage risk thresholds for it (e.g., 95% coverage of core transaction process fields). Then, they can associate the project with a pre-configured production environment database connection (from the configuration management module) and assign two testers, Zhang San and Li Si, to the project.

[0064] The project manager or senior tester accesses the rules management module. Selecting the "E-commerce System V2.5" project, the system retrieves the table structure from the project's associated database. By downloading a template, filling it out, and uploading it, they batch-configure multiple rules, such as "The order status field (status) enumeration value must be ['Pending Payment', 'Paid', 'Shipped', 'Completed', 'Cancelled']". These rules are stored in the rule base and bound to the project and specific table fields.

[0065] After logging in, tester Zhang San can only see the "E-commerce System V2.5" project. He exports a test case template from the test case management module and, when writing the test cases, fills in the associated "order status field" in the specified column of the template. After uploading the test cases, he can retrieve and execute the test cases assigned to him from the test task list provided by the platform. All his execution activities are recorded under the project.

[0066] Before the release, the coverage analysis unit of the test quality monitoring module was run. It analyzed all executed test cases under the "E-commerce System V2.5" project and found that these test cases covered 85% of the core database fields. Since this value was lower than the 95% threshold set in the project management module, the system automatically generated a high-risk alert and sent it to the project manager and administrator, indicating insufficient regression coverage and preventing the release process.

[0067] Example 2: Field Value Verification Example

[0068] Scenario: In the "Order Fulfillment System", when the logistics company reports the "delivered" status, the system business logic should automatically update the order's status field to "completed" and set the finish_time field to the current time.

[0069] Configuration phase: Testers log into the platform, enter the rules management module, and select the "Order Fulfillment System" project and its corresponding business database. In the "Configure Field Rules" section, two rules are configured for the `order` table: Rule A (Enumerated Value Matching): Select the field status, set the rule operation to "equal to", and configure the expected value to "completed".

[0070] Rule B (Time Range Matching): Select the field finish_time, set the rule operation to "between", and configure the expected value to "within 60 seconds before and after the current time".

[0071] Save these two rules as a rule set named "Verification of Order Status Update After Receipt" and associate it with the test case "TC_ORD_008: Verify Automatic Update of Order Status After Logistics Receipt".

[0072] Execution and verification phase: The tester executes test case TC_ORD_008. First, the test case is marked as started on the platform. Then, the test case is simulated in an external system, indicating the return of a signed package. After execution, the test case is marked as complete on the platform. The platform generates execution record Rec_TC_ORD_008.

[0073] Based on the relationship between the use case and the rule, the system automatically starts the verification job for Rec_TC_ORD_008. The monitoring module executes a query based on rules A and B to obtain the actual values: status='Completed', finish_time='2025-10-27 14:30:05'.

[0074] Rule A: Actual value 'Completed' equals expected value 'Completed', pass.

[0075] Rule B: The current system time is 14:30:00, and the actual value is 14:30:05. If the time is within 60 seconds before or after this time, the rule is passed.

[0076] Both rules passed, and the verification result was "successful." This result, the executed query, and the comparison timestamp were fully recorded and strongly associated with the execution record Rec_TC_ORD_008. If any rule fails (e.g., the status remains 'shipped'), the monitoring module will immediately generate a detailed alert, indicating which rule for which field was not met, and recording both the actual and expected values ​​for quick problem localization.

[0077] Example 3: Application Programming Interface Scanning and Verification

[0078] Testers should select the "User Service Center" item in the "Interface Scanning Rules" configuration section of the rules management module. They should then select the version time and corresponding application package to scan. By integrating CI / CD information or code repositories, the platform can automatically list all API interfaces under that version and package path.

[0079] Verification Phase: The monitoring module obtains the target version of the application package based on the configuration and obtains the interface list List_API through static analysis or dynamic retrieval of API documentation. The module analyzes all executed test cases within this testing cycle. For automated API test cases, the interface paths they call can be directly extracted; for manual test cases, inference and matching are performed based on keywords in the test step descriptions or their association with automated test cases. A mapping relationship is established: which interfaces are covered by which test cases.

[0080] Calculate interface coverage using the following formula: Interface coverage = (Number of interfaces covered by at least one executed use case / Total number of List_APIs) 100%.

[0081] If the coverage does not reach the project's preset threshold, the system generates an alert and lists all uncovered API interfaces. This alerts the testing team that there may be omissions in the testing of the "user status change" function, and they need to immediately add test cases or check whether the test execution was complete.

[0082] The three embodiments above elaborate on how this application achieves automated, objective, and in-depth software testing quality monitoring from four key dimensions: field value correctness, data sequence compliance, test coverage adequacy, and interface coverage completeness. These embodiments together constitute a comprehensive, evidence-driven quality assurance system.

[0083] The software testing quality monitoring system based on database data comparison proposed in this application has the following beneficial effects: (1) Achieve objective verification and eliminate false reports: Through automated database field-level comparison, the subjective "test passed" assertion is transformed into an objective "data consistency" judgment, which fundamentally eliminates human false reporting.

[0084] (2) Constructing a credible chain of evidence: The system forcibly associates “test execution activities” with “automatic verification results” to form a complete and tamper-proof chain of evidence that “who, when, what was executed, and what data results were produced”, which greatly enhances the auditability of the testing process.

[0085] (3) Provide dynamic and multi-dimensional coverage insights: not only count the number of use cases executed, but also analyze the coverage of executed use cases to core data entities and code, and promptly identify the dual risks of "incomplete use case design" and "incomplete use case execution".

[0086] (4) Improve monitoring efficiency and timeliness: Change passive manual inquiry to active, automated continuous scanning and alarm, so that quality problems can be discovered and located earlier and faster.

[0087] This application also provides a software testing quality monitoring method based on database data comparison. For example... Figure 9 As shown, the software testing quality monitoring method 900 includes: Step S91: Store and manage structured test cases through the test case management module; Step S92: Configure data validation rules for a specific project through the rule management module. The data validation rules include database field comparison rules. Step S93: In response to the test execution command, generate and store test execution records corresponding to at least one structured test case through the test quality monitoring module; Step S94: Based on the test cases associated with the test execution records, call the corresponding data verification rules in the rule management module, connect to the business database to perform automated data comparison, and generate data verification results; Step S95: Associate and store the data verification results with the corresponding test execution records; and, Step S96: When the data verification result indicates that the data is inconsistent or the test coverage calculated based on the test execution record does not reach the threshold, an alarm message is automatically generated.

[0088] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a network device or stored on any usable medium. When the computer program product runs on at least one network device, it causes the at least one network device to perform a software testing quality monitoring method.

[0089] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a network device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the network device to execute a software testing quality monitoring method.

[0090] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously. Furthermore, other operations may be added to these processes, or one or more steps may be removed from these processes.

[0091] To make the objectives, technical solutions, and advantages of this application clearer, the application will be described in further detail below with reference to the accompanying drawings. The specific operating methods and functional descriptions in the method embodiments can also be applied to the device embodiments or system embodiments.

[0092] Furthermore, it should be noted that the use of terms such as "first" and "second" to define components is merely for the purpose of distinguishing the corresponding components. Unless otherwise stated, these terms have no special meaning and therefore should not be construed as limiting the scope of protection of this application. In addition, although the terminology used in this application is selected from commonly known and used terms, some terms mentioned in this application's specification may have been chosen by the applicant according to his or her judgment, and their detailed meanings are explained in the relevant sections of this description. Moreover, this application should be understood not only through the actual terms used, but also through the meaning implied by each term.

[0093] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

[0094] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0095] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A software testing quality monitoring system based on database data comparison, characterized in that, include: The test case management module is used to store and manage structured test cases; The rules management module is used to configure data verification rules for specific projects, including database field comparison rules; The test quality monitoring module, connected to the test case management module and the rule management module, is used to: generate and store test execution records corresponding to at least one of the structured test cases in response to test execution instructions; and, based on the test cases associated with the test execution records, call the corresponding data verification rules in the rule management module, connect to the business database for automated data comparison, and generate data verification results. The data verification results are associated and stored with the corresponding test execution records; Furthermore, when the data verification result indicates data inconsistency or the test coverage calculated based on the test execution record fails to reach a threshold, an alarm message is automatically generated.

2. The software testing quality monitoring system as described in claim 1, characterized in that, The rule management module includes: The rule configuration unit is used to provide an interactive interface for users to select database table fields and configure the expected value or value range rule corresponding to the field to form the database field comparison rule; The rule storage unit is used to associate and store the configured data validation rules with the corresponding projects and database table fields.

3. The software testing quality monitoring system as described in claim 2, characterized in that, The data validation rules also include at least one of the following: The table creation time field rule is used to verify whether the record creation timestamp of the specified data table meets the preset conditions; Field enumeration value rules are used to verify whether the actual value of a specified field falls within a preset set of enumeration values.

4. The software testing quality monitoring system as described in claim 1, characterized in that, The test quality monitoring module also includes: The coverage analysis unit is used to obtain all test execution records and their associated structured test cases within a test cycle; based on predefined mapping relationships, it determines the set of target objects covered by the structured test cases, the target objects including database fields and / or application interfaces; and based on the set of target objects, it calculates the test coverage metric.

5. The software testing quality monitoring system as described in claim 1, characterized in that, The use case management module includes: The template import unit is used to provide a standard template, receive a test case file filled in by the user according to the standard template, and parse the file to generate the structured test cases. The structured test cases contain association information with database fields and / or business requirements.

6. The software testing quality monitoring system as described in claim 1, characterized in that, Also includes: The report management module is used to generate a visual test quality report based on the test execution records, associated data verification results, and test coverage metrics. The report supports drill-down to view specific test execution evidence.

7. The software testing quality monitoring system as described in claim 1, characterized in that, Also includes: The configuration management module is communicatively connected to the test quality monitoring module. The configuration management module is used to receive and store database connection configuration information for at least one project. The database connection configuration information includes database type, network address, port and authentication information. When performing automated data comparison, the test quality monitoring module calls the corresponding database connection configuration information stored in the configuration management module according to the project to establish a connection with the business database.

8. The software testing quality monitoring system as described in claim 1, characterized in that, Also includes: The login and permission management module is used for user authentication and authorization; The login and permission management module provides a login interface, receives the user's entered account and password, and verifies them with the pre-stored account information; The system predefines at least two user roles: administrator role and test member role; Users with the administrator role are authorized to access and operate all the functions of the rule management module, configuration management module, and report management module. Users with the aforementioned test member role are authorized to access the test case management module and execute test tasks and view corresponding test results and reports according to their project permissions.

9. The software testing quality monitoring system as described in claim 8, characterized in that, Also includes: The project management module is used to create and maintain test projects; The project management module allows users with the administrator role to create an independent configuration space for each test project and set at least one test coverage risk threshold for that project. The project management module is also used to associate the configured database connection information with each test project and assign project members with corresponding permissions; After performing test coverage analysis, the test quality monitoring module compares the calculated coverage index with the risk threshold set for the test project, and uses this as one of the bases for generating alarm information.

10. A software testing quality monitoring method based on database data comparison, characterized in that, Applied to the system as described in any one of claims 1-9, the method comprises: Structured test cases are stored and managed through the test case management module; The rule management module allows you to configure data validation rules for specific projects, including database field comparison rules. In response to the test execution command, the test quality monitoring module generates and stores test execution records corresponding to at least one of the structured test cases; Based on the test cases associated with the test execution records, the corresponding data verification rules in the rule management module are invoked, and the business database is connected to perform automated data comparison to generate data verification results. The data verification results are associated and stored with the corresponding test execution records; and... When the data verification result indicates data inconsistency or the test coverage calculated based on the test execution record fails to reach the threshold, an alarm message is automatically generated.

Images