Test tool service management method and system combined with full life cycle

Abstract

The embodiment of the application provides a kind of test tool service management method and system combined with full life cycle, the method obtains the service architecture adjustment record and historical test case set after the key service function upgrade of bank service system, the record includes functional module change description, interface protocol update instruction and data flow reconstruction information;Based on this, the historical test case set is associatedly marked, and the test scene correlation graph containing the function change correlation degree label is generated;Through the graph expansion processing of test case generation server, the newly added test case set is generated in combination with real-time user operation behavior sequence, and the full-amount test case library is obtained by conflict detection and de-coincidence of historical test case set;Accordingly, automatic regression test is executed, performance index and function execution result are collected, performance optimization suggestion and test case update instruction are generated by combining user operation sequence analysis, and optimization suggestion is fed back and test case library is updated.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and more specifically, to a method and system for managing test tool services across the entire lifecycle. Background Technology

[0002] Upgrading critical service functions is a common practice in the development and maintenance of banking service systems. As business grows and technology advances, banks need to continuously expand and optimize their service systems to meet the ever-increasing demands of their customers. After upgrading critical service functions, regression testing is a crucial means of ensuring that existing system functions remain unaffected and that new functions operate normally.

[0003] However, in practical applications, existing technologies are inefficient in regression testing of critical service functions after upgrades in banking service systems, and cannot effectively guarantee the stability and performance of banking service systems. Summary of the Invention

[0004] The embodiments of the present invention provide at least a method and system for managing test tool services throughout their entire lifecycle.

[0005] This invention provides a method for managing test tool services across the entire lifecycle, applicable to a test tool service management system that integrates the entire lifecycle. The method includes: Obtain the service architecture adjustment record and corresponding historical test case set of the bank service system after the upgrade of key service functions. The service architecture adjustment record includes descriptions of functional module changes, interface protocol update instructions and data flow reconstruction information. Based on the service architecture adjustment records, the historical test case set is labeled with correlation to generate a test scenario correlation graph containing functional change correlation tags. The functional change correlation tags are used to indicate the degree of matching between historical test cases and service architecture adjustment content. The test case generation server performs test scenario expansion processing on the test scenario association graph, generates a new test case set by combining real-time user operation behavior sequence, and performs conflict detection and deduplication merging processing on the new test case set and the historical test case set to obtain a full test case library. An automated regression testing process is executed based on the full test case library. Service response performance indicators and function execution results are collected during the testing process. Correlation analysis is performed on the real-time user operation behavior sequence to generate performance optimization suggestions and test case update instructions for key service functions. The performance optimization suggestions are fed back to the service optimization module of the bank service system, and the full test case library is updated according to the test case update instructions.

[0006] This invention also provides a test tool service management system that integrates the entire lifecycle, including a processor and a memory; the processor and the memory are communicatively connected, and the processor is used to read computer programs from the memory and execute them to implement the above method.

[0007] This invention also provides a computer-readable storage medium having a computer program stored thereon, the computer program implementing the above-described method when running.

[0008] This invention, through a comprehensive lifecycle testing tool service management method, achieves comprehensive and efficient management of regression testing after the upgrade of key service functions in a banking service system. By acquiring service architecture adjustment records and historical test case sets following the upgrade of key service functions, it fully considers the various changes brought about by the service architecture adjustments. Furthermore, by performing correlation annotation on the historical test case set and generating a test scenario correlation graph, it clearly demonstrates the degree of matching between historical test cases and the service architecture adjustments, thereby accurately identifying test cases requiring focused attention and improving testing effectiveness.

[0009] Secondly, by leveraging a test case generation server to extend the test scenario association graph, and combining it with real-time user operation behavior sequences, a new set of test cases is generated. This ensures that the test cases closely reflect actual user operations, enhancing the realism and comprehensiveness of the tests. The new test case set is then combined with the historical test case set for conflict detection and deduplication to obtain a complete test case library. This guarantees the integrity and accuracy of the test case library and avoids wasted test resources due to duplicate testing and conflicts.

[0010] Then, an automated regression testing process is executed based on the full test case library. A portion of the test cases are used for routine testing, while the rest are used for automated and performance testing. Service response performance metrics and function execution results are collected, and correlation analysis is performed using real-time user action sequences to update the test cases. This allows for in-depth analysis of system performance bottlenecks and test case coverage blind spots. The generated performance optimization suggestions for key service functions can be directly fed back to the service optimization module, enabling targeted optimization of the bank's service system performance. Test case update commands update the full test case library, ensuring it remains synchronized with system changes and guaranteeing the effectiveness and reliability of regression testing.

[0011] With this design, the embodiments of the present invention improve the efficiency and quality of regression testing of banking service systems, and ensure the stability and performance of the systems.

[0012] For a description of the effects of the above-mentioned integrated lifecycle test tool service management system and computer-readable storage media, please refer to the description of the above methods.

[0013] To make the above-mentioned objects, features and advantages of the embodiments of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to the present invention and, together with the specification, serve to explain the technical solutions of the embodiments of the present invention. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as limiting the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0015] Figure 1 This is a block diagram illustrating a test tool service management system that integrates the entire lifecycle, as shown in an embodiment of the present invention.

[0016] Figure 2 This is a flowchart illustrating a test tool service management method that integrates the entire lifecycle, as shown in an embodiment of the present invention.

[0017] Figure 3 This is a functional module block diagram of a test tool service management device that integrates the entire lifecycle, as shown in an embodiment of the present invention. Detailed Implementation

[0018] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of the present invention.

[0019] Figure 1 The schematic diagram of the integrated lifecycle test tool service management system 10 provided in this embodiment of the invention includes a processor 102, a memory 104, and a bus 106. The memory 104 stores execution instructions and includes main memory and external memory. The main memory can also be understood as internal memory, used to temporarily store computational data in the processor 102 and data exchanged with external memory such as a hard disk. The processor 102 exchanges data with external memory through the main memory. When the integrated lifecycle test tool service management system 10 is running, the processor 102 and the memory 104 communicate through the bus 106, causing the processor 102 to execute the integrated lifecycle test tool service management method of this embodiment of the invention.

[0020] Please combine Figure 2 , Figure 2 This is a flowchart illustrating a test tool service management method that integrates the entire lifecycle, provided by an embodiment of the present invention. It is applied to a test tool service management system that integrates the entire lifecycle. The method may include the following steps 110-140.

[0021] Step 110: Obtain the service architecture adjustment record and corresponding historical test case set of the bank service system after the upgrade of key service functions. The service architecture adjustment record includes descriptions of functional module changes, interface protocol update instructions and data flow reconstruction information.

[0022] In this embodiment of the invention, after the upgrade of key service functions of the banking service system is completed, it is necessary to obtain service architecture adjustment records and corresponding historical test case sets. The service architecture adjustment records contain detailed information about the service architecture adjustments after the upgrade of key service functions. The functional module change descriptions explain which functional modules have changed; for example, a functional module that originally handled customer account inquiries may have added account freezing and unfreezing functions after the upgrade. The interface protocol update descriptions explain the updates to the interface protocols, such as changes in interface calling methods and parameter passing rules. The data flow refactoring information presents the new way data flows within the system; a previously serial data processing flow may have become a parallel processing flow after the upgrade. The historical test case set consists of a series of test cases previously used for regression testing. These test cases are designed to verify whether the original functions still operate normally after the system has been modified or upgraded. Obtaining this data can be used to perform targeted processing and optimization of historical test cases to adapt to the new service architecture.

[0023] Step 120: Based on the service architecture adjustment record, perform correlation annotation processing on the historical test case set to generate a test scenario correlation graph containing function change correlation labels. The function change correlation labels are used to indicate the degree of matching between historical test cases and service architecture adjustment content.

[0024] After obtaining the service architecture adjustment records and historical test case sets, the historical test case sets need to be annotated for relevance. By analyzing the information in the service architecture adjustment records, the degree of matching between each historical test case and the service architecture adjustment content is determined, and a functional change relevance label is assigned to it. This label can use different levels or values ​​to represent the degree of matching. For example, if the test object of a historical test case is completely consistent with the functional module changed in the service architecture adjustment, its functional change relevance label may be high; if it is only partially related, the relevance label may be medium; if there is almost no relevance, the relevance label may be low. Based on these labeled tags, a test scenario relationship graph is generated. This graph uses historical test cases as nodes and functional change relevance labels as edge weights, clearly showing the relationship between each test case and the service architecture adjustment content.

[0025] In one embodiment, the step of performing correlation annotation processing on the historical test case set based on the service architecture adjustment records to generate a test scenario correlation graph containing functional change correlation tags includes: Step 121: Based on the description of functional module changes in the service architecture adjustment record, extract the identification information of the changed functional modules and the change data of interface call relationships.

[0026] Based on the functional module change descriptions in the service architecture adjustment records, extract the identification information of the changed functional modules and the interface call relationship change data. The identification information of the changed functional modules is used to uniquely identify the functional modules that have undergone changes; for example, it could be the functional module's name or number. The interface call relationship change data records the changes that have occurred in the functional modules' interface calls. For example, if a functional module originally called interface A, it might change to calling interface B after the upgrade, or the parameters of the interface calls might have changed. Extracting this information can be used to determine the correlation between historical test cases and functional module changes.

[0027] Step 122: Perform test case feature extraction processing on the historical test case set to obtain the test object identifier, interface call sequence and expected result verification rules for each historical test case.

[0028] The historical test case set undergoes feature extraction processing. For each historical test case, its test object identifier is extracted to clarify which specific functional module or business process the test case targets; the interface call sequence records the order and content of the interfaces called during the execution of the test case; and the expected result verification rules are used to determine whether the test case execution result meets expectations, such as specifying the data format and numerical range returned after one of the interface calls. By extracting these features, a more comprehensive understanding of the characteristics of each historical test case can be obtained.

[0029] Step 123: calculating the semantic similarity between the identification information of the changed functional module and the test object identification of the historical test case, and generating a first relevance parameter.

[0030] Calculating the semantic similarity between the identification information of the changed functional module and the test object identification of the historical test case, thereby generating the first relevance parameter. Semantic similarity is used to measure the degree of semantic similarity between two pieces of identification information. For example, the identification information of the changed functional module is "account freezing and thawing functional module", and the test object identification of a historical test case is "account freezing function test case", these two pieces of identification information have a certain degree of semantic similarity. The semantic similarity therebetween is calculated by a set algorithm, and then the similarity value is converted into the first relevance parameter according to a preset rule, said parameter can reflect the relevance degree between the historical test case and the functional module change at the identification level.

[0031] In detail, said calculating the semantic similarity between the identification information of the changed functional module and the test object identification of the historical test case, and generating the first relevance parameter comprises: Step 1230: performing word segmentation processing on the identification information of the changed functional module and the test object identification of the historical test case, and removing stop words to obtain a core vocabulary set; calling a pre-trained semantic vector model to convert said core vocabulary set into lexical semantic vectors, said semantic vector model being trained through banking domain corpus; calculating the cosine similarity between the lexical semantic vector of the changed functional module identification information and the lexical semantic vector of the historical test case test object identification; generating the first relevance parameter according to the cosine similarity value and a preset mapping rule, said mapping rule linearly mapping the cosine similarity value to a preset numerical interval.

[0032] Firstly, performing word segmentation processing on the identification information of the changed functional module and the test object identification of the historical test case, splitting the identification information into individual words or phrases. Then removing stop words therein, stop words are words with no actual semantic meaning, such as "de" (of), "shi" (is), "zai" (at / in) and the like, the core vocabulary set is obtained after removal. Next, calling the pre-trained semantic vector model, said model is trained through corpus of the banking field, and can convert the core vocabulary set into lexical semantic vectors. Each vocabulary has a corresponding vector representation in the vector space, and the vector can reflect the semantic information of the vocabulary. After that, calculating the cosine similarity between the lexical semantic vector of the changed functional module identification information and the lexical semantic vector of the historical test case test object identification. Cosine similarity measures the size of the cosine value of the included angle between two vectors: the smaller the included angle, the higher the cosine similarity, indicating that the two vectors are more similar in semantics. Finally, according to the preset mapping rule, linearly mapping the cosine similarity value to the preset numerical interval, thereby generating the first relevance parameter.

[0033] Step 124: Analyze the degree of matching between the interface protocol update description and the interface call sequence of historical test cases, and generate a second correlation parameter. The second correlation parameter is negatively correlated with the number of interface parameter changes.

[0034] The interface protocol update description and the interface call sequences of historical test cases are analyzed to determine their degree of matching. The interface protocol update description records the update status of the interface protocol, while the interface call sequence is the order and content of the interface calls during the execution of historical test cases. By comparing the two, it is seen whether the interface call sequence conforms to the updated interface protocol. If the interface protocol update involves changes to interface parameters, the more parameters that are changed, the lower the degree of matching between the historical test cases and the updated interface protocol. Based on this relationship between the degree of matching and the number of interface parameter changes, a second correlation parameter is generated. This parameter is negatively correlated with the number of interface parameter changes; that is, the more interface parameter changes, the lower the second correlation parameter.

[0035] Step 125: Based on the data flow reconstruction information, perform an adaptive evaluation of the expected result verification rules of historical test cases to generate a third correlation parameter.

[0036] An adaptive evaluation of the expected result verification rules for historical test cases is performed based on data flow refactoring information. Data flow refactoring information demonstrates changes in how data flows within the system, while expected result verification rules are used to determine whether the execution results of test cases meet expectations. If the data flow has been refactored, the expected results of test cases may change. For example, if data was originally processed serially with the expected result of obtaining a predetermined output value at a specific point in time, the expected result may differ after the data flow is refactored to parallel processing. By evaluating whether the expected result verification rules are suitable for the new data flow, a third correlation parameter is generated, reflecting the degree of correlation between historical test cases and data flow refactoring.

[0037] Step 126: Construct a function change correlation label based on the first correlation parameter, the second correlation parameter, and the third correlation parameter.

[0038] After obtaining the first, second, and third relevance parameters, these three parameters are comprehensively considered to construct a functional change relevance label. A weighted approach can be used, assigning different weights to each relevance parameter, and then combining them according to a certain calculation logic to obtain a comprehensive numerical value or level as the functional change relevance label. For example, the first relevance parameter reflects the relevance at the identifier level and may have a higher weight; the second relevance parameter reflects the relevance at the interface protocol level; and the third relevance parameter reflects the relevance at the data flow level. Through reasonable weighting and calculation, the degree of matching between historical test cases and service architecture adjustments can be more accurately reflected.

[0039] Step 127: Using historical test cases as nodes and functional change relevance labels as edge weights, construct a test scenario association graph that includes test scenario hierarchy relationships. The test scenario hierarchy relationships are divided according to the importance of the functional modules covered by the test cases.

[0040] A test scenario relationship graph is constructed using historical test cases as nodes and feature change relevance labels as edge weights. In this graph, each historical test case is a node, edges connect different nodes, and the edge weights are the feature change relevance labels. Furthermore, the test scenario hierarchy is determined based on the importance of the functional modules covered by the test cases. For example, in a banking service system, functional modules related to customer fund security are likely very important, and test cases covering these modules may be at a higher level; while test cases covering auxiliary functional modules may be at a lower level. By constructing such a graph, the relationships between various test cases and their relevance to service architecture adjustments can be clearly displayed.

[0041] Step 130: The test scenario association graph is extended by the test case generation server, and a new test case set is generated by combining the real-time user operation behavior sequence. The new test case set is then combined with the historical test case set for conflict detection and deduplication merging to obtain the full test case library.

[0042] A test case generation server is used to expand the test scenario association graph. This server possesses powerful computing and analytical capabilities, enabling it to uncover more potential test scenarios based on information from the graph. Simultaneously, real-time user action sequences are incorporated. These sequences record users' actual actions within the banking service system, revealing user behavior habits and business needs. New test case sets are generated based on this information. After generation, these sets undergo conflict detection and deduplication merging with historical test case sets. Conflict detection checks for conflicts between new and historical test cases, such as input parameter dependency conflicts or API call conflicts. Deduplication merging removes duplicate test cases and merges the remaining ones, resulting in a comprehensive test case library containing all valid test cases, enabling more comprehensive regression testing of the banking service system.

[0043] As one implementation, the test scenario generation server performs test scenario expansion processing on the test scenario association graph, and generates a new set of test cases by combining real-time user operation behavior sequences, including: Step 131: Input the test scenario association graph into the scenario parsing module of the test case generation server, and extract the core test paths in the test scenario association graph whose association degree labels are higher than the preset label values. The core test paths are composed of multiple historical test cases with sequential dependencies.

[0044] The test scenario association graph is input into the scenario parsing module of the test case generation server. This module parses and analyzes the test scenario association graph. In the graph, paths with association labels higher than a preset value are considered core test paths. This preset value is a threshold set based on actual needs and experience; only paths with association labels above this threshold are extracted. A core test path consists of multiple historical test cases with dependencies. These test cases are executed sequentially, and the result of one test case may affect the execution of the next. Extracting core test paths allows for focusing on test cases highly relevant to service architecture adjustments, improving the targeting and efficiency of testing.

[0045] Step 132: Perform path expansion processing on the core test path, insert interface exception simulation test cases and boundary condition test cases into the preceding and following nodes of each historical test case, and generate an expanded test path set.

[0046] The extracted core test paths undergo path expansion processing. Interface exception simulation test cases and boundary condition test cases are inserted into the preceding and following nodes of each historical test case. Interface exception simulation test cases are used to simulate abnormal situations that may occur during interface calls, such as network interruptions and interface timeouts. Inserting these test cases tests the system's stability and fault tolerance under abnormal conditions. Boundary condition test cases test the system's boundary conditions, such as the maximum and minimum values ​​of input data, to ensure the system can operate normally under boundary conditions. After inserting these test cases, an expanded test path set is generated, which contains more test scenarios and can more comprehensively test the system.

[0047] Step 133: Collect real-time user operation behavior sequences, perform operation intent recognition processing on the real-time user operation behavior sequences, and extract frequent operation sequences and abnormal operation patterns.

[0048] Real-time user action sequence data is collected. This can be achieved by setting up a logging function in the bank's service system to record each user's action step and the time of each action. The collected real-time user action sequence is then processed for action intent recognition. Action intent recognition analyzes the purpose and intent of user actions. Through defined algorithms and models, frequent action sequences and abnormal action patterns are extracted from user behavior. Frequent action sequences are a series of actions that users frequently perform, reflecting common business needs. Abnormal action patterns are action sequences that differ from normal action patterns, which may be due to user errors or potential security risks. This extracted information can be used to generate more targeted test cases that better reflect actual user needs.

[0049] In a preferred embodiment, the step of performing operation intent recognition processing on the real-time user operation behavior sequence and extracting frequent operation sequences and abnormal operation patterns includes: Step 1330: Divide the user operation behavior sequence into multiple operation sessions, each operation session containing multiple continuously executed operation steps; perform sequence pattern mining on each operation session, using the prefix tree algorithm to extract frequently occurring operation step combinations, generating frequent item operation sequences; calculate the support and confidence of frequent item operation sequences, and filter frequent item operation sequences whose support and confidence both exceed the corresponding preset indicators; perform anomaly detection on the user operation behavior sequence, using the isolated forest algorithm to identify abnormal operation sequences that deviate from the normal operation pattern; perform cluster analysis on the abnormal operation sequences, extracting abnormal operation patterns with similar characteristics, the characteristics of which include the order of operation steps, operation interval time, and operation permission level; statistically analyze the occurrence frequency and impact range of different abnormal operation patterns, generating an abnormal operation pattern priority ranking result.

[0050] First, user action sequences are divided into multiple operation sessions. Each operation session is a set of consecutively executed operation steps. For example, a series of account queries and transfers performed by a user after logging into the system can be considered an operation session. Then, sequence pattern mining is performed on each operation session, using the prefix tree algorithm to extract frequently occurring combinations of operation steps. The prefix tree algorithm is an efficient sequence pattern mining algorithm that can quickly identify frequently occurring combinations of operation steps, generating frequent operation sequences. Next, the support and confidence of the frequent operation sequences are calculated. Support refers to the frequency of the frequent operation sequence in all operation sessions, and confidence refers to the probability that an operation session containing one of the operation steps also contains that frequent operation sequence. Frequent operation sequences whose support and confidence both exceed the corresponding preset indicators are selected; these sequences are relatively reliable and representative of frequent operations.

[0051] For user action sequences, the Isolation Forest algorithm is used for anomaly detection. The Isolation Forest algorithm is a tree-based anomaly detection algorithm that can identify abnormal action sequences that deviate from normal operation patterns. Cluster analysis is performed on the detected abnormal action sequences. Based on features such as the order of operation steps, operation intervals, and operation permission levels, abnormal action sequences with similar characteristics are grouped together to extract abnormal action patterns. Finally, the frequency and impact range of different abnormal action patterns are statistically analyzed. Based on this information, a priority ranking of abnormal action patterns is generated, which is used for subsequent processing of abnormal action patterns according to priority and generation of corresponding test cases.

[0052] Step 134: Convert the frequent operation sequence and abnormal operation pattern into test case generation rules.

[0053] The extracted frequent operation sequences and abnormal operation patterns are converted into test case generation rules. Frequent operation sequences reflect common user business needs; converting them into rules generates test cases for these common business needs. Abnormal operation patterns reflect potential abnormal situations; converting them into rules generates test cases to test the system's stability and fault tolerance under abnormal conditions. For example, a frequent operation sequence like "login to system - account query - transfer" can generate a test case simulating a user's actions according to this sequence to check if the system responds normally. An abnormal operation pattern like "making a large transfer outside of working hours" can generate a test case simulating this abnormal operation to check if the system can handle it correctly and provide appropriate prompts.

[0054] Step 135: Based on the test case generation rules, the extended test path set is instantiated to generate a new test case set containing an operation process description, an input data template, and a result verification script. The input data template is constructed based on the data distribution characteristics in the real-time user operation behavior sequence.

[0055] The extended test path set is instantiated based on test case generation rules. The test case generation rules specify the generation method and requirements for test cases, and the extended test path set contains expanded test paths. By applying the rules to the extended test path set, a new set of test cases is generated. Each new test case includes an operation flow description, an input data template, and a result verification script. The operation flow description details the execution steps and sequence of the test case; the input data template is constructed based on the data distribution characteristics in the real-time user operation behavior sequence, specifying the format and value range of the input data during test case execution; the result verification script is used to determine whether the test case execution result meets expectations, providing the execution status of the test case by comparing the actual output result with the expected result.

[0056] As another implementation, the process of performing conflict detection and deduplication merging on the newly added test case set and the historical test case set to obtain a full test case library includes: Step 1361: Extract the test object identifier, input parameter combination, and expected result verification rules for each test case in the newly added test case set and the historical test case set, and construct the test case feature vector.

[0057] From the newly added test case set and the historical test case set, for each test case, extract its test object identifier, input parameter combination, and expected result verification rules. The test object identifier clarifies the test objective of the test case; the input parameter combination is the set of parameter values ​​used when the test case is executed; and the expected result verification rules are the rules for judging whether the execution result of the test case meets expectations. Combining this information, a test case feature vector is constructed. This vector can comprehensively represent the characteristics of each test case and can be used for similarity calculation and conflict detection.

[0058] Step 1362: Calculate the cosine similarity between the feature vectors of any two test cases. When the cosine similarity is greater than the preset similarity threshold, it is determined to be a potential duplicate test case.

[0059] Calculate the cosine similarity between the feature vectors of any two test cases. Cosine similarity measures the magnitude of the cosine of the angle between two vectors; the smaller the angle, the higher the cosine similarity, indicating that the features of the two test cases are more similar. A preset similarity threshold is set based on actual needs and experience. When the cosine similarity between the feature vectors of two test cases exceeds this threshold, the two test cases are considered potentially duplicate test cases. Potentially duplicate test cases may be functionally similar or have similar execution steps, requiring further inspection and processing.

[0060] Step 1363: Perform an execution path consistency check on the potential duplicate test cases, and generate an execution path tree by simulating the execution process of the test cases using symbolic execution technology.

[0061] For test cases identified as potentially duplicated, an execution path consistency check is performed. Symbolic execution technology is used to simulate the execution process of the test cases. Symbolic execution is a technique that simulates program execution in a symbolic way, abstracting the execution process of a test case into a symbolic path. During the simulation, each step and conditional branch traversed by the test case is recorded, generating an execution path tree. The execution path tree is a tree structure, where each node represents an execution step, and edges represent the order and conditional relationships between steps. By comparing the execution path trees, it is possible to more accurately determine whether the execution processes of two test cases are consistent.

[0062] Step 1364: Compare the node structure and path branch conditions of the execution path tree. When the node matching degree and the branch condition overlap degree both exceed the corresponding preset indicators, it is determined to be a duplicate test case.

[0063] The execution path tree's node structure and branching conditions are compared. Node structure refers to the number, hierarchy, and connections of nodes in the execution path tree; branching conditions refer to the condition judgments and branching situations encountered during execution. Node matching degree and branching condition overlap degree are calculated. Node matching degree is the proportion of identical nodes in two execution path trees, and branching condition overlap degree is the proportion of identical branching conditions in two execution path trees. When both node matching degree and branching condition overlap degree exceed the corresponding preset indicators, the two test cases are determined to be duplicate test cases. The preset indicators are thresholds set based on actual conditions; only when both indicators exceed the thresholds can the two test cases be determined to be true duplicate test cases.

[0064] Step 1365: Perform conflict detection processing on new, non-duplicate test cases, analyze the input parameter dependencies and interface call conflicts between test cases, and generate a conflict detection report.

[0065] For the newly added, non-duplicate test cases remaining after deduplication, conflict detection processing is performed. This involves analyzing the input parameter dependencies between test cases, i.e., whether the input parameters of one test case depend on the output of another test case; and checking for interface call conflicts, such as whether two test cases simultaneously call the same interface or whether there are conflicts between the called interfaces. Based on the analysis results, a conflict detection report is generated. The conflict detection report records in detail the conflict situation between test cases, including the type of conflict and the test cases involved.

[0066] Step 1366: Prioritize the conflict test cases according to the conflict detection report to obtain the processed new test cases and historical test cases.

[0067] Prioritize conflicting test cases based on the conflict detection report. Prioritization can be determined based on factors such as the severity of the conflict and the importance of the test cases. For example, test cases with severe conflicts and involving critical business functions have higher priority. After prioritizing the conflicting test cases, process them according to the ranking results. This may require adjusting the execution order of test cases, modifying input parameters, or deleting some unnecessary test cases. After processing, you will obtain the processed new test cases and historical test cases.

[0068] Step 1367: Organize the processed new test cases and historical test cases according to the hierarchical relationship of the test scenario association graph to generate a full test case library containing version identifiers and update timestamps.

[0069] The newly added test cases and historical test cases are organized according to the hierarchical relationship of the test scenario association graph. This hierarchy is based on the importance of the functional modules covered by the test cases. Arranging the test cases according to this hierarchy makes the structure of the full test case library clearer and more logical. Additionally, version identifiers and update timestamps are added to the full test case library. Version identifiers distinguish different versions of the full test case library, and update timestamps record the update time of the full test case library for management and traceability.

[0070] Step 140: Execute the automated regression testing process according to the full test case library, collect service response performance indicators and function execution results during the test, perform correlation analysis and processing in conjunction with the real-time user operation behavior sequence, generate performance optimization suggestions and test case update instructions for key service functions, feed back the performance optimization suggestions to the service optimization module of the bank service system, and perform update operation on the full test case library according to the test case update instructions.

[0071] An automated regression testing process is executed based on a full test case library. This process uses automated testing tools and scripts to execute tests sequentially according to the test cases in the full test case library. During testing, service response performance metrics and function execution results are collected. Service response performance metrics include system response time and throughput, reflecting the system's performance status; function execution results refer to the execution outcome of each test case, whether it passed or failed. The collected data is then analyzed in conjunction with real-time user action behavior sequences. These sequences contain actual user actions, and correlation analysis reveals the relationships between service response performance metrics, function execution results, and user actions.

[0072] Based on the correlation analysis results, performance optimization suggestions and test case update instructions are generated for key service functions. Performance optimization suggestions address system performance bottlenecks, such as adjusting interface caching strategies and optimizing data query statements. Test case update instructions are used to update the full test case library, including adding test scenario descriptions and adjusting test case parameter rules. The performance optimization suggestions are fed back to the service optimization module of the bank's service system, which then optimizes the system based on these suggestions. Simultaneously, the full test case library is updated according to the test case update instructions, ensuring that the full test case library is always up-to-date and accurate.

[0073] In one implementation approach, the automated regression testing process is executed based on the full test case library, and service response performance metrics and function execution results are collected during the testing process, including: Step 1411: Extract the test case set corresponding to the core test path of the test scenario association graph from the full test case library, and sort them by priority according to the test scenario hierarchy.

[0074] The test case set corresponding to the core test paths in the test scenario relationship graph is extracted from the full test case library. The core test paths are the parts highly related to service architecture adjustments, and the corresponding test cases better reflect the key functions of the system and potential problems. These test cases are then prioritized according to the test scenario hierarchy. The test scenario hierarchy is based on the importance of the functional modules covered by the test cases; the more important the test case, the higher its priority. This prioritization allows for the execution of important test cases first, improving testing efficiency and focus.

[0075] Step 1412: Construct a test task execution queue based on the priority sorting results, and set the resource allocation parameters and execution timeout threshold for each test task.

[0076] A test task execution queue is constructed based on the priority ranking. The queue is a sequentially arranged list of test cases, executed according to priority. Resource allocation parameters and execution timeout thresholds are set for each test task. Resource allocation parameters refer to the system resources allocated to each test task, such as CPU and memory. Resources are allocated reasonably according to the complexity and requirements of the test tasks to ensure smooth execution. The execution timeout threshold is the maximum allowed execution time for each test task; if the test task has not completed within this time, it is considered a failure. Setting these parameters can be used to control the stability and efficiency of the testing process.

[0077] Step 1413: Call the automated test execution engine to load the test task execution queue, execute test cases sequentially, and record service response performance metrics.

[0078] The automated test execution engine loads the test task execution queue. The automated test execution engine is a tool that automatically executes test cases, following the order in the queue. During test case execution, service response performance metrics are recorded. These metrics include system response time and throughput; recording these metrics provides insight into the system's performance during test case execution.

[0079] Step 1414: Monitor the function execution results in real time during the test execution process, compare the actual output results with the expected results through the result verification script, and generate a function execution status indicator.

[0080] Monitor the function execution results in real time during test execution. Use a result verification script to compare the actual output with the expected results. The result verification script is written during test case design and is used to determine whether the test case execution results meet expectations. Through comparison, generate function execution status indicators. Function execution status indicators can be "passed," "failed," etc., clearly indicating the execution result of each test case. Real-time monitoring of function execution results can help identify problems in the testing process promptly, improving testing efficiency and accuracy.

[0081] Step 1415: Perform error localization processing on test cases that fail to execute, collect error stack information, interface interaction logs and service status snapshots, and generate an error diagnosis report.

[0082] For test cases that fail to execute, error localization is performed. Error stack traces, API interaction logs, and service status snapshots are collected. Error stack traces record the call stack at the time of the error; analyzing this trace can pinpoint the location of the faulty code. API interaction logs record the interactions between the test case and the API during execution, which can be used to troubleshoot API call issues. Service status snapshots provide system status information at the time of test case failure, including memory usage and process status. Based on this collected information, an error diagnosis report is generated, detailing the reasons for the test case failure and related information.

[0083] Step 1416: Associate and store the service response performance indicators, function execution status identifiers, and error diagnosis reports according to the test case identifiers to construct a test execution result dataset.

[0084] The collected service response performance metrics, function execution status indicators, and error diagnosis reports are associated and stored according to test case identifiers. Each test case has a unique identifier, which is used to link related data and construct a test execution result dataset. The test execution result dataset is a dataset containing the execution results of all test cases and related information.

[0085] In one implementation approach, the step of performing correlation analysis on the real-time user operation behavior sequence to generate performance optimization suggestions and test case update instructions for key service functions includes: Step 1421: Perform time-dimensional alignment processing on the test execution result dataset and the user operation behavior sequence to establish a mapping relationship between the test scenario and the user's actual operation scenario.

[0086] The test execution result dataset and user action sequence are aligned along the time dimension. The test execution result dataset records the execution time and results of the test cases, while the user action sequence records the user's action time and actions. By aligning the two along the time dimension, the correspondence between the test scenario and the user's actual operation scenario can be identified. For example, if a user performs a series of account query operations within a certain time period, and the system executes related account query test cases within the same time period, a mapping relationship can be established between the two. This mapping relationship can be used to more accurately analyze the correlation between test results and user actions.

[0087] Step 1422: Extract test cases with abnormal service response performance indicators from the test execution result dataset, analyze the corresponding user operation behavior sequence characteristics, and identify the key operation paths that affect service performance.

[0088] Extract test cases with abnormal service response performance metrics from the test execution result dataset. These abnormalities may manifest as excessively long response times or low throughput. For these abnormal test cases, analyze the corresponding user operation behavior sequence characteristics. These characteristics include operation steps, operation frequency, and operation time. By analyzing these characteristics, identify the critical operation paths affecting service performance. For example, if it is found that the system response time significantly increases when users frequently perform large-amount transfers, then the large-amount transfer operation path is likely a critical operation path affecting service performance.

[0089] Step 1423: Calculate the correlation coefficient between service response performance indicators and user operation behavior characteristics using a correlation analysis algorithm to determine the target operation parameters that affect performance.

[0090] Correlation analysis algorithms are used to calculate the correlation coefficient between service response performance metrics and user behavior characteristics. Correlation analysis measures the degree of correlation between two variables; by calculating the correlation coefficient, the strength of the association between service response performance metrics and user behavior characteristics can be understood. Based on the magnitude of the correlation coefficient, user behavior characteristics with a high correlation to service response performance metrics are selected, and the corresponding operational parameters are the target operational parameters affecting performance. For example, if the calculation shows a high correlation coefficient between the frequency of user operations and the system's response time, then the operation frequency parameter is considered a target operational parameter affecting performance.

[0091] In an alternative embodiment, the step of calculating the correlation coefficient between service response performance indicators and user operation behavior characteristics using a correlation analysis algorithm to determine target operation parameters affecting performance includes: Step 14230: Calculate the correlation coefficient between each user's operational behavior feature and the service response performance index using the Pearson correlation coefficient algorithm; sort the features according to the absolute value of the correlation coefficient and select target user operational behavior features that meet the correlation condition with the service response performance index; perform multicollinearity test on the selected target user operational behavior features and use the variance inflation factor method to identify features with multicollinearity; remove redundant features with multicollinearity and retain independent key operational behavior features as target operational parameters affecting performance; calculate the partial correlation coefficient between the target operational parameters and the service response performance index, and determine the degree of independent influence of the target operational parameters on performance based on the partial correlation coefficient.

[0092] The Pearson correlation coefficient algorithm is used to calculate the correlation coefficient between each user's behavioral characteristic and the service response performance index. The Pearson correlation coefficient is a commonly used indicator to measure the degree of linear correlation between two variables. By calculating the correlation coefficient, the strength of the association between each user's behavioral characteristic and the service response performance index can be obtained. User behavioral characteristics that meet the correlation criteria with the service response performance index are then selected based on the absolute value of their correlation coefficients. This correlation criterion is a threshold set based on actual needs and experience; only user behavioral characteristics with an absolute correlation coefficient exceeding this threshold are selected.

[0093] Multicollinearity was tested on the selected target user behavior features, and the variance inflation factor (VIF) method was used to identify features exhibiting multicollinearity. Multicollinearity refers to a high degree of linear correlation among multiple independent variables, which can affect the accuracy and stability of the model. The VVIF method is a commonly used method for testing multicollinearity; it determines the presence of multicollinearity by calculating the variance inflation factor for each feature. Redundant features exhibiting multicollinearity were removed, retaining only independent, key behavioral features as target operational parameters affecting performance.

[0094] Finally, the partial correlation coefficient between the target operating parameters and the service response performance index is calculated. The partial correlation coefficient measures the degree of correlation between two variables while controlling for other variables. By calculating the partial correlation coefficient, the degree of independent influence of the target operating parameters on the service response performance index can be determined; that is, the magnitude of the impact of the target operating parameters on performance after eliminating the interference of other factors.

[0095] Step 1424: Construct a performance bottleneck localization model based on the target operation parameters and key operation paths, and identify the performance bottleneck modules and interfaces in the service architecture through the performance bottleneck localization model.

[0096] A performance bottleneck localization model is constructed based on target operation parameters and critical operation paths. Target operation parameters are key parameters affecting service performance, while critical operation paths are critical operation processes affecting service performance. The performance bottleneck localization model is a model capable of identifying performance bottleneck modules and interfaces in the service architecture based on this information. The model can be built using machine learning or data analysis methods, trained and learned from a large amount of historical data to accurately identify performance bottlenecks. The performance bottleneck localization model is then used to analyze the service architecture to identify modules and interfaces with performance bottlenecks, such as a functional module processing too slowly or an interface having excessively low call efficiency.

[0097] Step 1425: Generate targeted performance optimization suggestions based on the type of performance bottleneck module and interface. The performance optimization suggestions include interface caching strategy adjustment, data query statement optimization, and service resource dynamic allocation scheme.

[0098] Based on the type of performance bottleneck module and interface, generate targeted performance optimization suggestions. Different types of performance bottlenecks require different optimization methods. If the performance bottleneck is caused by frequent interface calls, suggestions can be made to adjust the interface caching strategy, such as increasing the interface cache time or expanding the cache capacity to reduce repeated interface calls. If the performance bottleneck is caused by inefficient data query statements, suggestions can be made to optimize the data query statements, such as optimizing query conditions and adding indexes. If the performance bottleneck is caused by unreasonable allocation of service resources, a dynamic service resource allocation scheme can be proposed to dynamically adjust resource allocation according to the system load, thereby improving system performance and efficiency.

[0099] Step 1426: Analyze the functional execution failure test cases in the test execution result dataset, and identify test case coverage blind spots by combining them with the abnormal operation patterns in the user operation behavior sequence.

[0100] Analyze the functional execution failure test cases in the test execution result dataset. Functional execution failure test cases refer to cases where the test case execution result fails. These test cases may be due to problems with the system itself or incomplete test case coverage. Combine this with abnormal operation patterns in the user operation behavior sequence. Abnormal operation patterns are situations in actual user operation that differ from normal operation, such as misoperation or violation of regulations. By analyzing functional execution failure test cases and abnormal operation patterns, identify areas not covered by the test cases, i.e., test case coverage blind spots. For example, if it is found that the system error occurs when a user enters a special character during a certain operation, and the existing test cases do not test this special character input situation, this is a test case coverage blind spot.

[0101] Step 1427: Generate a test case update instruction based on the test case coverage blind spot. The test case update instruction includes a description of the new test scenario, test case parameter adjustment rules, and updated result verification script content.

[0102] Based on the identified test case coverage blind spots, test case update instructions are generated. These instructions are used to update the entire test case library, including new test scenario descriptions, test case parameter adjustment rules, and updated result verification script content. The new test scenario description is a new test scenario designed to address the test case coverage blind spots. For example, for the aforementioned special character input situation, a new test scenario can be designed to test the system's fault tolerance. The test case parameter adjustment rules are rules used to adjust the parameters of existing test cases, which may require adding boundary conditions or parameters for special cases. The updated result verification script content modifies and improves the result verification script to adapt to the new test scenarios and parameter adjustments.

[0103] In one implementation approach, the step of feeding back the performance optimization suggestions to the service optimization module of the bank service system, and performing an update operation on the full test case library according to the test case update instruction, includes: Step 1431: Convert the performance optimization suggestion into a configuration update instruction to be executed by the service optimization module. The configuration update instruction includes the target module identifier, parameter adjustment value and effective time window.

[0104] The performance optimization suggestions are converted into configuration update commands to be executed by the service optimization module. Performance optimization suggestions are improvement proposals aimed at addressing system performance bottlenecks. These need to be converted into specific configuration update commands so that the service optimization module can execute them. The configuration update command includes a target module identifier, parameter adjustment values, and an effective time window. The target module identifier refers to the identifier of the functional module or interface that needs optimization; the parameter adjustment values ​​are the specific parameter adjustments determined based on the performance optimization suggestions, such as adjustments to interface cache time or optimization parameters for data query statements; the effective time window refers to the time range within which the configuration update command takes effect, such as within a specified time period.

[0105] Step 1432: Send the configuration update instruction to the service optimization module of the bank service system via an interface call, and receive the configuration update result returned by the service optimization module.

[0106] The configuration update command is sent to the service optimization module of the bank's service system via an API call. An API call is a method of data transmission and interaction through a system interface, which facilitates the transmission of configuration update commands to the service optimization module. Upon receiving the configuration update command, the service optimization module executes the corresponding configuration update operation and returns the configuration update result. The configuration update result can indicate whether the update was successful or failed; receiving this result can be used to understand the execution status of the configuration update.

[0107] Step 1433: When the configuration update result is successful, extract the description of the new test scenario from the test case update instruction and generate the corresponding new test cases.

[0108] When the configuration update result is successful, it indicates that the system performance optimization is complete. At this point, extract the new test scenario description from the test case update command. The new test scenario description is a new test scenario designed to address blind spots in test case coverage. Based on these descriptions, generate corresponding new test cases. The new test cases need to include information such as operation process descriptions, input data templates, and result validation scripts to ensure accurate testing of the system's functionality and performance in the new scenarios.

[0109] Step 1434: Modify the input parameters, expected results, and verification rules of existing test cases in the full test case library according to the test case parameter adjustment rules.

[0110] Based on the test case parameter adjustment rules, the input parameters, expected results, and validation rules of existing test cases in the full test case library are modified. These rules are designed to adapt to system changes and new testing requirements. For example, it may be necessary to add input parameters for boundary conditions or special cases, modify expected results to conform to new system behavior, and update validation rules to ensure accurate judgment of test case execution results. By modifying these parameters and rules, existing test cases become more complete and accurate.

[0111] Step 1435: Refactor the verification logic of the test cases based on the updated content of the result verification script.

[0112] The validation logic of test cases is refactored based on updates to the result validation script. These updates involve modifying and improving the result validation script. As the system changes and new testing requirements emerge, the original result validation logic may no longer be applicable, necessitating refactoring. Refactoring the validation logic ensures that test cases can accurately determine execution results, improving the accuracy and reliability of testing.

[0113] Step 1436: Organize the newly added and modified test cases according to the hierarchical relationship of the test scenario association graph, insert them into the full test case library, and update the version identifier and update timestamp of the test cases.

[0114] New and modified test cases are organized according to the hierarchical relationship of the test scenario association graph. This graph is based on the importance of the functional modules covered by the test cases. Arranging the test cases according to this hierarchy makes the structure of the full test case library clearer and more logical. The organized test cases are then inserted into the full test case library, and their version identifiers and update timestamps are updated simultaneously. The version identifier distinguishes different versions of the test cases, and the update timestamp records the update time, facilitating management and traceability of the test case library.

[0115] Step 1437: Perform a consistency check on the entire test case library and generate a test case library update report based on the dependencies between test cases and the correctness of the execution order.

[0116] Perform a consistency check on the entire test case library. The consistency check verifies the completeness, accuracy, and consistency of all test cases in the library. This includes checking the validity of input parameters, the reasonableness of expected results, and the correctness of validation rules. By considering the dependencies and execution order of test cases, it ensures that test cases execute in the correct order, and that the result of one test case does not affect the normal execution of the next. Based on the consistency check results and the dependencies and execution order of test cases, a test case library update report is generated. This report details the updates to the entire test case library, the consistency check results, identified problems, and recommendations.

[0117] Please refer to the following: Figure 3 It provides a comprehensive test tool service management system that integrates the entire lifecycle, including: Data acquisition module 310 is used to acquire the service architecture adjustment record and corresponding historical test case set of the bank service system after the key service function upgrade is completed. The service architecture adjustment record includes the functional module change description, interface protocol update description and data flow reconstruction information. The association annotation module 320 is used to perform association annotation processing on the historical test case set based on the service architecture adjustment record, and generate a test scenario association map containing function change association labels. The function change association labels are used to indicate the degree of matching between the historical test cases and the service architecture adjustment content. Test extension module 330 is used to perform test scenario extension processing on the test scenario association graph through the test case generation server, generate a new test case set by combining real-time user operation behavior sequence, and perform conflict detection and deduplication merging processing on the new test case set and the historical test case set to obtain a full test case library; The regression testing module 340 is used to execute an automated regression testing process based on the full test case library, collect service response performance indicators and function execution results during the testing process, perform correlation analysis and processing in conjunction with the real-time user operation behavior sequence, generate performance optimization suggestions and test case update instructions for key service functions, feed back the performance optimization suggestions to the service optimization module of the bank service system, and perform update operations on the full test case library according to the test case update instructions.

[0118] This invention, through a comprehensive lifecycle testing tool service management method, achieves comprehensive and efficient management of regression testing after the upgrade of key service functions in a banking service system. By acquiring service architecture adjustment records and historical test case sets following the upgrade of key service functions, it fully considers the various changes brought about by the service architecture adjustments. Furthermore, by performing correlation annotation on the historical test case set and generating a test scenario correlation graph, it clearly demonstrates the degree of matching between historical test cases and the service architecture adjustments, thereby accurately identifying test cases requiring focused attention and improving testing effectiveness.

[0119] Secondly, by leveraging a test case generation server to extend the test scenario association graph, and combining it with real-time user operation behavior sequences, a new set of test cases is generated. This ensures that the test cases closely reflect actual user operations, enhancing the realism and comprehensiveness of the tests. The new test case set is then combined with the historical test case set for conflict detection and deduplication to obtain a complete test case library. This guarantees the integrity and accuracy of the test case library and avoids wasted test resources due to duplicate testing and conflicts.

[0120] Then, an automated regression testing process is executed based on the full test case library. A portion of the test cases are used for routine testing, while the rest are used for automated and performance testing. Service response performance metrics and function execution results are collected, and correlation analysis is performed using real-time user action sequences to update the test cases. This allows for in-depth analysis of system performance bottlenecks and test case coverage blind spots. The generated performance optimization suggestions for key service functions can be directly fed back to the service optimization module, enabling targeted optimization of the bank's service system performance. Test case update commands update the full test case library, ensuring it remains synchronized with system changes and guaranteeing the effectiveness and reliability of regression testing.

[0121] With this design, the embodiments of the present invention improve the efficiency and quality of regression testing of banking service systems, and ensure the stability and performance of the systems.

[0122] Furthermore, a readable storage medium is provided on which a program is stored, which, when executed by a processor, implements the above-described method.

[0123] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided by this invention, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

Claims

1. A method for managing test tool services across their entire lifecycle, characterized in that, The method includes: Obtain the service architecture adjustment record and corresponding historical test case set of the bank service system after the upgrade of key service functions. The service architecture adjustment record includes descriptions of functional module changes, interface protocol update instructions and data flow reconstruction information. Based on the service architecture adjustment records, the historical test case set is labeled with correlation to generate a test scenario correlation graph containing functional change correlation tags. The functional change correlation tags are used to indicate the degree of matching between historical test cases and service architecture adjustment content. The test case generation server performs test scenario expansion processing on the test scenario association graph, generates a new test case set by combining real-time user operation behavior sequence, and performs conflict detection and deduplication merging processing on the new test case set and the historical test case set to obtain a full test case library. The automated regression testing process is executed according to the full test case library. Service response performance indicators and function execution results are collected during the test process. The real-time user operation behavior sequence is combined with the correlation analysis and processing to generate performance optimization suggestions and test case update instructions for key service functions. The performance optimization suggestions are fed back to the service optimization module of the bank service system, and the full test case library is updated according to the test case update instructions. The step of performing test scenario expansion processing on the test scenario association graph through the test case generation server, and generating a new set of test cases by combining real-time user operation behavior sequences, includes: The test scenario association graph is input into the scenario parsing module of the test case generation server to extract the core test paths in the test scenario association graph whose association degree labels are higher than the preset label values. The core test paths are composed of multiple historical test cases with sequential dependencies. The core test path is extended by inserting interface exception simulation test cases and boundary condition test cases into the preceding and following nodes of each historical test case to generate an extended test path set. Collect real-time user operation behavior sequences, perform operation intent recognition processing on the real-time user operation behavior sequences, and extract frequent operation sequences and abnormal operation patterns; The frequent operation sequences and abnormal operation patterns are converted into test case generation rules. Based on the test case generation rules, the extended test path set is instantiated to generate a new test case set containing operation process description, input data template and result verification script. The input data template is constructed according to the data distribution characteristics in the real-time user operation behavior sequence. The step of performing operation intent recognition processing on the real-time user operation behavior sequence, and extracting frequent operation sequences and abnormal operation patterns, includes: The user action sequence is divided into multiple operation sessions, and each operation session contains multiple operation steps that are executed consecutively; Sequence pattern mining is performed on each operation session, and the prefix tree algorithm is used to extract frequently occurring operation step combinations to generate frequent operation sequence. Calculate the support and confidence of frequent item operation sequences, and filter frequent item operation sequences whose support and confidence both exceed the corresponding preset indicators; Anomaly detection is performed on user operation behavior sequences, and the isolated forest algorithm is used to identify abnormal operation sequences that deviate from the normal operation mode. Cluster analysis is performed on abnormal operation sequences to extract abnormal operation patterns with similar characteristics. The characteristics of the abnormal operation patterns include the order of operation steps, the operation interval time, and the operation permission level. The frequency and impact of different abnormal operation modes are statistically analyzed, and a priority ranking of abnormal operation modes is generated.

2. The test tool service management method integrating the entire lifecycle as described in claim 1, characterized in that, The process of performing correlation annotation on the historical test case set based on the service architecture adjustment records to generate a test scenario correlation graph containing functional change correlation tags includes: Based on the description of functional module changes in the service architecture adjustment record, extract the identification information of the changed functional modules and the change data of interface call relationships; The historical test case set is subjected to test case feature extraction processing to obtain the test object identifier, interface call sequence and expected result verification rules for each historical test case; Calculate the semantic similarity between the identifier information of the modified functional module and the test object identifier of the historical test cases, and generate a first correlation parameter; The degree of matching between the interface protocol update description and the interface call sequence of historical test cases is analyzed to generate a second correlation parameter. The second correlation parameter is negatively correlated with the number of interface parameter changes. Based on the data flow reconstruction information, an adaptive evaluation is performed on the expected result verification rules of historical test cases to generate a third correlation parameter; Function change correlation labels are constructed based on the first correlation parameter, the second correlation parameter, and the third correlation parameter; Using historical test cases as nodes and functional change relevance labels as edge weights, a test scenario association graph containing test scenario hierarchy is constructed. The test scenario hierarchy is divided according to the importance of the functional modules covered by the test cases. The step of calculating the semantic similarity between the identifier information of the changed functional module and the test object identifier of the historical test cases to generate a first correlation parameter includes: The identification information of the changed functional modules and the test object identification of historical test cases are segmented into words, and stop words are removed to obtain the core vocabulary set; The core vocabulary set is converted into vocabulary semantic vectors by calling a pre-trained semantic vector model, which is trained using banking domain corpus. Calculate the cosine similarity between the lexical semantic vector of the changed functional module identifier information and the lexical semantic vector of the test object identifier of the historical test cases; A first correlation parameter is generated based on the cosine similarity value and a preset mapping rule, wherein the mapping rule linearly maps the cosine similarity value to a preset numerical range.

3. The test tool service management method integrating the entire lifecycle as described in claim 1, characterized in that, The process of performing conflict detection and deduplication merging on the newly added test case set and the historical test case set to obtain a full test case library includes: Extract the test object identifier, input parameter combination, and expected result verification rules for each test case from the newly added test case set and the historical test case set, and construct a test case feature vector; Calculate the cosine similarity between the feature vectors of any two test cases. When the cosine similarity is greater than the preset similarity threshold, it is determined to be a potential duplicate test case. The execution path consistency check is performed on the potential duplicate test cases, and the execution process of the test cases is simulated by symbolic execution technology to generate an execution path tree; Compare the node structure and branch conditions of the execution path tree. When both the node matching degree and the branch condition overlap degree exceed the corresponding preset indicators, it is determined to be a duplicate test case. Perform conflict detection processing on new, non-duplicate test cases, analyze the input parameter dependencies and interface call conflicts between test cases, and generate a conflict detection report; Based on the conflict detection report, the conflict test cases are prioritized to obtain the processed new test cases and historical test cases. The newly added test cases and historical test cases are organized according to the hierarchical relationship of the test scenario association graph to generate a full test case library containing version identifiers and update timestamps.

4. The test tool service management method integrating the entire lifecycle as described in claim 1, characterized in that, The automated regression testing process, executed according to the full test case library, collects service response performance metrics and function execution results during the testing process, including: Extract the test case set corresponding to the core test path of the test scenario association graph from the full test case library, and sort them by priority according to the hierarchical relationship of the test scenarios; A test task execution queue is constructed based on the priority sorting results, and resource allocation parameters and execution timeout thresholds are set for each test task; The automated test execution engine is invoked to load the test task execution queue, execute test cases sequentially, and record service response performance metrics. During the test execution, the function execution results are monitored in real time, and the actual output results are compared with the expected results through the result verification script to generate function execution status indicators; For test cases that fail to execute, perform error localization and processing, collect error stack information, interface interaction logs and service status snapshots, and generate error diagnosis reports; The service response performance metrics, function execution status identifiers, and error diagnosis reports are associated and stored according to the test case identifiers to construct a test execution result dataset.

5. The test tool service management method integrating the entire lifecycle as described in claim 4, characterized in that, The process of performing correlation analysis on the real-time user operation behavior sequence to generate performance optimization suggestions and test case update instructions for key service functions includes: The test execution result dataset and user operation behavior sequence are aligned in the time dimension to establish a mapping relationship between the test scenario and the user's actual operation scenario; Extract test cases with abnormal service response performance metrics from the test execution result dataset, analyze the corresponding user operation behavior sequence characteristics, and identify the key operation paths that affect service performance. The correlation coefficient between service response performance indicators and user operation behavior characteristics is calculated by using a correlation analysis algorithm to determine the target operation parameters that affect performance. A performance bottleneck localization model is constructed based on the target operation parameters and key operation paths. The performance bottleneck localization model is used to identify the performance bottleneck modules and interfaces in the service architecture. Based on the type of performance bottleneck module and interface, targeted performance optimization suggestions are generated. These suggestions include adjustments to interface caching strategies, optimization of data query statements, and dynamic allocation schemes for service resources. Analyze the functional failure test cases in the test execution result dataset, and combine them with the abnormal operation patterns in the user operation behavior sequence to identify test case coverage blind spots; Test case update instructions are generated based on the test case coverage blind spots. The test case update instructions include a description of the new test scenario, test case parameter adjustment rules, and updated result verification script content.

6. The test tool service management method integrating the entire lifecycle as described in claim 5, characterized in that, The step of feeding back the performance optimization suggestions to the service optimization module of the bank service system, and performing an update operation on the full test case library according to the test case update instruction, includes: The performance optimization suggestions are converted into configuration update instructions to be executed by the service optimization module. The configuration update instructions include the target module identifier, parameter adjustment values, and effective time window. The configuration update command is sent to the service optimization module of the bank service system via an interface call, and the configuration update result returned by the service optimization module is received. When the configuration update result is successful, extract the description of the new test scenario from the test case update instruction and generate the corresponding new test case; Modify the input parameters, expected results, and verification rules of existing test cases in the full test case library according to the test case parameter adjustment rules; The validation logic of the test cases is refactored based on the updated content of the result validation script; The newly added and modified test cases are inserted into the full test case library according to the hierarchical relationship of the test scenario association graph, and the version identifier and update timestamp of the test cases are updated. Perform a consistency check on the entire test case library and generate a test case library update report based on the dependencies between test cases and the correctness of the execution order.

7. The test tool service management method combining the entire lifecycle as described in claim 5, characterized in that, The step of calculating the correlation coefficient between service response performance indicators and user operation behavior characteristics using a correlation analysis algorithm to determine target operation parameters affecting performance includes: The Pearson correlation coefficient algorithm was used to calculate the correlation coefficient between each user's operational behavior characteristics and service response performance indicators. Based on the absolute value of the correlation coefficient, target user operation behavior characteristics that meet the correlation condition with the service response performance index are selected. Multicollinearity tests were performed on the selected target user operation behavior features, and the variance inflation factor method was used to identify features with multicollinearity. Redundant features with multicollinearity were removed, and independent key operation behavior features were retained as target operation parameters affecting performance. Calculate the partial correlation coefficient between the target operating parameters and the service response performance index, and determine the degree of independent influence of the target operating parameters on performance based on the partial correlation coefficient.

8. A test tool service management system integrating the entire lifecycle, characterized in that, It includes a processor and a memory; the processor and the memory are communicatively connected, and the processor is configured to read a computer program from the memory and execute it to implement the method described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, It contains a computer program that, when run, implements the method described in any one of claims 1-7.

Images