A service order driven software iterative development method and system

Abstract

The application relates to the technical field of micro-service testing, and discloses a software iterative development method and system based on service work order driving, wherein a cross-service link time sequence constraint test case generation method for a micro-service real-time system comprises the following steps: analyzing a service work order text to extract time sequence constraint elements and generate a time sequence work order semantic description; acquiring micro-service architecture configuration information to generate a service-to-service calling topology graph; matching service nodes based on the time sequence work order semantic description to track a calling path and generate a time sequence problem associated service calling link; identifying time sequence related code structures to generate a link-level time sequence code feature set; extracting time sequence parameters to generate a link-level time sequence parameter constraint graph; applying a link time sequence boundary analysis strategy to generate a link-level time sequence test input combination matrix; deducing a link-level time sequence assertion set; assembling test input and assertion configuration cross-service test arrangement parameters to output a micro-service link time sequence constraint test case set.

Description

Technical Field

[0001] This invention relates to the field of microservice testing technology, and more specifically, to a software iterative development method and system based on service work order driven by service work orders. Background Technology

[0002] In real-time software systems with a microservice architecture, business functions are completed collaboratively by multiple independently deployed microservices. The microservices communicate with each other through API gateways or RPC to form complex call chains. Each service node has an independent response timeout configuration, and there is cascading timeout propagation between service calls. The entire call chain must meet strict end-to-end timing requirements.

[0003] Existing technologies typically employ two independent approaches to handle timing-related issues: one is to locate the cross-service call chain involved in the service work order based on service registration information, but only focuses on the code location at the functional level; the other is to identify the timing-related code structure based on a single service code repository to generate timing test cases, but is limited to the boundary of a single service.

[0004] Cross-service call chain localization technology outputs code change location reports rather than timing test cases, and does not address timing-level verification requirements. Single-service timing test case generation technology, which extracts timing parameters and derives assertions, is limited to a single code repository and cannot handle timing dependencies between cross-service calls, such as scenarios where upstream service timeouts trigger duplicate requests from downstream services, or where cumulative latency across multiple services exceeds end-to-end thresholds. Neither technology, used independently, can generate test cases that verify cross-service chain-level timing behavior, resulting in a lack of effective automated test coverage for cross-service timing constraints in microservice real-time systems. Summary of the Invention

[0005] This invention provides a software iterative development method and system based on service work order, which solves the technical problems in related technologies such as difficulty in generating test cases for timing constraints across service links in microservice architecture, inaccurate location of timing problems, and incomplete test coverage.

[0006] This invention discloses a service ticket-driven software iterative development method, comprising the following steps: parsing service ticket text, identifying time-series related descriptive words and business entities, extracting time-series constraint elements, and generating a time-series service ticket semantic description; the time-series constraint elements include timeout thresholds, delay descriptions, and sequence dependencies; obtaining service registration information and API contract definitions of the microservice architecture, parsing the interface signatures exposed by each microservice and the inter-service call dependencies, and generating an inter-service call topology graph; matching the list of services involved in the time-series service ticket semantic description with the service nodes in the inter-service call topology graph, determining the starting and ending service nodes, tracing the call path, and generating a time-series problem-related service call chain; and traversing the code repositories corresponding to each service node in the time-series problem-related service call chain. Static code analysis is performed to identify timing-related code structures and generate a link-level timing code feature set. Local timeout thresholds for each service node are extracted from this feature set, and the timeout propagation relationship between service calls is analyzed to generate a link-level timing parameter constraint graph. Based on this graph, a link-level timing boundary analysis strategy is applied to identify cross-service timeout propagation critical points, cumulative latency boundaries, and retry triggering conditions, generating a link-level timing test input combination matrix. A link-level timing assertion set is derived based on the timing work order semantic description and service contract definition. The link-level timing test input combination matrix and the link-level timing assertion set are assembled, and service call simulation parameters for cross-service test orchestration are configured to output a microservice link timing constraint test case set.

[0007] Furthermore, the process of parsing the service order text, identifying time-related descriptive words and business entities, extracting time-related constraint elements, and generating a time-series service order semantic description includes: performing lexical analysis on the service order text, segmenting the service order text into a sequence of lexical units, and tagging each lexical unit with part-of-speech tags; using dependency parsing to perform semantic parsing, identifying grammatical dependencies between words, and determining the business entities modified by time-related descriptive words by identifying subject-verb-object structures and modification relationships; and generating a time-series service order semantic description, which includes a list of services involved, time-series problem types, time-series parameter values, trigger condition descriptions, and expected behavior descriptions.

[0008] Furthermore, the inter-service call topology graph is a directed graph structure, where service nodes correspond to independently deployed microservice instances, and call edges represent inter-service call dependencies. The attributes carried by the call edges include the call interface identifier, call type, and timeout specification defined in the contract. When generating the inter-service call topology graph, historical call chain records are obtained from the distributed tracing system in conjunction with service call chain tracing data, and the actual inter-service call relationships are supplemented into the inter-service call topology graph generated based on the static contract definition.

[0009] Furthermore, the step of matching the list of services involved in the semantic description of the time-series work order with the service nodes in the service call topology diagram includes: using a combination of service identifier matching and interface name matching, first performing precise matching based on service identifiers, and for business entities that cannot be precisely matched, performing fuzzy matching based on interface names; calculating the matching confidence score using a cosine similarity algorithm, sorting the matching results according to the matching confidence score, and taking the service node with the highest matching confidence score as the matching result; identifying the microservice first mentioned in the triggering condition description from the list of involved services as the starting service node, and identifying the microservice last mentioned in the expected behavior description as the ending service node.

[0010] Furthermore, the timing-related code structure includes timer configuration code, timeout configuration code, asynchronous callback code, retry configuration code, delayed execution code, and concurrency control code; the static code analysis adopts the abstract syntax tree parsing method to parse the source code file into an abstract syntax tree structure, and identifies specific syntax patterns in the abstract syntax tree to locate the timing-related code structure; each feature element in the link-level timing code feature set includes the identifier of the service node to which it belongs, the code structure type, the code location information, the original value of the timing parameter, and the associated interface identifier.

[0011] Furthermore, the link-level timing parameter constraint graph is a graph structure with constraint attributes extended based on the service call link associated with the timing problem. It includes a set of service nodes, a set of call edges, and a set of constraints. The set of constraints includes node constraints and edge constraints. Node constraints are attached to service nodes, recording the local timeout threshold and retry configuration parameters of the service nodes. Edge constraints are attached to call edges, recording the constraint relationship between the service call timeout threshold configured by the caller and the response time of the callee. When generating the link-level timing parameter constraint graph, for each path from the entry service to the terminal service, the service call timeout thresholds of each call edge on the path are accumulated to obtain the upper bound of the cumulative link delay for that path. The upper bound of the cumulative link delay is added to the constraint set as a path-level constraint.

[0012] Furthermore, the link timing boundary analysis strategy includes: for cross-service timeout propagation critical points, identifying boundary conditions where the service call timeout threshold of the upstream service is equal to the response time of the downstream service, and generating two types of boundary test inputs: exactly triggering a timeout and exactly not triggering a timeout; for link cumulative latency boundaries, identifying boundary conditions where the end-to-end response time threshold is equal to the cumulative response time of each service, and generating two types of boundary test inputs: link cumulative latency exactly reaching the end-to-end response time threshold and exactly exceeding the end-to-end response time threshold; for retry triggering conditions, identifying timeout conditions that trigger retry and boundary conditions where the number of retry attempts is exhausted; the rows of the link-level timing test input combination matrix represent test scenarios, and the columns represent the response latency injection values ​​of each service node.

[0013] Furthermore, the link-level timing assertion set includes end-to-end response time verification assertions, inter-service timeout propagation correctness verification assertions, and duplicate request idempotency verification assertions. The end-to-end response time verification assertion is used to verify whether the total time from receiving a request from the ingress service to returning a response from the endpoint service meets the upper bound of the response time defined by the inter-service contract. The inter-service timeout propagation correctness verification assertion is used to verify whether the upstream service correctly triggers the timeout handling logic when the downstream service times out, including verifying whether the timeout exception is correctly captured, whether the degradation logic after the timeout is executed, and whether the timeout information is correctly passed to the caller. The duplicate request idempotency verification assertion is used to verify whether the downstream service can correctly handle duplicate requests when the retry mechanism is triggered.

[0014] Furthermore, the service call simulation parameters include the service stub's response latency configuration, response content configuration, exception injection configuration, and call count configuration; each test case in the microservice link timing constraint test case set includes a test case identifier, a test scenario description, service call simulation parameter configuration for each service node, the service call sequence executed during the test, assertion verification expressions, and expected test results; a priority score is calculated for each test case based on the problem severity in the timing work order semantic description and the boundary type of the test input. The priority score is obtained by weighted summation of the normalized problem severity score and the normalized boundary type score, and is arranged in descending order of priority score when outputting the microservice link timing constraint test case set.

[0015] This invention discloses a software iterative development method based on service work orders, comprising: a time-series work order parsing module, used to parse service work order text, identify time-series related descriptive words and business entities, extract time-series constraint elements, and generate a time-series work order semantic description; a call topology construction module, used to obtain service registration information and API contract definitions of the microservice architecture, parse the interface signatures exposed by each microservice and the inter-service call dependency relationships, and generate an inter-service call topology diagram; a call link positioning module, used to match the list of services involved in the time-series work order semantic description with the service nodes in the inter-service call topology diagram, determine the starting service node and the ending service node, trace the call path, and generate a time-series problem-related service call link; and a time-series code recognition module, used to traverse the code repositories corresponding to each service node in the time-series problem-related service call link, perform static code analysis, and identify... The system comprises four modules: a timing-related code structure module to generate a link-level timing code feature set; a constraint graph generation module to extract local timeout thresholds for each service node from the link-level timing code feature set, analyze the timeout propagation relationship between service calls, and generate a link-level timing parameter constraint graph; a test input generation module to identify cross-service timeout propagation critical points, link cumulative delay boundaries, and retry triggering conditions based on the link-level timing parameter constraint graph and applying link timing boundary analysis strategies, generating a link-level timing test input combination matrix; an assertion derivation module to derive a link-level timing assertion set based on the semantic description of timing work orders and the definition of inter-service contracts; and a test case assembly module to assemble the link-level timing test input combination matrix with the link-level timing assertion set, configure service call simulation parameters for cross-service test orchestration, and output a microservice link timing constraint test case set.

[0016] This invention extracts timing constraint elements from service ticket text to generate a semantic description of timing tickets. It combines microservice architecture configuration information to generate an inter-service call topology diagram and traces the service call links associated with timing issues. It traverses the code repositories of each service node to identify timing-related code structures and generate a link-level timing code feature set. It extracts timing parameters to generate a link-level timing parameter constraint diagram. It applies a link timing boundary analysis strategy to identify cross-service timeout propagation critical points, link cumulative delay boundaries, and retry triggering conditions to generate a link-level timing test input combination matrix. It derives a link-level timing assertion set including end-to-end response time verification assertions, inter-service timeout propagation correctness verification assertions, and duplicate request idempotency verification assertions. It assembles test inputs and assertions to configure cross-service test orchestration parameters and outputs a microservice link timing constraint test case set. This solves the technical problem of existing technologies being unable to generate test cases to verify cross-service link-level timing behavior, achieving the technical effect of providing automated test coverage for cross-service timing constraints in real-time microservice systems. Attached Figure Description

[0017] Figure 1This is a flowchart of a software iterative development method based on service work order driven by an embodiment of the present invention. Detailed Implementation

[0018] The software iterative development method based on service work order driven by this invention includes the following steps: Step 1: Parse the service order text, extract the time-series constraint elements, and generate a time-series service order semantic description. The system acquires service order text data submitted by users, performs lexical analysis and semantic parsing on the service order text, identifies time-related descriptive words and business entities in the service order text, extracts time-series constraint elements, and generates a time-series semantic description of the service order. The time-series constraint elements include timeout thresholds, delay descriptions, and sequence dependencies.

[0019] It should be noted that timing-related descriptive terms refer to words in the service ticket text that characterize timing-related behaviors, including but not limited to words such as timeout, delay, waiting, retry, blocking, lag, and slow response. Business entities refer to entity identifiers mentioned in the service ticket text, such as microservice names, interface names, and business operation names, which can be located to specific service nodes.

[0020] Furthermore, lexical analysis segments the service order text into a sequence of lexical units and performs part-of-speech tagging on each lexical unit. The types of part-of-speech tagging include nouns, verbs, adjectives, and time adverbs. Time-related descriptive words mainly correspond to the categories of verbs and time adverbs.

[0021] Furthermore, semantic parsing employs dependency parsing to identify grammatical dependencies between words in the service order text. By identifying subject-verb-object structures and modification relationships, it determines the business entities modified by time-related descriptive words, thereby establishing the association between time-series behaviors and service nodes.

[0022] It should be noted that the semantic description of a time-series work order is a structured semantic representation, containing the following fields: a list of services involved, the time-series problem type, the time-series parameter value, a description of the triggering condition, and a description of the expected behavior. For example, for a service work order describing how a timeout in the order service's call to the inventory service resulted in a retry causing the payment service to receive duplicate requests, the generated semantic description of the time-series work order would include the list of services involved as order service, inventory service, and payment service; the time-series problem type as timeout retry causing duplicate requests; and the triggering condition description as the order service's call to the inventory service timed out.

[0023] In this embodiment of the application, in order to improve the accuracy of time-related descriptor recognition, a time-series domain dictionary can be pre-configured. The time-series domain dictionary contains common terms in microservice time-series scenarios and their synonym mappings. During the lexical analysis stage, word matching and normalization processing are performed based on the time-series domain dictionary.

[0024] Step 2: Obtain microservice architecture configuration information, parse inter-service call dependencies, and generate an inter-service call topology graph. Obtain service registration information and API contract definitions from the microservice architecture, parse the interface signatures exposed by each microservice and the inter-service call dependencies, and generate an inter-service call topology graph.

[0025] It should be noted that service registration information refers to the service metadata stored in the microservice registry, including information such as service identifier, service address, health status, and service version. API contract definition refers to the interface specifications exposed by each microservice, including interface path, request parameters, response structure, and dependent service declarations. The format of API contract definition can be an OpenAPI specification document, a gRPC protocol definition file, or a service interface description language file.

[0026] Furthermore, the process of parsing the interface signature includes extracting the interface path, HTTP method type, data type of request parameters, and response status code definition from the API contract definition file, and constructing this information into an interface metadata structure.

[0027] Furthermore, the method for resolving inter-service call dependencies is as follows: extract the dependency service declaration field from the API contract definition. The dependency service declaration field records the identifiers and interface paths of other microservices that the current microservice needs to call when processing a request. The current microservice is regarded as the caller and the called microservice is regarded as the callee, thus establishing an inter-service call dependency record.

[0028] It should be noted that the service call topology graph is a directed graph structure, represented as follows: ,in Represents a set of service nodes. This represents the set of edges to be invoked. Each service node... This corresponds to a single, independently deployed microservice instance, where Represents the set of service nodes The first in Each service node. Each call edge microservices To microservices The service call dependencies, where Indicates from service node To service node The calling edge carries attributes including the calling interface identifier, the calling type, and the timeout specification defined in the contract.

[0029] In this embodiment of the application, in order to handle the dynamic changes in inter-service call relationships, service call chain tracing data can be combined when generating the inter-service call topology graph. Historical call chain records can be obtained from the distributed tracing system, and the actual inter-service call relationships can be added to the inter-service call topology graph generated based on the static contract definition, thereby obtaining a more complete inter-service call topology graph.

[0030] Step 3: Match service nodes based on the semantic description of the time-series work order, trace the call path, and generate the service call chain associated with the time-series problem. Match the list of services involved in the semantic description of the time-series work order with the service nodes in the service call topology diagram to determine the starting and ending service nodes involved in the time-series problem. In the service call topology diagram, trace the upstream and downstream call paths from the starting service node to the ending service node to generate the service call chain associated with the time-series problem.

[0031] It should be noted that service node matching combines service identifier matching and interface name matching. First, precise matching is performed based on the service identifier. For business entities that cannot be precisely matched, fuzzy matching is performed based on the interface name. The matching results are then sorted according to matching confidence, and the service node with the highest matching confidence is selected as the final match. Matching confidence is calculated using a cosine similarity algorithm. The input is the text vector of the business entity and the text vector of the service node identifier; the output is the cosine similarity value between the two vectors.

[0032] Furthermore, the method for determining the starting and ending service nodes is as follows: identify the microservice first mentioned in the triggering condition description of the time-series work order semantic description from the list of involved services as the starting service node, and identify the microservice last mentioned in the expected behavior description as the ending service node. If the microservice calling order is not clearly reflected in the service work order description, then the first microservice in the list of involved services is taken as the starting service node and the last microservice is taken as the ending service node.

[0033] Furthermore, the method for tracing the call path is as follows: starting from the starting service node, traverse along the direction of the call edge in the service call topology graph, record all service nodes and call edges passed during the traversal, and when the traversal reaches the ending service node, extract all service nodes and call edges on the traversal path to form the call path from the starting service node to the ending service node.

[0034] It should be noted that the service call chain associated with the timing problem is a subgraph of the service call topology graph, which includes all service nodes involved in the timing problem and the call edges between them. Each service node in the service call chain associated with the timing problem is marked with its position number in the call path, and the call edge is marked with its call direction and call type.

[0035] In this embodiment of the application, in order to handle the situation where there are multiple call paths, a breadth-first search algorithm can be used to traverse the inter-service call topology graph when tracing the call path, obtain all reachable paths from the starting service node to the ending service node, merge all reachable paths into a time-series problem-related service call link, and record the call depth information of each call path.

[0036] Step 4: Traverse the code repositories of each service node in the service call chain associated with the timing problem, identify timing-related code structures, and generate a chain-level timing code feature set. The code repositories corresponding to each service node in the service call chain associated with the timing problem are traversed. Static code analysis is performed on each code repository to identify the timing-related code structure in the code repository. The timing-related code structures of each service node are aggregated to generate a chain-level timing code feature set.

[0037] It should be noted that timing-related code structure refers to the program structure in the code repository involving timing behavior control, including timer configuration code, timeout configuration code, asynchronous callback code, retry configuration code, delayed execution code, and concurrency control code. Timer configuration code refers to the code that uses the timer API to set up periodic or delayed execution tasks; timeout configuration code refers to the code that sets service call timeout thresholds or connection timeout thresholds; asynchronous callback code refers to the code that registers callback functions using asynchronous programming models; and retry configuration code refers to the code that configures service call retry strategies, including the number of retries, retry interval, and retry conditions.

[0038] Furthermore, static code analysis employs an abstract syntax tree (AST) parsing method to parse source code files in the code repository into an AST structure. Specific syntax patterns are identified within the AST to locate timing-related code structures. For example, timeout configuration code can be located by identifying method call nodes containing timeout keywords, and retry configuration code can be located by identifying code nodes containing retry annotations or retry method calls.

[0039] Furthermore, the method for extracting the original values ​​of timing parameters is as follows: after identifying the timing-related code structure, extract the parameter assignment expression from the abstract syntax tree node of the timing-related code structure, parse the constant value or configuration variable reference in the parameter assignment expression, if the parameter value is a constant, directly extract the constant value, if the parameter value references a configuration variable, further trace the assignment of the configuration variable in the configuration file to obtain the specific value of the timing parameter.

[0040] It should be noted that the link-level temporal code feature set is a cross-code repository feature aggregation structure, represented as... ,in Represents a set of link-level timing code features. This represents the total number of feature elements, and each feature element... Indicates the first Each timing code feature includes the following attributes: the identifier of the service node to which it belongs, the code structure type, the code location information, the original value of the timing parameter, and the identifier of the associated interface.

[0041] In this embodiment of the application, in order to identify the timing code association relationship of cross-service calls, when generating the link-level timing code feature set, the timing-related code structure of each service node can be analyzed for association. Based on the call edge information, the timeout configuration code of the upstream service and the called interface code of the downstream service can be associated and mapped. A cross-service association identifier field is added to the feature element.

[0042] Step 5: Extract timing parameters from the link-level timing code feature set and generate a link-level timing parameter constraint diagram. Extract the local timeout thresholds of each service node from the link-level timing code feature set, analyze the timeout propagation relationship between service calls, and generate a link-level timing parameter constraint graph.

[0043] It should be noted that the local timeout threshold refers to the timeout parameter value configured for a single service node, including the service call timeout threshold, connection timeout threshold, read timeout threshold, and retry interval threshold. Timeout propagation refers to the impact of the upstream service's timeout configuration on the downstream service's call behavior. When the upstream service's call timeout threshold is less than the downstream service's response time, timeout propagation is triggered.

[0044] Furthermore, the method for extracting local timeout thresholds is as follows: traverse all feature elements in the link-level timing code feature set, filter out feature elements whose code structure type is timeout configuration code, extract timeout values ​​from the original value attributes of the timing parameters of these feature elements, associate the timeout values ​​with the identifier of the service node to which they belong, and construct a mapping relationship between the service node and the local timeout threshold.

[0045] Furthermore, the method for resolving timeout propagation relationships is as follows: For each call edge in the service call chain associated with the time-series problem, obtain the service call timeout threshold configured by the starting service node of the call edge, obtain the response time characteristics of the ending service node of the call edge, and when the service call timeout threshold of the starting service node is less than the maximum response time of the ending service node, establish a timeout propagation relationship record from the starting service node to the ending service node. The timeout propagation relationship record contains the threshold conditions that trigger timeout propagation.

[0046] It should be noted that the link-level timing parameter constraint graph is a graph structure with constraint attributes that extends the service call chain associated with timing problems. It is represented as follows: ,in Represents a set of service nodes. This indicates the call to the edge set. Represents a set of constraints. and Inherited from the time-series problem-related service call chain. Constraint set It includes two types of constraints: node constraints and edge constraints. Attached to the service node, it records the local timeout threshold and retry configuration parameters of the service node; edge constraints. Attached to the call side, it records the constraint relationship between the service call timeout threshold configured by the caller and the response time of the callee.

[0047] Furthermore, edge constraints The constraint relationship is expressed as follows: timeout processing is triggered when the service call timeout threshold configured by the caller is less than the actual response time of the callee. The constraints are used to identify the timeout propagation critical point in subsequent steps.

[0048] In this embodiment of the application, in order to characterize the cumulative latency constraints of multi-level service calls, the upper bound of the cumulative latency of the links can be calculated when generating the link-level timing parameter constraint graph. For each path from the ingress service to the endpoint service in the link-level timing parameter constraint graph, the service call timeout thresholds of each call edge on the path are accumulated to obtain the upper bound of the cumulative latency of the path. ,in Indicates the upper bound of the cumulative link delay. This indicates the call path from the entry service to the terminal service. Indicates the call path The call edge in the middle, Indicates calling edge The corresponding service call timeout threshold will be used to add the upper bound of the cumulative latency of the link as a path-level constraint to the constraint set.

[0049] Step 6: Based on the link-level timing parameter constraint diagram, apply the link-time boundary analysis strategy to generate the link-level timing test input combination matrix. Based on the link-level timing parameter constraint graph, the link timing boundary analysis strategy is applied to identify the critical point of cross-service timeout propagation, the link cumulative delay boundary and the retry triggering condition, and generate the link-level timing test input combination matrix.

[0050] It should be noted that the link timing boundary analysis strategy is a test input generation strategy for distributed timing constraints, and includes the following analysis rules: (1) For the cross-service timeout propagation critical point, identify the boundary condition where the service call timeout threshold of the upstream service is equal to the response time of the downstream service, and generate two types of boundary test inputs: exactly triggering timeout and exactly not triggering timeout. (2) For the link cumulative delay boundary, identify the boundary condition where the end-to-end response time threshold is equal to the cumulative response time of each service, and generate two types of boundary test inputs: the link cumulative delay just reaches the end-to-end response time threshold and the link cumulative delay just exceeds the end-to-end response time threshold. (3) For retry triggering conditions, identify the timeout conditions that trigger retry and the boundary conditions that exhaust the number of retries.

[0051] Furthermore, the method for identifying the cross-service timeout propagation critical point is as follows: traverse all call edges in the link-level timing parameter constraint graph, and for each call edge, obtain the service call timeout threshold configured by the caller from the edge constraints of the call edge. Use the service call timeout threshold as the cross-service timeout propagation critical point, generate a test input whose response time is equal to the service call timeout threshold minus the preset tolerance value as the boundary input that just does not trigger a timeout, and generate a test input whose response time is equal to the service call timeout threshold plus the preset tolerance value as the boundary input that just triggers a timeout.

[0052] Furthermore, the method for identifying the cumulative link delay boundary is as follows: obtain path-level constraints from the constraint set of the link-level timing parameter constraint graph, extract the upper bound of the cumulative link delay as the end-to-end response time threshold, generate test inputs whose cumulative response time value of each service is equal to the end-to-end response time threshold minus the preset tolerance value as boundary inputs that just reach the end-to-end response time threshold, and generate test inputs whose cumulative response time value of each service is equal to the end-to-end response time threshold plus the preset tolerance value as boundary inputs that just exceed the end-to-end response time threshold.

[0053] Furthermore, the method for identifying retry triggering conditions is as follows: obtain retry configuration parameters from the node constraints of the link-level timing parameter constraint graph, extract the number of retryes and retry interval, generate test inputs where the response time exceeds the service call timeout threshold and the number of retryes has not reached the configured value as boundary inputs for triggering retry, and generate test inputs where the response time exceeds the service call timeout threshold and the number of retryes is equal to the configured value as boundary inputs for exhausting the number of retryes.

[0054] Furthermore, the method for generating the link-level timing test input combination matrix is ​​as follows: group all the test inputs corresponding to the identified boundary conditions according to the test scenarios. Each test scenario corresponds to a row of the link-level timing test input combination matrix. For each test scenario, determine the response latency time that needs to be injected by each service node in the timing problem-related service call link, and fill these response latency time values ​​into the cells of each column of the corresponding row of the link-level timing test input combination matrix. Each column corresponds to a different service node.

[0055] It should be noted that the link-level timing test input combination matrix is ​​a structured representation of test inputs. The rows of the link-level timing test input combination matrix represent the test scenario, and the columns represent the response latency injection values ​​of each service node. The value of each cell represents the response latency time that needs to be injected into the corresponding service node under the corresponding test scenario.

[0056] Furthermore, the response latency injection value for each test scenario in the link-level timing test input combination matrix is ​​determined based on the identified boundary conditions. For the cross-service timeout propagation critical point scenario, the response latency injection value of the downstream service node is set to the service call timeout threshold of the upstream service plus or minus a preset tolerance value. For the link cumulative latency boundary scenario, the response latency injection value of each service node is distributed proportionally so that the cumulative response time of each service is equal to the end-to-end response time threshold plus or minus a preset tolerance value. For the retry triggering condition scenario, the response latency injection value of the service node being retried is set to the value exceeding the service call timeout threshold of the caller.

[0057] In this embodiment of the application, in order to reduce the redundancy of test input combinations, a pairing test algorithm can be applied when generating the link-level timing test input combination matrix. The input of the pairing test algorithm is the response delay injection value range of each service node, and the output of the pairing test algorithm is the minimum test input set covering the delay combinations of each pair of service nodes, thereby reducing the number of test cases while ensuring boundary coverage.

[0058] Step 7: Based on the semantic description of the time-series work order and the definition of the service inter-contract, derive the set of link-level time-series assertions. Based on the expected timing behavior in the semantic description of the timing work order and the timing specifications defined in the inter-service contract, a set of link-level timing assertions is derived. The set of link-level timing assertions includes end-to-end response time verification assertions, inter-service timeout propagation correctness verification assertions, and duplicate request idempotency verification assertions.

[0059] It should be noted that the end-to-end response time verification assertion is used to verify whether the total time from receiving a request from the ingress service to returning a response from the endpoint service meets the upper bound of the response time defined in the inter-service contract. The expression for the end-to-end response time verification assertion is: ,in This represents the actual measured end-to-end response time. This represents the upper bound of the response time defined in the service contract.

[0060] It should be noted that the service timeout delivery correctness verification assertion is used to verify whether the upstream service correctly triggers the timeout handling logic when the downstream service times out. This includes verifying whether the timeout exception is correctly caught, whether the degradation logic after the timeout is executed, and whether the timeout information is correctly delivered to the caller.

[0061] Furthermore, the method for deriving the end-to-end response time verification assertion is as follows: extract the interface specification of the entry service from the service inter-contract definition, and obtain the upper bound of the response time declared in the interface specification of the entry service as... The upper bound of the response time declared in the interface specification of the entry service is compared with the actual end-to-end response time measured during test execution to generate a verification expression. As an end-to-end response time verification assertion condition.

[0062] Furthermore, the method for deriving the verification assertion of the correctness of timeout propagation between services is as follows: Identify call edges with timeout propagation relationships from the link-level timing parameter constraint graph. For each call edge with a timeout propagation relationship, generate three types of verification assertions. The first type of assertion verifies whether the upstream service has caught the timeout exception by checking the exception logs or execution flags of the exception handling code of the upstream service. The second type of assertion verifies whether the upstream service has executed the degradation logic by checking the call records of the degradation method. The third type of assertion verifies whether the timeout information has been passed to the caller by checking whether the response returned by the upstream service contains a timeout error code or timeout error information.

[0063] Furthermore, the method for deriving the idempotency verification assertion for duplicate requests is as follows: identify service nodes configured with retry policies from the node constraints of the link-level timing parameter constraint graph. For each service node configured with a retry policy, generate two types of verification assertions. The first type of assertion verifies whether duplicate requests are correctly identified by checking whether downstream services have recorded the identifier of duplicate requests. The second type of assertion verifies whether the processing result of duplicate requests is consistent with the first request by comparing whether the response result of the first request is the same as the response result of the duplicate request.

[0064] It should be noted that the duplicate request idempotency verification assertion is used to verify whether the downstream service can correctly handle duplicate requests when the retry mechanism is triggered, including verifying whether duplicate requests are identified, whether the processing result of duplicate requests is consistent with the first request, and whether duplicate requests produce side effects.

[0065] In this embodiment of the application, in order to generate more targeted assertions, assertion templates can be selected based on the time-series problem type in the semantic description of the time-series work order. For timeout problems, assertions verifying the correctness of inter-service timeout transmission are generated first. For retry problems, assertions verifying the idempotency of repeated requests are generated first. For delay problems, assertions verifying end-to-end response time are generated first.

[0066] Step 8: Assemble the link-level timing test input combination matrix and the link-level timing assertion set, configure cross-service test orchestration parameters, and output the microservice link timing constraint test case set. Assemble the link-level timing test input combination matrix with the link-level timing assertion set, configure the corresponding assertion verification logic for each test input combination, configure the service call simulation parameters for cross-service test orchestration, and output the microservice link timing constraint test case set.

[0067] It should be noted that service call simulation parameters refer to configuration parameters used to simulate service response behavior during test execution. These include the service stub's response latency configuration, service stub's response content configuration, service stub's exception injection configuration, and service stub's call count configuration. The response latency configuration is set based on the response latency injection value in the link-level timing test input combination matrix; the exception injection configuration sets the triggering conditions for timeout exceptions according to the timeout scenarios to be tested.

[0068] Furthermore, the method for assembling test inputs and assertions is as follows: traverse each row of the link-level timing test input combination matrix, select assertions related to the test scenario from the link-level timing assertion set for each test scenario, and combine the response delay injection values ​​of each service node corresponding to the test scenario with the selected assertions to form a complete test case.

[0069] Furthermore, the method for configuring service call simulation parameters is as follows: For each service node in the test case, configure the response latency of the service stub according to the response latency injection value corresponding to the service node in the link-level timing test input combination matrix; configure the exception injection conditions of the service stub according to whether the test scenario involves timeout exceptions; if the test scenario needs to trigger timeout, configure the service stub to throw a timeout exception when the response latency exceeds the service call timeout threshold; configure the call counter of the service stub to record the number of times the service node is called to support the verification of repeated requests.

[0070] It should be noted that each test case in the microservice link timing constraint test case set contains the following components: test case identifier, test scenario description, service call simulation parameter configuration for each service node, service call sequence for test execution, assertion verification expression, and expected test results.

[0071] In this embodiment of the application, in order to support the automated execution of test cases, the microservice link timing constraint test case set can be output as a standardized test script format, and an executable test code file can be generated according to the specification of the target test framework. The test code file includes service stub configuration code, test request sending code, and assertion verification code.

[0072] In this embodiment, to facilitate the priority ranking of test cases, a priority score can be calculated for each test case based on the problem severity in the semantic description of the time-series work order and the boundary type of the test input. The priority score is then appended to the metadata of the test case, and the test cases are sorted in descending order of priority score when outputting the microservice link time-series constraint test case set. When calculating the priority score, the problem severity score and boundary type score are first normalized using a mean normalization method based on the range, mapping both types of scores to the same numerical range. Then, a weighted summation method is used to calculate the priority score, using the following formula: ,in Indicates the priority score. This represents the normalized score indicating the severity of the problem. This represents the normalized boundary type score. and Represents the weight coefficients and satisfies .

[0073] This implementation provides a method for generating cross-service link timing constraint test cases for microservice real-time systems. By acquiring service registration information and API contract definitions, it generates an inter-service call topology graph, expanding the location of service ticket timing issues from a single service boundary to the complete call chain, enabling the analysis scope to cover multiple collaborating service nodes. By traversing the code repositories of each service node in the service call chain associated with the timing issue, it identifies timing-related code structures and generates a link-level timing code feature set, achieving unified identification and aggregation of timing code structures in distributed deployments. By extracting local timeout thresholds for each service node and timeout propagation relationships between services from the link-level timing code feature set, it generates a link-level timing parameter constraint graph, depicting the dependencies and propagation paths of timeout configurations between services. By applying a link timing boundary analysis strategy to identify cross-service timeout propagation critical points, link cumulative delay boundaries, and retry triggering conditions, the generated link-level timing test input combination matrix can provide test coverage for cross-service timing boundary conditions. By deriving a set of link-level timing assertions that includes end-to-end response time verification assertions, inter-service timeout propagation correctness verification assertions, and duplicate request idempotency verification assertions, test cases can verify the correctness of cross-service link-level timing behavior. Therefore, this implementation can generate test cases that verify cross-service link-level timing constraints, providing automated test coverage for cross-service timing constraints in microservice real-time systems.

[0074] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

[0075] An online education platform uses a microservice architecture to build its real-time interactive classroom system. On March 15, 2024, this system received a critical service ticket (ticket number: [not provided]). The work order description reads: "After a student initiates a class question, the system responds slowly, taking about 5 seconds to display that the question was successfully asked. However, teachers often do not receive the question notification or receive duplicate notifications. The problem is particularly severe during peak hours (7:00 PM - 9:00 PM)." This interactive classroom system involves four core microservices: ClassroomGateway, QuestionService, NotificationService, and TeacherService. The system architecture requires that the end-to-end response time from student submitting a question to teacher receiving the notification should not exceed 3 seconds. According to the service registry records, the ClassroomGateway service is configured with a timeout threshold of 2 seconds, the QuestionService's call to the NotificationService has a timeout threshold of 1.5 seconds, and a retry mechanism is configured (maximum of 2 retries, with a retry interval of 500 milliseconds).

[0076] Application example of step 1: Parsing service order text and extracting time-series constraint elements. For work orders Lexical analysis and semantic parsing are performed. First, lexical analysis is conducted, segmenting the work order text into lexical units: "Student / Noun", "Initiate / Verb", "Classroom Question / Noun", "Response / Verb", "Slow / Adjective", "5 Seconds / Time Adverb", "Display / Verb", "Question Successful / Noun", "Teacher / Noun", "Not Received / Verb", "Question Notification / Noun", "Received / Verb", "Repeated / Adjective", and "Question Notification / Noun". Through temporal domain dictionary matching, temporal-related descriptive words are identified: "Slow Response", "5 Seconds", "Not Received", and "Repeated", and the business entities are identified: "Student", "Classroom Question", "Teacher", and "Question Notification".

[0077] Through dependency parsing, we establish the semantic relationship of "slow response" modifying "classroom question", the temporal relationship of "5 seconds" modifying "response", and the quantitative relationship of "repeated" modifying "question notification".

[0078] Table 1 Input data for step 1 Table 2 Output data of step 1 Application example of step 2: Generating an inter-service call topology graph Retrieve registration information for four services from the microservice registry center, and extract API contract definitions from the OpenAPI specification documents of each service. Expose the interface of the classroom gateway service. Dependent on question processing service Interface; the question processing service depends on the message push service. Interface; the message push service depends on the teacher-side service. interface.

[0079] Parse the interface signature and extract interface metadata. For example, the query processing service. The HTTP method for the interface is POST, and the request parameters include... (String type) (String type) (String type), the response status codes include 200 (success) and 504 (timeout).

[0080] Analyze inter-service call dependencies and establish call edges: Classroom Gateway Service Question processing service Push notification service Teacher-side service.

[0081] Table 3 Output data of step 2 (service node information) Table 4 Output data of step 2 (call edge information) The service call topology structure is as follows: ,in , .

[0082] Application example of step 3: Generating service call chains related to timing issues Match the list of services involved in the semantic description of the time-series work order with the service call topology diagram. "Classroom Gateway Service" and... Exact match, "question processing service" and Precise matching, "message push service" and Precise matching, "teacher-side service" and Exact match.

[0083] Based on the trigger condition description "students submit classroom questions through the classroom gateway service", the starting service node is determined to be... (ClassroomGateway); Based on the expected behavior description "the teacher-side service should receive a question notification", the service termination node is determined to be... (TeacherService).

[0084] Using a breadth-first search algorithm, from The process involves traversing the service topology graph and tracing the arrival points. Call path: This path passes through the calling edge. The call depth is 3.

[0085] The timing issue involves a service call chain containing 4 service nodes and 3 call edges. The position numbers of each service node are as follows: (Serial Number 1) (Serial No. 2) (Serial No. 3) (Serial number 4).

[0086] Application example of step 4: Generating a set of link-level timing code features Iterate through the code repositories corresponding to the four service nodes and perform static code analysis on each repository.

[0087] In the QuestionService code repository, the timeout configuration code is located in the file. Line 127: restTemplate.setReadTimeout(1500); / / Timeout threshold for calling NotificationService The retry configuration code is located in the file. The comment on line 132: @Retryable(maxAttempts = 2, backoff = @Backoff(delay = 500)) In the NotificationService code repository, the code that identifies the timeout configuration is located in the file. Line 89: httpClient.setConnectTimeout(1000); / / Timeout threshold for calling TeacherService In the ClassroomGateway code repository, the timeout configuration code was found to be located in the configuration file. Line 45: timeout: 2000ms # Timeout threshold for calling QuestionService Extract the raw values ​​of timing parameters from the abstract syntax tree nodes: The timeout threshold for QuestionService to call NotificationService is 1500 milliseconds, the maximum number of retries is 2, and the retry interval is 500 milliseconds; the timeout threshold for NotificationService to call TeacherService is 1000 milliseconds; and the timeout threshold for ClassroomGateway to call QuestionService is 2000 milliseconds.

[0088] Table 5 Output data of step 4 (link-level timing code feature set) The link-level timing code feature set is represented as It contains a total of 4 feature elements.

[0089] Application example of step 5: Generating link-level timing parameter constraint diagrams Extract local timeout thresholds from the link-level time-series code feature set. Iterate through the feature elements and filter out those whose code structure type is timeout configuration code. Extract timeout values ​​and establish mappings: The configured call timeout threshold is 2000 milliseconds. The configured call timeout threshold is 1500 milliseconds. The configured call timeout threshold is 1000 milliseconds.

[0090] Analyze the timeout propagation relationship. For the calling edge... Starting point service The configured timeout threshold is 1500 milliseconds. If the endpoint service... If the response time exceeds 1500 milliseconds, a timeout propagation is triggered; for the calling edge Starting point service The configured timeout threshold is 1000 milliseconds. If the endpoint service... If the response time exceeds 1000 milliseconds, a timeout propagation will be triggered.

[0091] Calculate the upper bound of the cumulative link delay. From arrive The call path is The timeout thresholds for each call edge on the path are accumulated:

[0092] Link-level timing parameter constraint diagram is represented as follows , where the constraint set Includes node constraints and edge constraints and path-level constraints millisecond.

[0093] Application example of step 6: Generating the link-level timing test input combination matrix Apply link timing boundary analysis strategies to identify key boundary conditions.

[0094] Identification of critical points for cross-service timeout propagation: for call edges The service call timeout threshold is 1500 milliseconds. Response time is milliseconds (just enough not to trigger a timeout) and Two types of boundary inputs are considered: milliseconds (exactly triggering a timeout) and a preset tolerance of 50 milliseconds. For the calling edge... The service call timeout threshold is 1000 milliseconds, generating... Response time is milliseconds and Two types of boundary inputs in milliseconds.

[0095] Link cumulative delay boundary identification: The end-to-end response time threshold is 3000 milliseconds, and the upper bound of the link cumulative delay is 4500 milliseconds. Generate boundary inputs that proportionally distribute the response times of each service: exactly reaching the end-to-end threshold; the cumulative value of the response times of each service. Milliseconds, evenly distributed across the call chain length, with an injection latency of approximately [missing information] per service node. Milliseconds. Just exceeding the end-to-end threshold: the cumulative response time of all services. Milliseconds, injection latency per service node is approximately millisecond.

[0096] Retry trigger condition identification: Configure a maximum of 2 retries with a retry interval of 500 milliseconds. Generate test input: Trigger retry scenario: The response time is 1550 milliseconds (exceeding the 1500 millisecond timeout threshold), and the number of retries is set to 1. Scenario where the number of retries is exhausted: The response time is 1550 milliseconds, and the number of retries is set to 2.

[0097] Application example of step 7: Deriving the set of link-level timing assertions Based on the expected behavior in the semantic description of the time-series work order, "the teacher-side service should receive a unique question notification within 3 seconds" and the definition of the service contract, three types of assertions are derived.

[0098] End-to-end response time verification assertion: Extract the upper bound of response time from the API contract definition of the Classroom Gateway service. Milliseconds, generating validation expressions .

[0099] Service timeout propagation correctness verification assertion: For the calling edge The timeout propagation relationship generates three types of assertions: Assertion 1: Verification Check if a timeout exception was caught. Check if a "TimeoutException" record exists in the exception log. Assertion 2: Verification Check whether to execute the degradation logic and the degradation method. The call log. Assertion 3: Verify whether the timeout information is passed to... ,examine Return to Does the response contain error code 504?

[0100] Idempotency verification assertion for repeated requests: [Targeting...] The retry configuration generates two types of assertions: Assertion 4: Verification Does it identify duplicate requests? Check Does the log record a duplicate request identifier? Assertion 5: Verify the consistency of processing results for duplicate requests by comparing the initial request with the retry request. Are the received notifications completely identical?

[0101] Table 6 Output data of step 7 (link-level timing assertion set) The link-level timing assertion set contains 6 assertion expressions, corresponding to the service timeout propagation correctness verification (3 sub-assertions), duplicate request idempotency verification (2 sub-assertions), and end-to-end response time verification (1 assertion).

[0102] Application example of step 8: Outputting a set of microservice link timing constraint test cases. The eight test scenarios of the link-level timing test input combination matrix are assembled with the link-level timing assertion set.

[0103] For test scenarios (Just triggered) (Timeout), configure service call simulation parameters: Service stub: Response delay 100 milliseconds, returned normally. Service stub: Response latency 200 milliseconds, call Injection delay. Service stub: Response latency 1550 milliseconds (exceeding) The timeout threshold of 1500 milliseconds is used to trigger a timeout exception. The exception injection condition is configured to throw a TimeoutException when the response time is greater than 1500 milliseconds. Service stump: Response latency of 200 milliseconds, configured with a call counter to record the number of notifications received.

[0104] Select the relevant assertion for this test scenario: Assertion 1 (Verification) (Catch timeout exception), Assertion 2 (Verify) Execute the degradation logic), assertion 3 (verify the timeout message delivery).

[0105] For test scenarios (Trigger retry), configure service call simulation parameters: Service stub: The first call response delay of 1550 milliseconds triggers a timeout, and the first retry response delay of 800 milliseconds returns normally. Service stub: Configure a call counter to record 2 calls (first failure + successful retry).

[0106] Select the relevant assertions for this test scenario: Assertion 4 (verify duplicate request identification) and Assertion 5 (verify the consistency of processing results).

[0107] Calculate the priority score for each test case. For the test scenario... The severity of the problem is "high," corresponding to a score. The score corresponding to the boundary type "timeout propagation critical point" Assume the severity rating range for all test scenarios is as follows: The boundary type scoring range is Range normalization is used:

[0108]

[0109] Set weighting coefficients Calculate the priority score:

[0110] Table 7 Output data of step 8 (microservice link timing constraint test case set) The microservice link timing constraint test case set contains 8 test cases, each containing a test case identifier (e.g., ...). Test scenario description, service call simulation parameter configuration for each service node, and service call sequence for test execution. The test cases are output after asserting and validating the expression and the expected test results. The test cases are sorted in descending order of priority score.

[0111] The service ticket text (Table 1) is semantically parsed to generate a time-series service ticket semantic description (Table 2). The list of services involved in this semantic description is matched with the service call topology diagram (Tables 3 and 4) generated from service registration information and API contract definitions to trace the service call chain associated with the time-series problem. The code repositories of each service node in the call chain are traversed to identify the time-series-related code structure and aggregate it into a link-level time-series code feature set (Table 5). Local timeout thresholds and retry configurations are extracted from this feature set, and the timeout propagation relationship is analyzed in combination with the service call relationship to generate a link-level time-series parameter constraint diagram (Table 6). Based on the constraint diagram, a link-series time-series boundary analysis strategy is applied to identify the cross-service timeout propagation critical point, the link cumulative delay boundary, and the retry triggering condition to generate a link-level time-series test input combination matrix (Table 7). At the same time, a link-level time-series assertion set is derived based on the time-series service ticket semantic description and the service contract definition (Table 8). The test input matrix and the assertion set are assembled, the service call simulation parameters are configured, and finally, a microservice link-series time-series constraint test case set containing 8 test cases is output (Table 9).

Claims

1. A software iterative development method based on service work order driven by service work orders, characterized in that, Includes the following steps: The service order text is parsed, time-related descriptive words and business entities are identified, time-series constraint elements are extracted, and a time-series semantic description of the service order is generated; the time-series constraint elements include timeout thresholds, delay descriptions, and sequence dependencies. Obtain service registration information and API contract definitions of the microservice architecture, parse the interface signatures exposed by each microservice and the inter-service call dependencies, and generate an inter-service call topology graph; The service list involved in the semantic description of the time-series work order is matched with the service nodes in the service call topology diagram to determine the starting service node and the ending service node, trace the call path, and generate the service call chain associated with the time-series problem. By traversing the code repositories corresponding to each service node in the service call chain associated with the timing problem, static code analysis is performed to identify timing-related code structures and generate a chain-level timing code feature set. Extract the local timeout threshold of each service node from the link-level timing code feature set, parse the timeout propagation relationship between service calls, and generate a link-level timing parameter constraint graph; Based on the link-level timing parameter constraint diagram, the link timing boundary analysis strategy is applied to identify the cross-service timeout propagation critical point, the link cumulative delay boundary and the retry triggering condition, and generate the link-level timing test input combination matrix. Based on the semantic description of the time-series work orders and the definition of the service inter-contract, derive the set of link-level time-series assertions; Assemble the link-level timing test input combination matrix with the link-level timing assertion set, configure the service call simulation parameters for cross-service test orchestration, and output the microservice link timing constraint test case set.

2. The method according to claim 1, characterized in that, The parsing service order text identifies time-related descriptive words and business entities, extracts time-series constraint elements, and generates a time-series service order semantic description, including: Lexical analysis is performed on the service order text to segment it into a sequence of lexical units, and part-of-speech tagging is performed on each lexical unit. Semantic parsing is performed using dependency parsing to identify grammatical dependencies between words. By identifying subject-verb-object structures and modification relationships, the business entities modified by time-related descriptive words are determined. Generate a semantic description of the time-series work order, which includes a list of services involved, the type of time-series problem, the value of time-series parameter, a description of the triggering conditions, and a description of the expected behavior.

3. The method according to claim 1, characterized in that, The service call topology graph is a directed graph structure, where service nodes correspond to independently deployed microservice instances, and call edges represent service call dependencies. The attributes carried by the call edges include the call interface identifier, call type, and timeout specification defined in the contract. When generating the service call topology graph, historical call chain records are obtained from the distributed tracing system by combining service call chain tracing data, and the actual service call relationships are added to the service call topology graph generated based on the static contract definition.

4. The method according to claim 1, characterized in that, The step of matching the list of services involved in the semantic description of the time-series work order with the service nodes in the inter-service call topology graph includes: The method combines service identifier matching and interface name matching. First, precise matching is performed based on the service identifier. For business entities that cannot be precisely matched, fuzzy matching is performed based on the interface name. The matching confidence score is calculated using the cosine similarity algorithm. The matching results are then sorted according to the matching confidence score, and the service node with the highest matching confidence score is taken as the matching result. Identify the microservice first mentioned in the trigger condition description from the list of services involved as the starting service node, and identify the microservice last mentioned in the expected behavior description as the ending service node.

5. The method according to claim 1, characterized in that, The timing-related code structure includes timer configuration code, timeout configuration code, asynchronous callback code, retry configuration code, delayed execution code, and concurrency control code; The static code analysis employs an abstract syntax tree parsing method to parse source code files into an abstract syntax tree structure, and identifies specific syntax patterns in the abstract syntax tree to locate time-related code structures. Each feature element in the link-level timing code feature set includes the identifier of the service node to which it belongs, the code structure type, the code location information, the original value of the timing parameter, and the associated interface identifier.

6. The method according to claim 1, characterized in that, The link-level timing parameter constraint graph is a graph structure with constraint attributes that is extended based on the service call link associated with the timing problem. It includes a set of service nodes, a set of call edges, and a set of constraints. The constraint set includes node constraints and edge constraints. Node constraints are attached to service nodes and record the local timeout threshold and retry configuration parameters of the service nodes. Edge constraints are attached to the call edges and record the constraint relationship between the service call timeout threshold configured by the caller and the response time of the callee. When generating the link-level timing parameter constraint graph, for each path from the ingress service to the terminal service, the service call timeout threshold of each calling edge on the path is accumulated to obtain the upper bound of the link cumulative delay for that path, and the upper bound of the link cumulative delay is added as a path-level constraint to the constraint set.

7. The method according to claim 1, characterized in that, The link timing boundary analysis strategy includes: For the critical point of cross-service timeout propagation, identify the boundary condition that the service call timeout threshold of the upstream service is equal to the response time of the downstream service, and generate two types of boundary test inputs: exactly triggering timeout and exactly not triggering timeout. For the cumulative link delay boundary, identify the boundary condition that the end-to-end response time threshold is equal to the cumulative response time of each service, and generate two types of boundary test inputs: the cumulative link delay just reaches the end-to-end response time threshold and the cumulative link delay just exceeds the end-to-end response time threshold. For retry triggering conditions, identify the timeout conditions that trigger retry and the boundary conditions that exhaust the number of retries; The rows of the link-level timing test input combination matrix represent the test scenario, and the columns represent the response latency injection values ​​of each service node.

8. The method according to claim 1, characterized in that, The link-level timing assertion set includes end-to-end response time verification assertions, inter-service timeout transmission correctness verification assertions, and duplicate request idempotency verification assertions. The end-to-end response time verification assertion is used to verify whether the total time from receiving a request from the ingress service to returning a response from the endpoint service meets the upper bound of the response time defined in the inter-service contract. The service timeout delivery correctness verification assertion is used to verify whether the upstream service correctly triggers the timeout handling logic when the downstream service times out, including verifying whether the timeout exception is correctly captured, whether the degradation logic after the timeout is executed, and whether the timeout information is correctly delivered to the caller. The idempotency verification assertion for repeated requests is used to verify whether the downstream service can correctly handle repeated requests when the retry mechanism is triggered.

9. The method according to claim 1, characterized in that, The service call simulation parameters include the service stub's response delay configuration, response content configuration, exception injection configuration, and call count configuration; Each test case in the microservice link timing constraint test case set includes a test case identifier, a test scenario description, service call simulation parameter configuration for each service node, service call sequence for test execution, assertion verification expression, and expected test results. Priority scores are calculated for each test case based on the severity of the problem in the semantic description of the time-series work order and the boundary type of the test input. The priority scores are obtained by weighted summation of the normalized problem severity score and the normalized boundary type score, and are arranged in descending order of priority scores when outputting the microservice link time-series constraint test case set.

10. A service order-driven software iterative development system, used to execute the method described in any one of claims 1 to 9, characterized in that, include: The time-series work order parsing module is used to parse service work order text, identify time-series related descriptive words and business entities, extract time-series constraint elements, and generate a semantic description of the time-series work order. The topology building module is invoked to obtain service registration information and API contract definitions of the microservice architecture, parse the interface signatures exposed by each microservice and the inter-service call dependencies, and generate an inter-service call topology graph. The call link localization module is used to match the list of services involved in the semantic description of the time sequence work order with the service nodes in the service call topology diagram, determine the starting service node and the ending service node, trace the call path, and generate the call link of the service associated with the time sequence problem. The timing code recognition module is used to traverse the code repositories corresponding to each service node in the service call chain associated with timing issues, perform static code analysis, identify timing-related code structures, and generate a chain-level timing code feature set. The constraint graph generation module is used to extract the local timeout threshold of each service node from the link-level timing code feature set, parse the timeout propagation relationship between service calls, and generate a link-level timing parameter constraint graph. The test input generation module is used to identify cross-service timeout propagation critical points, link cumulative delay boundaries, and retry triggering conditions based on the link-level timing parameter constraint diagram and applying link timing boundary analysis strategies, and generate a link-level timing test input combination matrix. The assertion derivation module is used to derive a set of link-level time-series assertions based on the semantic description of time-series work orders and the definition of inter-service contracts. The test case assembly module is used to assemble the link-level timing test input combination matrix and the link-level timing assertion set, configure the service call simulation parameters for cross-service test orchestration, and output the microservice link timing constraint test case set.

Images