Quality certification methods, apparatus, equipment, media and procedures for products

Abstract

This specification discloses a quality exit method, apparatus, device, medium, and program product, which can improve the efficiency and reliability of quality exit in non-code configuration change scenarios. The method includes: in response to detecting a configuration change event, acquiring change metadata of the configuration change event; the change metadata includes change type and change parameters; based on the change metadata and pre-built data assets, determining at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource; the at least one service resource includes a service interface and / or a service application; generating test work orders for each service resource according to the at least one service scenario associated with each service resource, and performing regression testing on each service resource based on the test work orders; and determining the exit judgment result of the configuration change event based on the regression test results of each service resource.

Description

Technical Field

[0001] This specification relates to the field of data processing technology, and in particular to a quality approval method, apparatus, equipment, medium, and program product. Background Technology

[0002] As software system architecture evolves towards low-code and configurable architectures, the way system behavior is changed has shifted from code deployment to dynamic adjustment of configuration parameters. In low-code configurable platforms, critical configurations such as rule configurations, process configurations, and parameter configurations can be changed in real time through a configuration center without redeploying the underlying code. However, such configuration changes are frequent and widespread; if they are deployed without effective quality control, it can lead to risks such as asset loss and system failures.

[0003] Currently, quality exit methods for software systems primarily focus on code change scenarios, identifying regression testing scope through code difference analysis and static dependency scanning. However, for non-code configuration changes, there is a lack of automated impact analysis mechanisms to confirm the regression testing scope. After completing non-code configuration changes, quality personnel often rely solely on manual experience to infer the services that the change might affect and conduct regression testing accordingly to obtain exit results. This quality exit approach is inefficient and unreliable, necessitating a more efficient and reliable method for non-code configuration change scenarios. Summary of the Invention

[0004] This specification provides a quality check method, apparatus, device, medium, and program product that can improve the efficiency and reliability of quality check in non-code configuration change scenarios.

[0005] Firstly, embodiments of this specification provide a quality check method, including: In response to a configuration change event, obtain the change metadata of the configuration change event; the change metadata includes the change type and change parameters; Based on the change metadata and pre-built data assets, identify at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource; the at least one service resource includes a service interface and / or a service application. Test tickets for each service resource are generated based on at least one service scenario associated with each service resource, and regression tests are performed on each service resource based on the test tickets for each service resource. Based on the regression test results of each service resource, determine the exit criteria for configuration change events.

[0006] In one possible implementation, the data assets include a service dependency library and a scenario dependency library. The service dependency library is used to store the calling dependencies between various service resources, and the scenario dependency library is used to store the consumption resources and consumption fields associated with each service scenario. Based on change metadata and pre-built data assets, identify at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource, including: When the change type indicates that the configuration change event is a field structure change, determine at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource based on the change parameters, service dependency library, and scenario dependency library. When the change type indicates that the configuration change event is a field value change, at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource are determined based on the change parameters and the scenario dependency library.

[0007] In one possible implementation, at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource are determined based on the change parameters, service dependency library, and scenario dependency library, including: Based on the changed parameters, determine the changed fields and at least one first service resource to which the changed fields belong; In the service dependency library, query at least one second service resource that has a call dependency relationship with each first service resource; Match at least one first service resource and at least one second service resource with the consumption resources in the scenario dependency library, and determine at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource based on the matching results.

[0008] In one possible implementation, the service dependency library is represented in the form of a service dependency graph, which includes multiple service resource nodes and call relationship edges connecting each service resource node. The call relationship edges are used to represent the call dependency relationship between two service resource nodes. In the service dependency library, query at least one second service resource that has a call dependency relationship with each first service resource, including: In the service dependency graph, identify the nodes of each first service resource corresponding to each first service resource; Starting with the first service resource node, the service dependency graph is traversed along the direction of the call relationship edge and the opposite direction of the call relationship edge to obtain each second service resource node that has a call dependency relationship with the first service resource node. The service resources corresponding to each second service resource node are determined to be second service resources that have a calling dependency relationship with the corresponding first service resource.

[0009] In one possible implementation, at least one service resource associated with a configuration change event and at least one service scenario associated with each service resource are determined based on the change parameters and the scenario dependency library, including: The fields to be changed are determined based on the changed parameters; Match the changed fields with the consumption fields in the scenario dependency library to determine at least one service scenario where the consumption fields match the changed fields; Based on the consumption resources associated with each service scenario in the scenario dependency library, determine at least one service resource associated with the configuration change event; For any given service resource, the service scenarios that are related to any given service resource are identified as at least one service scenario associated with that service resource.

[0010] In one possible implementation, test tickets for each service resource are generated based on at least one service scenario associated with each service resource, and regression tests are performed on each service resource based on the test tickets, including: Based on at least one service scenario associated with each service resource, generate a test case set corresponding to each service scenario for each service resource; Based on the test case sets corresponding to each service scenario, generate test work orders for each service resource; Regression tests are performed in parallel on each service resource based on the test work orders for each service resource.

[0011] In one possible implementation, the exit criteria for configuration change events are determined based on the regression test results of each service resource, including: If all service resources pass the regression test, the exit decision for the configuration change event is determined to be exit. If the regression test result for any service resource fails, the exit decision for the configuration change event is determined to be non-exit.

[0012] In one possible implementation, the service dependency library is constructed in the following way: Obtain the interface definition information and call log information of each service resource; The external interfaces declared by each service resource are determined based on the interface definition information; Determine the call relationships between various service resources based on the call log information; A service dependency graph is generated based on the external interfaces declared by each service resource and the calling relationships between the service resources. The service dependency graph includes multiple service resource nodes and calling relationship edges connecting each service resource node. The calling relationship edges are used to represent the calling dependency relationship between two service resource nodes. Store the service dependency graph as a service dependency library.

[0013] In one possible implementation, the scenario dependency library is constructed in the following way: Obtain scenario definition information for multiple service scenarios; scenario definition information is used to characterize the service meaning of each service scenario; Obtain call chain data corresponding to each service scenario; the call chain data includes at least one service resource called by each service scenario during execution and the data fields used by each service resource; Based on the call chain data collected for each service scenario, the consumption resources and consumption fields associated with each service scenario are determined. A scenario dependency mapping table is generated based on each service scenario and the associated consumption resources and consumption fields. Store the scene dependency mapping table as a scene dependency library.

[0014] Secondly, embodiments of this specification provide a quality check device, comprising: The change capture module is used to respond to configuration change events by obtaining the change metadata of the configuration change event; the change metadata includes the change type and change parameters; The impact analysis module is used to determine, based on change metadata and pre-built data assets, at least one service resource associated with a configuration change event and at least one service scenario associated with each service resource; the at least one service resource includes a service interface and / or a service application. The merged regression module is used to generate test work orders for each service resource based on at least one service scenario associated with each service resource, and to perform regression tests on each service resource based on the test work orders of each service resource. The dynamic admission module is used to determine the admission decision for configuration change events based on the regression test results of each service resource.

[0015] Thirdly, embodiments of this specification provide an electronic device, including: a processor and a memory; the memory stores a computer program, and the processor executes the computer program to implement the method steps provided in the first aspect of embodiments of this specification.

[0016] Fourthly, embodiments of this specification provide a computer storage medium storing multiple instructions adapted for loading by a processor and executing the method steps provided in the first aspect of embodiments of this specification.

[0017] Fifthly, embodiments of this specification provide a computer program product, including a computer program; when the computer program is executed by a processor, it implements the method steps provided in the first aspect of embodiments of this specification.

[0018] The aforementioned quality exit method, apparatus, electronic device, computer storage medium, and computer program product automatically capture the change content in response to a configuration change event, automatically identify the scope of the change's impact based on the change content, automatically schedule regression tests based on the scope of the change's impact, and automatically complete the quality exit decision based on the regression test results. This eliminates the need for manual analysis of the scope of the change's impact and judgment of whether the exit conditions are met, thereby improving the overall efficiency and reliability of quality exit in non-code-based configuration change scenarios. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this specification, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic diagram illustrating an application scenario of a quality check method provided in an exemplary embodiment of this specification; Figure 2 A schematic diagram illustrating the application environment of a quality approval method provided as an exemplary embodiment of this specification; Figure 3 A flowchart illustrating a quality check method provided for an exemplary embodiment of this specification; Figure 4 A schematic flowchart of another quality clearance method provided for an exemplary embodiment of this specification; Figure 5 A flowchart illustrating yet another quality approval method provided as an exemplary embodiment of this specification; Figure 6 A schematic flowchart illustrating another quality approval method provided as an exemplary embodiment of this specification; Figure 7 A schematic diagram of a quality check device provided for an exemplary embodiment of this specification; Figure 8 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this specification. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this specification clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this specification.

[0022] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of these terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0023] First, combine Figure 1 This specification describes the application scenarios applicable to the embodiments of this document: A certain business system integrates with a configuration center to dynamically change and manage key configurations such as rule configurations, process configurations, routing configurations, and parameter configurations. For example, developers can add a permission level field to the data structure of the information query interface through the configuration center, and add an enumeration value of "manual review" to the risk control decision field, which previously only had "pass" and "reject" values. To ensure that the above configuration changes meet expectations after official launch and do not cause system malfunctions, impact analysis and quality verification are required before the changes are released. This is to accurately identify the scope of business functions that the changes may affect and to predict potential risks after launch.

[0024] Please see Figure 1 The quality admission process provided in the embodiments of this specification can be divided into: change capture stage, impact analysis stage, merge regression stage, and dynamic admission stage. The specific implementation process of each stage is as follows: During the change capture phase, the quality exit system responds to the configuration change event detected by the configuration center by obtaining the change metadata of the configuration change event. This change metadata includes the change type and change parameters. The change type indicates whether the change event is a field structure change or a field value change, and the change parameters include the changed field identifier information and / or the change information of the changed field.

[0025] During the impact analysis phase, the quality admission system employs different impact analysis paths based on the change type in the change metadata. Specifically, if the change type indicates a configuration change event of a field structure change (such as adding a field to the information query interface), the quality admission system first determines the changed field and the service resource to which the changed field belongs based on the change parameters; then it traces the upstream caller and downstream dependent of the service resource to which the changed field belongs to obtain the service resources that may be affected by the change; finally, it matches the service resources that may be affected by the change with the consumption resources in the scenario dependency library to determine the actual affected service resources and their corresponding service scenarios. If the change type indicates a configuration change event of a field value change (such as adding an enumeration value to a risk control decision field), the quality admission system first determines the changed field based on the change parameters, matches the changed field with the consumption fields in the scenario dependency library to determine the service scenarios that consume the changed field, and then determines the actual affected service resources based on the service scenarios.

[0026] During the regression testing phase, the quality admission system first creates a test ticket for each affected service resource. Each test ticket includes the service scenario to be regressed, the corresponding test case set for each service scenario, and the execution result of the ticket. Then, the quality admission system schedules the execution of all test tickets in parallel, assigning each test ticket to its corresponding execution node to perform regression testing on the affected service resources. After completing the regression test, each execution node sends its execution result back to the quality admission system, which then updates the execution result of each test ticket accordingly. The execution result of each test ticket represents the regression test result of the service resource corresponding to that test ticket.

[0027] During the dynamic admission phase, the quality admission system determines the admission decision for configuration change events based on the regression test results of each service resource. If all service resources pass the regression test, the quality admission system sends an admission command to the configuration center to allow the configuration center to execute configuration distribution; if any service resource fails the regression test, the quality admission system sends a blocking command to the configuration center to prevent the configuration center from executing configuration distribution.

[0028] The aforementioned quality exit process achieves timely awareness of configuration changes by automatically acquiring change metadata and triggering the quality exit process in response to configuration change events during the change capture phase. During the impact analysis phase, based on change metadata and pre-built data assets, it automatically determines the service resources associated with the configuration change event and the service scenarios associated with each service resource, improving the comprehensiveness and accuracy of the configuration change impact analysis. During the merging and regression phase, it improves the efficiency and coverage accuracy of multi-service resource regression testing by creating test tickets for affected service resources and scheduling their execution uniformly. Finally, during the dynamic exit phase, it determines the exit decision for the configuration change event based on the regression test results of each service resource, thereby automatically exiting or blocking configuration changes and implementing dynamic quality gatekeeping based on regression verification results, improving the reliability of quality exit.

[0029] Throughout the entire quality exit process, once the quality exit system detects a configuration change event, it automatically captures the change content, automatically identifies the scope of the change's impact based on the change content, automatically schedules regression tests based on the scope of the change's impact, and automatically completes the quality exit decision based on the regression test results. This eliminates the need for manual analysis of the scope of the change's impact and judgment of whether the exit conditions are met, thereby improving the overall efficiency and reliability of quality exit in non-code configuration change scenarios.

[0030] The quality clearance method provided in the embodiments of this specification can be applied to, for example, Figure 2 The application environment is shown below. Configuration terminal 10 is a device used by users (such as developers or operations personnel) to submit configuration change operations, and it communicates with configuration center 20 via a communication network. Configuration center 20 is used to manage versions of various business configurations and push configuration content to business systems. It communicates with quality exit system 30, which is used to implement change quality assurance, via a communication network. Data storage system 40 can store pre-built data assets, such as service dependency libraries and scenario dependency libraries. Data storage system 40 can be integrated into quality exit system 30 or deployed independently on cloud servers or other network storage systems.

[0031] In some possible embodiments, in response to a configuration change operation, configuration terminal 10 sends a configuration change request carrying change metadata to configuration center 20 to trigger configuration center 20 to generate a configuration change event. Quality exit system 30, in response to detecting a configuration change event from configuration center 20, obtains the change metadata of the configuration change event, which includes change type and change parameters; based on the change metadata and pre-built data assets, it determines at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource; the at least one service resource includes a service interface and / or a service application; based on the at least one service scenario associated with each service resource, it generates test work orders for each service resource; based on the test work orders for each service resource, it performs regression testing on each service resource, and determines the exit judgment result of the configuration change event based on the regression test results of each service resource. If the exit determination result is "exit", the quality exit system 30 sends an exit instruction to the configuration center 20 to allow the configuration center 20 to execute configuration distribution; if the exit determination result is "disallow", the quality exit system 30 sends a blocking instruction to the configuration center 20 to prevent the configuration center from executing configuration distribution.

[0032] Understandably, the configuration terminal 10 can be a single terminal or a cluster of multiple terminals. The configuration terminal 10 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, etc. Both the configuration center 20 and the quality exit system 30 can be implemented using independent servers or server clusters composed of multiple servers. The data storage system 40 can include multiple storage partitions, such as storage partitions for storing service dependency libraries, storage partitions for storing scenario dependency libraries, etc.

[0033] In one embodiment, such as Figure 3 As shown, a quality clearance method is provided, which is applied to... Figure 2 The following steps are used as an example to illustrate the application environment shown: S302: In response to a configuration change event, retrieve the change metadata of the configuration change event.

[0034] The configuration change event is an event object generated by the configuration center in response to a configuration change request submitted by the configuration terminal. It triggers the quality verification process of the quality exit system. Change metadata describes the attribute information of the configuration change event, including the change type and change parameters. Specifically, the change type indicates the category of the configuration change event; it can be a field structure change or a field value change. A field structure change refers to a change at the configuration data structure level, such as adding a field to the data structure of a service interface. A field value change refers to a change in the value range of an existing field, such as adding an enumeration value to a field. Change parameters describe the specific changes made to the configuration change event, including the changed field identifier information and / or the change information of the changed field.

[0035] Optionally, the quality exit system can establish a communication connection with the configuration center in advance. After generating a configuration change event, the configuration center pushes the event to a message queue or sends it to the quality exit system via an HTTP callback. The quality exit system receives the configuration change event in real time by subscribing to a specified topic in the message queue or listening to the HTTP callback interface. After receiving the configuration change event, the quality exit system needs to obtain the corresponding change metadata. The specific method of obtaining this metadata can be flexibly selected according to the actual deployment architecture. For example, the configuration center can generate the change metadata along with the configuration change event and include it in the configuration change event. The quality exit system can then directly parse the change metadata from the received configuration change event. Alternatively, the configuration change event can only carry an event identifier. After receiving the configuration change event, the quality exit system can proactively initiate a query request to the configuration center based on the event identifier to obtain the corresponding change metadata.

[0036] In this embodiment, once the quality checkout system detects a configuration change event, it automatically captures the changed content and triggers the subsequent quality checkout process. This enables timely detection of non-code-based configuration changes, improves the response efficiency of configuration changes, and allows time for subsequent regression testing and problem fixing. This enhances the efficiency and reliability of quality checkout in non-code-based configuration change scenarios.

[0037] S304: Based on change metadata and pre-built data assets, determine at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource.

[0038] In this context, service resources refer to resource objects within a software system that provide specific business capabilities; these can be service interfaces or service applications. A service interface is a network access endpoint (such as an HTTP interface or RPC interface) exposed by a service application, while a service application is an independently deployed and running process or group of processes. A service scenario refers to an execution path formed by one or more service resources collaboratively executing according to preset execution logic under specific service conditions to achieve a particular service objective. The same service function corresponds to different service scenarios under different service conditions. For example, in the authorization and approval function, the system will execute different approval paths based on the user's risk level, thus forming different authorization and approval scenarios such as low-risk user authorization and approval scenarios and high-risk user authorization and approval scenarios.

[0039] Data assets are pre-built, structured collections of data used to support impact analysis. Data assets include service dependency libraries and scenario dependency libraries. The service dependency library stores the call dependencies between various service resources, while the scenario dependency library stores the consumed resources and consumed fields associated with each service scenario. It's worth noting that consumed resources refer to the service resources invoked by a service scenario during its historical execution, and consumed fields refer to the data fields used by a service scenario during its historical execution. In other words, consumed resources and consumed fields can be determined based on the historical consumption records of a service scenario.

[0040] Optionally, the quality exit system employs different impact analysis paths based on the change type in the change metadata. Specifically, if the change type indicates a field structure change (such as adding a field to a service interface), it means that this configuration change event involves changes at the data structure level. To ensure the comprehensiveness of the impact analysis, the quality exit system first determines the changed field and the service resource to which the changed field belongs based on the change parameters; then, based on the service dependency library, it traces the upstream caller and downstream dependent of the service resource to obtain the service resources that may be affected by the change; finally, it matches the service resources that may be affected by the change with the consumption resources in the scenario dependency library to determine the actual affected service resources and their corresponding service scenarios. If the change type indicates a field value change (such as adding an enumeration value to a field in a service interface), since the changed field already has historical consumption records in the scenario dependency library, the quality exit system first determines the changed field based on the change parameters, matches the changed field with the consumption fields in the scenario dependency library to determine the service scenario that consumed the changed field, and then, based on the consumption resources associated with the service scenario in the scenario dependency library, it reverses the process to determine the actual affected service resources.

[0041] In this embodiment, the quality exit system automatically identifies the service resources associated with configuration changes and their corresponding service scenarios based on pre-built data assets, transforming the determination of the scope of impact from manual experience judgment to data-driven automated analysis. This effectively improves the comprehensiveness and accuracy of impact analysis, thereby enhancing the reliability of quality exit in non-code-based configuration change scenarios.

[0042] S306: Generate test work orders for each service resource based on at least one service scenario associated with each service resource, and perform regression tests on each service resource based on each test work order.

[0043] A test work order is a task execution unit created by the quality exit system for each affected service resource, used to organize and schedule regression tests for that service resource. Each test work order includes, but is not limited to, the service scenario to be regressed, the corresponding test case set, the work order identifier, the work order execution status, and the work order execution result. Specifically, the test case set corresponding to any service scenario includes one or more automated test cases corresponding to that service scenario; these test cases are pre-configured and stored in the test case library. The work order identifier can be generated based on the corresponding service resource identifier, allowing for quick location of the corresponding service resource. The work order execution status characterizes the current lifecycle stage of the test work order, such as pending execution, in execution, completed execution, or terminated due to failure. The work order execution result records the business judgment conclusion of the regression test after the work order execution is completed, such as pass or fail. The work order execution result of each test work order characterizes the regression test result for the service resource corresponding to that test work order.

[0044] When generating a test ticket, the quality checkout system first searches for test cases associated with each service scenario from the test case library based on at least one service scenario associated with each service resource; then it generates a test case set corresponding to each service scenario based on the test cases associated with each service scenario; next, it writes each service scenario associated with the service resource and the test case set corresponding to each service scenario into the test ticket, and at the same time generates a ticket identifier based on the service resource identifier and initializes the ticket execution status to pending execution, so as to create a test ticket for each affected service resource.

[0045] After generating each test ticket, the quality admission system performs regression tests on the service resources affected by the configuration changes based on each test ticket. Optionally, the quality admission system can schedule multiple test tickets in parallel to improve regression testing efficiency. For example, the quality admission system can assign each test ticket to a corresponding execution node, and each execution node will perform regression tests on the corresponding service resources according to the test case set in the test ticket. Here, an execution node refers to the computing resources, container instances, or process instances used to execute regression testing tasks. For example, an execution node can be a worker node of an automated testing platform, a Pod instance in a Kubernetes cluster, or an independent test execution service process. After completing the regression tests, each execution node sends its execution status and results back to the quality admission system, which then updates the execution status and results of each test ticket accordingly.

[0046] It should be understood that throughout the entire lifecycle of each test ticket, the execution status of each test ticket will be continuously updated as the regression test progresses. For example, when a test ticket is scheduled for execution, the execution status can be updated from pending to executing; when the test cases of a test ticket are completed, the execution status can be updated from executing to execution completed or terminated due to failure.

[0047] After each test order is completed, the execution result is automatically determined based on the regression test results of all test cases in that test order. For example, if all test cases corresponding to a test order pass the execution, that is, if the execution results of each node are all passed, then the execution result of that test order is "passed"; if any test case corresponding to a test order fails the execution, then the execution result of that test order is "failed".

[0048] In this embodiment, the quality exit system generates test work orders for each service resource based on at least one service scenario associated with each service resource, and performs regression testing on each service resource based on each test work order. This allows the scope of regression testing to be automatically determined by the actual impact of the change, effectively improving the efficiency and coverage accuracy of regression testing, and thus improving the efficiency and reliability of quality exit in non-code configuration change scenarios.

[0049] S308: Determine the admission / exit decision of configuration change events based on the regression test results of each service resource.

[0050] The regression test results for each service resource are determined based on the execution results of the corresponding test work orders. The exit determination result is used to characterize whether the configuration change event has passed quality verification, and the exit determination result includes two states: exit and non-exit.

[0051] Optionally, the quality exit system determines the regression test results of the corresponding service resources based on the work order execution results of each test work order; then, based on the regression test results of each service resource, it determines the exit judgment result of the configuration change event.

[0052] Specifically, if a test work order passes, the quality exit system determines that the regression test result for the corresponding service resource is also passed. If a test work order fails, the quality exit system determines that the regression test result for the corresponding service resource is also failed. If all service resources pass the regression test, the quality exit system determines the configuration change event's exit decision as approved and can send an exit instruction to the configuration center to allow the configuration center to execute configuration distribution. If any service resource fails the regression test, the quality exit system determines the configuration change event's exit decision as disapprovable and can send a blocking instruction to the configuration center to prevent the configuration center from executing configuration distribution.

[0053] Understandably, when the exit decision is negative, the quality exit system can also trigger an alarm to notify the user that the configuration change failed quality verification. The alarm content includes, but is not limited to, the identifier of the configuration change event, the service resource information that failed the regression test, and the reason for the failure. Furthermore, after the quality exit system sends a blocking command to the configuration center, the configuration change is blocked from being published; once the relevant issues are resolved, the user can re-trigger the quality exit process to allow the quality exit system to re-perform impact analysis and quality verification.

[0054] In this embodiment, the quality exit system determines the exit judgment result of the configuration change event based on the regression test results of each service resource, so that the quality exit decision is driven by the actual test results of each relevant service resource, which effectively improves the efficiency and reliability of quality exit in non-code configuration change scenarios.

[0055] By adopting the above quality exit method, the quality exit system can automatically capture the change content as soon as it detects a configuration change event, automatically identify the scope of the change based on the change content, automatically schedule regression tests based on the scope of the change, and automatically complete the quality exit decision based on the regression test results. There is no need for manual judgment of the test scope and exit conditions, thereby improving the efficiency and reliability of quality exit in non-code configuration change scenarios.

[0056] In one embodiment, such as Figure 4 As shown, another quality clearance method is provided, which can be applied to... Figure 2 The following steps are used as an example to illustrate the application environment shown: S402: In response to a configuration change event, obtain the change metadata of the configuration change event; the change metadata includes the change type and change parameters.

[0057] The change type indicates the category of the configuration change event. The change type can be either a field structure change or a field value change. A field structure change refers to a change at the configuration data structure level, including adding, deleting, or modifying field types. A field value change refers to a change in the value range of an existing field, including adding, deleting, or modifying field values.

[0058] Change parameters describe the specific changes made during a configuration change event. These parameters may include the identifier information of the changed field and / or the change information of the changed field. The identifier information of the changed field includes, but is not limited to, the field name, field number, and field path of the changed field. The change information of the changed field includes, but is not limited to, changes in the field's value (e.g., the field value before and after the change), changes in the field's type (e.g., the field type before and after the change), and changes in the field's structure (e.g., the field hierarchy before and after the change).

[0059] For details, please refer to S302; further details will not be provided here.

[0060] S404: When the change type indicates that the configuration change event is a field structure change, determine at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource based on the change parameters, service dependency library, and scenario dependency library.

[0061] The service dependency library stores the call dependencies between various service resources. It can be built based on communication data generated during the operation of each service resource. This communication data includes, but is not limited to, RPC (Remote Procedure Call) logs and message queue records. After determining the service resource to which a changed field belongs, the quality admission system can trace the upstream callers and downstream dependencies of that service resource based on the service dependency library.

[0062] The scenario dependency library stores the mapping relationships between service scenarios and consumed resources, as well as between service scenarios and consumed fields. The scenario dependency library can be built based on the actual execution data of each service scenario during its historical execution. Based on the scenario dependency library, the quality admission system can reverse-engineer related service scenarios based on changed fields or service resources.

[0063] Understandably, if the change type indicates a field structure change event, it means that this configuration change event involves changes at the data structure level. In this case, to ensure the comprehensiveness of the impact analysis, the quality exit system first determines the target service resources directly associated with the change based on the change parameters. Then, based on the call dependencies in the service dependency library, it traces the upstream callers and downstream dependencies of the target service resources to determine all service resources that may be affected by the change. Finally, it matches each service resource with the consumer resources in the scenario dependency library to determine all service scenarios that are actually affected.

[0064] In one possible implementation, determining at least one service resource associated with a configuration change event and at least one service scenario associated with each service resource based on change parameters, a service dependency library, and a scenario dependency library includes: determining a change field and at least one first service resource to which the change field belongs based on the change parameters; querying at least one second service resource in the service dependency library that has a call dependency relationship with each first service resource; matching at least one first service resource and at least one second service resource with consumer resources in the scenario dependency library; and determining at least one service resource associated with a configuration change event and at least one service scenario associated with each service resource based on the matching results.

[0065] Optionally, the quality exit system extracts the field paths of the changed fields from the changed parameters, determines the service resource directly to which the changed field belongs based on the extracted field paths, and designates it as the first service resource. Then, for each first service resource, it queries the service dependency library for service resources with call dependencies on that first service resource, i.e., the upstream caller and downstream dependent of the first service resource, and designates them as the second service resource. Understandably, the first and second service resources together constitute a set of candidate service resources that may be affected by the change. Next, the quality exit system matches each service resource in the candidate service resource set with the consumer resources associated with each service scenario in the scenario dependency library. If any service resource in the candidate service resource set successfully matches with the consumer resource of any service scenario, then that service resource is determined as the service resource associated with the configuration change event, and that service scenario is determined as the service scenario associated with that service resource.

[0066] This implementation method allows for the identification of all service resources affected by field structure changes, starting with the changed field and then tracing upstream and downstream callers through the service dependency library. This comprehensively identifies all service resources that may be affected by the change, effectively avoiding the omission of indirectly dependent service resources and improving the comprehensiveness and accuracy of impact analysis.

[0067] In one possible implementation, the service dependency library is represented in the form of a service dependency graph, which includes multiple service resource nodes and call relationship edges connecting each service resource node. The call relationship edges are used to represent the call dependency relationship between two service resource nodes. The process of querying the service dependency library for at least one second service resource that has a call dependency relationship with each first service resource includes: determining each first service resource node corresponding to each first service resource in the service dependency graph; traversing the service dependency graph along the direction and the opposite direction of the call relationship edges, starting from the first service resource node, to obtain each second service resource node that has a call dependency relationship with the first service resource node; and determining the service resource corresponding to each second service resource node as the second service resource that has a call dependency relationship with the corresponding first service resource.

[0068] In this context, the direction of the call relationship edge is from the caller to the callee, and the opposite direction of the call relationship edge is from the callee to the caller.

[0069] Optionally, the quality checkout system first locates the node corresponding to the first service resource in the service dependency graph based on the identifier of the first service resource, using it as the starting node. Then, starting from the starting node, it traverses along the direction of the call relationship edges to obtain each service node on the downstream call chain of the first service resource, that is, each downstream service node directly or indirectly called by the first service resource. At the same time, it traverses along the reverse direction of the call relationship edges to obtain each service node on the upstream call chain of the first service resource, that is, each upstream service node directly or indirectly called by the first service resource. Finally, the service resources corresponding to the traversed upstream and downstream service nodes are determined as the second service resources that have a call dependency relationship with the first service resource.

[0070] In the above implementation, the service dependency library represents the call dependency relationship between service resources in the form of a service dependency relationship graph. The quality checkout system can systematically trace the upstream caller and downstream dependent of the first service resource by bidirectionally traversing along the call relationship edge starting from the first service resource node. This extends the impact of changes from the directly attributable service resource to all service resources with call dependency relationships, effectively avoiding the omission of indirectly dependent service resources and improving the comprehensiveness and accuracy of impact analysis in the scenario of field structure changes.

[0071] S406: When the change type indicates that the configuration change event is a field value change, determine at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource based on the change parameters and the scenario dependency library.

[0072] Among them, field value changes refer to changes in the value range of an existing field, such as adding an enumeration value to a field. The scenario dependency library is used to store the consumption resources and consumption fields associated with each service scenario; consumption resources refer to the service resources called by the service scenario during historical execution, and consumption fields refer to the data fields used by the service scenario during historical execution.

[0073] Understandably, if the change type indicates that the configuration change event is a field value change, it means that this configuration change event only involves changes at the data value level. In this case, since the changed field already has historical consumption records in the scenario dependency library, the changed field can be directly matched with the consumed fields in the scenario dependency library to identify all service scenarios that have consumed the changed field. Then, based on the service resources pre-associated with each service scenario in the scenario dependency library, the actual affected service resources can be determined in reverse.

[0074] In one possible implementation, determining at least one service resource associated with a configuration change event and at least one service scenario associated with each service resource based on change parameters and a scenario dependency library includes: determining a change field based on change parameters; cross-matching the change field with consumption fields in the scenario dependency library to determine at least one service scenario where the consumption field matches the change field; determining at least one service resource associated with a configuration change event based on the consumption resources associated with each service scenario in the scenario dependency library; and for any service resource, determining the service scenarios in each service scenario that have a relationship with any service resource as at least one service scenario associated with that service resource.

[0075] Optionally, the quality exit system extracts the change field identifier from the change parameters; then, it matches the change field identifier with the consumption field identifier of each service scenario stored in the scenario dependency library, and determines at least one service scenario whose consumption field identifier matches the change field identifier as at least one service scenario associated with the configuration change event; next, it determines the consumption resources pre-associated with each service scenario in the scenario dependency library as at least one service resource associated with the configuration change event; finally, for each determined service resource, it determines the service scenario that has a relationship with the service resource among the at least one service scenario associated with the configuration change event as at least one service scenario associated with the service resource.

[0076] In this implementation, changes in field values ​​can be made using historical consumption records stored in the scenario dependency library. By matching the changed field with the consumption field, all service scenarios that consumed the changed field can be directly located. Then, the association between each service scenario and the consumption resource in the scenario dependency library can be used to reverse look up the service resources associated with the configuration change event. There is no need to first determine the service resource to which the changed field belongs and trace its upstream and downstream callers, thereby improving the efficiency and accuracy of impact analysis.

[0077] S408: Based on at least one service scenario associated with each service resource, generate a test case set corresponding to each service scenario for each service resource.

[0078] A test case set refers to a collection of one or more automated test cases associated with the same service scenario. Each test case is used to verify the functional correctness of the service scenario under specific input conditions. These test cases are pre-configured and stored in a test case library, and each test case is associated with one or more service scenarios.

[0079] Optionally, the quality exit system searches for test cases associated with each service scenario from the test case library based on at least one service scenario associated with each service resource. Then, it aggregates the found test cases by service scenario to generate a test case set corresponding to each service scenario. It should be understood that if a service scenario has multiple test cases associated with it in the test case library, these test cases together constitute the test case set for that service scenario.

[0080] S410: Generate test work orders for each service resource based on the test case sets corresponding to each service scenario.

[0081] A test work order is a task execution unit created by the quality exit system for each affected service resource, used to organize and schedule regression tests for that service resource. Each test work order includes, but is not limited to, at least one service scenario to be regressed, a set of test cases for each service scenario, a work order identifier, a work order execution status, and a work order execution result. The work order identifier can be generated based on the corresponding service resource identifier, allowing for quick location of the corresponding service resource. For example, the work order identifier can contain the service resource identifier. The work order execution status characterizes the current lifecycle stage of the test work order, such as pending execution, in execution, completed execution, or terminated due to failure. The work order execution result records the business judgment conclusion of the regression test after the work order is completed, such as pass or fail. The work order execution result of each test work order characterizes the regression test result for the service resource corresponding to that test work order.

[0082] Optionally, when generating a test work order, the quality exit system first searches for test cases associated with each service scenario from the test case library based on at least one service scenario associated with each service resource; then, it generates a test case set corresponding to each service scenario based on the test cases associated with each service scenario; next, it writes each service scenario associated with the service resource and the test case set corresponding to each service scenario into the test work order, and at the same time generates a work order identifier based on the service resource identifier and sets the work order execution status to pending execution, so as to create a test work order for each affected service resource.

[0083] S412: Regression tests are performed in parallel on each service resource based on the test work orders for each service resource.

[0084] Optionally, the quality exit system includes a scheduling module and multiple execution nodes for performing regression tests. The scheduling module is responsible for generating and distributing test orders; each execution node receives test orders and executes regression tests. After generating each test order, the scheduling module schedules the execution of all test orders in parallel, assigning each test order to its corresponding execution node. Each execution node then performs regression tests on the corresponding service resources based on the test cases in the test order. After completing the regression tests, each execution node sends its execution status and results back to the scheduling module, which then updates the execution status and results of each test order accordingly.

[0085] It's worth noting that an execution node can correspond to one test ticket or multiple test tickets. When multiple test tickets are assigned to the same execution node, that node can execute the test case sets in each test ticket in parallel to ensure the efficiency of regression testing. To avoid confusion between the execution status and results of different test tickets, each execution node, during the execution of its corresponding test ticket, can send back the execution status carrying the ticket identifier to the scheduling module at preset time intervals. The scheduling module then updates the execution status of the corresponding test ticket based on this ticket identifier. After each execution node completes its corresponding regression test, it sends back the execution result carrying the ticket identifier to the scheduling module, which then updates the execution result of the corresponding test ticket based on this ticket identifier.

[0086] In this embodiment, the quality exit system collects test case sets according to service scenarios and creates test work orders accordingly, ensuring that regression testing accurately covers the service scenarios actually affected by changes. In addition, the quality exit system schedules test work orders of various service resources to execution nodes in parallel for concurrent execution, enabling regression tasks of multiple service resources to be completed efficiently and collaboratively. This improves the execution efficiency of regression testing while ensuring the completeness of regression test coverage.

[0087] S414: Determine whether the regression test results for each service resource are all passed. If yes, proceed to S416; otherwise, proceed to S418.

[0088] Understandably, since each test work order is a task execution unit created by the quality exit system for each affected service resource, the execution result of each test work order is used to characterize the regression test result of the service resource corresponding to that test work order.

[0089] Optionally, the quality exit system obtains the execution results of each test work order, determines the regression test results of the corresponding service resources based on the execution results of each test work order, and then determines whether the regression test results of all service resources are passed based on the regression test results of each service resource. If the regression test results of all service resources are passed, the quality exit system determines that the exit judgment result of the configuration change event is exit; if the regression test result of any service resource is failed, the quality exit system determines that the exit judgment result of the configuration change event is not exit.

[0090] S416: Determine the exit decision result for the configuration change event as exit.

[0091] Optionally, if the regression test results of all service resources are passed, the quality exit system determines the exit judgment result of the configuration change event as exit and sends an exit instruction to the configuration center to allow the configuration center to execute the configuration distribution.

[0092] S418: Determine that the exit decision result for the configuration change event is non-exit.

[0093] Optionally, if the regression test result of any service resource fails, the quality exit system determines that the exit judgment result of the configuration change event is not to exit, and sends a blocking command to the configuration center to prevent the configuration center from executing the configuration distribution.

[0094] Understandably, when the exit decision is negative, the quality exit system can also trigger an alarm to notify the user that the configuration change failed quality verification. The alarm content includes, but is not limited to, the identifier of the configuration change event, the service resource information that failed the regression test, and the reason for the failure. Furthermore, after the quality exit system sends a blocking command to the configuration center, the configuration change is blocked from being published; once the relevant issues are resolved, the user can re-trigger the quality exit process to allow the quality exit system to re-perform impact analysis and quality verification.

[0095] In this embodiment, the quality exit system determines the regression test results of each service resource based on the execution results of each test work order. Configuration is only allowed to be issued when all actually affected service resources pass the regression test. This makes the quality exit decision driven by the actual execution results of the regression test, ensuring that high-risk configuration change events that fail the regression test can be intercepted in a timely manner, thereby improving the objectivity and reliability of quality exit.

[0096] By adopting the above-mentioned quality admission method, the quality admission system can be driven by configuration change events, execute differentiated impact analysis strategies according to the change type, accurately locate the service resources and service scenarios actually affected by the change, and automatically generate test work orders, schedule regression tests in parallel, and automatically complete admission decisions based on the regression test results. This realizes a fully automated process from configuration change perception, change impact analysis, merging regression tests to dynamic admission determination, effectively improving the efficiency and reliability of quality admission in non-code configuration change scenarios.

[0097] In one embodiment, such as Figure 5 As shown, another quality admission method is provided, in which the construction of the service dependency library includes the following steps: S502: Obtain the interface definition information and call log information of each service resource.

[0098] Interface definition information refers to the metadata describing the external interfaces declared by a service resource, which is used to determine the set of interfaces exposed by each service resource. Interface definition information includes, but is not limited to, interface name, interface path, request parameter structure, response parameter structure, and interface version. Interface definition information can be obtained from the service registry, API gateway, or service interface description file.

[0099] Call log information refers to log data that records the actual call behavior between various service resources, and is used to determine the actual call relationship between them. Call log information includes, but is not limited to, the calling service resource identifier, the called service resource identifier, the call time, the called interface name, the call duration, and the call status. Call log information can be obtained from service monitoring systems, distributed tracing systems, or the service logs of each service node.

[0100] Optionally, the quality exit system can interact with the API gateway according to a first preset collection period to obtain the interface definition information of each service resource; and interact with the service monitoring system according to a second preset collection period to obtain the call log information of each service resource. The first and second preset collection periods can be set according to actual needs, such as hourly, daily, or weekly; the first and second preset collection periods can be the same or different. Each time call log information is obtained, call records within a first preset time window (e.g., the last 7 days) can be retrieved to ensure that the call log information fully covers the actual call relationships between each service resource.

[0101] S504: Determine the external interfaces declared by each service resource based on the interface definition information.

[0102] The external interfaces declared by each service resource refer to the network access endpoints exposed by the service resource to the outside world that can be invoked by other services. When a service resource is a service interface, its declared external interface is the interface itself; when a service resource is a service application, its declared external interfaces are the set of all service interfaces contained in that service application. The external interfaces declared by each service resource are used as attribute information for each service resource node when constructing the service dependency graph later.

[0103] Optionally, the quality exit system extracts the external interface information declared by each service resource from the obtained interface definition information, including interface name, interface path, request parameter structure, and response parameter structure, and uses this information as the attribute information of each service resource for subsequent construction of the service dependency graph. For service resources of service application type, the quality exit system aggregates the interface definition information of all service interfaces under that application into the interface definition information of the service application.

[0104] In the embodiments of this specification, the external interfaces declared by each service resource are determined based on interface definition information rather than on call log information. This is because the call log may record that service resource A called a certain interface, but if that interface is not declared in the interface definition information of service resource B, then the call relationship may be incorrect, outdated, or using a deprecated interface. By determining the external interfaces declared by each service resource based on interface definition information, invalid call records can be filtered out, improving the accuracy of the service dependency graph.

[0105] S506: Determine the call relationships between various service resources based on the call log information.

[0106] The invocation relationship between service resources refers to the association between one service resource and another during the execution of the service resource. The invocation relationship is directional; for example, if service resource A calls service resource B, then there is a invocation relationship between service resource A and service resource B, with the direction being from service resource A to service resource B. The invocation relationships between service resources are used to construct the invocation relationship edges in the subsequent service dependency graph.

[0107] Optionally, the quality exit system parses the obtained call log information, extracts the calling service resource identifier and the called service resource identifier from each call record; then it performs statistics and aggregation on the parsing results to determine the call relationship and call frequency between each service resource.

[0108] Specifically, the quality exit system extracts the calling service resource identifier field, the called service resource identifier field, and the calling interface field from the call log information. Then, it performs grouping and statistics based on the calling service resource identifier and the called service resource identifier to obtain a list of call relationships between various service resources. For call relationships with extremely low call frequency, such as those called only once, the quality exit system can filter them out to avoid occasional calls interfering with the accuracy of the service dependency graph.

[0109] S508: Generate a service dependency graph based on the external interfaces declared by each service resource and the calling relationships between each service resource.

[0110] The service dependency graph is a knowledge graph that represents the call dependencies between service resources in the form of a graph data structure. The service dependency graph includes multiple service resource nodes and call relationship edges connecting these nodes. Call relationship edges represent the call dependencies between two service resource nodes. Each service resource node corresponds one-to-one with a specific service resource, and the direction of the edge is from the caller to the callee.

[0111] Optionally, the quality exit system treats each service resource as a service resource node and the external interfaces declared by each service resource as the attribute information of the service resource node; then, based on the calling relationship between each service resource, it adds calling relationship edges between the corresponding service resource nodes to generate a service dependency graph.

[0112] Specifically, the quality exit system first creates service resource nodes that correspond one-to-one with each service resource, and uses the identifiers of each service resource (such as service resource name and service resource code) and its declared list of external interfaces as node attributes; then it traverses the list of call relationships between each service resource, and for each call relationship, adds a directed call relationship edge between the callee service resource node and the caller service resource node, with the edge pointing from the caller to the callee; finally, the above processing yields a complete service dependency graph.

[0113] S510: Store the service dependency graph as a service dependency library.

[0114] Optionally, the quality admission system stores the generated service dependency graph in the form of a graph database or a relational database, resulting in a service dependency library. Graph databases better support traversal and query operations on the graph, such as querying the upstream callers or downstream dependencies of a service resource; while relational databases better support structured queries and statistical aggregation operations. The specific storage format can be flexibly selected based on actual needs.

[0115] Once the service dependency library is built, the quality exit system can understandably obtain the call dependency relationships between various service resources by querying the service dependency library during the subsequent impact analysis of configuration change events, so as to trace the upstream caller and downstream dependent of the service resource to which the changed field belongs.

[0116] In this embodiment, the quality admission system determines the declared external interfaces of each service resource and the actual call relationships between them based on the interface definition information and call log information of each service resource. It then generates a service dependency graph, ensuring the efficiency and accuracy of the graph's construction. Since the declaration information of the external interfaces is used to determine the attributes of each service resource node in the service dependency graph, and the call relationships are used to determine the call relationship edges between nodes, the combination of these two elements allows the service dependency graph to fully represent the call dependencies between each service resource. This provides data asset support for subsequent impact analysis, thereby helping to improve the efficiency and reliability of the entire quality admission process.

[0117] In one embodiment, such as Figure 6 As shown, another quality admission method is provided, in which the construction of the scenario dependency library includes the following steps: S602: Obtain scenario definition information for multiple service scenarios.

[0118] The scenario definition information for each service scenario within the multiple service scenarios is used to characterize the service meaning of each scenario. This scenario definition information can be obtained from the service scenario management platform or service process configuration file. Scenario definition information includes, but is not limited to, scenario identifier, scenario description, and the service domain to which the scenario belongs. The scenario identifier is used to uniquely identify each service scenario in subsequent steps and serves as the scenario dimension in the scenario dependency mapping table.

[0119] Optionally, the quality exit system can obtain the scenario definition information of each of the pre-configured service scenarios by calling the interface of the service scenario management platform; or, the quality exit system can also extract the scenario definition information of each of the service scenarios by parsing the service process configuration file.

[0120] S604: Obtain call chain data corresponding to each service scenario.

[0121] Call chain data collection refers to the data collected that records the service call chain and data consumption when each service scenario is triggered during actual operation. Each call chain record in the call chain data collection includes the corresponding service scenario identifier, the identifier of at least one service resource called sequentially during the execution of the corresponding service scenario, the call order between the service resources, and the identifiers of the data fields used by each service resource during execution. Call chain data collection can be obtained from the call chain tracing system, the service monitoring system, or the service logs of each service node.

[0122] Optionally, the quality exit system can interact with the link tracing system according to a third preset collection cycle to obtain call link collection data for each service scenario within a second preset time window. The second preset time window can be set according to actual needs, such as the most recent 24 hours, the most recent 7 days, or the most recent 30 days, to ensure that the call link collection data can fully cover the typical execution paths of each service scenario.

[0123] S606: Based on the call chain data collected for each service scenario, determine the consumption resources and consumption fields associated with each service scenario.

[0124] Among them, the consumption resources associated with each service scenario are the service resources invoked by each service scenario during its historical execution; the consumption fields associated with each service scenario are the data fields used by each service scenario during its historical execution. The relationship between consumption resources and service scenarios, and the relationship between consumption fields and service scenarios, are all determined based on the call chain data collected for each service scenario.

[0125] Optionally, the quality exit system parses the acquired call chain data. For each call chain record, it extracts the service scenario identifier corresponding to the record, the service resource identifier called by the service scenario, and the data field identifier passed by the service scenario during the call. Then, it groups and aggregates the data based on the service scenario identifier to determine the consumption resources and consumption fields associated with each service scenario.

[0126] Specifically, the quality exit system extracts the service scenario identifier, the called service resource identifier, and the data identifier contained in the request and response parameters from the data collected in the call chain. Then, it performs deduplication on the extraction results. For the same service scenario, if the same service resource is called or the same data field is used in multiple executions, only one related record is retained. Finally, the deduplicated related records are grouped according to the service scenario identifier to obtain the consumption resources and consumption fields associated with each service scenario.

[0127] S608: Generate a scenario dependency mapping table based on each service scenario and the associated consumption resources and consumption fields.

[0128] The scenario dependency mapping table is a data structure that stores the mapping relationships between service scenarios and consumer resources, and between service scenarios and consumer fields, in tabular form. Each scenario dependency record in the scenario dependency mapping table represents the association between a service scenario and a consumer resource, or between a service scenario and a consumer field.

[0129] Optionally, for each service scenario, the quality admission system establishes mapping entries between the service scenario and each consumer resource, as well as mapping entries between the service scenario and each consumer field, forming a scenario dependency mapping table.

[0130] Specifically, the quality admission system first creates an empty mapping table. Then, for each service scenario, it combines the scenario identifier of the service scenario with the resource identifier of each associated consumer resource to generate a scenario-consumer resource mapping record, which is added to the mapping table. It also combines the scenario identifier of the service scenario with the field identifier of each associated consumer field to generate a scenario-consumer field mapping record, which is added to the mapping table. After traversing all service scenarios, a complete scenario dependency mapping table is obtained.

[0131] S610: Store the scene dependency mapping table as a scene dependency library.

[0132] Optionally, the quality exit system stores the generated scene dependency mapping table in the form of a relational database table, a key-value pair set, etc., to obtain a scene dependency library.

[0133] After the scenario dependency library is stored, the quality admission system can query the scenario dependency library in the subsequent impact analysis process to query all service scenarios that use (i.e. consume) the changed field, or query all service scenarios that call (i.e. consume) the service resource, thereby improving the query efficiency of the impact analysis path.

[0134] In this embodiment, the quality admission system determines the service resources (i.e., consumed resources) and data fields (i.e., consumed fields) actually invoked by each service scenario during its historical execution, based on the scenario definition information and the call chain data collected for each service scenario. It then generates a scenario dependency mapping table, ensuring the efficiency and accuracy of the scenario dependency library construction. Since the scenario definition information uniquely identifies each service scenario, and the call chain data records the service call chain and data consumption when each service scenario is triggered during actual operation, the combination of these two elements allows the scenario dependency mapping table to accurately reflect the resource and field dependencies of each service scenario during historical execution. This enables the quality admission system to directly query the service scenarios affected by configuration change events based on the changed fields in subsequent impact analysis, and then determine at least one service resource associated with the configuration change event based on the service scenario. This effectively improves the efficiency and accuracy of impact analysis, thereby contributing to the efficiency and reliability of the entire quality admission process.

[0135] To illustrate the technical solution of the quality check method in the embodiments of this specification, the following specific application example will be used to explain the entire process, which specifically includes the following steps: Phase 1: Asset Building Phase 1.1 The quality exit system obtains the interface definition information and call log information of each service resource. The service resource can be a service interface or a service application; the interface definition information includes the interface name, interface path, request parameter structure, and response parameter structure declared by each service resource; the call log information includes the calling service resource identifier, the called service resource identifier, the call time, and the calling interface name.

[0136] 1.2 The quality exit system determines the external interfaces declared by each service resource based on the interface definition information.

[0137] 1.3 The quality exit system determines the calling relationship between various service resources based on the call log information.

[0138] 1.4 The quality access system generates a service dependency graph based on the external interfaces declared by each service resource and the calling relationships between each service resource. The service dependency graph includes multiple service resource nodes and calling relationship edges connecting each service resource node. The calling relationship edges are used to represent the calling dependency relationship between two service resource nodes.

[0139] 1.5 The quality exit system stores the service dependency graph as a service dependency library.

[0140] 1.6 The quality exit system acquires scenario definition information for multiple service scenarios; the scenario definition information is used to characterize the service meaning of each service scenario.

[0141] 1.7 The quality exit system acquires call chain data corresponding to each service scenario; wherein, the call chain data includes at least one service resource called by each service scenario during execution and the data fields used by each service resource.

[0142] 1.8 The quality exit system collects data based on the call chain corresponding to each service scenario to determine the consumption resources and consumption fields associated with each service scenario.

[0143] 1.9 The quality exit system generates a scenario dependency mapping table based on each service scenario and the associated consumption resources and consumption fields.

[0144] 1.10 Store the scene dependency mapping table as a scene dependency library.

[0145] Phase Two: Change Capture Phase 2.1 Users can initiate configuration change operations for a service resource through the management interface of the configuration center. For example, users can add a dataLevel field to the response parameter structure of the information query interface to identify the security level of the data, so that downstream services can perform differentiated permission control based on this field; or, users can expand the value set of the existing dataLevel field in the response parameters of the information query interface from the original "public data, internal data" to "public data, internal data, top secret data", that is, add the enumeration value "top secret data" to this field, so that downstream services can identify more granular data security levels and perform corresponding permission control.

[0146] 2.2 The configuration center responds to configuration change operations by generating configuration change events.

[0147] 2.3 The configuration center sends the configuration change event to the quality exit system through a preset communication method (such as message queue or HTTP callback).

[0148] 2.4 The quality exit system responds to the configuration change event detected by the configuration center by obtaining the change metadata of the configuration change event; wherein, the change metadata includes change type and change parameters. The change type is used to indicate whether the change event is a field structure change or a field value change, and the change parameters include the change field identification information and / or the change information of the change field.

[0149] Phase Three: Impact Analysis Phase 3.1 The quality exit system determines the impact analysis path of the configuration change event based on the change type. If the change type indicates a field structure change (such as adding a dataLevel field to the response parameter structure of the information query interface as described above), execute steps 3.2 to 3.6 below; if the change type indicates a field value change (such as expanding the value set of the existing dataLevel field in the response parameter structure as described above), execute steps 3.7 to 3.10 below.

[0150] 3.2 The quality exit system determines the changed fields and at least one first service resource to which the changed fields belong based on the changed parameters.

[0151] 3.3 The quality access system determines the nodes of each first service resource corresponding to each first service resource in the service dependency graph.

[0152] 3.4 The quality checkout system takes the first service resource node as the starting node and traverses the service dependency graph along the direction of the call relationship edge and the opposite direction of the call relationship edge to obtain each second service resource node that has a call dependency relationship with the first service resource node.

[0153] 3.5 The quality exit system determines the service resources corresponding to each second service resource node as second service resources that have a calling dependency relationship with the corresponding first service resource.

[0154] 3.6 The quality exit system matches at least one first service resource and at least one second service resource with the consumption resources in the scenario dependency library, and determines at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource based on the matching results.

[0155] 3.7 The quality exit system determines the change fields based on the changed parameters.

[0156] 3.8 The quality exit system matches the change fields with the consumption fields in the scenario dependency library to determine at least one service scenario where the consumption fields match the change fields.

[0157] 3.9 The quality exit system determines at least one service resource associated with a configuration change event based on the consumption resources associated with each service scenario in the scenario dependency library.

[0158] 3.10. For any service resource, the quality exit system shall identify the service scenarios that are related to any service resource as at least one service scenario associated with any service resource.

[0159] Phase 4: Merging and Regression Phase 4.1 The quality exit system generates test case sets corresponding to each service resource and each service scenario based on at least one service scenario associated with each service resource.

[0160] 4.2 The quality exit system generates test orders for each service resource based on the test case sets corresponding to each service scenario; the execution result of each test order is used to characterize the regression test results of the service resource corresponding to that test order.

[0161] 4.3 The quality exit system performs regression tests on each service resource in parallel based on the test work orders of each service resource.

[0162] Phase 5: Dynamic Exit Stage 5.1 The quality exit system determines the regression test results of each service resource based on the execution results of each test work order.

[0163] 5.2 The quality exit system determines whether the regression test results of each service resource are all passed. If yes, proceed to step 5.3 below; otherwise, proceed to step 5.4 below.

[0164] 5.3 The quality exit system determines the exit decision result of the configuration change event as the exit result.

[0165] 5.4 The quality exit system determines that the exit judgment result for the configuration change event is non-exit.

[0166] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0167] Based on the inventive concept of the above-mentioned quality clearance method, such as Figure 7 As shown in the embodiments of this specification, a quality checkout apparatus 700 for implementing the quality checkout method described above is also provided. The quality checkout apparatus 700 includes: The change capture module 701 is used to obtain the change metadata of the configuration change event in response to the listening configuration change event; the change metadata includes the change type and change parameters; The impact analysis module 702 is used to determine, based on change metadata and pre-built data assets, at least one service resource associated with a configuration change event and at least one service scenario associated with each service resource; the at least one service resource includes a service interface and / or a service application. The merged regression module 703 is used to generate test work orders for each service resource based on at least one service scenario associated with each service resource, and to perform regression tests on each service resource based on the test work orders of each service resource. The dynamic admission module 704 is used to determine the admission decision for configuration change events based on the regression test results of each service resource.

[0168] In one possible implementation, the data assets include a service dependency library and a scenario dependency library. The service dependency library stores the call dependencies between various service resources, and the scenario dependency library stores the consumption resources and consumption fields associated with each service scenario. The impact analysis module 702 is specifically used to: determine at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource based on the change parameters, the service dependency library, and the scenario dependency library when the change type indicates that the configuration change event is a field value change; and determine at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource based on the change parameters and the scenario dependency library when the change type indicates that the configuration change event is a field value change.

[0169] In one possible implementation, the impact analysis module 702 is specifically used to: determine the changed field and at least one first service resource to which the changed field belongs based on the changed parameters; query at least one second service resource that has a call dependency relationship with each first service resource in the service dependency library; match at least one first service resource and at least one second service resource with the consumption resources in the scenario dependency library; and determine at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource based on the matching result.

[0170] In one possible implementation, the service dependency library is represented in the form of a service dependency graph. The service dependency graph includes multiple service resource nodes and call relationship edges connecting each service resource node. The call relationship edges are used to represent the call dependency relationship between two service resource nodes. The impact analysis module 702 is specifically used to: determine each first service resource node corresponding to each first service resource in the service dependency graph; traverse the service dependency graph along the direction of the call relationship edges and the opposite direction of the call relationship edges, starting from the first service resource node, to obtain each second service resource node that has a call dependency relationship with the first service resource node; and determine the service resource corresponding to each second service resource node as the second service resource that has a call dependency relationship with the corresponding first service resource.

[0171] In one possible implementation, the impact analysis module 702 is specifically used to: determine the changed field based on the changed parameters; match the changed field with the consumption field in the scenario dependency library to determine at least one service scenario where the consumption field matches the changed field; determine at least one service resource associated with the configuration change event based on the consumption resources associated with each service scenario in the scenario dependency library; and for any service resource, determine the service scenarios in each service scenario that have a relationship with any service resource as at least one service scenario associated with any service resource.

[0172] In one possible implementation, the merging regression module 703 is specifically used to: generate test case sets corresponding to each service scenario for each service resource based on at least one service scenario associated with each service resource; generate test work orders for each service resource based on the test case sets corresponding to each service scenario; and perform regression tests on each service resource in parallel based on the test work orders for each service resource.

[0173] In one possible implementation, the dynamic admission module 704 is specifically used to: determine the admission result of the configuration change event as admission when the regression test results of all service resources are passed; and determine the admission result of the configuration change event as non-exit when the regression test result of any service resource is failed.

[0174] In one possible implementation, the quality exit device 700 further includes an asset construction module, used for: obtaining interface definition information and call log information of each service resource; determining the external interfaces declared by each service resource based on the interface definition information; determining the call relationships between each service resource based on the call log information; generating a service dependency graph based on the external interfaces declared by each service resource and the call relationships between each service resource; the service dependency graph includes multiple service resource nodes and call relationship edges connecting each service resource node, the call relationship edges being used to characterize the call dependency relationship between two service resource nodes; and storing the service dependency graph as a service dependency library.

[0175] In one possible implementation, the asset construction module is further configured to: obtain scenario definition information for multiple service scenarios; the scenario definition information is used to characterize the service meaning of each service scenario; obtain call chain collection data corresponding to each service scenario; the call chain collection data includes at least one service resource called by each service scenario during execution and the data fields used by each service resource; determine the consumption resources and consumption fields associated with each service scenario based on the call chain collection data corresponding to each service scenario; generate a scenario dependency mapping table based on each service scenario and the consumption resources and consumption fields associated with each service scenario; and store the scenario dependency mapping table as a scenario dependency library.

[0176] Each module in the aforementioned quality approval device 700 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0177] This specification also provides an electronic device, which may be a server, and its internal structure diagram may be as follows: Figure 8As shown, this electronic device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The application database stores pre-built data assets, such as service dependency libraries and scenario dependency libraries. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. The processor executes computer programs to implement a quality admission method.

[0178] Those skilled in the art will understand that Figure 8 The structures shown are merely block diagrams of a portion of the structure related to the scheme described in this specification, and do not constitute a limitation on the electronic devices to which the scheme described in this specification is applied. Specific electronic devices may include more or fewer components than those shown in the figures, or may combine certain components, or may have different component arrangements.

[0179] In one possible implementation, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0180] This specification also provides a computer storage medium storing instructions that, when executed on a computer or processor, cause the computer or processor to perform one or more steps in the above embodiments. If the constituent modules of the above-described electronic device are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer storage medium.

[0181] In one possible implementation, a computer storage medium is provided that stores a computer program, which, when executed by a processor, implements the steps in the above method embodiments.

[0182] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0183] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0184] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks. Unless otherwise specified, the technical features of this embodiment and its implementation can be combined arbitrarily.

[0185] The embodiments described above are merely preferred embodiments of this specification and are not intended to limit the scope of this specification. Any modifications and improvements made by those skilled in the art to the technical solutions of this specification without departing from the spirit of this specification should fall within the protection scope defined by the claims.

[0186] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the features, data, and information involved in this specification were all obtained under full authorization.

[0187] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

Claims

1. A quality accreditation method, characterized in that, The method includes: In response to a detected configuration change event, the system obtains the change metadata of the configuration change event; the change metadata includes the change type and change parameters. Based on the change metadata and pre-built data assets, at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource are determined; the at least one service resource includes a service interface and / or a service application. Test work orders for each service resource are generated based on at least one service scenario associated with each service resource, and regression tests are performed on each service resource based on the test work orders for each service resource. Based on the regression test results of each of the service resources, the exit decision result of the configuration change event is determined.

2. The method as described in claim 1, characterized in that, The data assets include a service dependency library and a scenario dependency library. The service dependency library is used to store the calling dependency relationships between various service resources, and the scenario dependency library is used to store the consumption resources and consumption fields associated with each service scenario. The step of determining at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource, based on the changed metadata and pre-built data assets, includes: If the change type indicates that the configuration change event is a field structure change, at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource are determined based on the change parameters, the service dependency library, and the scenario dependency library. When the change type indicates that the configuration change event is a field value change, at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource are determined based on the change parameters and the scenario dependency library.

3. The method as described in claim 2, characterized in that, The step of determining at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource based on the change parameters, the service dependency library, and the scenario dependency library includes: Based on the change parameters, determine the change field and at least one first service resource to which the change field belongs; In the service dependency library, query at least one second service resource that has a call dependency relationship with each of the first service resources; The at least one first service resource and the at least one second service resource are matched with the consumption resources in the scenario dependency library, and based on the matching results, at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource are determined.

4. The method as described in claim 3, characterized in that, The service dependency library is represented in the form of a service dependency graph, which includes multiple service resource nodes and call relationship edges connecting each service resource node. The call relationship edges are used to represent the call dependency relationship between two service resource nodes. The step of querying the service dependency library for at least one second service resource that has a call dependency relationship with each of the first service resources includes: In the service dependency graph, each first service resource node corresponding to each first service resource is determined; Starting with the first service resource node, the service dependency graph is traversed along the direction of the call relationship edge and the opposite direction of the call relationship edge to obtain each second service resource node that has a call dependency relationship with the first service resource node. The service resources corresponding to each second service resource node are determined as second service resources that have a calling dependency relationship with the corresponding first service resource.

5. The method as described in claim 2, characterized in that, The step of determining at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource based on the change parameters and the scenario dependency library includes: The changed fields are determined based on the changed parameters; The changed field is matched with the consumption field in the scenario dependency library to determine at least one service scenario in which the consumption field matches the changed field; Based on the consumption resources associated with each service scenario in the scenario dependency library, determine at least one service resource associated with the configuration change event; For any of the service resources, the service scenarios that are associated with any of the service resources are identified as at least one service scenario associated with any of the service resources.

6. The method as described in claim 1, characterized in that, The step of generating test work orders for each service resource based on at least one service scenario associated with each service resource, and performing regression testing on each service resource based on the test work orders, includes: Based on at least one service scenario associated with each of the service resources, generate a test case set corresponding to each of the service scenarios for each of the service resources; Based on the test case sets corresponding to each of the service scenarios, generate test work orders for each of the service resources; Regression tests are performed in parallel on each of the service resources based on the test work orders for each of the service resources.

7. The method as described in claim 1, characterized in that, The step of determining the exit decision result of the configuration change event based on the regression test results of each of the service resources includes: If the regression test results of all the service resources are passed, the exit determination result of the configuration change event is determined to be exit. If the regression test result of any of the service resources fails, the exit determination result of the configuration change event is determined to be non-exit.

8. The method as described in claim 2, characterized in that, The service dependency library is constructed in the following way: Obtain the interface definition information and call log information of each of the aforementioned service resources; The external interfaces declared by each of the service resources are determined based on the interface definition information; The call relationships between the various service resources are determined based on the call log information. A service dependency graph is generated based on the external interfaces declared by each service resource and the calling relationships between the service resources. The service dependency graph includes multiple service resource nodes and calling relationship edges connecting each service resource node. The calling relationship edges are used to represent the calling dependency relationship between two service resource nodes. The service dependency graph is stored as the service dependency library.

9. The method as described in claim 2, characterized in that, The scenario dependency library is constructed in the following way: Obtain scenario definition information for multiple service scenarios; the scenario definition information is used to characterize the service meaning of each service scenario; Obtain the call chain data corresponding to each of the aforementioned service scenarios; The call chain data includes at least one service resource called during the execution of each service scenario and the data fields used by each service resource. Based on the call chain data collected for each service scenario, the consumption resources and consumption fields associated with each service scenario are determined. A scenario dependency mapping table is generated based on each service scenario and the associated consumption resources and consumption fields. The scene dependency mapping table is stored as the scene dependency library.

10. A quality certification device, characterized in that, The device includes: The change capture module is used to obtain the change metadata of the configuration change event in response to the detected configuration change event; the change metadata includes the change type and change parameters; The impact analysis module is used to determine, based on the change metadata and pre-built data assets, at least one service resource associated with the configuration change event and at least one service scenario associated with each service resource; the at least one service resource includes a service interface and / or a service application; The merged regression module is used to generate test work orders for each service resource based on at least one service scenario associated with each service resource, and to perform regression tests on each service resource based on the test work orders of each service resource. The dynamic admission module is used to determine the admission decision result of the configuration change event based on the regression test results of each of the service resources.

11. An electronic device, characterized in that, include: A processor and a memory; the memory stores a computer program, and the processor executes the computer program to implement the steps of the method according to any one of claims 1-9.

12. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions adapted for loading by a processor and executing the steps of the method as described in any one of claims 1-9.

13. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1-9.

Images