Interface component defect automated testing method and system for micro-frontend architecture

Abstract

The application provides a micro-front-end architecture-oriented interface component defect automatic testing method and system, relates to the technical field of software testing, and comprises the following steps: obtaining an interface component to be tested and instantiating, injecting a state-aware probe to collect an evolution sequence, and constructing a state transition topology; listening to a cross-application communication layer to extract a data flow dependency relationship, inserting a topology structure to form a state evolution graph, generating a test excitation sequence based on the graph, and driving execution; and real-time monitoring of a state evolution track and rendering presentation, consistency verification positioning of a defect node, extraction of a trigger context, and generation of a defect diagnosis report. Efficient positioning and accurate diagnosis of in-component endogenous behavior and cross-application collaborative scene defects are realized.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to an automated testing method and system for interface component defects in a micro-frontend architecture. Background Technology

[0002] Micro-frontend architecture significantly improves the maintainability and team autonomy of large systems by combining multiple independently deployed frontend applications into a unified experience. As the basic unit of a micro-frontend, the correctness of UI components directly affects the stability of the overall system. Automated testing of UI components typically employs DOM-based assertion-based unit testing or end-to-end testing tools. Test cases are manually written and fixed, verifying expected rendering results by simulating user operations or directly calling component interfaces. During test execution, the testing framework relies on callback functions or data-bound properties exposed by the components to determine state changes, and compares UI snapshots after the test to confirm the absence of anomalies. For collaborative scenarios involving cross-application communication, an integration test environment containing multiple micro-applications is built. Predefined stub modules or recorded playback data are used to simulate message interactions from external applications, and several critical path test cases are designed based on the business process diagram for regression verification.

[0003] The aforementioned testing methods largely rely on test engineers' understanding of the component's internal state machine details. Test case coverage is limited by human experience, making it difficult to systematically exhaustively enumerate state transition paths. When a component undergoes version iterations or runtime environment differences leading to adjustments in internal state flow logic, statically written assertions are prone to failure, increasing maintenance costs. A more significant drawback is the lack of explicit modeling of component state evolution trajectories in conventional testing methods. This makes it impossible to perceive the causal relationships and triggering conditions between state transitions, leaving defects lurking in illegal state sequences often untraceable. Furthermore, stub modules and recorded data in cross-application collaborative testing fail to accurately reflect dynamically changing online message patterns. The lack of data flow dependencies creates a structural discrepancy between the test scenario and actual runtime behavior, making it difficult to accurately locate and reproduce defect triggering contexts. Ultimately, this results in insufficient test result reliability and prolonged defect diagnosis cycles. Summary of the Invention

[0004] This invention provides an automated testing method and system for interface component defects in micro-frontend architecture, which can solve the problems in the prior art.

[0005] A first aspect of this invention provides an automated testing method for UI component defects in a micro-frontend architecture, comprising:

[0006] Obtain the interface component to be tested, and instantiate the interface component to be tested in an isolated runtime environment to obtain a component runtime instance;

[0007] State-aware probes are injected into component running instances to collect value evolution sequences and trigger sources, state invariants are extracted to construct a set of state nodes, directed transition edges are established and organized into a state transition topology;

[0008] The interface of the cross-application communication layer of the interface component under test is monitored, the cross-domain message interaction mode and data flow dependency are extracted, and the data flow dependency is inserted into the state transition topology as a cross-application transformation edge to form a state evolution graph.

[0009] Generate test stimulus sequences that cover the intrinsic behavior of components and cross-application collaboration scenarios based on state evolution graphs;

[0010] The test stimulus sequence is executed to monitor the state evolution trajectory and rendering of the component running instance in real time. The consistency between the state evolution trajectory and the expected evolution path of the state evolution graph is verified. When the state evolution deviates from the expected path or the rendering violates the state constraint rules, the defect node is located and the defect triggering context is extracted.

[0011] Generate a defect diagnosis report that includes the defective node and the defect triggering context.

[0012] In one optional embodiment, injecting state-aware probes into component runtime instances to collect value evolution sequences and trigger sources, extracting state invariants to construct a set of state nodes, and establishing directed transition edges and organizing them into a state transition topology includes:

[0013] A state-aware probe is injected into the execution path of the component's running instance to collect the value evolution sequence of state variables and the triggering source of state transitions in real time. The triggering source is semantically classified to form a set of triggering event types, and a temporal correlation relationship is established between the value evolution sequence and the set of triggering event types.

[0014] Based on the value evolution sequence, state invariants are extracted, states that satisfy the same state invariant are grouped into state equivalence classes, a set of state nodes is constructed, and the transformation dependencies and transformation constraints between state nodes are identified according to the temporal correlation relationship, and a directed transformation edge including transformation dependency strength and transformation priority is established.

[0015] The set of state nodes and the directed transition edges are organized into a hierarchical topology. Critical paths and deadlock nodes in the state transition are identified in the hierarchical topology to form a state transition topology.

[0016] In an optional embodiment, extracting state invariants based on the value evolution sequence, grouping states that satisfy the same state invariants into state equivalence classes, and constructing a set of state nodes includes:

[0017] Dependency analysis is performed on the state variables in the value evolution sequence to identify the co-occurrence and mutual exclusion relationships between the state variables. For the co-occurrence relationship, the value conditions that the state variables can satisfy at the same time are determined, and for the mutual exclusion relationship, the value combinations that the state variables cannot appear at the same time are determined.

[0018] Verify the value condition and the value combination in different migration paths of the value evolution sequence, and extract the value condition and value combination that are true in all migration paths as state invariants;

[0019] Traverse the state snapshots in the value evolution sequence, determine the set of state invariants that each state snapshot conforms to, and merge the state snapshots that conform to the same set of state invariants into state equivalence classes;

[0020] Assign a state node identifier to each state equivalence class, and use the set of state invariants corresponding to the state equivalence class as the constraint rule for the state node identifier to construct a state node set including the state node identifier and the constraint rule.

[0021] In one optional embodiment, the cross-application communication layer of the interface component under test is monitored to extract cross-domain message interaction patterns and data flow dependencies. The data flow dependencies are then inserted as cross-application transition edges into the state transition topology to form a state evolution graph, including:

[0022] The interface of the cross-application communication layer of the interface component under test is monitored to capture the sending and receiving timing of cross-domain messages, extract the transmission direction of cross-domain messages, the data field composition of message payload, and the interface response actions triggered by the messages, and summarize them into cross-domain message interaction patterns.

[0023] Track the state change links corresponding to the cross-domain message interaction mode, identify the source state node before message sending and the target state node triggered after message reception, determine the mapping relationship between the output data items of the source state node and the input data items of the target state node, and establish the data flow dependency relationship from the source state node to the target state node.

[0024] In the state transition topology, the source state node and the target state node are located, and the data flow dependency is inserted as a cross-application transition edge between the corresponding nodes in the state transition topology. The semantic identifier of the cross-domain message interaction mode and the mapping relationship are attached to the cross-application transition edge to form a state evolution graph.

[0025] In one optional embodiment, tracing the state change chain corresponding to the cross-domain message interaction mode and identifying the source state node before message sending and the target state node triggered after message reception includes:

[0026] Locate the trigger position of the cross-domain message sending operation in the state transition topology, and record the state node associated with the trigger position as the starting point for tracking;

[0027] Traverse the forward path along the directed transition edges of the state transition topology, identify candidate state nodes that undergo state transition after receiving the cross-domain message, extract the state variable value change records of the candidate state nodes, and determine whether the data content in the state variable value change records has a field-level data association with the message payload of the cross-domain message.

[0028] Candidate state nodes with field-level data associations are identified as target state nodes, the tracing starting point is identified as the source state node, a transformation path sequence from the source state node to the target state node is constructed, and the propagation trajectory of the cross-domain message interaction mode is marked in the transformation path sequence to form a state change link.

[0029] In one optional embodiment, generating a test stimulus sequence based on the state evolution graph that covers the intrinsic behavior of components and cross-application collaboration scenarios includes:

[0030] Extract state transition edges corresponding to component intrinsic behaviors and cross-application transition edges corresponding to cross-application collaboration scenarios from the state evolution graph. Analyze the transition conditions and trigger event types of the state transition edges. At the same time, analyze the semantic identifiers and data flow dependencies of the cross-application transition edges. Construct a hybrid path set including component intra-state transition paths and cross-application message passing paths.

[0031] Traverse each path in the mixed path set, extract the trigger events and data constraints carried by each transformation edge in the path, convert the trigger events into interface operation instructions, convert the data constraints into input parameter configurations for the interface operation instructions, and additionally generate cross-domain message sending instructions and message receiving verification instructions for the cross-application transformation edges.

[0032] The interface operation instructions, the input parameter configuration, the cross-domain message sending instructions, and the message receiving verification instructions are organized sequentially according to the topological order of the transformation edges in the path to form a test stimulus subsequence for that path;

[0033] All test stimulus subsequences corresponding to the hybrid path set are sorted and summarized according to path coverage priority to generate a test stimulus sequence.

[0034] In one optional embodiment, the test stimulus sequence is executed to monitor the state evolution trajectory and rendering of the component's running instance in real time. The consistency between the state evolution trajectory and the expected evolution path of the state evolution graph is verified. When a deviation from the expected path in state evolution or a violation of state constraint rules in rendering is detected, defect nodes are located, and the defect triggering context is extracted, including:

[0035] Operation events are injected into the component running instance in the order of interface operation instructions and cross-domain message sending instructions in the test stimulus sequence. After each injection, the state variable value of the component running instance is read, the state variable value is mapped to the state node in the state evolution graph, and the state node migration sequence is recorded to form the state evolution trajectory.

[0036] The expected evolution path corresponding to the test stimulus sequence is retrieved from the state evolution graph. The state node migration sequence in the state evolution trajectory is compared with the state node sequence in the expected evolution path node by node. State nodes in the state evolution trajectory that are not defined in the expected evolution path are identified as deviation positions.

[0037] Extract the state node corresponding to the deviation position as the defect node, and compare the interface rendering data with the state constraint rules of the state node in the state evolution graph. When the rendering attribute value exceeds the set of values ​​determined by the state constraint rules, mark the state node as a defect node.

[0038] Extract the interface operation instructions and cross-domain message content corresponding to the defect node at that moment, and combine them with the values ​​of state variables to form a defect triggering context.

[0039] A second aspect of this invention provides an automated testing system for UI component defects in a micro-frontend architecture, comprising:

[0040] An instantiation unit is used to obtain the interface component to be tested, and to instantiate the interface component to be tested in an isolated running environment to obtain a component running instance;

[0041] The state acquisition unit is used to inject state-aware probes into the component running instance to collect the value evolution sequence and trigger source, extract state invariants to construct a set of state nodes, establish directed transition edges and organize them into a state transition topology.

[0042] The cross-domain listening unit is used to listen to the cross-application communication layer of the interface component under test, extract the cross-domain message interaction mode and data flow dependency, insert the data flow dependency as a cross-application transformation edge into the state transformation topology, and form a state evolution graph.

[0043] The graph construction unit is used to generate test stimulus sequences that cover the intrinsic behavior of components and cross-application collaboration scenarios based on the state evolution graph;

[0044] The stimulus generation unit is used to drive the execution of the test stimulus sequence, monitor the state evolution trajectory and rendering of the component running instance in real time, verify the consistency between the state evolution trajectory and the expected evolution path of the state evolution graph, and locate the defect node and extract the defect trigger context when the state evolution deviates from the expected path or the rendering violates the state constraint rules.

[0045] The diagnostic report unit is used to generate a defect diagnostic report that includes the defect node and the defect triggering context.

[0046] A third aspect of the present invention provides an electronic device, comprising:

[0047] processor;

[0048] Memory used to store processor-executable instructions;

[0049] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0050] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0051] In this embodiment of the invention, components are instantiated in an isolated runtime environment to eliminate external interference and ensure a stable and controllable environment for state acquisition and test execution. State-aware probes collect value evolution sequences and trigger sources, extract state invariants, construct a set of state nodes and directed transition edges, forming a state transition topology that fully describes the intrinsic behavior of components and provides a unified benchmark for test stimulus generation and state determination. Interface monitoring is performed on the cross-application communication layer to extract cross-domain message interaction patterns and data flow dependencies. Data flow dependencies are inserted into the state transition topology as cross-application transition edges to form a state evolution graph. This graph reflects the real cross-component state transitions under the micro-frontend architecture, expands the testing scope, compensates for the shortcomings of traditional testing that only focuses on single components and ignores integration interactions, and improves the detection capability of cross-domain communication anomalies and integration defects. Test stimulus sequences are automatically generated based on the state evolution graph, avoiding manual design of test cases and reducing test preparation costs. When executing the stimulus sequence, the state evolution trajectory and rendering are monitored in real time, and the actual trajectory is compared with the expected path of the graph. When the state deviates from the expectation or the rendering violates the state constraints, the defect node is immediately located, and the defect triggering context containing the trigger source, value evolution and interaction messages is extracted to improve the efficiency of defect location and diagnosis. Attached Figure Description

[0052] Figure 1 A flowchart illustrating an automated testing method for UI component defects in a micro-frontend architecture.

[0053] Figure 2 Generate a flowchart for the state evolution diagram;

[0054] Figure 3 This is a diagram illustrating the nodes and semantics of the state evolution graph.

[0055] Figure 4 The test stimulus sequence execution results and coverage analysis table are used. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0057] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0058] Figure 1 This is a flowchart illustrating an automated testing method for UI component defects in a micro-frontend architecture according to an embodiment of the present invention. Figure 1 As shown, the method includes:

[0059] Obtain the interface component to be tested, and instantiate the interface component to be tested in an isolated runtime environment to obtain a component runtime instance;

[0060] State-aware probes are injected into component running instances to collect value evolution sequences and trigger sources, state invariants are extracted to construct a set of state nodes, directed transition edges are established and organized into a state transition topology;

[0061] The interface of the cross-application communication layer of the interface component under test is monitored, the cross-domain message interaction mode and data flow dependency are extracted, and the data flow dependency is inserted into the state transition topology as a cross-application transformation edge to form a state evolution graph.

[0062] Generate test stimulus sequences that cover the intrinsic behavior of components and cross-application collaboration scenarios based on state evolution graphs;

[0063] The test stimulus sequence is executed to monitor the state evolution trajectory and rendering of the component running instance in real time. The consistency between the state evolution trajectory and the expected evolution path of the state evolution graph is verified. When the state evolution deviates from the expected path or the rendering violates the state constraint rules, the defect node is located and the defect triggering context is extracted.

[0064] Generate a defect diagnosis report that includes the defective node and the defect triggering context.

[0065] In one optional embodiment, injecting state-aware probes into component runtime instances to collect value evolution sequences and trigger sources, extracting state invariants to construct a set of state nodes, and establishing directed transition edges and organizing them into a state transition topology includes:

[0066] A state-aware probe is injected into the execution path of the component's running instance to collect the value evolution sequence of state variables and the triggering source of state transitions in real time. The triggering source is semantically classified to form a set of triggering event types, and a temporal correlation relationship is established between the value evolution sequence and the set of triggering event types.

[0067] Based on the value evolution sequence, state invariants are extracted, states that satisfy the same state invariant are grouped into state equivalence classes, a set of state nodes is constructed, and the transformation dependencies and transformation constraints between state nodes are identified according to the temporal correlation relationship, and a directed transformation edge including transformation dependency strength and transformation priority is established.

[0068] The set of state nodes and the directed transition edges are organized into a hierarchical topology. Critical paths and deadlock nodes in the state transition are identified in the hierarchical topology to form a state transition topology.

[0069] In one specific implementation, after the instantiation of the UI component under test is completed in the isolated runtime environment, a state-aware probe is injected into the execution path of the component's runtime instance. A state-aware probe is a lightweight listening device that is non-intrusively mounted on the component's lifecycle hooks, property accessors, and method call chains. Its core function is to continuously capture the dynamic changes of the component's internal state variables during runtime without altering the component's original logic. The probe's injection points cover the component initialization phase, property update phase, event response phase, and destruction phase, ensuring that state changes are fully recorded in any execution path. For UI components using a reactive data binding mechanism, the probe intercepts read and write operations on reactive properties through a proxy object; for components using an immutable state management pattern, the probe obtains a state snapshot by subscribing to change notifications from the state repository.

[0070] The state-aware probe outputs two types of raw data during the acquisition process: one is the value evolution sequence of state variables, recording the continuous values ​​of each state variable on the timeline and their corresponding timestamps; the other is the trigger source, i.e., the event or call source that causes the state transition. When semantically classifying the trigger sources, they are categorized according to their nature into user interaction events (such as clicks, inputs, scrolling, etc.), lifecycle events (such as hook callbacks for mounting completion, update completion, etc.), asynchronous response events (such as network request returns, timer triggers), and cross-application message events (such as push notifications from other micro-frontend sub-applications). The above classification results form a set of trigger event types and establish a temporal correlation with the value evolution sequence—that is, for each state transition in the value evolution sequence, its corresponding trigger event type, trigger time, and trigger parameters are recorded, enabling subsequent analysis to trace the direct cause of any state transition.

[0071] State invariants are extracted based on the collected value evolution sequence. State invariants refer to the set of attribute constraints that all state instances must satisfy within a specific state equivalence class. For example, a form component in the "Submitting" state must satisfy the constraint that "the submit button is disabled and the loading indicator is visible." The specific method for extracting state invariants is as follows: cluster analysis is performed on recurring state snapshots in the value evolution sequence to identify attribute combinations that remain stable within the same semantic stage. These stable attribute combinations are then used as candidate invariants. Further verification is performed on the coverage and consistency of the candidate invariants across the entire evolution sequence, eliminating pseudo-invariants that only hold true in local segments and retaining true invariants that are universally true within the corresponding semantic stage. All state snapshots satisfying the same state invariant are grouped into a single state equivalence class, with each state equivalence class corresponding to a node in the state node set. The identification information of a state node includes: an invariant description, a typical state snapshot sample, and the timestamp of the node's first appearance in the evolution sequence.

[0072] After the state node set is constructed, the transition dependencies and constraints between state nodes are identified based on temporal relationships, and then directed transition edges are established. A transition dependency means that the state transition from the source state node to the target state node must depend on the occurrence of a specific triggering event type; a transition constraint means that the state variables or input parameters must meet the preconditions when triggering the transition, such as "the transition from the 'Pending Submission' state to the 'Submitting' state is only allowed when the user has completed authentication and the form data has passed format validation." Each directed transition edge carries two key attributes: transition dependency strength and transition priority. The transition dependency strength reflects the frequency and inevitability of the transition path in the historical evolution sequence. Let the number of transitions corresponding to a certain directed transition edge in the entire evolution sequence be... Source state node The total number of arbitrary migrations is Then the transformation dependency strength of that edge. Defined as The range of values ​​is A higher value indicates a more deterministic migration path. Transition priority, on the other hand, considers both the strength of the transition dependency and the semantic weight of the triggering event type, guiding the path traversal order during the subsequent test stimulus sequence generation phase.

[0073] When organizing the set of state nodes and directed transition edges into a hierarchical topology, all state nodes are divided into multiple levels according to the abstraction level of state semantics: bottom-level nodes correspond to the fine-grained attribute states within the component, middle-level nodes correspond to the aggregated states at the functional module level of the component, and top-level nodes correspond to the macroscopic state presented externally by the component as a whole. The advantage of hierarchical organization is that it can analyze the structural characteristics of the component state machine at different granularities, supporting both in-depth tracking of local details and a holistic understanding of global behavioral patterns. In the hierarchical topology, the critical paths of state transitions are identified through depth-first traversal and critical path algorithms—that is, the paths from the initial state node to the terminating state node with the largest product of transition dependency strength or the path covering the most state nodes. The results of critical path identification will be prioritized for coverage in the subsequent test stimulus sequence generation stage to ensure that test resources are concentrated on the most representative execution paths.

[0074] The identification of deadlock nodes is also completed during the hierarchical topology construction phase. A deadlock node is a state node that meets the following conditions: the node has an incoming directed transition edge but no outgoing directed transition edges, and the node is not the expected terminating state node. The existence of such nodes means that the component may get stuck in a state that it cannot exit on its own during runtime, which is a potential functional defect. When identifying deadlock nodes, all state nodes are traversed, and their outgoing edge sets are checked to see if they are empty. This is compared with a predefined list of valid terminating state nodes. Nodes that are not in the list of valid terminating states and have empty outgoing edge sets are marked as deadlock nodes and distinguished by a special marker in the hierarchical topology structure for quick location in the subsequent defect localization phase.

[0075] After the above processing, the final state transition topology fully describes the state machine behavior characteristics of the interface component under test in the isolated operating environment. It covers the semantic definition of state nodes, the dependency strength and constraints of the transition relationship between nodes, the hierarchical organizational structure, key execution paths and potential deadlock locations, providing a solid structural foundation for the subsequent interface listening and state evolution map construction of cross-application communication layers.

[0076] In an optional embodiment, extracting state invariants based on the value evolution sequence, grouping states that satisfy the same state invariants into state equivalence classes, and constructing a set of state nodes includes:

[0077] Dependency analysis is performed on the state variables in the value evolution sequence to identify the co-occurrence and mutual exclusion relationships between the state variables. For the co-occurrence relationship, the value conditions that the state variables can satisfy at the same time are determined, and for the mutual exclusion relationship, the value combinations that the state variables cannot appear at the same time are determined.

[0078] Verify the value condition and the value combination in different migration paths of the value evolution sequence, and extract the value condition and value combination that are true in all migration paths as state invariants;

[0079] Traverse the state snapshots in the value evolution sequence, determine the set of state invariants that each state snapshot conforms to, and merge the state snapshots that conform to the same set of state invariants into state equivalence classes;

[0080] Assign a state node identifier to each state equivalence class, and use the set of state invariants corresponding to the state equivalence class as the constraint rule for the state node identifier to construct a state node set including the state node identifier and the constraint rule.

[0081] In one specific implementation, when performing dependency resolution on all state variables involved in the value evolution sequence, it is necessary to identify two core relationships: co-occurrence relationships and mutual exclusion relationships. Co-occurrence relationships describe the phenomenon that certain state variables tend to be in a specific value range simultaneously in the evolution sequence; for example, a component's loading flag variable and data-ready flag variable are often true simultaneously in the normal rendering path. Mutual exclusion relationships describe that certain combinations of state variables will not appear simultaneously in any observation snapshot; for example, a component's error state flag and successful rendering flag will not be activated simultaneously. For co-occurrence relationships, the conditions that state variables simultaneously satisfy are extracted, i.e., the constraint expressions that multiple variables jointly hold in the same snapshot are determined. For mutual exclusion relationships, combinations of state variables that cannot appear simultaneously are determined, i.e., variable assignment pairs that are prohibited in any legal snapshot are marked. Dependency resolution is implemented by scanning the value evolution sequence frame by frame, counting the joint occurrence frequency of each variable's value, and semantically filtering the frequency results in conjunction with the component's declarative state definition to exclude occasional co-occurrences introduced by test noise.

[0082] After dependency resolution is complete, the extracted value conditions and value combinations need to be verified path-by-path across different migration paths in the value evolution sequence. A migration path refers to the complete trajectory of state variable changes from component initialization to a certain termination state. Different user interaction sequences or cross-application message triggering orders will produce different migration paths. For each time point in each migration path, it is verified whether the candidate value condition remains true throughout the path, and whether the candidate mutually exclusive value combinations never appear simultaneously in the path. Only value conditions and value combinations that pass verification in all observable migration paths are confirmed as state invariants. This cross-path verification mechanism ensures the universality of state invariants, avoids misjudging local constraints that only happen to be true in a specific execution path as global invariants, and thus reduces the error rate of subsequent state node partitioning.

[0083] After confirming the state invariants, all state snapshots in the value evolution sequence are traversed, and invariant compliance is determined for each snapshot. Specifically, for each snapshot, the state variable values ​​are checked one by one to see if they satisfy the constraints of each extracted state invariant, and all state invariants satisfied by that snapshot are summarized into a set of invariants. If two state snapshots satisfy the exact same set of invariants, they are considered equivalent in state semantics and are merged into the same state equivalence class. This merging strategy based on invariant sets compresses the originally high-dimensional, continuously changing state space into a finite number of discrete equivalence classes, making subsequent state node modeling computable. During the merging process, if the invariant set of a snapshot is empty, it is assigned to a separate equivalence class, indicating that the snapshot is in a boundary state not covered by known invariants. Such boundary states often have high analytical value in subsequent defect localization.

[0084] A unique state node identifier is assigned to each state equivalence class, serving as a globally unique reference key for the node in the state evolution graph. Simultaneously, the set of state invariants corresponding to that equivalence class is recorded as the constraint rules for that state node identifier. These constraint rules serve a dual purpose during subsequent test execution: firstly, they act as the basis for state identification, assigning snapshots to corresponding state nodes by matching constraint rules when a component generates new state snapshots during runtime; secondly, they serve as a standard for state validity verification, checking whether the current snapshot satisfies all constraint rules of that node when the component's actual state evolution trajectory reaches that node. If not, it is determined to be a state constraint violation defect.

[0085] The completed set of state nodes includes an identifier for each state node and its corresponding set of constraint rules. Taking a typical micro-frontend sub-application component as an example, this component may contain multiple state equivalence classes, such as data loading, data loading completed and rendering ready, data loading failed and error message activated, and waiting for cross-application messages. The constraint rules of each equivalence class precisely describe the legal value range of each key state variable in that state and the joint constraints between variables. For example, the data loading completed and rendering ready state requires three conditions to be met simultaneously: the loading flag is false, the data object is not empty, and the rendering completed flag is true. This expression of multi-variable joint constraints, compared to single-variable threshold judgment, can more accurately capture the true state semantics of micro-frontend components in complex interaction scenarios.

[0086] In practical engineering implementations, the amount of data in the value evolution sequence can increase significantly with the increase of component complexity and the number of test cases, resulting in high computational overhead for frame-by-frame scanning. To address this, an incremental statistical strategy can be introduced during the dependency resolution phase to maintain a joint frequency table of variable values ​​in real time during probe acquisition, avoiding a full rescan after the complete sequence collection. For the invariant verification phase, migration paths can be grouped according to trigger source type, with initial screening prioritized in the path group with the highest coverage, followed by full-path verification of the remaining candidate invariants, thereby reducing the computational complexity of verification while ensuring accuracy. The merging operation of state snapshots can be implemented using a hash mapping structure, using the normalized string representation of the invariant set as the key, directly merging snapshots with the same key, ensuring that the time complexity of the merging process remains linearly related to the number of snapshots.

[0087] like Figure 2 As shown, a flowchart illustrating the generation process of the state evolution graph is presented.

[0088] In one optional embodiment, the cross-application communication layer of the interface component under test is monitored to extract cross-domain message interaction patterns and data flow dependencies. The data flow dependencies are then inserted as cross-application transition edges into the state transition topology to form a state evolution graph, including:

[0089] The interface of the cross-application communication layer of the interface component under test is monitored to capture the sending and receiving timing of cross-domain messages, extract the transmission direction of cross-domain messages, the data field composition of message payload, and the interface response actions triggered by the messages, and summarize them into cross-domain message interaction patterns.

[0090] Track the state change links corresponding to the cross-domain message interaction mode, identify the source state node before message sending and the target state node triggered after message reception, determine the mapping relationship between the output data items of the source state node and the input data items of the target state node, and establish the data flow dependency relationship from the source state node to the target state node.

[0091] In the state transition topology, the source state node and the target state node are located, and the data flow dependency is inserted as a cross-application transition edge between the corresponding nodes in the state transition topology. The semantic identifier of the cross-domain message interaction mode and the mapping relationship are attached to the cross-application transition edge to form a state evolution graph.

[0092] In one specific implementation, when listening to the cross-application communication layer of the UI component under test, listening hooks need to be attached to the message channel entry and exit points of the component's runtime instance. The cross-application communication layer typically includes inter-window communication based on the postMessage mechanism, a custom event bus based on CustomEvent, and a publish-subscribe channel based on a shared state container. For each type of communication mechanism, the listening hook proxies the native interface in a non-intrusive manner. Without changing the component's original communication behavior, it adds high-precision timestamps to the sending and receiving times of each cross-domain message, forming complete sending and receiving time sequences. The sending time sequence record stores the time the message originates from the current component, the target application identifier, and the original content of the message payload; the receiving time sequence record stores the time the message arrives at the current component, the source application identifier, and the original content of the message payload. The two types of time sequences are associated according to the message's unique identifier to obtain a complete lifecycle description of each cross-domain message.

[0093] After obtaining the sending and receiving sequence of cross-domain messages, the message payload is structured and parsed to extract its data field composition. Data field composition analysis includes field name, data type, whether a field is required, and its value range. Simultaneously, listener hooks record the UI response actions triggered by the message, i.e., DOM changes, style updates, or child component mounting and unmounting operations performed by the component after receiving the message. The three types of information—transmission direction (from which application to which application), data field composition, and UI response actions—are aggregated and summarized. Structural similarity patterns that recur in multiple communication records are identified, and messages with the same transmission direction and highly consistent data field composition are grouped into the same interaction pattern category, ultimately forming a set of cross-domain message interaction patterns. Each interaction pattern is characterized by a pattern identifier, transmission direction description, field structure template, and a corresponding list of UI response actions.

[0094] When tracing the state change chain corresponding to cross-domain message interaction patterns, the state snapshot of the component's running instance before message sending is extracted, using the message sending time as the dividing point. This snapshot is then matched with the constructed set of state nodes to locate the source state node. Similarly, the state snapshot after message reception and UI response actions are completed is matched with the set of state nodes to locate the target state node. The state snapshot matching process employs a state invariant comparison strategy, which compares only the key attribute fields extracted when constructing the state node set, without requiring all attributes to be completely identical, thus tolerating fluctuations in non-key attributes introduced by differences in rendering timing.

[0095] After identifying the source and target state nodes, it is necessary to further establish the data flow dependency between them. Specifically, the output data items of the source state node (i.e., the fields written into the message payload at message sending time) are compared field-by-field with the input data items of the target state node (i.e., the fields read by the interface response after message reception). Field pairs with the same name or semantically equivalent after naming rule conversion are identified, and a field-level mapping relationship is established. The mapping relationship is stored as an ordered list of field pairs. Each field pair records the source field path, the target field path, and a description of optional data conversion rules (e.g., unit conversion, format conversion, etc.). When the same source state node corresponds to multiple target state nodes, an independent data flow dependency relationship is established for each target state node to avoid confusion in the mapping relationships between different target nodes.

[0096] After locating the source and target state nodes in the state transition topology, data flow dependencies are inserted as cross-application transition edges between the corresponding nodes. These cross-application transition edges maintain data structure compatibility with the component's native directed transition edges, but carry two additional attributes: first, a semantic identifier for the cross-domain message interaction mode, indicating the message mode category corresponding to the transition edge, facilitating path coverage according to the mode category during subsequent test stimulus sequence generation; second, a field-level mapping relationship, recording a complete mapping list from the source state node's output data items to the target state node's input data items. The semantic identifier is encoded using a triple format of "source application identifier - target application identifier - mode number," ensuring that the semantic identifier of each cross-application transition edge is globally unique in multi-application collaboration scenarios.

[0097] After inserting all cross-application transition edges into the state transition topology, the original state transition topology, which only described the intrinsic behavior of components, is expanded to form a state evolution graph that simultaneously covers both the intrinsic state transition paths of components and the cross-application collaborative communication paths. Nodes in the state evolution graph are divided into two categories: internal state nodes that only participate in the intrinsic transitions of components, and boundary state nodes that also participate in the cross-application transition edges. Boundary state nodes have a dual role in the graph, serving as both intermediate nodes in the intrinsic behavior chain of components and triggering or receiving points for cross-application communication. This explicit labeling of dual roles allows subsequent test path generation to distinguish between purely intrinsic test scenarios and cross-application collaborative test scenarios, thereby enabling the targeted construction of test stimulus sequences covering different scenarios.

[0098] After the state evolution graph is constructed, connectivity verification is performed to check for isolated nodes or state nodes that cannot be reached from the initial state node. If isolated nodes exist, the process backtracks to the interface listening phase to check for coverage blind spots in the corresponding communication channel's listening hooks. After supplementing the listening, the cross-domain message interaction pattern extraction process is re-executed. For graphs that pass connectivity verification, the proportion of cross-application transition edges in the full state evolution graph is calculated. If this proportion is lower than a preset threshold, a supplementary sampling process is triggered to simulate more cross-application message interaction scenarios in an isolated operating environment, supplementing the collection of cross-domain message records to ensure the state evolution graph adequately covers cross-application collaborative behaviors. The final state evolution graph serves as the input for subsequent test stimulus sequence generation, providing a complete path basis for testing that covers cross-application collaborative scenarios.

[0099] like Figure 3As shown, 13 core state nodes that the interface component under test may present in the micro-frontend runtime environment are defined, forming the basic semantic units and unified benchmark of the state evolution graph. Divided by component lifecycle stages, these nodes can be categorized into five types: initial state (initialization S01), loading state (data loading S02, loading failed S05, retrying S06), ready state (data loading completed S03, rendering ready S04), interactive state (form input S09, submission in progress S10, submission successful S11, submission failed S12), and cross-application collaboration state (cross-application message waiting S07, collaborative data merging S08). Of particular note is the "deadlock state" (S13), which has only incoming edges and no outgoing edges in the topology and is not an expected termination state. It has been automatically marked as a defect node by the system (corresponding to D01 in the report), directly reflecting the design flaw of the component in an abnormal locking scenario. From the perspective of state constraint rules, each node is associated with a set of invariants extracted by state-aware probes. These multivariate joint constraints accurately characterize the true semantics of complex interaction scenarios, avoiding the risk of misjudgment from single threshold judgments. In the evolutionary graph, S04 (rendering ready) acts as a core hub, connecting internal interaction paths (such as jumping to S09 form input) and triggering cross-application communication (such as jumping to S07 message waiting), fully demonstrating the dual characteristics of "intrinsic behavior + external collaboration" of micro-frontend components. This set of nodes, together with the directed transformation edges, supports the hierarchical topology, providing a calculable and traceable benchmark for the automatic generation of subsequent test stimuli, consistency verification of state evolution trajectories, and accurate location of defective nodes.

[0100] In one optional embodiment, tracing the state change chain corresponding to the cross-domain message interaction mode and identifying the source state node before message sending and the target state node triggered after message reception includes:

[0101] Locate the trigger position of the cross-domain message sending operation in the state transition topology, and record the state node associated with the trigger position as the starting point for tracking;

[0102] Traverse the forward path along the directed transition edges of the state transition topology, identify candidate state nodes that undergo state transition after receiving the cross-domain message, extract the state variable value change records of the candidate state nodes, and determine whether the data content in the state variable value change records has a field-level data association with the message payload of the cross-domain message.

[0103] Candidate state nodes with field-level data associations are identified as target state nodes, the tracing starting point is identified as the source state node, a transformation path sequence from the source state node to the target state node is constructed, and the propagation trajectory of the cross-domain message interaction mode is marked in the transformation path sequence to form a state change link.

[0104] In one specific implementation, within a micro-frontend architecture, multiple sub-applications communicate via a cross-domain messaging mechanism. This communication triggers a series of state transitions within each sub-application. To accurately track the state change chain corresponding to the cross-domain messaging interaction pattern, it is necessary to map the message sending and receiving times to specific nodes in the state transition topology, thereby establishing a causal relationship across application dimensions.

[0105] Locating the trigger position of a cross-domain message sending operation within the state transition topology relies on the value evolution sequence and trigger source information collected by the state-aware probe injected in the preceding stage. Each cross-domain message sending operation corresponds to a specific trigger event, which carries a timestamp, component identifier, and a snapshot of the state at that time in the state-aware probe's collection record. By aligning and matching the timestamp of the message sending event with the time intervals of each state node in the state evolution sequence, the specific state node where the component was when the message sending operation occurred can be determined, and this node is recorded as the tracing starting point. Determining the tracing starting point is the foundation for subsequent path traversal, and its accuracy directly affects the reliability of the entire state change chain.

[0106] After determining the starting point of the tracking, a forward path traversal is performed along the directed transition edges of the state transition topology. The forward path traversal starts from the starting point and visits subsequent state nodes sequentially according to the migration direction indicated by the directed transition edges, covering all state nodes reachable from the starting point. During the traversal, nodes that undergo state transitions within the cross-domain message arrival time window are selected as candidate state nodes. The time window is set based on a reasonable estimate of the message propagation delay, typically starting at the message sending time and ending with the maximum expected delay for the message to be processed at the receiving end. State nodes that undergo transitions within this time window are included in the candidate set.

[0107] For candidate state nodes, their state variable value change records are extracted. These records contain the specific values ​​of each state variable before and after the migration, as well as the operation type and parameter information that triggered the migration. The core logic for filtering target state nodes is to determine whether the data content in the candidate state node's state variable value change records has a field-level data association with the message payload of the cross-domain message. The method for determining field-level data association is as follows: Each field name and value in the cross-domain message payload is compared field-by-field with the state variable set of the candidate state node after migration. If there are cases where field names are the same and values ​​are identical, or where values ​​have a derivation relationship, then the two are considered to have a field-level data association. The identification of derivation relationships is achieved by calculating hash fingerprints of the state variable values ​​and matching them with the hash fingerprints of the message payload fields, thus covering cases where the message payload is written to state variables after format conversion or data mapping.

[0108] Let the set of fields in the message payload be... The set of fields in the state variable set after the candidate state node migration is The criteria for determining field-level data association are: And for Each field in Its value in message load With respect to the values ​​in the set of state variables satisfy or Depend on This is derived from a known mapping function. Candidate state nodes that satisfy the above conditions are determined as target state nodes, and the remaining candidate state nodes are removed from the candidate set.

[0109] The starting point for tracing is determined as the source state node, and nodes that pass the field-level association judgment are determined as the target state node. A sequence of transition paths from the source state node to the target state node is constructed within the state transition topology. The construction of this transition path sequence employs a directed graph shortest path algorithm, using the transition dependency strength of directed transition edges as a path weight reference. Paths passing through edges with high dependency strength are prioritized, thus ensuring that the constructed transition path sequence better reflects the actual state evolution backbone. When multiple reachable paths exist, all paths are retained and sorted by dependency strength to cover various potential cross-application collaborative scenarios in the subsequent test stimulus generation phase.

[0110] After the transformation path sequence is constructed, the propagation trajectory of the cross-domain message interaction mode is annotated. The propagation trajectory annotation includes the following information: the message sending and receiving times, the field summary of the message payload, the message forwarding record at each intermediate node (if a message relay mechanism exists), and the specific field mapping relationship of the message-triggered state transition. The above information is attached to the corresponding directed transformation edges in the transformation path sequence in the form of annotations, forming a state change link carrying cross-application semantics. The state change link not only records the topological path from the source state node to the target state node, but also completely preserves the message propagation process that drives the path, enabling subsequent defect localization to trace back to the specific message field and state variable mapping relationship.

[0111] In practical micro-frontend scenarios, sending a single cross-domain message may trigger the migration of multiple target state nodes in multiple sub-applications, forming a one-to-many state change link structure. To address this, an independent transition path sequence is constructed for each target state node, and a shared source state node association index is established between these path sequences. This allows for a complete representation of the state diffusion effect caused by cross-application message broadcasting in the state evolution graph. When the same message payload triggers state variable updates in different fields across different sub-applications, field-level data association determination is performed separately for each sub-application's state variable set, ensuring that the field mapping relationships in each state change link are independent and accurate.

[0112] Once the state change link is formed, it is inserted as a cross-application transition edge into the state transition topology, together with the original component-native directed transition edges, to form a complete topology of the state evolution graph. Cross-application transition edges are stored in the graph with a label type distinct from that of native edges, enabling the differentiation between component-native behavior and cross-application collaborative scenarios during the test stimulus sequence generation phase, allowing for the formulation of separate coverage strategies. The entire tracing process, from trigger location positioning, forward path traversal, field-level association determination to path sequence construction and propagation trajectory annotation, forms a complete closed-loop cross-domain state link analysis process, providing accurate expected evolution path basis for subsequent consistency verification and defect localization.

[0113] In one optional embodiment, generating a test stimulus sequence based on the state evolution graph that covers the intrinsic behavior of components and cross-application collaboration scenarios includes:

[0114] Extract state transition edges corresponding to component intrinsic behaviors and cross-application transition edges corresponding to cross-application collaboration scenarios from the state evolution graph. Analyze the transition conditions and trigger event types of the state transition edges. At the same time, analyze the semantic identifiers and data flow dependencies of the cross-application transition edges. Construct a hybrid path set including component intra-state transition paths and cross-application message passing paths.

[0115] Traverse each path in the mixed path set, extract the trigger events and data constraints carried by each transformation edge in the path, convert the trigger events into interface operation instructions, convert the data constraints into input parameter configurations for the interface operation instructions, and additionally generate cross-domain message sending instructions and message receiving verification instructions for the cross-application transformation edges.

[0116] The interface operation instructions, the input parameter configuration, the cross-domain message sending instructions, and the message receiving verification instructions are organized sequentially according to the topological order of the transformation edges in the path to form a test stimulus subsequence for that path;

[0117] All test stimulus subsequences corresponding to the hybrid path set are sorted and summarized according to path coverage priority to generate a test stimulus sequence.

[0118] In one specific implementation, when extracting state transition edges corresponding to component-intrinsic behaviors and cross-application transition edges corresponding to cross-application collaboration scenarios from the state evolution graph, it is necessary to distinguish and label the edge types in the graph. State transition edges originate from the observation of the evolution of state variable values ​​within the component's running instance. Each state transition edge carries the event type that triggers the transition (such as user click, input change, lifecycle hook trigger, etc.) and the corresponding transition conditions (i.e., the pre-constraints that the state variables must satisfy). Cross-application transition edges originate from interface listening to the cross-application communication layer, carrying the semantic identifier of the message (such as message topic, event name, or communication protocol identifier) ​​and the data flow dependencies involved in the message transmission process (i.e., which local state fields will change with the message content). After parsing the attributes of the above two types of edges, the component-intra-component state transition paths and cross-application message transmission paths are merged to construct a hybrid path set. Each path in the hybrid path set represents a complete directed path that starts from the initial state node, passes through several transition edges, and reaches the terminal state node. The path can contain both state transition edges and cross-application transition edges, thus covering two types of testing requirements: component intrinsic behavior and cross-application collaboration scenarios.

[0119] When traversing each path in the mixed path set, the triggering events and data constraints carried by each transition edge in the path are extracted one by one. For state transition edges, the triggering events usually correspond to specific UI interaction actions, such as button clicks, dropdown selections, and form submissions; the data constraints describe the range or format requirements of the input data needed to trigger the transition, such as the input box content must be a non-empty string, or the value must be within a specific range. When mapping the triggering events to UI operation instructions, the abstract event types need to be converted into specific operation descriptions that the test execution framework can recognize. For example, a "click event" is converted into a click operation instruction for a specific DOM node, and an "input change event" is converted into an assignment operation instruction for an input control. The data constraints are then converted into input parameter configurations for the UI operation instructions, that is, specific parameter values ​​are attached to each operation instruction to ensure that the values ​​meet the constraints specified by the transition conditions.

[0120] For cross-application transition edges, in addition to generating UI operation instructions, two additional types of dedicated instructions need to be generated. The cross-domain message sending instruction simulates an external micro-frontend application sending a message with specific semantics to the component under test. Its message content is constructed based on the data flow dependencies of the cross-application transition edge, ensuring that the message payload contains field values ​​that can trigger the target state transition. The message receiving verification instruction, after the message is received and processed by the component under test, asserts and verifies the update results of the component's state variables, confirming that the actual values ​​of the state variables are consistent with the expected transition target state described by the cross-application transition edge. The cross-domain message sending instruction and the message receiving verification instruction together constitute a closed-loop test logic for cross-application collaboration scenarios, ensuring that the cross-application message interaction path can be fully covered and verified.

[0121] The aforementioned instructions are organized sequentially according to the topological order of the transition edges in the path, forming a test stimulus subsequence for that path. The topological order is determined by the order of the transition edges in the directed path, ensuring that the execution order of each UI operation instruction, input parameter configuration, cross-domain message sending instruction, and message reception verification instruction remains consistent with the dependencies of state transitions. For example, if the first edge in the path is a state transition edge and the second edge is a cross-application transition edge, the test stimulus subsequence will first contain the UI operation instruction and its input parameter configuration corresponding to the first edge, followed by the cross-domain message sending instruction and message reception verification instruction corresponding to the second edge. With this organization, each path corresponds to a structurally complete test stimulus subsequence with a determined execution order, which can be directly driven and executed by the test execution engine.

[0122] All test stimulus subsequences corresponding to the mixed path set are sorted and summarized according to path coverage priority to generate the final test stimulus sequence. The evaluation of path coverage priority takes into account the following factors: the more state nodes a path covers, the higher its priority, because longer paths can cover more state transition behaviors; the more cross-application transition edges a path contains, the higher its priority, because the defect risk in cross-application collaboration scenarios is usually higher than that of pure component internal behavior; when a path passes through transition edges with low transition dependency strength, its priority also increases accordingly, because low-frequency transition paths are easily overlooked in conventional manual testing and are high-value coverage targets. Based on the above multi-dimensional evaluation, all test stimulus subsequences are sorted in descending order, with higher-priority subsequences listed first and executed first, in order to maximize the probability of defect discovery with limited testing resources.

[0123] In the specific implementation, the construction of the hybrid path set adopts a depth-first traversal strategy to enumerate paths in the state evolution graph, while setting an upper limit on the path length. This is to avoid infinite recursion when loops exist in the graph. When the path length exceeds... When a path is truncated, the enumerated portion is added to the mixed path set as a valid path. For state evolution graphs containing loops, each loop is allowed to be traversed at most once in a single path. Next, among them This is the preset loop coverage depth parameter, typically set to 2, to cover the boundary behavior of loop state transitions without introducing excessive redundant testing. The quantified score for path coverage priority is denoted as... Overall path length (Total number of transformation edges in the path), Number of cross-application transformation edges and the mean dependency strength of each transformation edge in the path. Perform the calculation, specifically expressed as ,in , , These are configurable weighting coefficients, with default values ​​of 1.0, 2.0, and 0.5, which can be adjusted according to the actual testing strategy.

[0124] The generated test stimulus sequences are stored in the form of structured description files. Each test stimulus subsequence includes a path identifier, a sequence of state nodes for the path, the operation instruction type for each step, input parameter configuration, cross-domain message content, and expected verification assertions. This structured description file can be parsed by the test execution engine, driving the component execution instances to perform corresponding operations in sequence. At each verification point, the component state and rendering presentation are collected and compared in real time, thereby achieving comprehensive automated coverage testing of the component's intrinsic behavior and cross-application collaborative scenarios.

[0125] like Figure 4 As shown, the execution results and coverage characteristics of 10 core test stimulus sequences (TC001~TC010) generated by the automated testing system for UI component defects in a micro-frontend architecture are recorded in detail. From a type perspective, intrinsic behavior test cases dominate (7 in total, such as TC001 and TC005), mainly verifying the independent evolution path of the component's internal state machine; one cross-application collaboration test case (TC004) specifically targets cross-domain message interaction in micro-frontend scenarios; and two mixed scenario test cases (TC007 and TC009) cover the complex links of intrinsic state transitions and external communication, reflecting the design goal of integrating intrinsic transformation edges and cross-application transformation edges into the state evolution graph. In terms of coverage level evaluation, high-coverage paths (5) are executed first, aiming to maximize the verification density of key business scenarios; medium-coverage paths (3) and low-coverage paths (2) correspond to regular processes and boundary conditions, respectively. Among them, low-coverage paths TC003 (retry failure loop) and TC008 (abnormal deadlock) are easily overlooked in manual testing due to their low frequency, but they are precisely high-risk areas for defect lurking. This also verifies the effectiveness of the system's sorting and generation strategy based on transition dependency strength and path priority. In terms of execution status, 7 out of 10 test cases passed and 3 failed. The failed TC003 exposed the defect that the retry mechanism could not correctly fall back to a safe state after repeated failures; the failure of TC007, as a high-priority mixed path, revealed the state competition problem when cross-application message waiting (S07) and form submission (S10) are concurrent; TC008 accurately hit the "deadlock state" (S13) marked in the state transition topology, confirming the structural defect that the node could not exit on its own. These failed test cases highly correspond to D01~D09 in the defect diagnosis report. Combined with the path sequence recorded in the table, developers can quickly reproduce and locate the root cause according to the chain of "path → node → triggering context", which significantly improves the efficiency of defect diagnosis.

[0126] In one optional embodiment, the test stimulus sequence is executed to monitor the state evolution trajectory and rendering of the component's running instance in real time. The consistency between the state evolution trajectory and the expected evolution path of the state evolution graph is verified. When a deviation from the expected path in state evolution or a violation of state constraint rules in rendering is detected, defect nodes are located, and the defect triggering context is extracted, including:

[0127] Operation events are injected into the component running instance in the order of interface operation instructions and cross-domain message sending instructions in the test stimulus sequence. After each injection, the state variable value of the component running instance is read, the state variable value is mapped to the state node in the state evolution graph, and the state node migration sequence is recorded to form the state evolution trajectory.

[0128] The expected evolution path corresponding to the test stimulus sequence is retrieved from the state evolution graph. The state node migration sequence in the state evolution trajectory is compared with the state node sequence in the expected evolution path node by node. State nodes in the state evolution trajectory that are not defined in the expected evolution path are identified as deviation positions.

[0129] Extract the state node corresponding to the deviation position as the defect node, and compare the interface rendering data with the state constraint rules of the state node in the state evolution graph. When the rendering attribute value exceeds the set of values ​​determined by the state constraint rules, mark the state node as a defect node.

[0130] Extract the interface operation instructions and cross-domain message content corresponding to the defect node at that moment, and combine them with the values ​​of state variables to form a defect triggering context.

[0131] In one specific implementation, during the test stimulus sequence-driven execution phase, operation events are injected into the component runtime instance sequentially according to the order of interface operation instructions and cross-domain message sending instructions in the test stimulus sequence. Interface operation instructions cover user interaction behaviors such as clicking, inputting, scrolling, and focus switching, while cross-domain message sending instructions simulate message delivery from other micro-frontend sub-applications or the host framework. After each operation event injection, the current full set of state variable values ​​for the component runtime instance is immediately read, including internal data attributes, computed attributes, and external state fields received through the cross-application communication layer. The read state variable values ​​are matched with the state invariant descriptions of each state node in the state evolution graph, mapping the current state variable value to the corresponding state node in the graph, and appending that state node to the state node migration sequence. This process continues until the entire test stimulus sequence is completed, ultimately forming a complete state evolution trajectory.

[0132] During state node mapping, the values ​​of state variables need to be rigorously compared with the state invariants of the state nodes. State invariants are extracted from the value evolution sequence collected by the state-aware probe during component instantiation. They describe the constraints that each state variable should satisfy under a specific state node, including the value range, enumeration set, and Boolean logic relationships. When a state variable value simultaneously satisfies all invariant constraints of a state node, the current state is considered to belong to that node. If a state variable value cannot match any known state node in the graph, that moment is marked as a candidate deviation point and included in the subsequent consistency verification process.

[0133] During the consistency verification phase, the expected evolution path corresponding to the current test stimulus sequence is retrieved from the state evolution graph. The expected evolution path, determined during the test stimulus sequence generation phase based on directed transition edges and cross-application transition edges in the graph, describes the sequence of state nodes that the component state should sequentially traverse under a given operation sequence. The state node migration sequence recorded in the actual state evolution trajectory is compared node-by-node with the state node sequence in the expected evolution path. After time-step alignment, each time-step's actual reached state node is checked to ensure it matches the expected node. If, at a certain time step, the actual state node does not match the expected state node, or the actual state node is an undefined node in the graph, the state node corresponding to that time step is marked as an deviation position. The time-step index where the deviation occurred, the actual state node identifier, and the expected state node identifier are recorded for subsequent defect localization.

[0134] After identifying the deviation position, the state node corresponding to the deviation position is extracted as a candidate defect node. Simultaneously, the interface rendering data of the component's running instance at the corresponding state node is collected, extracting the actual values ​​of each rendering attribute in the rendering tree, including visibility flags, text content, style attributes, and child node structure. The collected rendering attribute values ​​are then compared item by item with the state constraint rules bound to that state node in the state evolution graph. State constraint rules describe the set of legal values ​​that the interface rendering should satisfy under that state node; for example, a button's interactive attribute should be disabled under a disabled state node, or a list component's child node count should be zero under a data-empty state node. When the actual value of any rendering attribute exceeds the set of legal values ​​determined by the state constraint rules, the state node is confirmed as a defect node, and the name of the violating rendering attribute and its deviation from the set of legal values ​​are recorded.

[0135] For a confirmed defect node, the complete defect triggering context at the corresponding moment is extracted. The defect triggering context consists of three parts: first, the sequence of interface operation instructions that triggered the defect node, including the operation type, target element identifier, operation parameters, and the time step where the operation occurred; second, the content of cross-domain messages received or sent through the cross-application communication layer at that moment, including the message type, message payload field, and its values; and third, a snapshot of all state variable values ​​of the component's running instance at the corresponding moment, recording the specific values ​​of each state variable at the instant the defect was triggered, to facilitate subsequent analysis of abnormal state variable assignment paths. These three parts together constitute the complete defect triggering context, providing accurate contextual basis for the generation of subsequent defect diagnosis reports.

[0136] In actual implementation, real-time monitoring of the state evolution trajectory is achieved using a non-intrusive probe mechanism. The probe triggers state variable reading in the synchronous callback after each operation event injection, ensuring a strict temporal correspondence between the state snapshot and the operation event, and avoiding deviations in state reading timing due to asynchronous rendering delays. For components containing asynchronous state updates, a configurable waiting mechanism is introduced after the operation event injection. State variable reading and rendering data collection are performed only after the component's rendering cycle is complete, ensuring that the collected state snapshot and the rendered presentation are in the same stable frame. For message injection across the application communication layer, the message delivery sequence is intercepted through the interface listening layer, ensuring that cross-domain message sending instructions and interface operation instructions are executed in a strict temporal order, preventing concurrent messages from interfering with the accurate recording of the state evolution trajectory.

[0137] When a test stimulus sequence contains multiple deviation positions or multiple rendering violation nodes, all defective nodes are sorted according to time step order. The corresponding defect triggering context is extracted independently for each defective node, ensuring that each defect has an independent and reproducible triggering condition description. For cases where both state deviation and rendering violation occur simultaneously at the same state node, the two types of defect information are merged and recorded in the same defective node entry. Both state deviation and rendering violation defect types are simultaneously labeled in the defect type field to avoid duplicate reporting of defects at the same location. All defective nodes and their defect triggering contexts are finally summarized and output as the core content source of the defect diagnosis report, supporting subsequent defect root cause analysis and remediation.

[0138] A second aspect of this invention provides an automated testing system for UI component defects in a micro-frontend architecture, comprising:

[0139] An instantiation unit is used to obtain the interface component to be tested, and to instantiate the interface component to be tested in an isolated running environment to obtain a component running instance;

[0140] The state acquisition unit is used to inject state-aware probes into the component running instance to collect the value evolution sequence and trigger source, extract state invariants to construct a set of state nodes, establish directed transition edges and organize them into a state transition topology.

[0141] The cross-domain listening unit is used to listen to the cross-application communication layer of the interface component under test, extract the cross-domain message interaction mode and data flow dependency, insert the data flow dependency as a cross-application transformation edge into the state transformation topology, and form a state evolution graph.

[0142] The graph construction unit is used to generate test stimulus sequences that cover the intrinsic behavior of components and cross-application collaboration scenarios based on the state evolution graph;

[0143] The stimulus generation unit is used to drive the execution of the test stimulus sequence, monitor the state evolution trajectory and rendering of the component running instance in real time, verify the consistency between the state evolution trajectory and the expected evolution path of the state evolution graph, and locate the defect node and extract the defect trigger context when the state evolution deviates from the expected path or the rendering violates the state constraint rules.

[0144] The diagnostic report unit is used to generate a defect diagnostic report that includes the defect node and the defect triggering context.

[0145] A third aspect of the present invention provides an electronic device, comprising:

[0146] processor;

[0147] Memory used to store processor-executable instructions;

[0148] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0149] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0150] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0151] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. An automated testing method for UI component defects in a micro-frontend architecture, characterized in that, include: Obtain the interface component to be tested, and instantiate the interface component to be tested in an isolated runtime environment to obtain a component runtime instance; State-aware probes are injected into component running instances to collect value evolution sequences and trigger sources, state invariants are extracted to construct a set of state nodes, directed transition edges are established and organized into a state transition topology; The interface of the cross-application communication layer of the interface component under test is monitored, the cross-domain message interaction mode and data flow dependency are extracted, and the data flow dependency is inserted into the state transition topology as a cross-application transformation edge to form a state evolution graph. Generate test stimulus sequences that cover the intrinsic behavior of components and cross-application collaboration scenarios based on state evolution graphs; The test stimulus sequence is executed to monitor the state evolution trajectory and rendering of the component running instance in real time. The consistency between the state evolution trajectory and the expected evolution path of the state evolution graph is verified. When the state evolution deviates from the expected path or the rendering violates the state constraint rules, the defect node is located and the defect triggering context is extracted. Generate a defect diagnosis report that includes the defective node and the defect triggering context.

2. The method according to claim 1, characterized in that, State-aware probes are injected into component runtime instances to collect value evolution sequences and trigger sources. State invariants are extracted to construct a set of state nodes, and directed transition edges are established and organized into a state transition topology, including: A state-aware probe is injected into the execution path of the component's running instance to collect the value evolution sequence of state variables and the triggering source of state transitions in real time. The triggering source is semantically classified to form a set of triggering event types, and a temporal correlation relationship is established between the value evolution sequence and the set of triggering event types. Based on the value evolution sequence, state invariants are extracted, states that satisfy the same state invariant are grouped into state equivalence classes, a set of state nodes is constructed, and the transformation dependencies and transformation constraints between state nodes are identified according to the temporal correlation relationship, and a directed transformation edge including transformation dependency strength and transformation priority is established. The set of state nodes and the directed transition edges are organized into a hierarchical topology. Critical paths and deadlock nodes in the state transition are identified in the hierarchical topology to form a state transition topology.

3. The method according to claim 2, characterized in that, Based on the value evolution sequence, state invariants are extracted, and states that satisfy the same state invariant are grouped into state equivalence classes. The set of state nodes is constructed as follows: Dependency analysis is performed on the state variables in the value evolution sequence to identify the co-occurrence and mutual exclusion relationships between the state variables. For the co-occurrence relationship, the value conditions that the state variables can satisfy at the same time are determined, and for the mutual exclusion relationship, the value combinations that the state variables cannot appear at the same time are determined. Verify the value condition and the value combination in different migration paths of the value evolution sequence, and extract the value condition and value combination that are true in all migration paths as state invariants; Traverse the state snapshots in the value evolution sequence, determine the set of state invariants that each state snapshot conforms to, and merge the state snapshots that conform to the same set of state invariants into state equivalence classes; Assign a state node identifier to each state equivalence class, and use the set of state invariants corresponding to the state equivalence class as the constraint rule for the state node identifier to construct a state node set including the state node identifier and the constraint rule.

4. The method according to claim 1, characterized in that, Interface monitoring is performed on the cross-application communication layer of the UI component under test. Cross-domain message interaction patterns and data flow dependencies are extracted. The data flow dependencies are then inserted into the state transition topology as cross-application transition edges to form a state evolution graph, including: The interface of the cross-application communication layer of the interface component under test is monitored to capture the sending and receiving timing of cross-domain messages, extract the transmission direction of cross-domain messages, the data field composition of message payload, and the interface response actions triggered by the messages, and summarize them into cross-domain message interaction patterns. Track the state change links corresponding to the cross-domain message interaction mode, identify the source state node before message sending and the target state node triggered after message reception, determine the mapping relationship between the output data items of the source state node and the input data items of the target state node, and establish the data flow dependency relationship from the source state node to the target state node. In the state transition topology, the source state node and the target state node are located, and the data flow dependency is inserted as a cross-application transition edge between the corresponding nodes in the state transition topology. The semantic identifier of the cross-domain message interaction mode and the mapping relationship are attached to the cross-application transition edge to form a state evolution graph.

5. The method according to claim 4, characterized in that, Tracing the state change chain corresponding to cross-domain message interaction patterns, identifying the source state node before message sending and the target state node triggered after message reception includes: Locate the trigger position of the cross-domain message sending operation in the state transition topology, and record the state node associated with the trigger position as the starting point for tracking; Traverse the forward path along the directed transition edges of the state transition topology, identify candidate state nodes that undergo state transition after receiving the cross-domain message, extract the state variable value change records of the candidate state nodes, and determine whether the data content in the state variable value change records has a field-level data association with the message payload of the cross-domain message. Candidate state nodes with field-level data associations are identified as target state nodes, the tracing starting point is identified as the source state node, a transformation path sequence from the source state node to the target state node is constructed, and the propagation trajectory of the cross-domain message interaction mode is marked in the transformation path sequence to form a state change link.

6. The method according to claim 1, characterized in that, The test stimulus sequence generated based on the state evolution graph covers the intrinsic behavior of components and cross-application collaboration scenarios, including: Extract state transition edges corresponding to component intrinsic behaviors and cross-application transition edges corresponding to cross-application collaboration scenarios from the state evolution graph. Analyze the transition conditions and trigger event types of the state transition edges. At the same time, analyze the semantic identifiers and data flow dependencies of the cross-application transition edges. Construct a hybrid path set including component intra-state transition paths and cross-application message passing paths. Traverse each path in the mixed path set, extract the trigger events and data constraints carried by each transformation edge in the path, convert the trigger events into interface operation instructions, convert the data constraints into input parameter configurations for the interface operation instructions, and additionally generate cross-domain message sending instructions and message receiving verification instructions for the cross-application transformation edges. The interface operation instructions, the input parameter configuration, the cross-domain message sending instructions, and the message receiving verification instructions are organized sequentially according to the topological order of the transformation edges in the path to form a test stimulus subsequence for that path; All test stimulus subsequences corresponding to the hybrid path set are sorted and summarized according to path coverage priority to generate a test stimulus sequence.

7. The method according to claim 1, characterized in that, The test stimulus sequence is executed to monitor the state evolution trajectory and rendering of the component's running instance in real time. The consistency between the state evolution trajectory and the expected evolution path of the state evolution graph is verified. When a deviation from the expected path in state evolution or a violation of state constraint rules in rendering is detected, defect nodes are located, and the defect triggering context is extracted, including: Operation events are injected into the component running instance in the order of interface operation instructions and cross-domain message sending instructions in the test stimulus sequence. After each injection, the state variable value of the component running instance is read, the state variable value is mapped to the state node in the state evolution graph, and the state node migration sequence is recorded to form the state evolution trajectory. The expected evolution path corresponding to the test stimulus sequence is retrieved from the state evolution graph. The state node migration sequence in the state evolution trajectory is compared with the state node sequence in the expected evolution path node by node. State nodes in the state evolution trajectory that are not defined in the expected evolution path are identified as deviation positions. Extract the state node corresponding to the deviation position as the defect node, and compare the interface rendering data with the state constraint rules of the state node in the state evolution graph. When the rendering attribute value exceeds the set of values ​​determined by the state constraint rules, mark the state node as a defect node. Extract the interface operation instructions and cross-domain message content corresponding to the defect node at that moment, and combine them with the values ​​of state variables to form a defect triggering context.

8. An automated testing system for UI component defects in a micro-frontend architecture, used to implement the method as described in any one of claims 1-7, characterized in that, include: An instantiation unit is used to obtain the interface component to be tested, and to instantiate the interface component to be tested in an isolated running environment to obtain a component running instance; The state acquisition unit is used to inject state-aware probes into the component running instance to collect the value evolution sequence and trigger source, extract state invariants to construct a set of state nodes, establish directed transition edges and organize them into a state transition topology. The cross-domain listening unit is used to listen to the cross-application communication layer of the interface component under test, extract the cross-domain message interaction mode and data flow dependency, insert the data flow dependency as a cross-application transformation edge into the state transformation topology, and form a state evolution graph. The graph construction unit is used to generate test stimulus sequences that cover the intrinsic behavior of components and cross-application collaboration scenarios based on the state evolution graph; The stimulus generation unit is used to drive the execution of the test stimulus sequence, monitor the state evolution trajectory and rendering of the component running instance in real time, verify the consistency between the state evolution trajectory and the expected evolution path of the state evolution graph, and locate the defect node and extract the defect trigger context when the state evolution deviates from the expected path or the rendering violates the state constraint rules. The diagnostic report unit is used to generate a defect diagnostic report that includes the defect node and the defect triggering context.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images