A dynamic self-verification method based on isomorphism execution of service flow-test flow

Abstract

This invention discloses a dynamic self-verification method based on the homogeneous and heterogeneous execution of business flow and test flow. The method includes: uniformly describing business logic and corresponding interface test contracts using a strongly typed Domain-Specific Language (DSL); utilizing a dual-path compilation engine to simultaneously compile the homogeneous DSL description into a stateful business workflow for execution by the process engine and a stateless, composable set of atomic test contracts for invocation by the test executor; and at runtime, achieving loosely coupled synchronous triggering and execution of business flow and test flow based on a high-throughput event bus, performing real-time, high-fidelity contract verification, performance monitoring, and chaos probe testing on cross-system interface calls in a production environment. This invention transforms traditional post-event, offline integration testing into in-process, online, and continuous system-native capabilities, effectively solving the industry problems of difficult integration testing of complex enterprise system groups and passive operation and maintenance monitoring.

Description

Technical Field

[0001] This invention relates to the field of software test automation technology, specifically to a dynamic self-verification method based on the homogeneous heterogeneous execution of business flow and test flow. Background Technology

[0002] Enterprise-driven procurement and bidding are core components of project execution and supply chain management, and their efficiency and quality directly impact operational costs and project success. However, existing technological solutions still face significant challenges in achieving full digitalization and intelligentization: system integration complexity and testing and verification difficulties. Modern enterprise IT environments consist of multiple heterogeneous systems (such as Project Management Systems (PMS), Supplier Relationship Management (SRM), and Intelligent Information Systems (IAS)). As a business process hub, the self-procurement system requires deep integration with these systems. Traditional system integration testing (SIT) and end-to-end (E2E) testing methods suffer from challenges such as complex environment setup, high test case maintenance costs, and low execution frequency, making integrated testing of complex enterprise system clusters difficult. This often leads to interface failures, performance bottlenecks, and data inconsistencies between systems only becoming apparent after deployment, causing business interruptions and economic losses. Summary of the Invention

[0003] To address the problems existing in the prior art, this invention provides a dynamic self-verification method based on the homogeneous and heterogeneous execution of business flow and test flow for automated bidding processes, effectively solving the problem of difficult integration testing of complex enterprise system groups in automated bidding processes. The technical solution is as follows:

[0004] Firstly, a dynamic self-verification method based on the homogeneous and heterogeneous execution of business flow and test flow is provided for automated bidding processes, including the following steps:

[0005] Step 1, Unified Modeling Phase: The unified modeling phase uses a domain-specific language (DSL) based on YAML syntax extensions to perform a unified declarative description of each business node in the bidding business process and its corresponding cross-system interface test and verification points, thereby obtaining the DSL description.

[0006] Step 2, Heterogeneous Compilation Stage: This stage uses a dual-path compilation engine to compile the DSL description into two heterogeneous executable objects simultaneously. One is a stateful business execution sequence driven by the process engine, serialized in JSON format, and possessing state management and transaction capabilities. The other is a stateless interface test suite composed of multiple atomic test contract verification units, used for test executor calls, and automatically generates an end-to-end test plan diagram describing the execution order and dependencies of the verification units.

[0007] Step 3, the execution phase, in which the business flow and the test flow are executed from the same source but in a heterogeneous manner. When the business flow is executed, the test executor and the process engine run concurrently and asynchronously through a loosely coupled triggering mechanism based on a high-throughput event bus. For each cross-system interface call process, the test executor locates and executes the corresponding atomic test contract verification unit for verification.

[0008] Secondly, a bidding automation decision-making method based on the homogeneous heterogeneous execution of business flow and test flow is provided, including:

[0009] Through the asynchronous event listening mechanism of the intelligent interface gateway, the project initiation approval state machine transition events in the project management system (PMS) are captured, and the transition to the approved state is used as the process trigger signal. After triggering, the process engine sequentially drives the execution of the following core business nodes:

[0010] a. Call the PMS data service interface to obtain a structured project requirement data package;

[0011] b. Based on the project requirement data package, the process engine automatically instantiates a self-tendering project context and triggers the supplier screening service of the supplier management system (SRM) to obtain a list of potential suppliers that match the tendering project.

[0012] c. Use the large model generation service to generate tender documents, and simultaneously use the Intelligent Early Warning System (IAS) for multiple rounds of compliance review;

[0013] d. After the enterprise officially electronically signs the self-published tender documents by calling the Digital Signature System (DSS), the intelligent interface gateway automatically publishes the final tender documents to designated platforms inside and outside the enterprise through its multi-channel distribution module, and simultaneously calls the notification service interface of the SRM to send tender invitations to entities in the potential supplier list.

[0014] e. Upon receiving tender documents, the system will enforce verification of the validity and authenticity of the supplier's digital signature through the built-in pre-signature verification gateway;

[0015] f. Automatically open bids after the bid deadline and perform a composite risk scan using IAS's multi-dimensional risk analysis engine;

[0016] g. During the bid evaluation stage, a preset intelligent bid evaluation algorithm is invoked to conduct dynamic bid evaluation and obtain a comprehensive score for the bid documents;

[0017] h. After the comprehensive scoring and benchmarking, the winning bid notification is automatically generated and the DSS is called to complete the electronic signature. Then the results are released and the relevant system status is updated to form a management closed loop.

[0018] During the entire execution process of the process engine, the dynamic self-verification method described in the first aspect is executed asynchronously to achieve homogeneous and heterogeneous execution of business flow and test flow.

[0019] This invention presents a dynamic self-verification method based on the homogeneous and heterogeneous execution of business flow and test flow, which has the following beneficial effects: This invention proposes a dynamic self-verification architecture of "homogeneous and heterogeneous execution of business flow and test flow," using a domain-specific language (DSL) to uniformly describe business logic and test logic. This automatically transforms each autonomous bidding process into high-fidelity automated testing of the integrated state of multiple systems. It achieves left-shifted testing and even test embedding, enabling real-time detection of interface faults, accurate location of performance bottlenecks, and proactive early warning of system risks. This transforms the operation and maintenance mode from "passive firefighting" to "proactive early warning," significantly improving system reliability, availability, and operational efficiency. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the dynamic self-verification method based on the homogeneous and heterogeneous execution of business flow and test flow in the embodiments of this application.

[0021] Figure 2 This is a flowchart illustrating the heterogeneous compilation stage in an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of the dual-path compilation process in an embodiment of this application;

[0023] Figure 4 This is a flowchart illustrating the operational phase in an embodiment of this application;

[0024] Figure 5 This is a flowchart illustrating the automated bidding decision-making method based on the homogeneous and heterogeneous execution of business flow and test flow in this embodiment of the application. Detailed Implementation

[0025] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0026] See Figure 1This application provides a dynamic self-verification method for automated bidding processes based on heterogeneous execution of business flow and test flow. In this automated bidding process, the system integrates with multiple external business systems through an intelligent interface gateway, and utilizes a process engine to drive the entire bidding process. The entire bidding process includes: project approval as the process trigger signal, followed by the generation and signing of bidding documents, screening of potential suppliers for bidding documents, publication and sending of bidding documents, receipt and verification of bid documents, intelligent evaluation of bid documents, and generation, signing, publication, and sending of the winning bid result. The external business systems include at least: a Project Management System (PMS) for managing the project process from initiation to completion; an Intelligent Early Warning System (IAS) for multi-dimensional review of bidding documents and bid documents; a Supplier Management System (SRM) for analyzing and obtaining a list of potential suppliers based on preset intelligent algorithms (e.g., matching algorithms to analyze whether the goods or services offered by suppliers match the bidding documents), and has a notification service interface to receive information sent by external systems; and a Digital Signature System (DSS) for electronically signing bidding documents and the winning bid result.

[0027] The self-verification process involves synchronously mapping the entire execution process of the workflow engine as an end-to-end test integrating multiple external business systems, generating a detailed test report covering all cross-system interface call statuses, performance metrics, signature system interaction statuses, and business assertion results. This self-verification process includes the following steps:

[0028] Step 1, Unified Modeling Phase: The unified modeling phase uses a domain-specific language (DSL) based on YAML syntax extensions to perform a unified declarative description of each business node in the bidding business process and its corresponding cross-system interface test and verification points, thereby obtaining the DSL description.

[0029] Step 2, Heterogeneous Compilation Stage: This stage uses a dual-path compilation engine to compile the DSL description into two heterogeneous executable objects simultaneously. One is a stateful business execution sequence driven by the process engine, serialized in JSON format, and possessing state management and transaction capabilities. The other is a stateless interface test suite composed of multiple atomic test contract verification units, used for test executor calls, and automatically generates an end-to-end test plan diagram describing the execution order and dependencies of the verification units.

[0030] Step 3, the execution phase, in which the business flow and the test flow are executed from the same source but in a heterogeneous manner. When the business flow is executed, the test executor and the process engine run concurrently and asynchronously through a loosely coupled triggering mechanism based on a high-throughput event bus (such as Redis Pub / Sub or Apache Pulsar). For each cross-system interface call process, the test executor locates and executes the corresponding atomic test contract verification unit for verification.

[0031] Specifically, the "Business Flow-Test Flow Homogeneous Heterogeneous Execution" dynamic self-verification method of this application's embodiments uses a strongly typed Domain-Specific Language (DSL) to uniformly describe business logic and corresponding interface test contracts; it utilizes a dual-path compilation engine to simultaneously compile the homogeneous DSL description into a stateful business workflow for execution by the process engine and a stateless, composable atomic test contract set for invocation by the test executor; at runtime, it achieves loosely coupled synchronous triggering and execution of business flow and test flow based on a high-throughput event bus, performing real-time, high-fidelity contract verification, performance monitoring, and chaos probe testing on cross-system interface calls in the production environment. This invention transforms traditional post-event, offline integration testing into in-process, online, and continuous system-native capabilities, effectively solving the problems of difficult integration testing of complex enterprise system groups and passive operation and maintenance monitoring.

[0032] This application's embodiments create a new paradigm of "business-test homogeneous heterogeneous execution," completely transforming testing from an independent, ex-post cost center into an intrinsic value-creating capability that coexists with business logic and runs synchronously during the process. Through specific technologies such as DSL unified modeling, dual-path compilation, event-driven architecture, and parallel multi-model verification, it achieves deep and seamless integration of business and testing at all stages of the declaration, compilation, and runtime phases.

[0033] In one implementation, in step 1 above, each business node in the DSL description must include a business_action business action description and a test_verification test verification block; the test_verification test verification block must include a target_endpoint target interface identifier and an assertions multidimensional assertion contract array.

[0034] In one implementation, the Domain-Specific Language (DSL) in step 1 above is defined using a binding metamodel, which includes the following hierarchical structure to ensure deep integration of business logic and test logic:

[0035] (1) Node-level mandatory verification constraints:

[0036] The DSL metamodel mandates that each business node declaration in the business process definition must include a test_verification block. During the DSL compilation phase, the compiler performs mandatory verification, and any node definition lacking this verification block will be identified as a syntax error, causing compilation failure and providing a clear error message.

[0037] (2) A multi-dimensional contract system for assertion arrays, meaning that the test_verification block must contain an assertion array. The assertion array defines a multi-dimensional, hierarchical verification contract for the target interface. The supported assertion types constitute a complete verification system, including:

[0038] a) Structural compliance assertion, denoted as schema type assertion, is used to strictly verify the static structure of the interface response data. During compilation, the system pre-compiles the JSON Schema file into efficient verification code, and at runtime, it achieves millisecond-level response structure verification to ensure that the data structure returned by the interface does not deviate from the norm, thereby avoiding system compatibility issues caused by changes in data structure from the root.

[0039] b) Business logic state assertion, denoted as business_rule type assertion, is used to verify the dynamic business logic state implied in the interface response by executing a Boolean expression. This type of assertion compiles the Boolean expression into intermediate code or bytecode during the DSL compilation stage, and executes it safely and efficiently in a sandbox environment at runtime, realizing automated and high-fidelity verification of the core business logic.

[0040] c) Service Quality Commitment Assertion, denoted as SLA type assertion, is used to verify the compliance of the Service Level Agreement (SLA) of the interface and focuses on the non-functional requirements of the system. During the DSL compilation phase, the system initializes a high-precision timer and a throughput counter. At runtime, performance indicators are collected and compared with the SLA threshold in real time to provide immediate alerts for performance degradation.

[0041] d) Data flow continuity assertion, denoted as data_contract type assertion, is implemented based on downstream node identifiers and custom compatibility rules. It is used to verify the continuity and logical consistency of data flow across nodes in the business process. This type of assertion is a significant innovation of this application, transcending the verification scope of a single interface to achieve data flow contract testing across business process nodes, ensuring the continuity and consistency of business data as it flows through multiple systems. During the DSL compilation phase, this data flow continuity assertion is used to establish a cross-node data dependency graph. At runtime, the test executor extracts relevant data from upstream and downstream nodes from the context snapshot and executes custom compatibility rules, thereby ensuring the data integrity of the business process at a global level.

[0042] In this embodiment, the data dependency graph is used for semantic checking and runtime data transfer of data_contract type assertions. It is constructed based on the data_contract assertions declared in the DSL. These assertions explicitly specify the downstream_node (downstream node identifier) ​​and the compatibility_rule (compatibility rule). The compiler establishes the data flow relationship between nodes by parsing these assertions. The vertices of the data dependency graph are business process nodes, and the edges represent data_contract contract relationships. Edges point from the node defining the contract (e.g., node_seal_announce) to its specified downstream node (e.g., node_bid_reception). The edge label in the data dependency graph is: compatibility_rule (compatibility rule). It is used for compile-time semantic checking and runtime data validation. Compile-time semantic checking includes verifying the existence of the downstream_node and the validity of variables in the compatibility_rule. Runtime data validation includes providing a basis for upstream and downstream data association and extraction for the test executor when executing the data_contract assertions.

[0043] In one implementation, in the multidimensional contract system of the aforementioned assertion array, the schema type assertion is implemented based on a predefined JSON Schema specification file; the business_rule type assertion is implemented based on an embedded lightweight rule engine, which can be based on Lua, JavaScript, or other embedded script engines; the sla type assertion presets thresholds for multiple performance metrics (e.g., response performance, service throughput), denoted as the SLA threshold. An example of a multidimensional contract assertion for a DSL is provided below:

[0044] yaml

[0045] - id: node_seal_announce

[0046] business_action: "Digitally sign and publish self-developed bidding documents"

[0047] test_verification: target_endpoint: "DSS_API_POST / seal"

[0048] assertions:

[0049] - type: "schema" definition: "schemas / seal_response_schema.json"

[0050] - type: "business_rule" # Business rule contract: | output.status == 'SUCCESS' && output.transaction_id =~ / ^TXN\\d{15}$ / && # Validate transaction ID format contains(output.evidence_package, 'timestamp', 'sealedHash') # Validate key fields of the evidence package

[0051] - type: "sla" # Performance contract max_response_time: 500 min_throughput: 10 # Added: Throughput requirement

[0052] - type: "data_contract" #

Innovation Point

[0053] In one implementation, in the multidimensional contract system of the aforementioned assertion array, the verification dimensions of the schema type assertion include: data integrity, type security, data format compliance, and whether value range constraints are met; the verification dimensions of the business_rule type assertion include: status codes and key identifiers, business rule compliance, and cross-field logical relationships; the verification dimensions of the sla type assertion include: response performance, service throughput, and availability; and the verification dimensions of the data_contract type assertion include: data transmission integrity and business context consistency. The data transmission integrity assertion is used to ensure that the output data of the upstream node can be correctly received and used by the downstream node, and the business context consistency assertion is used to check whether key business context information remains consistent during process transmission to prevent data loss or tampering.

[0054] Specifically, the verification dimensions of the aforementioned structural compliance assertion (schema type) include:

[0055] a) Completeness: Check that all fields marked as required:true in the schema exist in the response body;

[0056] b) Type safety: Verify that the data type of each field (such as string, numeric, boolean, object, array) fully matches the schema definition;

[0057] c) Data format: Perform regular expression or format compliance validation on fields with specific format requirements (such as format: date-time, format:email);

[0058] d) Value range constraints: Check whether numeric fields conform to the defined range (e.g., minimum: 0) and whether strings conform to the defined pattern (e.g., pattern: ^TXN\\d{15}$).

[0059] The verification dimensions for the business logic state assertion include:

[0060] a) Status codes and key identifiers: Verify the success status of business operations (e.g., output.status == SUCCESS) and the validity of the transaction ID.

[0061] b) Business rule compliance: Execute complex business logic judgments, such as verifying whether the bid price is within the budget (output.bid_amount<=context.project_budget), or verifying whether the supplier's qualifications meet the project requirements.

[0062] c) Cross-field logical relationships: Check the logical consistency between multiple fields in the response body. For example, when payment_status is PAID, the payment_time field must exist and be a valid timestamp.

[0063] The service quality commitment assertion is verified in the following dimensions:

[0064] a) Response performance: Set the maximum allowed response time for API calls (e.g., max_response_time: 500 milliseconds) to ensure user experience and system performance;

[0065] b) Service throughput: Set a minimum throughput requirement (e.g., min_throughput: 10TPS) to verify the system's service capacity under high concurrency;

[0066] c) Availability: Through continuous monitoring, indirectly verify whether the service's error rate and availability meet the standards;

[0067] The data flow continuity assertion includes the following verification dimensions:

[0068] a) Data transmission integrity: Ensure that the output data of the upstream node can be correctly received and used by the downstream node. For example, verify that the hash of the signed document generated by the tender document issuing node (node_seal_announce) is consistent with the hash of the original document received by the tender document receiving node (node_bid_reception) (this.sealedHash==downstream.originalDocHash);

[0069] b) Business context consistency: Check whether key business context information remains consistent during process transmission to prevent data loss or tampering.

[0070] See Figure 2 In one implementation, step 2 above, the heterogeneous compilation stage, includes the following steps:

[0071] Step 200: For each business node (Node) declaration, check whether it contains the test_verification test verification block. If it does, continue the compilation process; otherwise, the node definition that is missing the verification block is determined to be a syntax error, and the compilation failure result is output with a clear error message.

[0072] Step 201: The compilation engine performs lexical and syntactic analysis on the DSL source file, constructs the AST, and performs semantic checks. If all semantic checks are successful, proceed to step 202; otherwise, the compilation process terminates immediately.

[0073] Step 202, dual-path compilation, where:

[0074] The business path compilation process, i.e. the business execution sequence generation process, includes: the compilation engine traversing the AST, extracting the business information of each node, and generating a JSON-formatted workflow instance that can be directly executed by the process engine;

[0075] The test path compilation, i.e., the interface test suite generation process, includes: the compilation engine traversing the AST, parsing the test_verification block of each node, and generating an independent atomic test contract verification unit for each block; at the same time, the compilation engine analyzes the data flow of the entire process and automatically generates an end-to-end test plan graph, which uses atomic test contract verification units as nodes and data dependencies as edges to guide the test executor to perform optimal test scheduling.

[0076] Specifically, this test plan graph is used for scheduling and optimizing test executors to ensure that tests are executed in the correct logical order. It is built upon the analysis of data flow dependencies throughout the entire business process. These dependencies are implicit in the business process logic; for example, the input parameters of node B depend on the output of node A. The compiler deduces the execution dependencies between nodes by analyzing the business logic (such as the semantic mapping of `business_action` and the passing of context variables). The vertices of this test plan graph are atomic test contract verification units, and the edges represent the data dependencies / execution order relationships between test units. Edges point from upstream test units to their downstream dependent test units. The labels on the edges indicate the data dependencies (e.g., the verification of one test unit requires the output of another test unit as input).

[0077] In one implementation, step 201 above, in which the compilation engine performs lexical and syntactic analysis on the DSL source file, constructs the AST, and performs semantic checks, specifically includes:

[0078] Step 2011: Perform lexical analysis on the DSL source file;

[0079] Step 2012: Perform syntax analysis on the DSL source file and construct the AST;

[0080] Step 2013: Perform semantic checks.

[0081] Specifically, step 2011 above, lexical analysis, includes: the compilation engine scanning the DSL source file using predefined lexical rules (regular expressions) to convert character sequences into a series of tokens with explicit meaning. For example, id:node_seal_announce is parsed as TOKEN_LIST_ITEM, TOKEN_ID, TOKEN_COLON, TOKEN_STRING('node_seal_announce').

[0082] The above step 2012, syntax analysis, includes: constructing an abstract syntax tree (AST) from the lexical sequence based on the predefined context-free DSL grammar. The root node of this AST represents the entire process, and the child nodes represent process nodes. Each node contains child nodes such as id, business_action, and test_verification. The test_verification node contains target_endpoint and assertions arrays, thus completely capturing the structured information of the DSL.

[0083] Step 2013 involves semantic checks, including reference validity checks, regular expression syntax validation, and data contract consistency checks. The data contract consistency check includes verifying whether a specified node exists in the AST and whether the referenced variables are valid within the context. Specifically, the initially constructed AST is traversed, and the following static semantic verifications are performed:

[0084] Reference validity check: For assertions of schema type, check whether the JSON schema file pointed to by its definition field exists and can be accessed by the system.

[0085] Rule expression syntax validation: For assertions of type business_rule, the boolean expression (such as output.status=='SUCCESS') is submitted to the built-in rule engine for pre-compilation syntax checking to ensure that operators are used correctly and variable names are valid.

[0086] Data contract consistency check: For assertions of type `data_contract`, check whether the specified `downstream_node` exists in the AST and whether the variables referenced in `compatibility_rule` (such as `this.sealedHash`, `downstream.originalDocHash`) are valid in the context. If any semantic check fails, the compilation process will terminate immediately and report detailed error information and location to the user.

[0087] Furthermore, in step 2012 of this application embodiment, the syntax analysis process constructs the AST. The definition of `test_verification` in the grammar is tightly coupled with the subsequent dual-path compilation. The information extracted from the AST does not lead to a single execution entity, but necessarily to two heterogeneous execution entities (business flow and test flow). This reflects the intention of the grammar design to serve the "homogeneous heterogeneous" architecture. At the same time, the assertion types (schema, business_rule, sla, data_contract) defined in the grammar constitute a multi-dimensional verification system. In particular, the `data_contract` type supports cross-node data flow verification, which is not common in general process description languages ​​or test DSLs.

[0088] See Figure 3 In one implementation, step 202 above, business path compilation, i.e., the business execution sequence generation process, includes the following steps:

[0089] (1) AST traversal and information extraction: The compiler depth-first traversal (DFS) extracts the core business attributes of each process node through the semantically checked AST, including but not limited to: node unique identifier id, business action description business_action (used for logging and monitoring), and target interface metadata (such as PMS project query interface URL) mapped by analyzing the semantics of business_action and system configuration.

[0090] (2) Workflow instance construction: The compiler will instantiate the extracted information into a stateful workflow instance; the workflow instance is described using a standard workflow definition language (such as a custom structure in JSON format) to specify the execution order of nodes, jump conditions and transaction boundaries;

[0091] (3) Interface call task encapsulation: The compiler generates a specific, executable interface call task for each node in the workflow instance. The encapsulation content includes: call endpoint, authentication information, request constructor, and fault tolerance logic. The fault tolerance logic adopts an automatically embedded elastic mode, including interface call timeout control, circuit breaker mode, and limited retries.

[0092] Specifically, in this embodiment, the interface call task is encapsulated. This encapsulation process is not manually orchestrated or configured, but automatically generated by a dual-path compilation engine from the same-source DSL. The target interface (target_endpoint) it calls comes directly from the declaration of the test_verification block in the DSL, ensuring consistency between business intent and implementation code, and avoiding errors or delays that may occur from manual maintenance of interface definitions. This task object automatically embeds fault-tolerance logic based on architectural intent (such as circuit breakers, retries, and timeouts). This logic is not manually added afterward, but is automatically inferred and injected during compilation based on business node semantics and system policies, making resilient design the default behavior generated by the system. This task is not only the carrier of business execution but also implicitly serves as a benchmark for testing and verification. Its encapsulated request construction logic and endpoint information are directly copied by "shadow traffic testing" for environmental consistency comparison and are also used to construct chaos probe requests. One encapsulation drives two sets of execution: business and testing. The specific encapsulation content of this interface call task includes:

[0093] 31) Invoking endpoint: The complete HTTP(S) endpoint URL;

[0094] 32) Authentication information: pre-configured API key or OAuth2.0 token;

[0095] 33) Request Builder: Dynamically constructs the request body based on context data, such as filling the project ID into the URL path parameter and filling the project budget into the JSON request body;

[0096] 34) Fault Tolerance Logic: Automatically embedded elastic modes, including: timeout control, setting the maximum waiting time for interface calls (e.g., 5 seconds); circuit breaker mode, automatically breaking the circuit when the number of consecutive failures exceeds a threshold (e.g., 5 times) to avoid a cascading failure effect; finite retries: exponentially backing off retries for retryable errors (e.g., network jitter). This fault tolerance logic, "automatically embedded," means that during the DSL compilation phase (design phase), the system does not require manual writing or configuration of these fault tolerance logics for each interface. Instead, the dual-path compilation engine automatically infers, generates, and injects them into each interface call task based on predefined system-level elasticity strategies and the semantics of business nodes. The system has a default, extensible elasticity strategy library (e.g., default 3 retries, default 2-second timeout). When generating tasks, the compiler automatically selects and instantiates the corresponding strategy and binds it to the task based on information such as the target system type (e.g., external DSS signature service) and business importance of the node call, through semantic association analysis. For example, for critical business nodes such as payments and signatures, the compiler may automatically embed a stricter circuit breaker strategy; for query-type nodes, it may embed a more lenient retry strategy. This correlation stems from the understanding of the semantics of business_action in the DSL.

[0097] See Figure 3 In one implementation, step 202 above, test path compilation, i.e., the interface test suite generation process, includes the following steps:

[0098] (1) Test Unit Instantiation: The compiler traverses the AST and instantiates an independent, stateless atomic test contract verification unit for each node's test_verification block. This process is fine-grained, ensuring that one business node strictly corresponds to one test verification unit. The atomic test contract verification unit is a composite executable object containing the following components:

[0099] Data Schema Contract Validator: During system initialization or DSL compilation, this component converts the JSON Schema definition file into native machine code or highly optimized intermediate code using pre-compilation technology. During runtime, upon receiving interface response data, this validator directly executes the pre-compiled validation code, performing millisecond-level validation of the JSON response's structural integrity, field data types, numerical ranges, and the existence of required fields. For example, it verifies whether the `transaction_id` field returned by the DSS signature interface is a string type and conforms to a predefined format. If validation fails, this component can accurately output the specific JSON path that violates the schema constraints (e.g., `$.data.evidence_package.timestamp`), the expected value, and the actual value, greatly facilitating troubleshooting.

[0100] Business Rule Contract Engine: During the DSL compilation phase, this component performs lexical analysis, syntax analysis, and semantic optimization on the Boolean expressions declared in the DSL, ultimately compiling them into platform-independent low-level bytecode. During runtime, the compiled bytecode executes in a strict sandbox environment, which restricts the variables it can access and the operations it can execute, ensuring that user-defined rules do not threaten system security and stability. The engine intelligently binds variables in the rules (such as `output.status`) to the actual response data of the interface (through a set of predefined, rigorous rules for automated mapping and binding), and supports complex logical operations, arithmetic operations, and string manipulation, achieving true business logic assertions.

[0101] SLA Contract Monitor: During the DSL compilation phase, this component initializes a nanosecond-precision timer and a thread-safe throughput counter. These are used to capture the precise time elapsed from the issuance of a service request to the receipt of a complete response, and to count the number of requests successfully processed by the interface within a sliding time window, respectively. At runtime, the monitor compares the collected response times (P50, P95, P99) and throughput (QPS) in real time with the preset thresholds of the SLA assertions in the DSL. It not only determines whether a single request times out but also continuously monitors the long-term trends of performance metrics. In addition to interface performance, the monitor can also be extended to monitor system resource consumption during the interface call process, such as CPU and memory usage, providing multi-dimensional data support for performance bottleneck analysis.

[0102] Data Validator: During the DSL compilation phase, this component is used to establish a cross-node data dependency graph based on data_contract assertions. At runtime, the test executor extracts relevant data from upstream and downstream nodes from the context snapshot and executes custom compatibility rules, thereby ensuring the data integrity of the business process at the global level.

[0103] Test Data Generator: This component parses the request / response JSON Schema file of the target interface, determines the data model and constraints in the JSON Schema file, and constructs diverse test data, including boundary value test data (automatically generating values ​​within the valid range boundaries, such as generating 0, 1, 99, 100, 101, etc. for an integer field maximum:100), outlier / invalid data (actively generating data that violates constraints, such as null, type errors (passing numbers to string fields), format errors (strings that do not conform to format:email), values ​​exceeding the enumeration range, etc., for negative testing and robustness testing); and actively and automatically performs "aggressive" testing on the production or test environment interfaces during non-business call times;

[0104] (2) Verification logic compilation and binding:

[0105] For schema assertions, the compiler reads the specified JSON Schema file and pre-compiles it to generate an efficient data validation function, which is then bound to the test unit.

[0106] For business_rule assertions, the compiler compiles the rule expression into platform-independent low-level bytecode (bytecode of the underlying virtual machine (such as JVM) or WebAssembly (WASM) module) for extremely fast execution. This compiled module is then bound to the test unit.

[0107] For sla assertions and data_contract assertions, corresponding monitors and data validators are generated and bound to the test unit;

[0108] (3) Test plan diagram construction:

[0109] The compiler analyzes the data flow dependencies of the entire business process and automatically constructs an end-to-end test plan graph, which is a directed acyclic graph.

[0110] In one implementation, step 3 above, the operation phase, includes the following steps:

[0111] Step 301: Before the process engine starts executing a business node, it constructs a node execution started event. The event includes the unique identifier node_id of the currently executing node and a business context snapshot business_context_snapshot. The event is then published to an internal event bus designed for high concurrency and low latency, denoted as the high-throughput event bus. The bus is implemented based on a publish-subscribe message middleware.

[0112] Step 302: The test executor subscribes to and listens for events based on the persistent subscriber Durable Subscriber; upon receiving the event, the test executor first parses the node_id in the event and finds the corresponding atomic test contract verification unit based on the node_id;

[0113] Step 303: After the test executor locates the target test unit, it immediately submits it to an independent, high-priority thread pool to execute asynchronous tasks; the asynchronous tasks include concurrently executing multiple verification modes of different dimensions for the same business target interface.

[0114] See Figure 4 Specifically, step 3, the operation phase, includes the following steps:

[0115] Step 301: The process engine constructs and publishes events, including:

[0116] Step 301(a), the process engine constructs an event: When the process engine starts executing a specific business node, before initiating the actual business request, it immediately constructs a structured node execution started event (NodeExecutionStarted event); the node execution started event (NodeExecutionStarted event) includes: the unique identifier node_id of the currently executing node, and the global tracing ID of this business execution. The test executor uses a global_trace_id, a precise timestamp of the event creation, and a lightweight business context snapshot (business_context_snapshot). This snapshot contains critical data necessary for executing this node (such as project ID, file hash, vendor ID, etc.). This data is used by the test executor to construct verification requests or perform data flow continuity assertions. Specifically, this data is used to construct or supplement verification requests, and the specific method varies depending on the verification mode (shadow traffic testing, chaos engineering probe). For example, in shadow traffic testing mode, the test executor needs to replicate a business request that is completely identical to the production environment. The test executor holds the interface call template compiled from the DSL, and then the test executor can inject key dynamic data (such as project_id, file_hash) from business_context_snapshot into the corresponding positions in the request template. In chaos engineering probe, the test executor needs to construct a pre-defined, anomalous test request. This process also requires context data, such as constructing a valid request baseline based on the data in business_context_snapshot. Predefined tampering rules can then be applied to the baseline request; for example, the rule might be "replace valid file_hash with an empty string." In this case, business_context_snapshot can provide the original valid value that needs to be tampered with.

[0117] Step 301(b), the process engine publishes the event: The event is published to an internal event bus designed for high concurrency and low latency, denoted as the high-throughput event bus. This bus is implemented based on a publish-subscribe message middleware, such as Redis's Pub / Sub functionality or Apache Pulsar. These technologies can support tens of thousands or even higher message throughput per second, ensuring the immediacy of event notifications and preventing them from becoming a bottleneck in the business process.

[0118] Step 302, test the executor response and scheduling, including:

[0119] Step 302(a), Test executor subscription and event listening: Set the test executor as a persistent subscriber on the event bus to continuously listen to the event stream from the process engine; this design achieves process-level decoupling between business flow and test flow, and will not cause event loss even if the test executor is temporarily restarted or overloaded.

[0120] Step 302(b), the test executor accurately locates the test unit: After receiving the NodeExecutionStarted event, the test executor first parses the node_id in the event and finds the corresponding atomic test contract verification unit based on the node_id; for example, a hash mapping table is pre-built in memory, where the key is node_id and the value is the corresponding instantiated atomic test contract verification unit.

[0121] Step 302(c), Asynchronous Task Execution: After the test executor locates the target test unit, it immediately submits it to an independent, high-priority thread pool for asynchronous task execution. The asynchronous task includes concurrently executing multiple verification modes of different dimensions on the same business target interface. The terms "immediately" and "asynchronously" are crucial; they ensure that the start of the verification task occurs almost simultaneously with the issuance of the business request, and does not block the subsequent execution of the process engine, thus guaranteeing the high availability of the business system.

[0122] Furthermore, in this embodiment of the application, step 302(c) concurrently executes multiple verification modes of different dimensions, including at least the following modes:

[0123] First verification mode: Shadow traffic test, which mirrors real business requests to a data-isolated, read-only test environment cluster to achieve risk-free testing;

[0124] The second verification mode is production environment contract verification. The test executor bypasses the monitoring or directly accesses the real response of the production environment interface received by the process engine, and uses the located atomic test contract verification unit to perform strict and sequential verification of the real response.

[0125] The third verification mode is the chaos engineering probe, which tests whether the system performs as expected when faced with disturbances by actively injecting a preset probe request that simulates a real-world fault into the production environment interface.

[0126] Specifically, the asynchronous tasks initiated by the test executor will concurrently execute the following three different verification modes on the same business target interface, forming a comprehensive quality protection network:

[0127] (1) Shadow Testing:

[0128] Traffic replication: The test executor performs a deep copy of a real business request constructed by the process engine. This copy is completely identical to the original request in memory structure, but has an independent lifecycle.

[0129] Read-only environment verification: The copied request is sent to a test environment cluster in read-only mode with the same configuration as the production environment but with data isolation via a dedicated, clearly identified HTTP header (such as X-Test-Mode:Shadow).

[0130] Behavioral Consistency Comparison: After receiving the response from the test environment, compare it with the response from the production environment that is about to be received (or has already been received) in terms of data schema and core business fields. This mode is mainly used to verify the behavioral consistency between the test environment and the production environment after new version deployment and configuration changes, and is an important quality gate in continuous delivery.

[0131] (2) Production Contract Validation:

[0132] Real-time response capture: The test executor receives real responses from production environment interfaces via either a bypass listener (Tap) or direct access to the process engine.

[0133] Triple contract synchronous assertion: Utilizing the located atomic test contract verification units, rigorous and sequential verification of the actual response is performed.

[0134] Data schema contract: Use a pre-compiled validator to ensure that the response data structure is 100% as expected.

[0135] Business rule contract: Executes the compiled bytecode rules to assert the correctness of business status (such as status) and key business identifiers (such as transaction_id).

[0136] SLA contract: Using a high-precision timer, record and assert whether the response time of this call is within the promised threshold.

[0137] This model is the core means of ensuring the correctness and stability of online business functions.

[0138] It's important to note that production environment contract verification primarily verifies the immediate response of a single interface call. Therefore, its core actions (response capture, pattern checking, rule execution, and SLA timing) are specific to that node. Data flow continuity assertion verification, however, occurs after the "production environment contract verification" step and is an asynchronous or delayed verification point. Data flow continuity assertion verification is not completed immediately upon receiving the interface response from this node, as it depends on data from downstream nodes. The assertion's verification condition is only satisfied after the specified downstream node has completed execution and its input data is ready. It utilizes data passed through the event bus and business context snapshots, executing only after the data is complete. When the process engine executes to a downstream node (such as `node_bid_reception`) and publishes its `NodeExecutionStarted` event, or when the test executor schedules an upstream test unit that depends on downstream node data (according to the test plan graph DAG), the system will recognize that an upstream `data_contract` assertion is waiting for data from that downstream node for verification. The verification process for this data flow continuity assertion includes: (a) Data preparation: The system retrieves two key data sets from the event bus or shared distributed context storage: output data (e.g., sealedHash) saved in the business_context_snapshot of the NodeExecutionStarted event when the upstream node (e.g., node_seal_announce) executes; and input data of the current downstream node (node_bid_reception) or related data extracted from its business_context_snapshot (e.g., originalDocHash). (b) Rule execution: After obtaining these two sets of data, the data validator (or equivalent component) substitutes them into the compatibility_rule defined in the data_contract assertion (e.g., this.sealedHash==downstream.originalDocHash) for calculation. (c) Result determination: Based on the rule calculation result (true / false), the verification result of the data_contract assertion is generated and summarized along with the results of other assertions, and written to the log and monitoring system.

[0139] (3) Chaos Engineering Probe:

[0140] Controlled fault injection: At a configurable, extremely low rate (e.g., 0.1% of requests), the test executor proactively injects pre-defined "probe" requests simulating real-world faults into the production environment interface. These faults are harmless (graceful degradation), for example:

[0141] Construct a request body that is correctly formatted but invalid in business logic (e.g., a non-existent project ID).

[0142] Inject a simulated short-lived network delay marker into the HTTP header.

[0143] Send an intentionally large request body to test the service's rate limiting capabilities.

[0144] Resilience verification: The purpose of this mode is not to cause business failure, but to verify whether the system performs as expected in the face of such disturbances.

[0145] In one embodiment, the dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to the present application further includes, after step 3 above:

[0146] Step 4, Continuous Monitoring and Optimization Phase: Optimize the graph and model. Write the assertion results, performance metrics, and end-to-end tracing data from all interfaces verified in Step 3 into the distributed log and tracing system. Dynamically compare these data with historical performance baselines learned autonomously through machine learning algorithms to achieve continuous monitoring and intelligent alerts in the production environment. Based on historical execution data, automatically optimize and evolve the test suite.

[0147] Specifically, in this embodiment, a distributed logging and tracing system is used to record events generated during application runtime (such as errors, warnings, and debugging information) to provide a detailed view of the system's operational status. The complete call trajectory of a single request is analyzed, and by correlating logs scattered across different services and nodes, the complete request process is reconstructed, thereby quickly locating performance bottlenecks or fault points. Based on the test results of all interface verifications in step 3, a comparative analysis is performed using historical performance baselines (such as average response time performance baselines) learned autonomously through machine learning algorithms and performance metrics during the current test process to determine the real-time performance status during the current test process. Furthermore, based on historical execution data, the test suite is automatically optimized and evolved, including the following steps:

[0148] Step 401: Obtain detailed execution history data for each atomic test contract verification unit, including success rate metrics, performance metrics, root causes of failure, and importance of related business processes. In this step, the system continuously and automatically records the detailed execution history of each atomic test contract verification unit, building a test knowledge base that evolves over time. The success rate metrics include: the pass rate of each test unit in the most recent N (e.g., 1000) executions; performance metrics include: recording the average response time, P95 / P99 quantile values, and system resource consumption (e.g., CPU, memory) during execution; root causes of failure are precisely categorized using structured logs and error codes (e.g., network timeout, incorrect response data format, business rule assertion failure, SLA breach, etc.); and business relevance is indicated by the criticality of the business functions verified by the test unit within the business process.

[0149] Step 402: Based on the data from Step 401, intelligently identify failed test cases and automate their handling. In this step, once a test case is determined to be "expired," the system automatically marks its status as "paused," causing it to immediately exit the test execution loop. A clear management notification is generated and sent to the administrator or developers via preset channels (such as email, DingTalk / Lark group), prompting them to update the test logic and attaching a detailed link to the failure history.

[0150] Step 403: Based on the data from step 401, determine a dynamic priority weight for each test unit, and adjust the allocation of test execution resources and the display order in the test report in real time according to the weight, so as to ensure that high-value tests receive more attention and resources.

[0151] Step 404: Based on the similarity of the core features of the verification logic of each atomic test contract verification unit, redundant test cases are identified and merged.

[0152] In one implementation, in step 402 above, the intelligent identification of failed use cases identifies whether a case is a failed use case based on multi-dimensional data, including:

[0153] Failure Mode: Determined based on whether test cases consistently fail for more than a preset duration due to the same type of reasonable change. Reasonable changes include interface version upgrades and non-destructive updates to response data structures. This failure mode dimension can be scored based on dimensions such as "whether the failure is consistently long-term" and "whether the cause of failure is singular." A high score (tending towards failure) indicates consistently long-term (>24 hours) failures due to the same cause.

[0154] Failure Impact: This is determined based on whether the failure was anticipated, i.e., whether it was caused by a legitimate evolution of the external system, rather than a system defect. This failure impact dimension can be scored based on dimensions such as "whether the failure was caused by a known external change" and "whether the change was a non-destructive and reasonable evolution." A higher score (tending towards failure) is obtained if it is correlated with known and reasonable downstream system version release logs.

[0155] Furthermore, it can also include a rule layer dimension (hard rules). For example, if the failure reason is clearly marked as "the interface is obsolete (HTTP 410)" or "the target service does not exist (HTTP 404)", and continues to exceed a set threshold (such as 12 hours), it can be directly determined as a failure.

[0156] Ultimately, based on the results of the rule layer, the failure mode dimension score, the failure impact dimension score, and the preset decision threshold (such as the total score exceeding X points), the final failure use case identification can be determined.

[0157] Determining whether the failure is due to a legitimate evolution of an external system includes: using error pattern matching to determine if the failure is due to a legitimate evolution of an external system, performing text or pattern matching between the specific details of the failure (such as missing field names, violated rules) and the description in the change log. For example, if the change log states "removed the deprecated old_id field," and the test failure reason is "missing the required old_id field," this directly proves that the failure is due to a legitimate evolution. Alternatively, it can be used to analyze change events to determine if the failure is due to a legitimate evolution of an external system. The system maintains or integrates a change event timeline (which can be obtained through CMDB integration, publishing system APIs, or monitoring logs). When a test case starts to fail continuously, the optimizer checks whether there are relevant change records (such as version number upgrades, configuration pushes, data migration announcements) in the target external system being verified by the test case near the failure start time.

[0158] In one implementation, when determining a dynamic priority weight for each test unit in step 403, the weighted determination is based on a multi-dimensional consideration factor, which includes: problem capture value, business criticality, and execution cost. Problem capture value represents the value of the problem captured by the test case, and can be represented by the number of times the test case captures a real-world problem in the production environment within a recent preset timeframe (e.g., within one week). Business criticality represents the importance of the business function covered by the test case within the process, and can be determined based on the core level of the business function covered by the test case within the process. Execution cost can include the average execution time and resource consumption of the test case.

[0159] See Figure 5This application provides a method for automated bidding decision-making based on the homogeneous and heterogeneous execution of business flow and test flow, including the following steps:

[0160] Through the asynchronous event listening mechanism of the intelligent interface gateway, the project initiation approval state machine transition events in the project management system (PMS) are captured, and the transition to the approved state is used as the process trigger signal. After triggering, the process engine sequentially drives the execution of the following core business nodes:

[0161] a. Call the PMS data service interface to obtain a structured project requirement data package;

[0162] b. Based on the project requirement data package, the process engine automatically instantiates a self-tendering project context and triggers the supplier screening service of the supplier management system (SRM) to obtain a list of potential suppliers that match the tendering project.

[0163] c. Use the large model generation service to generate tender documents, and simultaneously use the Intelligent Early Warning System (IAS) for multiple rounds of compliance review;

[0164] d. After the enterprise officially electronically signs the self-published tender documents by calling the Digital Signature System (DSS), the intelligent interface gateway automatically publishes the final tender documents to designated platforms inside and outside the enterprise through its multi-channel distribution module, and simultaneously calls the notification service interface of the SRM to send tender invitations to entities in the potential supplier list.

[0165] e. Upon receiving tender documents, the system will enforce verification of the validity and authenticity of the supplier's digital signature through the built-in pre-signature verification gateway;

[0166] f. Automatically open bids after the bid deadline and perform a composite risk scan using IAS's multi-dimensional risk analysis engine. Before the bid opening, use IAS's automated compliance verification engine to perform machine readability checks and logical consistency checks on the mandatory clauses of the bid documents. After the bid deadline threshold is reached, the bid opening is automatically triggered. The system decrypts the encrypted bid documents in batches. Based on the plaintext bid data obtained after the bid opening, use IAS's multi-dimensional risk analysis engine to perform a composite risk scan, including analysis of corporate equity relationships, calculation of bid document text similarity, and detection of price sequence regularity, and output a quantitative risk assessment report.

[0167] g. During the bid evaluation stage, a preset intelligent bid evaluation algorithm is invoked to perform dynamic bid evaluation and obtain a comprehensive score for the bid documents. This preset intelligent bid evaluation algorithm may, for example, be that the system first automatically calculates the objective scores of all bid proposals, then initiates a Shapley value-based analysis of the judges' contribution, and dynamically adjusts the weights of each scoring dimension in conjunction with a multi-agent reinforcement learning model, and finally generates a comprehensive score ranking.

[0168] h. After the comprehensive scoring and benchmarking, the winning bid notification is automatically generated and the DSS is called to complete the electronic signature. Then the results are released and the relevant system status is updated to form a management closed loop.

[0169] During the entire execution process of the process engine, the dynamic self-verification process in the above-mentioned dynamic self-verification method based on the homogeneous and heterogeneous execution of business flow and test flow is executed asynchronously to realize the homogeneous and heterogeneous execution of business flow and test flow.

[0170] Furthermore, at the aforementioned key nodes in the entire self-service bidding process, especially all digital signature operations (including signing for the issuance of self-service bidding documents, verification of bid receipts, and signing of the notification of award), the system periodically uploads business operation logs, interface performance data, and the Merkle root hash value of the signature evidence package to the blockchain network through a lightweight audit and evidence storage module, achieving tamper-proof and legally traceable processes. In this embodiment, business logic and test logic are uniformly described using a domain-specific language (DSL), automatically transforming each self-service bidding process into a high-fidelity automated test of the multi-system integration state; an "end-to-end trusted signature process based on a digital identity chain" is constructed, deeply embedding digital signatures into key stages such as bid document upload and bid result transmission, and combining this with blockchain evidence storage to ensure the legal validity of documents and the non-repudiation of operations.

[0171] This invention is not limited to the specific embodiments described above. Any modifications made by those skilled in the art based on the above concept without creative effort are within the scope of protection of this invention.

Claims

1. A dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow, used for automated bidding processes, characterized in that... Includes the following steps: Step 1, Unified Modeling Phase: The unified modeling phase uses a domain-specific language (DSL) based on YAML syntax extensions to perform a unified declarative description of each business node in the bidding business process and its corresponding cross-system interface test and verification points, thereby obtaining the DSL description. Step 2, Heterogeneous Compilation Stage: This stage uses a dual-path compilation engine to compile the DSL description into two heterogeneous executable objects simultaneously. One is a stateful business execution sequence driven by the process engine, serialized in JSON format, and possessing state management and transaction capabilities. The other is a stateless interface test suite composed of multiple atomic test contract verification units, used for test executor calls, and automatically generates an end-to-end test plan diagram describing the execution order and dependencies of the verification units. Step 3, the execution phase, in which the business flow and the test flow are executed from the same source but in a heterogeneous manner. When the business process is executed, the test executor and the process engine run concurrently and asynchronously through a loosely coupled triggering mechanism based on a high-throughput event bus. For each cross-system interface call process, the test executor locates and executes the corresponding atomic test contract verification unit for verification. The Domain-Specific Language (DSL) in step 1 is defined using a binding metamodel, which includes the following hierarchical structure to ensure deep integration of business logic and test logic: (1) Node-level mandatory verification constraints: The DSL metamodel mandates that each business node declaration in the business process definition must include a test_verification test verification block. (2) A multi-dimensional contract system for assertion arrays, meaning that the test_verification block must contain an assertion array. The assertion array defines a multi-dimensional, hierarchical verification contract for the target interface. The supported assertion types constitute a complete verification system, including: a) Structural compliance assertion, denoted as schema type assertion, is used to rigorously verify the static structure of the interface response data; b) Business logic state assertion, denoted as business_rule type assertion, is used to verify the dynamic business logic state implied in the interface response by executing a Boolean expression; c) Service Quality Commitment Assertion, denoted as SLA type assertion, is used to verify the compliance of the Service Level Agreement (SLA) of the interface and focuses on the non-functional requirements of the system. d) Data flow continuity assertion, denoted as data_contract type assertion, is implemented based on downstream node identifiers and custom compatibility rules, and is used to verify the data flow continuity and logical consistency across nodes in the business process.

2. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 1, characterized in that, In step 1, each business node in the DSL description must include a business_action business action description and a test_verification test verification block; the test_verification test verification block must include a target_endpoint target interface identifier and an assertions multidimensional assertion contract array.

3. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 2, characterized in that, The schema type assertion is implemented based on a predefined JSON Schema specification file; The business_rule type assertion is implemented based on an embedded lightweight rule engine; The SLA type assertion presets thresholds for multiple performance metrics, denoted as SLA thresholds.

4. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 2, characterized in that, The verification dimensions of schema type assertions include: data integrity of the response data, type safety, data format compliance, and whether the value range constraint is met. The validation dimensions for business_rule type assertions include: status codes and key identifiers, business rule compliance, and cross-field logical relationships; The verification dimensions for SLA type assertions include: response performance, service throughput, and availability; The verification dimensions of the data_contract type assertion include: data transmission integrity and business context consistency. The data transmission integrity assertion is used to ensure that the output data of the upstream node can be correctly received and used by the downstream node. The business context consistency assertion is used to check whether the key business context information is consistent during the process transmission to prevent data loss or tampering.

5. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 1, characterized in that, Step 2, the heterogeneous compilation stage, includes the following steps: Step 201: The compilation engine performs lexical and syntactic analysis on the DSL source file, constructs the AST, and performs semantic checks. After all semantic checks are successful, proceed to step 202. Otherwise, the compilation process will terminate immediately; Step 202, dual-path compilation, where: The business path compilation process, i.e. the business execution sequence generation process, includes: the compilation engine traversing the AST, extracting the business information of each node, and generating a JSON-formatted workflow instance that can be directly executed by the process engine; The test path compilation, i.e., the interface test suite generation process, includes: the compilation engine traversing the AST, parsing the test_verification block of each node, and generating an independent atomic test contract verification unit for each block; at the same time, the compilation engine analyzes the data flow of the entire process and automatically generates an end-to-end test plan graph, which uses atomic test contract verification units as nodes and data dependencies as edges to guide the test executor to perform optimal test scheduling.

6. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 5, characterized in that, Before step 201, the process includes: for each business node declaration, checking whether it contains a test_verification block. If so, the compilation process continues; otherwise, for node definitions that lack the verification block, a syntax error is determined, the compilation failure result is output, and a clear error message is given.

7. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 5, characterized in that, The semantic checks in step 201 include: reference validity checks, regular expression syntax checks, and data contract consistency checks. The data contract consistency checks include checking whether the specified node exists in the AST and whether the referenced variables are valid in the context.

8. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 5, characterized in that, Step 202, the business execution sequence generation process, includes the following steps: (1) AST traversal and information extraction: The compiler performs a depth-first traversal of the semantically checked AST and extracts the core business attributes of each process node, including: node unique identifier id, business action description business_action, and target interface metadata mapped by analyzing the semantics of business_action and system configuration. (2) Workflow instance construction: The compiler will instantiate the extracted information into a stateful workflow instance; the workflow instance is described using the standard workflow definition language, which clarifies the execution order of nodes, jump conditions and transaction boundaries; (3) Interface call task encapsulation: The compiler generates a specific, executable interface call task for each node in the workflow instance. The encapsulation content includes: call endpoint, authentication information, request constructor, and fault tolerance logic. The fault tolerance logic adopts an automatically embedded elastic mode, including interface call timeout control, circuit breaker mode, and limited retries.

9. A dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 5, characterized in that, Step 202, the interface test suite generation process includes the following steps: (1) Test unit instantiation: The compiler traverses the AST and instantiates an independent, stateless atomic test contract verification unit for each node's test_verification block; the atomic test contract verification unit is a composite executable object containing the following components: Data Schema Contract Verifier: During system initialization or DSL compilation, this component is used to convert JSON Schema definition files into native machine code or highly optimized intermediate code using pre-compilation techniques; Business rule contract engine: During the DSL compilation phase, this component is used to perform lexical analysis, syntax analysis and semantic optimization on the Boolean expressions declared in the DSL, and finally compile them into platform-independent low-level bytecode; SLA Contract Monitor: During the DSL compilation phase, this component initializes a nanosecond-precision timer and a thread-safe throughput counter, which are used to capture the precise time elapsed from the issuance of a business request to the receipt of a complete response, and to count the number of requests successfully processed by the interface within the sliding time window, respectively. Data Validator: During the DSL compilation phase, this component is used to establish a cross-node data dependency graph based on data_contract assertions. Test data generator: This component parses the request / response JSON Schema file of the target interface, determines the data model and constraints in the JSON Schema file, and constructs diverse test data; (2) Verification logic compilation and binding: For schema assertions, the compiler reads the specified JSON Schema file and pre-compiles it to generate an efficient data validation function, which is then bound to the test unit. For the business_rule assertion, the compiler compiles the rule expression into platform-independent low-level bytecode, and the compiled module is bound to the test unit. For sla assertions and data_contract assertions, corresponding monitors and data validators are generated and bound to the test unit; (3) Test plan diagram construction: The compiler analyzes the data flow dependencies of the entire business process and automatically constructs an end-to-end test plan graph, which is a directed acyclic graph.

10. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 1, characterized in that, Step 3, the operation phase, includes the following steps: Step 301: Before the process engine starts executing a business node, it constructs a node execution started event. The event includes the unique identifier node_id of the currently executing node and a business context snapshot business_context_snapshot. The event is then published to an internal event bus designed for high concurrency and low latency, denoted as the high-throughput event bus. The bus is implemented based on a publish-subscribe message middleware. Step 302: The test executor subscribes to and listens for events based on the persistent subscriber Durable Subscriber; upon receiving the event, the test executor first parses the node_id in the event and finds the corresponding atomic test contract verification unit based on the node_id. Step 303: After the test executor locates the target test unit, it immediately submits it to an independent, high-priority thread pool to execute asynchronous tasks; the asynchronous tasks include concurrently executing multiple verification modes of different dimensions for the same business target interface.

11. A dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 10, characterized in that, Multiple verification modes with different dimensions, including at least the following modes: First verification mode: Shadow traffic test, which mirrors real business requests to a data-isolated, read-only test environment cluster to achieve risk-free testing; The second verification mode is production environment contract verification. The test executor bypasses the monitoring or directly accesses the real response of the production environment interface received by the process engine, and uses the located atomic test contract verification unit to perform strict and sequential verification of the real response. The third verification mode is the Chaos Engineering Probe, which tests whether the system performs as expected when faced with disturbances by actively injecting a pre-set probe request that simulates a real-world fault into the production environment interface.

12. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 1, characterized in that, Also includes: Step 4, the continuous monitoring and optimization phase, writes the assertion results, performance indicators and end-to-end tracing data of all interfaces verified in Step 3 into the distributed log and tracing system, and dynamically compares them with the historical performance baseline learned autonomously through machine learning algorithms to achieve continuous monitoring and intelligent alarms in the production environment; and automatically optimizes and evolves the test suite based on historical execution data.

13. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 12, characterized in that, Step 4 includes the following steps: Step 401: Obtain detailed execution history data for each atomic test contract verification unit, including success rate metrics, performance metrics, root causes of failure, and importance of related business. Step 402: Based on the data from step 401, intelligently identify failed use cases and automatically handle them. Step 403: Based on the data from step 401, determine a dynamic priority weight for each test unit, and adjust the allocation of test execution resources and the display order in the test report in real time according to the weight, so as to ensure that high-value tests receive more attention and resources. Step 404: Based on the similarity of the core features of the verification logic of each atomic test contract verification unit, redundant test cases are identified and merged.

14. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 13, characterized in that, In step 403, when determining a dynamic priority weight for each test unit, the weighted determination is based on multi-dimensional consideration factors, including: problem capture value, business criticality, and execution cost.

15. The dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 1, characterized in that, In the process of the automated bidding business, it is integrated with multiple external business systems through an intelligent interface gateway, and the entire bidding process is driven by a process engine. The entire bidding process includes: taking the approval of project establishment as the process trigger signal, and then generating and signing the bidding documents, screening potential suppliers for the bidding documents, publishing and sending the bidding documents, receiving and verifying the bid documents, intelligent evaluation of the bid documents, generating, signing and publishing the winning bid results, and sending them. The self-verification process involves synchronously mapping the entire execution process of the process engine into an end-to-end test integrating multiple external business systems, generating a detailed test report covering all cross-system interface call status, performance metrics, signature system interaction status, and business assertion results.

16. A dynamic self-verification method based on homogeneous heterogeneous execution of business flow and test flow according to claim 15, characterized in that, The external business system includes at least: A Project Management System (PMS) is used to manage the process of a project from its inception to its completion. The Intelligent Early Warning System (IAS) is used for multi-dimensional review of bidding documents and tender documents. The Supplier Management System (SRM) is used to analyze and obtain a list of potential suppliers based on a preset intelligent algorithm, and has a notification service interface to receive information sent by external systems. The Digital Signature System (DSS) is used for electronic signatures on tender documents and bid-winning results.

17. A method for automated bidding decision-making based on the homogeneous and heterogeneous execution of business flow and test flow, characterized in that, include: Through the asynchronous event listening mechanism of the intelligent interface gateway, the project initiation approval state machine transition events in the project management system (PMS) are captured, and the transition to the approved state is used as the process trigger signal. After triggering, the process engine sequentially drives the execution of the following core business nodes: a. Call the PMS data service interface to obtain a structured project requirement data package; b. Based on the project requirement data package, the process engine automatically instantiates a self-tendering project context and triggers the supplier screening service of the supplier management system (SRM) to obtain a list of potential suppliers that match the tendering project. c. Use the large model generation service to generate tender documents, and simultaneously use the Intelligent Early Warning System (IAS) for multiple rounds of compliance review; d. After the enterprise officially electronically signs the self-published tender documents by calling the Digital Signature System (DSS), the intelligent interface gateway automatically publishes the final tender documents to designated platforms inside and outside the enterprise through its multi-channel distribution module, and simultaneously calls the notification service interface of the SRM to send tender invitations to entities in the potential supplier list. e. Upon receiving tender documents, the system will enforce verification of the validity and authenticity of the supplier's digital signature through the built-in pre-signature verification gateway; f. Automatically open bids after the bid deadline and perform a composite risk scan using IAS's multi-dimensional risk analysis engine; g. During the bid evaluation stage, a preset intelligent bid evaluation algorithm is invoked to conduct dynamic bid evaluation and obtain a comprehensive score for the bid documents; h. After the comprehensive scoring and benchmarking, the winning bid notification is automatically generated and the DSS is called to complete the electronic signature. Then the results are released and the relevant system status is updated to form a management closed loop. The dynamic self-verification method as described in any one of claims 1-16 is executed asynchronously throughout the entire execution process of the process engine, thereby achieving homogeneous and heterogeneous execution of business flow and test flow.

Images