A ui test and api test collaborative test method based on a service logic chain graph

Abstract

The application discloses a UI test and API test collaborative test method based on a business logic chain graph, and the method comprises the following steps: performing semantic analysis on a business requirement document, an interface specification and user interface metadata of a target system based on a first large language model, and constructing a business logic chain graph; automatically generating a test workflow based on the business logic chain graph, and driving a UI executor and an API executor to perform collaborative test in parallel; synchronously capturing multi-modal data of a UI side, an API side and a data storage side in a test process, and generating a verification context based on the multi-modal data; inputting a second large language model LLM based on the verification context and the business logic chain graph to perform multi-dimensional consistency checking, and outputting a standardized arbitration result, so that the application realizes deep collaboration of UI test and API test, and solves the problem of missing business semantic understanding.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software testing, in particular to a UI test and API test collaborative test method based on a business logic chain graph. BACKGROUND

[0002] With the evolution of software architecture towards microservices and separation of front and back ends, business logic is fragmented and deployed in the front-end UI layer and the back-end multi-API service layer, forming a distributed business link of "front-end interaction-back-end calculation-data storage". Although this architecture improves development flexibility, it also brings the core pain point in the testing field-the "modal gap" between UI testing and API testing, leading to the difficulty of end-to-end business logic consistency verification in the industry.

[0003] Existing testing technologies mainly fall into two categories: one is UI automation testing based on Selenium and Playwright, and the other is API automation testing based on Postman and RestAssured. Through analysis, the existing technologies have the following inherent defects:

[0004] (1) Insufficient verification depth: UI testing can only verify the display and operation response of interface elements, and cannot penetrate to the back-end API call chain and business rule execution logic; API testing can verify interface functions, but cannot cover front-end data rendering logic, and cannot find consistency defects such as "API returns correctly but UI displays incorrectly".

[0005] (2) Verification dimension is fragmented: UI and API testing are designed and executed independently, and lack data correlation mechanisms. For example, the API call triggered by the "submit order" operation in UI testing needs to be manually checked in the API test report to confirm consistency, which is inefficient and prone to missing cross-modal defects.

[0006] (3) Lack of understanding of business semantics: existing tools are essentially "script executors" that can only execute operations according to pre-set scripts and cannot understand the business meaning behind the test. For example, when testing the "order payment" scenario, the tool cannot determine whether the "payment amount meets the discount rules".

[0007] In recent years, some existing technologies have attempted to introduce AI technology to optimize the testing process, such as generating test scripts based on LLM. However, such technologies only use AI for the "script generation" single link and do not run through the entire testing process: on the one hand, the generated scripts still need to be manually checked for compliance with business rules, and the "business semantic understanding" problem has not been solved; on the other hand, without business logic modeling capabilities, it cannot achieve collaborative verification of UI and API, and still cannot break through the "modal gap". SUMMARY

[0008] To solve the problems in the prior art, the application provides a UI test and API test collaborative test method and device based on a business logic chain graph, a computer device and a storage medium, which can understand business semantics, implement integrated testing of UI and API deep collaboration and fault analysis, and realize the testing paradigm upgrade from "script automation" to "cognitive intelligence". The technical solution is as follows:

[0009] In a first aspect, a UI test and API test collaborative test method based on a business logic chain graph is provided, including the following steps:

[0010] Step 1: Based on a first large language model, the business requirement document, interface specification and user interface metadata of a target system are semantically analyzed to construct a business logic chain graph; the graph at least includes the mapping relationship between UI elements and API interfaces and business elements, and the mapping relationship is used to represent the corresponding relationship between front-end UI elements and back-end API interfaces and business concepts or operations in the graph;

[0011] Step 2: Based on the business logic chain graph, a test workflow is automatically generated, and a UI executor and an API executor are concurrently driven for collaborative testing;

[0012] Step 3: Multi-modal data of the UI side, API side and data storage side in the testing process are synchronously captured, and a verification context is generated based on the multi-modal data;

[0013] Step 4: Based on the verification context and the business logic chain graph, a second large language model LLM is input for multi-dimensional consistency checking, and a standardized arbitration result is output.

[0014] In a second aspect, a UI test and API test collaborative test device based on a business logic chain graph is provided, which includes:

[0015] A business logic chain graph construction unit is configured to, based on a first large language model, semantically analyze the business requirement document, interface specification and user interface metadata of a target system to construct a business logic chain graph; the graph at least includes the mapping relationship between UI elements and API interfaces and business elements, and the mapping relationship is used to represent the corresponding relationship between front-end UI elements and back-end API interfaces and business concepts or operations in the graph;

[0016] A collaborative test unit is configured to, based on the business logic chain graph, automatically generate a test workflow and concurrently drive a UI executor and an API executor for collaborative testing;

[0017] A verification context generation unit is configured to synchronously capture multi-modal data of the UI side, API side and data storage side in the testing process, and generate a verification context based on the multi-modal data;

[0018] An arbitration unit is configured to perform multi-dimensional consistency verification based on the verification context and the service logic chain graph, input a second large language model (LLM), and output a standardized arbitration result.

[0019] In a third aspect, a computer device is provided, and the computer device comprises:

[0020] A memory is configured to store executable instructions.

[0021] A processor is configured to implement the method for UI test and API test collaboration based on a service logic chain graph according to the first aspect when executing the executable instructions stored in the memory.

[0022] In a fourth aspect, a computer readable storage medium is provided, and the computer readable storage medium stores executable instructions, and the executable instructions are executed by a processor to implement the method for UI test and API test collaboration based on a service logic chain graph according to the first aspect.

[0023] The method for UI test and API test collaboration based on a service logic chain graph has the following beneficial effects:

[0024] (1) A machine-executable service logic chain graph is constructed to realize automatic mapping from business requirements to test benchmarks and solve the problem of missing business semantic understanding.

[0025] (2) A collaboration mechanism for UI and API tests is established to break the modal gap and realize end-to-end business logic consistency verification.

[0026] (3) Based on LLM and graph topology, intelligent consistency arbitration and fault analysis are realized to shorten the troubleshooting time from hours to minutes.

[0027] (4) The method is suitable for multi-industry and multi-environment test requirements, provides an extensible tool chain and architecture, and reduces the landing threshold of enterprises. BRIEF DESCRIPTION OF DRAWINGS

[0028] Figure 1 FIG. 1 is a flowchart of a method for UI test and API test collaboration based on a service logic chain graph according to an embodiment of the present application;

[0029] Figure 2 FIG. 3 is a flowchart of a construction process of a service logic chain graph according to an embodiment of the present application;

[0030] Figure 3 FIG. 5 is a schematic diagram of a UI and API executor collaboration test process according to an embodiment of the present application;

[0031] Figure 4 FIG. 7 is a flowchart of a process of generating a verification context based on multi-modal data according to an embodiment of the present application.

[0032] Figure 5 FIG. 1 is a UI test and API test collaborative testing method flowchart with fault analysis in the embodiments of the present application;

[0033] Figure 6 FIG. 2 is a UI test and API test collaborative testing device structure diagram based on a business logic chain graph in the embodiments of the present application. DETAILED DESCRIPTION

[0034] It should be understood that the specific embodiments described herein are merely intended to explain the present application and are not intended to limit the present application.

[0035] Referring to Figure 1 The embodiments of the present application provide a UI test and API test collaborative testing method based on a business logic chain graph, including the following steps:

[0036] Step 1, based on a first large language model LLM, performing semantic analysis on the business requirement document, interface specification and user interface metadata of the target system, and constructing a business logic chain graph; the graph at least includes the mapping relationship between UI elements and API interfaces and business elements, and the mapping relationship is used to represent the corresponding relationship between front-end UI elements and back-end API interfaces and business concepts or operations in the graph;

[0037] Step 2, based on the business logic chain graph, automatically generating a test workflow, and concurrently driving a UI executor and an API executor to perform collaborative testing;

[0038] Step 3, synchronously capturing multi-modal data of the UI side, API side and data storage side in the testing process, and generating a verification context based on the multi-modal data;

[0039] Step 4, based on the verification context and the business logic chain graph, inputting a second large language model LLM to perform multi-dimensional consistency checking, and outputting a standardized arbitration result, which is used to represent abnormal item data in the test result.

[0040] In the embodiment of the present application, the business logic chain graph is constructed, the UI executor and the API executor are cooperatively tested, and the large language model LLM is combined to solve the problems of UI and API testing fragmentation and lack of business semantic understanding in the prior art. The business logic chain graph and the large language model (LLM) are used to realize deep cooperation of UI testing and API testing, and the test method and system with intelligent consistency checking and fault analysis capability are suitable for complex business system testing under micro-service and front-end and back-end separation architecture, especially for e-commerce, finance and other industries with high requirements for business logic consistency. In the embodiment of the present application, the "business logic chain graph" is taken as a unified verification benchmark, the LLM is taken as a business cognition engine, and a full-process intelligent testing system of "graph construction-cooperative execution-data fusion-intelligent arbitration" is constructed to realize deep cooperation of UI and API testing and system self-evolution.

[0041] In one embodiment, the step 1 of constructing the business logic chain graph includes:

[0042] Step 101, acquiring multi-source heterogeneous data, the multi-source heterogeneous data including unstructured, semi-structured and structured data;

[0043] Step 102, structuring, cleaning and standardizing the multi-source data to obtain standardized multi-source data;

[0044] Step 103, based on the standardized multi-source data and a pre-set sequential prompt word chain, extracting business elements by using a first large language model, the sequential prompt word chain including four-layer architecture of "basic layer-business layer-reasoning layer-output layer", and the business element extraction including extracting mapping relationships of UI, API and database to business operations;

[0045] Step 104, constructing a directed attribute graph based on the extracted elements to form a business logic chain graph and sequentially storing.

[0046] In the embodiment, the standardized multi-source data is taken as input, and the large language model is guided to extract business elements in combination with a pre-designed prompt word chain, and a business logic chain graph is constructed based on the extracted various business elements. Further, in order to optimize the response efficiency and response result accuracy of the large language model, a retrieval enhancement generation technology is used in the embodiment of the present application, the multi-source heterogeneous data collected in advance is structured and processed through multi-source data pre-association to form a vector, and stored in a vector database for inference process of the large language model.

[0047] Specifically, referring to Figure 2 In the embodiment of the present application, the step 1 of constructing the business logic chain graph includes:

[0048] Step 11, obtaining multi-source heterogeneous data including unstructured, semi-structured and structured data;

[0049] Step 12, structuring, cleaning and standardizing the multi-source heterogeneous data to obtain standardized multi-source data, performing cross-source data association preprocessing, feature vector generation and multi-dimensional vector fusion on the standardized multi-source data, and storing the fused multi-dimensional vector into a vector database, wherein the cross-source data association preprocessing includes obtaining the association relationship between business rules, APIs, UIs and databases based on similarity analysis technology;

[0050] Step 13, guiding a first large language model to extract business elements based on the vector database and a pre-set first sequential prompt word chain, wherein the first sequential prompt word chain includes four layers of architecture, i.e., a basic layer, a business layer, an inference layer and an output layer, and the extraction of business elements includes extracting the cross-modal mapping relationship of UIs, APIs and databases to business operations;

[0051] Step 14, constructing a directed attribute graph based on the extracted elements, forming a business logic chain map and sequentially storing it.

[0052] In an embodiment, the multi-source heterogeneous data in step 11 includes:

[0053] Unstructured data, including: PDF, Word, Markdown format business requirement and business rule description documents;

[0054] Semi-structured data, including: YAML / JSON format API development specification files, API request data, UI design drafts;

[0055] Structured data, including: UIDOM tree, database, mobile UI control tree.

[0056] In the embodiments of the present application, the data used to construct the business chain knowledge graph adopts multi-source heterogeneous data, including:

[0057] Unstructured PDF / Word / Markdown format business requirement and business rule description documents, etc.;

[0058] Semi-structured API development specification files, API request data, UI design drafts, etc.;

[0059] Structured data such as UIDOM tree, database, mobile UI control tree, etc.;

[0060] In step 12, the following steps are included:

[0061] Step 121, structuring the multi-source heterogeneous data;

[0062] Step 122, cleaning and standardization processing to obtain standardized multi-source data;

[0063] Step 123, cross-source data association preprocessing of standardized multi-source data;

[0064] Step 124, feature vector generation;

[0065] Step 125, multi-dimensional vector fusion;

[0066] Step 126, storing the fused multi-dimensional vector to the vector database.

[0067] Specifically, in step 121, for multi-source heterogeneous data, an adaptive structured processing and key data extraction method is used to obtain key data stored in multi-source heterogeneous data sources, for example:

[0068] For unstructured data, PDF file parsing technology, OCR recognition technology, Word document parsing technology, and Markdown document parsing technology can be used. Apache PDFBox (v2.0.32) is used to parse PDF format business requirement documents, combined with Tesseract OCR (v5.3.1) to process scanned copies. Python-docx (v0.8.11) is used to parse Word documents, preserving chapter structure (title level, paragraph relationship). Python-markdown (v3.4.4) is used to parse Markdown documents to extract lists, tables, and other business rule descriptions.

[0069] For semi-structured data, for example, PyYAML (v6.0.1) can be used to parse OpenAPI3.0 specifications (YAML / JSON format) to extract endpoint paths, HTTP methods, request / response schemas (field types, constraint conditions). Postman-collection (v4.4.1) is used to parse Postman Collections to extract API request examples and environment variables. Figma API (v1.0) is used to parse UI design drafts to extract component visual properties (size, color) and interaction relationships.

[0070] For structured data, for example, the UI DOM tree can be obtained by Playwright (v1.38.0), the unique identifier (XPath / CSS Selector) of the element is extracted, the core attributes (id, textContent, data-bind) are extracted; through JDBC to connect MySQL (v8.0.33) / PostgreSQL (v15.4) database, extract business table structure (field name, data type, primary key / foreign key); through Appium (v2.1.0) to obtain mobile UI control tree, extract resource-id, content-desc and other attributes.

[0071] In the above step 122, data cleaning and standardization processing is performed, which can be, for example:

[0072] Text denoising: regular expressions are used to remove headers and footers, page numbers, and stop words (such as "the" and "the") are removed by NLTK (v3.8.1), and the text purity is improved to more than 95%;

[0073] Format uniformity: map API data types to standard types (e.g. "integer" in OpenAPI is unified as "int64", "string(date)" is unified as "date(yyyy-MM-dd)"); unify UI element identifiers to "XPath+unique attribute" format (e.g. " / / input[@id='username']");

[0074] Conflict handling: establish a conflict level classification mechanism (fatal / warning / minor), for example, "API parameter type conflict with requirement document" is a fatal conflict, which automatically triggers manual confirmation; "UI element textContent representation difference" is a minor conflict, which is marked and continues to be processed;

[0075] Missing value completion: based on similar business rules to complete API parameter constraints (e.g. "password" field is not defined length, automatically complete "6-20 digits"); complete UI element state attributes (e.g. disabled, hidden) through simulation operation (Playwright's is_enabled() method).

[0076] In one embodiment, the above step 123, cross-source data association preprocessing includes:

[0077] (1) Business rules and API association: calculate the semantic similarity between business rules in the requirement document and API operation summaries, and retain the association pairs with a similarity greater than a first preset value; and further analyze whether the rule constraints and API parameter constraints are consistent, and retain the association pairs with consistent parameter constraints;

[0078] (2) UI elements and business operations are associated: business operation keywords in the UI element text are extracted through named entity recognition, and are matched with business operations in the requirement document; for textless elements, image recognition is used in combination with context semantic analysis to determine whether they are matched with business operations in the requirement document, so as to realize the association of UI elements and business operations;

[0079] (3) API and database association: the mapping relationship between API and business table is established through field name semantic matching.

[0080] In the embodiment of the application, the cross-source data association preprocessing in step 123 establishes a preliminary association relationship between multi-source data (documents, APIs, UIs, and databases) through algorithms (such as BERT, NER, and semantic matching), so as to provide candidate association pairs for the extraction process of the cross-modal mapping relationship in step 13. Specifically, (1) the association of business rules and APIs binds natural language business rules (such as "order amount ≥ 100 yuan") and API parameter constraints (such as orderAmount.min = 100), so as to ensure that the business rules have corresponding API execution points in the graph. (2) The association of UI elements and business operations maps the front-end interface operation (such as the "submit order" button) to the business operation node, so as to realize the link connection of UI operation→business action→API call. (3) The association of API and database establishes the mapping between API parameters and database fields, so as to ensure data consistency checking and traceability to the data source (such as the API return userId corresponding to the database user.id). The three types of associations together constitute the cross-modal business link: UI→business logic→API→database, so that the graph can completely express the full-process business logic "from front-end operation to data storage". Among them, (1) the association of business rules and APIs, the business rule is a natural language description of the business requirement (such as "free shipping for orders over 100 yuan"), and the API is a technical interface for implementing the rule (such as an API for calculating shipping). The association of business rules and APIs can realize the mapping of business semantics to technical implementation, and ensure that each business rule has a corresponding API (or API parameter) to execute. It can support automated test verification, and the API can be triggered according to the rule during testing, and it can be verified whether the API return result meets the business rule. It can avoid the disconnection between rules and implementation, and if the business rule is not associated with the API, it may have a loophole that "the rule is in the document, but not implemented by the system".

[0081] It should be noted that in the above calculation analysis of the association of the business rules and the API, only the "rule-API pair" that is semantically related and consistent in constraint will be finally adopted as a valid association. Misassociation (such as "order amount ≥ 100" misassociated with "query order list API") that is semantically similar but logically inconsistent is avoided. The accuracy and executability of the association are ensured, and reliable basis is provided for subsequent graph-driven testing.

[0082] Further, the above steps 124-126 include:

[0083] Step 124, feature vector generation: including the generation of the following three vectors, (1) semantic vector: encode the text block into a 768-dimensional vector using SentenceTransformer (all-MiniLM-L6-v2); (2) structured feature vector: one-hot encoding and normalization of structured information such as data types and constraint conditions to generate a 256-dimensional vector; (3) association relationship feature vector: hash encoding of association factors (such as the number of associated business rules) to generate a 128-dimensional vector.

[0084] Step 125, multi-dimensional vector fusion: weighted fusion using attention mechanism (for example, semantic vector weight 0.6, structured vector 0.3, and association vector 0.1) to generate a 1024-dimensional fusion vector;

[0085] Step 126, vector storage: store the vector into ChromaDB (v0.4.24) and configure HNSW index, with retrieval response time ≤ 100 ms and support for multi-condition filtering (such as "retrieve business rule vectors of order module associated API").

[0086] In an embodiment, the extracted business elements in the above step 13 include:

[0087] a) Extract core business concepts and build a standardized vocabulary;

[0088] b) Extract structured elements, including: extract business entities and attributes; convert natural language rules into "IF-THEN" expressions to obtain formalized business rules; analyze and obtain business processes;

[0089] c) Extract entity state and transition rules to build a state machine;

[0090] d) Extract cross-modal mapping relationships, including: UI element to business operation mapping (UI-business mapping) and API to business operation mapping (API-business mapping).

[0091] Specifically, in the embodiments of the present application, the business element extraction task of step 13 includes:

[0092] a) Field concept unification: Extract core business concepts (e.g., "order, payment, refund") and define a standardized vocabulary (e.g., "unify 'Pending' as 'Pending' to avoid ambiguity between 'unpaid' and 'pending payment'").

[0093] b) Structured element extraction:

[0094] Business entities and attributes: Identify entities (e.g., "order") and their attributes (e.g., "orderId:string, orderAmount:decimal(10,2), orderStatus:enum [Pending, Paid, Shipped]").

[0095] Business rule formalization: Convert natural language rules into "IF-THEN" expressions (e.g., "IF orderAmount≥200 THEN shippingFee=0 ELSE shippingFee=10").

[0096] Business process analysis: Analyze core processes (e.g., "order placement process: add to cart → submit order → pay → generate order").

[0097] c) State machine modeling: Define entity states and transition rules (e.g., "order state transition: Pending → Paid (trigger condition: payment success), Paid → Shipped (trigger condition: merchant shipment)").

[0098] d) Cross-modal mapping analysis:

[0099] UI-business mapping: Establish mapping between UI elements and business operations (e.g., " / / button [@id='payBtn'] → trigger payment operation").

[0100] API-business mapping: Establish mapping between APIs and business operations (e.g., "POST / api / pay → execute payment operation, return payment result").

[0101] This cross-modal mapping relationship analysis converts the associated relationships obtained through preprocessing into structured mapping relationships in the graph (e.g., "UI button → business operation → API call"), forming a machine-executable business logic chain.

[0102] In one embodiment, the above step 13, the prompt word chain of the four-layer architecture of the base layer, the business layer, the reasoning layer, and the output layer, the base layer is business domain knowledge, the business layer is business element extraction task description, the reasoning layer is business element extraction step description, and the output layer is the standardized format of the reasoning result.

[0103] Specifically, the base layer: import business domain knowledge (such as "e-commerce domain core entities include orders, goods, users"); business layer: clearly extract targets (such as "extract order status and transition rules"); reasoning layer: define extraction steps (such as "first identify state names, then sort out state-to-state trigger conditions").

[0104] Examples of the four-layer architecture of the prompt word chain are as follows:

[0105]

Base Layer

[0106] You are an e-commerce domain business analyst who needs to extract business elements from multiple sources of data.

[0107] E-commerce core concepts include: orders, users, goods, payments, logistics.

[0108]

Business Layer

[0109] Please extract the following elements from the provided business documents, API specifications, and UI designs: 1. Business entities and their attributes; 2. Business rules (converted to IF-THEN format); 3. Business process steps; 4. State machine model; 5. Mapping of UI elements to business operations; 6. Mapping of API to business operations.

[0110]

Reasoning Layer

[0111] Please analyze according to the following steps:

[0112] Step 1: Identify all business nouns in the text and determine core entities

[0113] Step 2: Extract attributes of each entity (name, type, constraints)

[0114] Step 3: Convert natural language rules to formalized rules

[0115] Step 4: Sort out the time sequence of the business process

[0116] Step 5: Define entity states and transition conditions

[0117] Step 6: Establish the association between UI elements and business operations

[0118] Step 7: Establish the association between API endpoints and business operations

[0119]

Output Layer

[0120] Please output strictly in JSON format:

[0121] {

[0122] "entities": [...],

[0123] "rules": [...],

[0124] "processes": [...],

[0125] "state_machines": [...],

[0126] "ui_mappings": [...],

[0127] "api_mappings": [...]

[0128] }.

[0129] In an embodiment, the step 14 described above constructs a directed attribute graph based on the extracted elements, forming a business logic chain graph, including:

[0130] Step 141, taking business entity nodes, business operation nodes, and system state nodes as graph nodes;

[0131] Step 142, taking data flow edges, control flow edges, and constraint edges as graph edges;

[0132] Step 143, injecting UI and API mappings into business operation nodes;

[0133] Step 144, using the iteration synthesis algorithm of nodes and edges in graph theory, first constructing core entity nodes, then adding operation nodes and state nodes based on business processes, and finally connecting through data flow / control flow edges to form a business logic chain graph.

[0134] Step 14, based on the extracted business elements described above, construct a business logic chain graph. The element extraction is the "raw material preparation" stage of graph construction. The extracted elements will be used to form different components of the graph. The corresponding relationship is as follows:

[0135] Table 1 Correspondence between extracted business elements and graph components

[0136] Serial number Business element extraction result Corresponding graph component 1 Unified domain concept, standardized vocabulary Standardized vocabulary (basis for node labels and attribute values) 2 Business entities and attributes Business entity node + attribute definition 3 Formal business rules Constraint edges + control flow logic 4 Business process Operation node sequence + data flow edge + control flow edge 5 State machine System state node + state transition edge 6 Cross-modal mapping relationship Cross-modal attributes of nodes (UI / API mapping information embedded in nodes)

[0137] Specifically, in the business logic chain graph:

[0138] Business entity nodes: Nodes have attribute information. Business entity nodes such as "order" entity nodes, "user" entity nodes, and "goods" entity nodes. The "order" entity node has attributes such as orderId:string and orderAmount:decimal.

[0139] Business operation node: derived from the business element "business process", and based on the "cross-modal mapping relationship" business element, UI / API mapping information is embedded for the operation node in the graph.

[0140] System state node: derived based on the business element "state machine", such as "pending state node", "paid state node", "shipped state node", etc., and connected between state nodes through transition rules.

[0141] Data flow edge: derived from the data transmission process between steps in the business element "business process", and the data input and output between entities and operations; the edge attribute of the data flow edge has: the data field name and type of the transmitted data;

[0142] Control flow edge: represents the control logic of business process or state transition, derived from the sequence between steps in the business element "business process" and the state transition rules in the business element "state machine"; for example, the "Pending→Paid" edge, with the attribute of trigger condition: payment success; the "submit order→payment" edge, with the attribute of execution order: sequential execution; the edge attribute of the control flow edge: annotates the trigger condition, execution condition and other control logic;

[0143] Constraint edge: represents the restriction of business rules on node behavior, derived from the IF-THEN expression in the business element "formal business rules", for example, the "order→amount constraint" edge, with the attribute of constraint condition: orderAmount≥0; the "order→shipping rules" edge, with the attribute of IF orderAmount≥200 THEN shippingFee=0. The edge attribute of the constraint edge: complete rule expression and execution logic.

[0144] Further, the graph is stored in a serialized format: supporting JSON-LD (for machine parsing) and Cypher script (for Neo4j storage).

[0145] Referring to Figure 3 In an embodiment, the above step 2 automatically generates a test workflow based on the business logic chain graph, and drives the UI executor and API executor to perform collaborative testing, including the following steps:

[0146] Step 21, based on the graph topology and constraint rules, generate a test sequence that covers the core business path and data;

[0147] Step 22, through the centralized session context manager and event listening mechanism, realize the state sharing and collaboration of UI and API executors, and the process includes:

[0148] A unique session ID, denoted as session_id, is assigned to each test session, a shared context object is created to store session-level variables, environment configurations, and test progress;

[0149] The collaborative test process of the UI executor and the API executor is driven in the session context manager: the UI executor performs the current operation, confirms that the UI executor has completed the operation by using an event listening mechanism, calls the context manager interface to write the operation result into the shared context, updates the session state, triggers the API executor to perform the operation, the API executor reads the latest UI operation result from the shared context, obtains the calling parameters and parses the response, confirms that the API executor has completed the operation by using an event listening mechanism, calls the context manager interface to synchronously write the response result into the context for the UI executor to assert, and triggers the UI executor to perform the next operation.

[0150] It should be noted that in the embodiments of the present application, the session context manager listens to the response results of the UI executor and the API executor through an event listening mechanism, drives the automatic execution of UI testing and API testing, and avoids the problems of state asynchronization and inability to handle asynchronous callbacks caused by hard-coded waiting time. For example, the API response state is continuously listened to, and when the API execution is completed (such as “the callback API returns success=true”), the subsequent operation of the UI executor (such as “displaying the ‘upload success’ prompt”) is triggered, which avoids the disconnection of test steps caused by asynchronous delay, and the success rate of asynchronous operation processing is ≥95%.

[0151] In the prior art, for UI testing and API testing, there are generally the following three modes: the first mode is to separately perform UI testing and API testing, and then manually compare the two test reports to determine the test result. This test mode completely separates UI testing and API testing, and cannot discover cross-modal inconsistency in real time. The second mode is to implement UI testing and API testing together based on script hard coding, first perform UI operation, then hard code to set a fixed waiting time to wait for API response, and after API verification, hard code to set a fixed waiting time to wait for UI rendering. In this mode, hard-coded waiting leads to unstable testing, and the state may be out of synchronization (API is successful but UI is not rendered), and asynchronous callbacks cannot be handled. The third mode is simple data transmission through global variables. In this case, there are thread safety and test pollution problems between tests.

[0152] In the embodiments of the present application, the unified context management of UI operation, API calling and business state is realized by using the centralized session context manager, the tool boundaries of UI testing and API testing are broken, and real-time collaboration is realized; through the timestamp and event listening mechanism, the state consistency during verification is ensured; the complex asynchronous test scene is standardized as an event listening mode. From the test paradigm level, the traditional "script execution" is upgraded to "state-driven intelligent collaboration", and the core pain points of long-term separation of UI testing and API testing are solved.

[0153] In the prior art, UI testing tools (Selenium, Playwright) have page context (Page Context), testing tools (Postman, RestAssured) have request context (Request Context), and integration testing frameworks have test case context (Test Case Context), none of which involves joint context management of UI testing and API testing. The centralized session context manager in the present application sets a unified context of "UI+API+business state", realizes cross-modal unified context, and uniformly manages the context of UI operation, API calling and business state; realizes real-time bidirectional synchronization: UI operation results automatically trigger API context update, and API response automatically triggers UI verification update; realizes session-level state tracking: complete recording of end-to-end state flow from UI operation to API calling to database change.

[0154] Specifically, in the above step 21, based on the graph topology and constraint rules, a test sequence and data covering the core business path are generated, including:

[0155] Step 2101, path traversal and test sequence generation:

[0156] The depth-first search (DFS) algorithm is used to traverse the business paths in the graph, from the initial state node (such as "order-to-be-created") to the terminal state node (such as "order-completed"), each path corresponds to a test scene;

[0157] Path priority sorting: based on node weight (core business node weight is high) and path length (short path first), the sorting result is used for test resource allocation (such as "order payment path" is executed first);

[0158] Test sequence generation: convert the path into executable steps (such as "step 1: call the create order API, step 2: click the UI payment button, step 3: verify the order state as Paid").

[0159] Step 2102, intelligent test data generation:

[0160] Constraint solving: The Z3 constraint solver (v4.12.2) is used to generate boundary test data based on the “IF-THEN” rule in the graph (e.g., “rule: orderAmount≥100, generated data: 99.99 (not satisfied), 100 (satisfied), 1000 (satisfied)”).

[0161] In one implementation, step 3 above involves simultaneously capturing multimodal data from the UI side, API side, and data storage side during the testing process, and generating a verification context based on the multimodal data. The multimodal data from the UI side, API side, and data storage side includes:

[0162] UI-side data includes: interaction operation data, interface status data, and front-end log data;

[0163] API-side data includes: request / response data, call chain data, and interface performance data;

[0164] Data storage side data includes: database operation data and data snapshots of business tables during testing.

[0165] Specifically, the captured UI-side data includes:

[0166] 1. Interactive operation data: Through the Playwright / Appium event listener interface, record the UI operation type (click, input, selection), operation element (XPath / CSS Selector), operation timestamp (accurate to milliseconds), and operation result (success / failure, such as "Enter username: testuser, result: success").

[0167] 2. Interface State Data: After each test step is completed, the current interface DOM tree (web version) / control tree (mobile version) is automatically captured, and the state of core elements is extracted (such as "order status text box textContent: paid" and "payment button disabled: false"). At the same time, a screenshot of the interface is captured (1920×1080 resolution), and the operation area is marked (such as "payment button" marked with a red box) to facilitate manual backtracking.

[0168] 3. Front-end log data: Capture front-end JavaScript errors (such as "Uncaught ReferenceError: orderStatus is not defined") and API call logs (such as "GET / api / order / 12345, status:200") through browser console log monitoring (Web) / Android Logcat (mobile), with a log capture coverage of ≥98%.

[0169] Captured API-side data includes:

[0170] 1. Request / response data: All API calls are intercepted by the API executor, recording request URL, HTTP method, request headers (including authentication Token), request parameters (Query / Body), response status code, response headers, response body (structured and parsed into JSON), and saving the original message (for exception troubleshooting);

[0171] 2. Call link data: Integrating Jaeger distributed tracking tool, assigning a unique trace_id to each API call, associating upstream and downstream service calls (such as "create order API → deduct inventory API → generate payment API"), recording the call duration of each service (such as "deduct inventory API takes 200ms"), service node IP and port, and call link visualization display, facilitating the positioning of service interaction exceptions;

[0172] 3. Interface performance data: Recording API response time (time spent from sending request to receiving complete response), request success rate (number of successful responses / total number of requests), peak QPS (queries per second), performance data sampling frequency 1 time / second, providing basis for performance bottleneck analysis.

[0173] Captured data storage-side data includes:

[0174] 1. Database operation data: Through JDBC agent / MySQL Binlog monitoring, capturing database insert, delete, update and query operations during testing (such as "INSERT INTO order (orderId, amount) VALUES ('123456',200)"), operation timestamp, execution result (success / failure, such as "UPDATE affected row count: 1");

[0175] 2. Data snapshot: Before the test starts, after the key steps (such as "after payment is completed"), and after the test ends, automatically generate data snapshots for core business tables (such as order, payment, user), record the current state of all data rows in the table, support data comparison before and after testing (such as "order amount is 200 yuan before payment, order status changes from 'to be paid' to 'paid' after payment").

[0176] It should be noted that the multi-modal data of the UI side, the API side and the data storage side includes structured data (session metadata, business entity attribute mapping, exception marking) and unstructured data (UI screenshot, API raw message, database snapshot). When serializing the verification context generated based on the multi-modal data, a hybrid storage strategy is adopted, for example, the structured data is serialized in the JSON-LD format, and the unstructured data is stored in a binary format.

[0177] Referring to Figure 4 In an embodiment, step 3 above, the verification context is generated based on the multi-modal data, the multi-modal data is associated based on the session ID (session_id) and the business entity (such as an order, a user), and an “entity-centered” verification context model is constructed, which specifically includes:

[0178] Step 31, taking the session ID (session_id) of the test session as the top-level association primary key, to ensure that all captured data belongs to a unique session;

[0179] Step 32, taking the core business entity ID as the secondary association primary key, to associate the UI data, the API data and the database data to the same entity, the core business entity ID including an order ID, a user ID and a payment ID;

[0180] Step 33, constructing a verification context model, which includes the following structure:

[0181] (1) Session metadata layer: storing basic information of the test process, including the session ID (session_id), the test scenario name (such as “order payment scenario”), the test start and end time, the test environment and the executor;

[0182] (2) Business entity layer: organizing data in units of business entities, each entity containing an association mapping relationship between entity attributes and multi-source values, the multi-source values including UI side data, API side data and database side data; the “entity attribute-multi-source value” mapping represents the association mapping between the attributes of the entity and the UI side data, the API side data and the database side data, to form a mapping relationship in the form of “entity attribute-UI side data-API side data-database side data”;

[0183] (3) Operation log layer: storing full-link operation logs in chronological order, including UI operations, API calls and database operations, each log being associated with a corresponding business entity ID;

[0184] (4) Exception marking layer: automatically detecting multi-source data conflicts, marking the conflict attributes, the conflict data sources and the conflict timestamps.

[0185] Further, the verification context generated in step 3 is further subjected to data cleaning and standardization, and is serialized and stored in layers.

[0186] In an embodiment, step 4, based on the verification context and the business logic chain graph, inputs a second large language model LLM to perform multi-dimensional consistency verification, and outputs a standardized arbitration result, including:

[0187] Based on the verification context and the business logic chain graph, a second large language model LLM is inputted, and the inference logic of the second large language model LLM is constrained in combination with a preset second sequential prompt word chain, which includes a four-layer architecture of a reference layer, a data layer, an inference layer, and an output layer. The reference layer includes at least consistency verification standards, including data consistency, behavior consistency, and state consistency. The data consistency is used to verify whether the property values of the same entity in the UI, API, and database are completely consistent. The behavior consistency is used to verify whether the API call chain triggered by the UI operation is consistent with the business process in the graph. The state consistency is used to verify whether the entity state transition conforms to the state machine rules in the graph.

[0188] In an embodiment, the second sequential prompt word chain in step 4 includes a four-layer architecture of a reference layer, a data layer, an inference layer, and an output layer.

[0189] The reference layer prompt includes business logic chain graph core information and consistency verification standards, and the business logic chain graph core information includes business entity definition, business rules, and cross-modal mapping relationship.

[0190] The data layer prompt includes verification context key data and data priority annotation data, and the verification context key data includes business entity attribute multi-source value, operation log, and exception mark. The data priority annotation data is used to annotate the priority of database data, API data, and UI data in descending order.

[0191] The inference layer prompt includes sequential inference steps, including data consistency verification, behavior consistency verification, state consistency verification, and conflict analysis.

[0192] The output layer prompt includes the standardized format of the arbitration result, which includes the following fields: arbitration ID, verification dimension, arbitration result of each dimension, specific conclusion, reasoning basis, confidence, and suggested action. The reasoning basis is expressed by referencing graph rules and verification context data.

[0193] Specifically, the four-layer architecture of the reference layer, the data layer, the inference layer, and the output layer includes:

[0194] Baseline layer hints:

[0195] 1. Import business logic chain graph core information, including business entity definition (such as "Enumeration value of order entity attribute orderStatus: Pending, Paid, Shipped, Completed"), business rules (such as "IF payment success THEN orderStatus should change from Pending to Paid"), cross-modal mapping relationship (such as "UI order status text should correspond to API returned orderStatus enumeration value: Paid→Paid");

[0196] 2. Clearly define consistency checking standards, for example, "Data consistency: The same entity attribute value in UI, API, and database should be completely consistent (after format unification); Behavior consistency: The API call chain triggered by UI operation should be consistent with the business process in the graph; State consistency: Entity state transition should comply with the state machine rules in the graph."

[0197] Data layer hints:

[0198] 1. Import verification context key data, including business entity attribute multi-source values (such as "orderStatus of orderId=123456: UI = Paid, API = Pending, Database = Pending"), operation logs (such as "15:30 Execute payment operation, 15:31 Call / api / order / status to get status"), exception markers (such as "UI and API orderStatus conflict");

[0199] 2. Label data priority, for example, "Database data is the business fact source, with the highest priority; API data is second; UI data is affected by front-end rendering logic, with the lowest priority", providing basis for the second large language model to judge the correctness of conflicting data.

[0200] Reasoning layer hints:

[0201] Define standardized reasoning steps to guide the second large language model to perform verification in order:

[0202] Step1: Data consistency verification - Compare the same entity attribute values in UI, API, and database to determine whether they are consistent (including format and semantic consistency, such as "API returns Paid and UI displays 'Paid' for semantic consistency");

[0203] Step2: Behavior consistency check - Check if the API call chain triggered by UI operations matches the business process in the graph (e.g., "whether to call the create order API first, then call the payment API"), and if the API parameters meet the constraints in the graph (e.g., "whether orderAmount is ≥ 0");

[0204] Step3: State consistency check - Verify if the entity state transition meets the state machine rules in the graph (e.g., "whether there is an illegal transition from Shipped to Pending directly"), and if the state transition trigger condition is met (e.g., "only after payment success is orderStatus allowed to be Paid");

[0205] Step4: Conflict analysis - If there is inconsistency, analyze the possible reasons (e.g., "UI rendering delay, API logic error, database update failure"), and associate the exception logs in the verification context (e.g., "front-end JavaScript error may cause UI display abnormalities").

[0206] Output layer prompt:

[0207] Define a standardized format for the arbitration result, and force to include the following fields:

[0208] a. Arbitration ID: Unique identifier (e.g., "arbitration_123456");

[0209] b. Check dimension: Data consistency / Behavior consistency / State consistency;

[0210] c. Arbitration result: PASS (consistent) / FAIL (inconsistent) / WARN (to be confirmed);

[0211] d. Specific conclusion: Describe the verification process and results (e.g., "data consistency check FAIL: UI displays orderStatus = Paid, API and database return orderStatus = Pending, judge that UI display and backend data are inconsistent");

[0212] e. Reasoning basis: Reference graph rules and verification context data (e.g., "according to graph rule R001: orderStatus should be Paid after payment success; verification context shows that the payment operation does not return a successful response (API / api / pay returns status = failed), so the API and database state is correct, and the UI display is wrong");

[0213] f. Confidence: 0-100 points (based on the sufficiency of the reasoning basis, e.g., "reasoning basis is sufficient, confidence is 95 points");

[0214] g. Suggestion action: give follow-up processing suggestions for FAIL / WARN results (such as "Suggest checking the UI side orderStatus rendering logic to check whether the API failure response is not handled correctly").

[0215] Reference Figure 5 In an embodiment, after step 4, the method further comprises: step 5, when the test result represents an abnormality, performing fault analysis on the abnormal point based on the business logic chain graph to form a fault diagnosis report.

[0216] In the embodiment, the "business logic chain graph" is taken as a unified verification benchmark, and the LLM is taken as a business cognition engine to build a full-process intelligent testing system of "graph construction-collaborative execution-data fusion-intelligent arbitration-fault analysis and positioning", thereby realizing deep collaboration of UI and API testing and system self-evolution.

[0217] Specifically, the step 5 of performing fault analysis on the abnormal point to form a fault diagnosis report can include: performing fault propagation analysis and reasoning on the abnormal point, locating the root cause of the fault, and generating a diagnosis report containing the root cause and warning information.

[0218] The fault propagation analysis and reasoning on the abnormal point can include the following steps:

[0219] Step 501, based on the business logic chain graph, filtering the nodes and edges directly associated with the consistency check abnormal point to form a fault correlation subgraph;

[0220] Step 502, according to a preset weighting method, weighting the edges between the nodes of the fault correlation subgraph to construct a fault propagation weight matrix;

[0221] Step 503, according to the fault propagation weight matrix, using a depth-first search and pruning strategy to calculate the probability of each propagation path to obtain a preset number of propagation paths with larger propagation probability as the fault propagation analysis and reasoning result.

[0222] The construction of the fault propagation weight matrix includes: defining the matrix element W(A, B) as the probability that the fault of node A leads to the abnormality of node B, and calculating the weight in three dimensions of dependency type, historical fault data, and real-time state, wherein the weight setting method is:

[0223] According to the dependency type between nodes A and B, set the initial weight W1 as W(A, B), and the dependency type includes data flow dependency, control flow dependency, and association dependency;

[0224] Obtain the proportion of the number of times that the fault of node A leads to the abnormality of node B in the historical data Then, update W(A, B) to W1(1+ ).

[0225] The updated probability is adjusted based on the current real-time status of node A. If node A has abnormal logs, then in W1(1+ Based on the above, further increase the probability of W(A, B). If node A is in a normal state, then in W1(1+ Based on this, further reduce the probability W(A, B).

[0226] Specifically, for example:

[0227] Basic weight assignment: Set initial weights according to the dependency type between nodes (data flow dependency 0.6, control flow dependency 0.3, association dependency 0.1);

[0228] Historical data adjustment: If the percentage of times "Node A failure causes Node B to malfunction" in the historical data is [percentage missing], then [the following is missing from the original text]. The weights are then updated to W(A, B) × (1 + ... )( The value range is 0-0.5 to avoid the influence of extreme values.

[0229] Real-time status adjustment: If node A has abnormal logs (such as API returning a 500 error), the weight is increased by an additional 20%; if node A is in a normal state (such as API response time ≤ 300ms), the weight is decreased by 10%.

[0230] In one implementation, step 5 above, which involves locating the root cause of the fault, includes the following steps:

[0231] Step 511: Based on the fault association subgraph features and combined with the preset verification knowledge base template, automatically generate 3-5 initial root cause hypotheses. The initial root causes of the hypotheses include technical layer reasons, business layer reasons, and configuration layer reasons.

[0232] Step 512: Collect multi-dimensional evidence. Extract evidence directly related to the hypothesis from "verification context + real-time logs + database snapshots". The evidence must meet the requirements of "quantifiable and verifiable".

[0233] Step 513: Based on Bayes' theorem, the evidence is substituted sequentially to update the hypothesis weights, so that the more evidence there is, the more accurate the root cause becomes.

[0234] In one implementation, step 5 above can be used to classify early warnings. By combining the scope of the fault's impact with the weight of the core root cause, the early warnings can be divided into four levels, P0-P3 (the classification criteria can be configured according to industry needs).

[0235] In one implementation, after step 5 above, the method further includes:

[0236] Step 6, the whole process data of the current test process, including the business logic chain graph, the verification context, the test result and the fault analysis result, is stored in the verification knowledge base in a structured manner, which is used to optimize the construction accuracy of subsequent graphs and the test strategy. In the embodiment of the application, the "business logic chain graph" is taken as a unified verification benchmark, the LLM is taken as a business cognition engine, and a whole-process intelligent test system of "graph construction-collaborative execution-data fusion-intelligent arbitration-fault analysis positioning-continuous learning" is constructed. The test whole-process data (graph, verification context, arbitration result, root cause report) is stored in the verification knowledge base, and the system self-evolution is realized through knowledge reuse and model optimization.

[0237] Referring to Figure 6 The embodiment of the application provides a UI test and API test collaborative test device based on a business logic chain graph, which comprises:

[0238] A business logic chain graph construction unit is configured to perform semantic analysis on a business demand document, an interface specification and user interface metadata of a target system based on a first large language model, and construct a business logic chain graph. The graph at least comprises mapping relationships between UI elements and API interfaces and business elements, respectively, and the mapping relationships are used to represent the corresponding relationship between front-end UI elements and back-end API interfaces and business concepts or operations in the graph.

[0239] A collaborative test unit is configured to automatically generate a test workflow based on the business logic chain graph, and concurrently drive a UI executor and an API executor to perform collaborative testing.

[0240] A verification context generation unit is configured to synchronously capture multi-modal data of the UI side, the API side and the data storage side in the test process, and generate a verification context based on the multi-modal data.

[0241] An arbitration unit is configured to input a second large language model LLM based on the verification context and the business logic chain graph to perform multi-dimensional consistency checking, and output a standardized arbitration result.

[0242] In an implementation manner, the UI test and API test collaborative test device based on the business logic chain graph further comprises a fault analysis unit configured to, when the test result represents that there is an abnormality, perform fault analysis on the abnormal point based on the business logic chain graph, and form a fault diagnosis report.

[0243] The specific limitation of the UI test and API test collaborative test device based on the business logic chain graph can be referred to the limitation of the UI test and API test collaborative test method based on the business logic chain graph in the foregoing, which will not be described herein again.

[0244] The embodiment of the application provides a computer device, which comprises:

[0245] a memory for storing executable instructions;

[0246] a processor for implementing the service logic chain graph-based UI testing and API testing collaborative testing method in the above method embodiments when running the executable instructions stored in the memory.

[0247] In some embodiments, the computer device can further optionally include an input interface and an output interface. The processor, the memory, and the input interface and the output interface can be connected through a bus or a signal line. Each peripheral device can be connected to the input interface and the output interface through the bus, the signal line or the circuit board. The input interface and the output interface can be used to connect at least one input / output related peripheral device to the processor and the memory.

[0248] The embodiments of the present application provide a computer readable storage medium storing executable instructions, and the executable instructions are executed by a processor to implement the service logic chain graph-based UI testing and API testing collaborative testing method in the above method embodiments.

[0249] Those skilled in the art can understand that all or part of the steps of the above embodiments can be completed by hardware, or can be completed by programs instructing relevant hardware, and the programs can be stored in a computer readable storage medium. The computer readable storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk. Those skilled in the art should realize that the functions described in the above one or more examples can be implemented by hardware, software, firmware or any combination thereof. When implemented by software, the functions can be stored in a computer readable storage medium or transmitted as one or more instructions or codes on a computer readable storage medium.

[0250] The present application is not limited to the above specific embodiments, and those skilled in the art can make various modifications without creative labor, and all the modifications fall within the protection scope of the present application.

Claims

1. A collaborative testing method for UI testing and API testing based on a business logic chain graph, characterized in that, Includes the following steps: Step 1: Based on the first large-scale language model, perform semantic parsing on the business requirements document, interface specifications, and user interface metadata of the target system to construct a business logic chain graph; the graph includes at least the mapping relationship between UI elements and API interfaces and business elements, and the mapping relationship is used to represent the correspondence between front-end UI elements and back-end API interfaces and business concepts or operations in the graph; Step 2: Automatically generate a test workflow based on the business logic chain graph, and concurrently drive the UI executor and API executor to perform collaborative testing; Step 3: Simultaneously capture multimodal data from the UI side, API side, and data storage side during the test, and generate a verification context based on the multimodal data; Step 4: Based on the verification context and the business logic chain graph, input the second large-scale language model LLM for multi-dimensional consistency verification and output the standardized arbitration result; Step 1, the steps of constructing the business logic chain graph, include: Step 11, acquiring multi-source heterogeneous data, including unstructured, semi-structured, and structured data; Step 12, performing structuring, cleaning, and standardization processing on the multi-source heterogeneous data to obtain standardized multi-source data, performing cross-source data association preprocessing, feature vector generation, and multi-dimensional vector fusion on the standardized multi-source data, and storing the fused multi-dimensional vectors in a vector database. The cross-source data association preprocessing includes: obtaining the association relationships between business rules, APIs, UIs, and databases based on similarity analysis technology; Step 13, based on the vector database and a preset first sequential prompt word chain, guiding the first large language model to extract business elements. The first sequential prompt word chain includes a four-layer architecture: a basic layer, a business layer, an inference layer, and an output layer. The extraction of business elements includes: extracting the cross-modal mapping relationships from UIs, APIs, and databases to business operations; Step 14, constructing a directed attribute graph based on the extracted elements to form the business logic chain graph, and storing it serially.

2. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 1, characterized in that, In step 11, The unstructured data includes: business requirements and business rule description documents in PDF, Word, and Markdown formats; The semi-structured data includes: API development specification documents in YAML / JSON format, API request data, and UI design drafts; The structured data includes: UI DOM tree, database, and mobile UI control tree.

3. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 1, characterized in that, In step 12, the cross-source data association preprocessing includes: Business rules and API association: Calculate the semantic similarity between business rules in the requirements document and API operation summaries, and retain association pairs with similarity exceeding a first preset value; further analyze whether the rule constraints and API parameter constraints are consistent, and retain association pairs with consistent parameter constraints; Associating UI elements with business operations: Keyword of business operations is extracted from the text of UI elements by named entity recognition and matched with business operations in the requirements document; for elements without text, image recognition combined with contextual semantic analysis is used to determine whether they match business operations in the requirements document, thus realizing the association between UI elements and business operations. API and database association: Establish a mapping relationship between API and business tables through semantic matching of field names.

4. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 1, characterized in that, The extracted business elements in step 13 include: a) Extract core business concepts and construct a standardized vocabulary; b) Extract structured elements, including: extracting business entities and attributes; converting natural language rules into "IF-THEN" expressions to obtain formalized business rules; and analyzing and obtaining business processes. c) Extract entity states and transition rules, and construct a state machine; d) Extract cross-modal mapping relationships, including: UI element to business operation mapping (UI-business mapping) and API to business operation mapping (API-business mapping).

5. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 1, characterized in that, In step 13, the prompt word chain of the four-layer architecture of the base layer, business layer, reasoning layer, and output layer is as follows: the base layer is business domain knowledge, the business layer is a description of the business element extraction task, the reasoning layer is a description of the business element extraction steps, and the output layer is a standardized format of the reasoning result.

6. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 1, characterized in that, Step 14 includes: Business entity nodes, business operation nodes, and system status nodes are used as graph nodes; Data flow edges, control flow edges, and constraint edges are used as the edges of the graph; Inject UI and API mappings into business operation nodes; Using an iterative synthesis algorithm of nodes and edges in graph theory, core entity nodes are first constructed, then operation nodes and state nodes are added based on business processes, and finally connected by data flow / control flow edges to form a business logic chain graph.

7. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 1, characterized in that, Step 2 includes: Step 21: Based on the graph topology and constraint rules, generate test sequences and data covering the core business paths; Step 22: Through a centralized session context manager and event listener mechanism, state sharing and collaboration between the UI and API executors are achieved. This process includes: Assign a unique session ID to each test session, create a shared context object, and store session-level variables, environment configuration, and test progress. The collaborative testing process of UI executors and API executors is driven in the session context manager: The UI executor executes the current operation. After confirming that the UI executor has completed the operation using the event listener mechanism, it calls the context manager interface to write the operation result to the shared context, updates the session state, and triggers the API executor to execute the operation. The API executor reads the latest UI operation result from the shared context, obtains the call parameters, and parses the response. After confirming that the API executor has completed the operation using the event listener mechanism, it calls the context manager interface to synchronously write the response result to the context for the UI executor to assert and triggers the UI executor to execute the next operation.

8. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 1, characterized in that, Step 3, multimodal data from the UI side, API side, and data storage side, including: UI-side data includes: interaction operation data, interface status data, and front-end log data; API-side data includes: request / response data, call chain data, and interface performance data; Data storage side data includes: database operation data and data snapshots of business tables during testing.

9. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 1, characterized in that, Step 3, generating a verification context based on multimodal data, includes: Use the session ID of the test session as the top-level association primary key to ensure that all captured data belongs to a unique session; Using the core business entity ID as the secondary association primary key, UI data, API data, and database data are associated with the same entity; Construct a validation context model, which includes the following structure: Session metadata layer: Stores basic information about the testing process, including session ID, test scenario name, test start and end time, test environment, and executor; Business Entity Layer: Data is organized in units of business entities. Each entity contains the association mapping relationship between entity attributes and multi-source values, which include UI-side data, API-side data, and database-side data. Operation log layer: Stores full-chain operation logs sorted by timestamp, including UI operations, API calls, and database operations. Each log entry is associated with a corresponding business entity ID. Anomaly marking layer: Automatically detects multi-source data conflicts and marks conflict attributes, conflict data sources, and conflict timestamps.

10. The UI testing and API testing collaborative testing method based on a business logic chain graph according to claim 1, characterized in that, Step 4 includes: The second large-scale language model is input based on the verification context and the business logic chain graph, and the reasoning logic of the second large-scale language model is constrained by the preset second sequential prompt word chain. The second sequential prompt word chain includes a four-layer architecture: base layer, data layer, reasoning layer, and output layer. The base layer includes at least a consistency verification standard, which includes data consistency, behavior consistency, and state consistency. The data consistency is used to verify whether the attribute values ​​of the same entity in the UI, API, and database are completely consistent. The behavior consistency is used to verify whether the API call chain triggered by UI operations is consistent with the business process in the graph. The state consistency is used to verify whether the entity state transition conforms to the state machine rules in the graph.

11. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 10, characterized in that, The four-layer architecture of the prompt word chain, consisting of the base layer, data layer, inference layer, and output layer, includes: Baseline layer hints: Includes core information of the business logic chain graph and consistency verification standards. The core information of the business logic chain graph includes business entity definitions, business rules, and cross-modal mapping relationships. Data layer hints include key data for validation context and data priority annotation data. Data priority annotation data is used to annotate database data, API data, and UI data with decreasing priority in that order. Reasoning layer hints: including sequential reasoning steps, first step, data consistency check, second step, behavior consistency check, third step, state consistency check, and fourth step, conflict analysis. Output layer hint: Includes a standardized format for the arbitration result.

12. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 1, characterized in that, Following step 4, the method further includes step 5: when the test results indicate an anomaly, perform fault analysis on the anomaly points based on the business logic chain graph, and generate a fault diagnosis report.

13. The UI testing and API testing collaborative testing method based on a business logic chain graph as described in claim 12, characterized in that, Step 5 involves fault analysis of the anomalies, including fault propagation analysis and reasoning, including: Based on the business logic chain graph, nodes and edges directly associated with consistency verification anomalies are selected to form a fault association subgraph. Based on the preset weighting method, the edges between nodes in the fault association subgraph are weighted to construct a fault propagation weight matrix; Based on the fault propagation weight matrix, the probability of each propagation path is calculated using a depth-first search and pruning strategy. Based on the propagation probability, a preset number of propagation paths are obtained as the results of fault propagation analysis and inference.

14. A collaborative testing device for UI testing and API testing based on a business logic chain graph, characterized in that, include: The business logic chain graph construction unit is used to perform semantic parsing on the business requirement documents, interface specifications, and user interface metadata of the target system based on the first large-scale language model, and to construct a business logic chain graph. The graph includes at least the mapping relationship between UI elements and API interfaces and business elements, and the mapping relationship is used to represent the correspondence between front-end UI elements and back-end API interfaces and business concepts or operations in the graph. The collaborative testing unit is used to automatically generate test workflows based on the business logic chain graph and concurrently drive the UI executor and API executor to perform collaborative testing. The verification context generation unit is used to synchronously capture multimodal data from the UI side, API side, and data storage side during the test, and generate verification context based on the multimodal data; The arbitration unit is used to perform multi-dimensional consistency verification based on the verification context and the business logic chain graph input to the second large language model LLM, and output a standardized arbitration result. The steps for constructing the business logic chain graph in the business logic chain graph construction unit include: Step 11, acquiring multi-source heterogeneous data, including unstructured, semi-structured, and structured data; Step 12, performing structuring, cleaning, and standardization processing on the multi-source heterogeneous data to obtain standardized multi-source data, performing cross-source data association preprocessing, feature vector generation, and multi-dimensional vector fusion on the standardized multi-source data, and storing the fused multi-dimensional vectors in a vector database. The cross-source data association preprocessing includes: obtaining the association relationships between business rules, APIs, UIs, and databases based on similarity analysis technology; Step 13, based on the vector database and a preset first sequential prompt word chain, guiding the first large language model to extract business elements. The first sequential prompt word chain includes a four-layer architecture: a basic layer, a business layer, an inference layer, and an output layer. The extraction of business elements includes: extracting the cross-modal mapping relationships from UIs, APIs, and databases to business operations; Step 14, constructing a directed attribute graph based on the extracted elements to form a business logic chain graph, and storing it serially.

15. A computer device, characterized in that, The computer device includes: Memory, used to store executable instructions; When a processor is used to run executable instructions stored in the memory, it implements the UI testing and API testing collaborative testing method based on a business logic chain graph as described in any one of claims 1 to 13.

16. A computer-readable storage medium storing executable instructions, characterized in that, When the executable instructions are executed by the processor, they implement the UI testing and API testing collaborative testing method based on the business logic chain graph as described in any one of claims 1 to 13.

Images