Mobile terminal app testing method and device based on agent system, equipment and medium

Abstract

The application relates to the technical field of research and development management, and discloses a mobile terminal APP testing method, device and equipment based on an agent system and a medium, which comprises the following steps: a main agent assigns a test task to each sub-agent based on a contract net protocol for parallel execution; an abnormality detection agent monitors system indexes and publishes an event to the main agent and a root cause analysis agent when an abnormality is triggered; the main agent instructs a scene reconstruction agent to capture context data packets; after abnormality features and historical graphs are extracted from the context, candidate cause nodes are selected and counterfactual deduction verification is performed; and a root cause analysis report is generated. The application can be applied to business scenarios such as financial technology and medical health, and through the cooperation of a knowledge graph and an agent, test automation is realized, and the efficiency of App stability testing is improved for users.

Description

Technical Field

[0001] This invention relates to the field of R&D management technology, and in particular to a mobile APP testing method, apparatus, equipment and medium based on an intelligent agent system. Background Technology

[0002] The stability of mobile apps has become a core quality lifeline for industries such as finance, healthcare, e-commerce, social media, and gaming, directly determining user retention and business revenue. Industry experience shows that even a small increase in the crash rate can lead to a significant loss of daily active users. During major e-commerce promotions, transaction interruptions caused by stability issues often result in extremely severe hourly revenue losses. However, with the exponential increase in app functionality (a single mainstream app often contains hundreds of pages and tens of thousands of interaction nodes), drastically compressed iteration cycles, and the widespread use of hybrid development and cross-platform frameworks, traditional stability testing methods are no longer sufficient to meet the quality assurance requirements of modern apps.

[0003] Current mainstream solutions in the industry suffer from several fundamental technical flaws. First, traditional Monkey testing relies on randomly generated click and swipe events, resulting in only a low level of code coverage. Furthermore, the vast majority of test operations are concentrated in high-frequency, simple scenarios, making it difficult to delve into deeper business logic paths and peripheral branches. For example, in an e-commerce app, the complete process of "order refund—after-sales review—return via original payment method" has an extremely low probability of being triggered by random testing, rendering coverage of complex business chains virtually ineffective. Second, UI automation testing based on recording and playback heavily relies on fixed element positioning and predetermined operation paths. Once the app interface undergoes slight changes, such as button relocation or text adjustment, the script failure rate increases dramatically. Simultaneously, this type of solution is almost powerless against dynamically loaded content, asynchronous API calls, and multi-threaded concurrent scenarios, which are precisely the main contributors to online stability issues.

[0004] More seriously, existing tools primarily focus on explicit anomalies such as crashes and ANRs (Application Not Responding), lacking effective detection capabilities for implicit stability issues like slow memory growth, gradual frame rate drops, and thread deadlocks. When problems are exposed, they often only provide basic stack traces, lacking operational context, system resource change trajectories, and business data correlations, leading to excessively long root cause analysis times and severely hindering repair efficiency. Furthermore, traditional testing employs a fixed-duration, fixed-intensity "one-size-fits-all" approach, failing to dynamically adjust strategies based on the app's actual operating state—applying high-intensity stress to areas with normal memory usage while neglecting testing duration in high-risk areas, resulting in significant waste of testing resources, forced extension of the overall testing cycle, and a high-cost, low-efficiency dilemma for quality assurance. In conclusion, the existing stability testing system is no longer suitable for the iteration speed and complexity of modern apps, urgently requiring a new testing paradigm oriented towards intelligence, dynamism, and deep business awareness.

[0005] In the healthcare sector, traditional random testing struggles to cover multi-step, logically dependent medical processes such as online consultations, electronic prescription transfers, and lab report parsing. Its extremely low trigger probability leads to long-term omission of critical path anomalies. Recorded playback scripts frequently fail due to changes in interface elements (such as drug name formats and button layouts), and are unable to handle dynamically loaded real-time monitoring data or asynchronous API calls. Stuttering or crashes in these scenarios can cause misdiagnosis or data loss in emergency situations or remote monitoring. Existing monitoring methods lack effective detection of hidden failures such as slow memory growth and interface rendering delays. When problems accumulate to a critical point, they interfere with the accurate presentation of continuous vital sign data, and root cause localization is delayed due to a lack of operational and business context. Fixed-intensity testing cannot dynamically apply pressure during peak patient visit periods or periods of intensive data synchronization, resulting in unbalanced resource allocation and severely weakening the stability of healthcare apps under high concurrency pressure.

[0006] In the fintech business, random testing cannot cover complex fund flows such as interbank transfers, wealth management product purchases, and anti-fraud risk control decisions. Edge path triggers have extremely low probability, making it difficult to expose hidden defects such as inconsistent account balances and disordered order statuses. Minor UI changes cause replay scripts to fail in batches, and dynamically loaded interest rates, market data, and multi-threaded concurrent trading scenarios (such as flash sales) are the main sources of online failures, which existing tools struggle to fully simulate and detect. Gradual performance degradation, such as memory leaks and thread deadlocks, can easily lead to service timeouts or unresponsive processes under high concurrency. Every minute of abnormal interruption can cause huge revenue losses, and current stack trace information lacks business relevance, making problem localization time-consuming. Fixed-duration testing cannot apply pressure based on peak business activity, resulting in insufficient testing depth in high-risk areas such as risk control audits and clearing and settlement, while excessively consuming resources in low-risk modules, leading to overall low efficiency and failing to meet the stringent stability requirements of the financial industry. Summary of the Invention

[0007] The main objective of this invention is to provide a mobile app testing method, apparatus, device, and storage medium based on an intelligent agent system, aiming to solve problems such as low random test coverage, fragile and easily failed scripts, single anomaly detection dimensions, and unintelligent resource scheduling in existing mobile app testing.

[0008] To achieve the above objectives, the present invention provides a mobile app testing method based on an intelligent agent system, comprising: The global master agent decomposes the global test task into multiple atomic sub-tasks according to the test objectives, and issues task bidding to the interface exploration agent, stress test agent, anomaly detection agent, root cause analysis agent and scene reconstruction agent through a cooperative communication mechanism. The global main agent receives bid responses from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent based on their own capabilities and current load, and distributes the task parameters of the atomic subtasks to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent respectively according to the bid responses. When the interface exploration agent and the stress testing agent receive the task parameters, they execute the atomic subtasks corresponding to the task parameters in parallel. The anomaly detection agent detects the system operation indicators of the App under test in real time according to the task parameters. When an anomaly event is detected, the anomaly event message is published to the global main agent and the root cause analysis agent. After receiving the abnormal event message, the global main agent instructs the scene reconstruction agent to pass the context data packets within a specified time window before and after the abnormality to the root cause analysis agent. The root cause analysis agent extracts an abnormal feature set from the context data packet, performs similarity matching between the abnormal feature set and historical cases in the historical abnormal pattern knowledge graph, selects multiple candidate cause nodes based on the matching degree, performs counterfactual inference on each candidate cause node, and generates a root cause analysis report. The global main agent collects execution data from the exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scenario reconstruction agent. Statistical analysis is performed on the execution data to generate a comprehensive stability result for the App under test.

[0009] Furthermore, to achieve the above objectives, the present invention provides a mobile APP testing device based on an intelligent agent system, comprising: The task bidding module is used to decompose the global test task into multiple atomic sub-tasks according to the test objectives by the global main agent, and to issue task bidding to the interface exploration agent, stress test agent, anomaly detection agent, root cause analysis agent and scene reconstruction agent through a collaborative communication mechanism. The task publishing module is used by the global main agent to receive bid responses from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent based on their own capabilities and current load, and to distribute the task parameters of the atomic subtasks to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent respectively according to the bid responses. The subtask execution module is used to execute the atomic subtasks corresponding to the task parameters in parallel when the interface exploration agent and the stress testing agent receive the task parameters. The anomaly monitoring module is used by the anomaly detection agent to detect the system operation indicators of the App under test in real time according to the task parameters. When an anomaly event is detected, the anomaly event message is published to the global main agent and the root cause analysis agent. An abnormal data acquisition module is used to instruct the scene reconstruction agent to transmit the context data packets within a specified time window before and after the abnormality occurs to the root cause analysis agent after the global main agent receives an abnormal event message. The root cause analysis module is used to extract an abnormal feature set from the context data packet through the root cause analysis agent, match the abnormal feature set with historical cases in the historical abnormal pattern knowledge graph, select multiple candidate cause nodes based on the matching degree, perform counterfactual inference on each candidate cause node, and generate a root cause analysis report. The data update module is used to collect execution data from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent by the global main agent, perform statistical analysis on the execution data, and generate a comprehensive stability result of the App under test.

[0010] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a mobile APP testing program based on an intelligent agent system stored in the memory and executable on the processor, wherein when the mobile APP testing program based on an intelligent agent system is executed by the processor, it implements the steps of the mobile APP testing method based on an intelligent agent system as described above.

[0011] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a mobile APP test program based on an intelligent agent system, wherein when the mobile APP test program based on an intelligent agent system is executed by a processor, it implements the steps of the mobile APP test method based on an intelligent agent system as described above.

[0012] Beneficial Effects: This invention relates to the field of R&D management technology and discloses a mobile APP testing method, apparatus, equipment, and medium based on an intelligent agent system. The method includes: a master intelligent agent allocating test tasks to various sub-intelligent agents for parallel execution based on a contract network protocol; an anomaly detection intelligent agent monitoring system indicators and publishing events to the master intelligent agent and root cause analysis intelligent agent when an anomaly is triggered; the master intelligent agent instructing a scenario reconstruction intelligent agent to capture context data packets; extracting anomaly features from the context and matching them with historical graphs to select candidate cause nodes and perform counterfactual inference verification; and generating a root cause analysis report. This invention can be applied to business scenarios such as fintech and healthcare. By constructing a functional knowledge graph to load historical anomaly patterns, dynamically allocating tasks by the master intelligent agent based on the contract network protocol, targeted execution by sub-intelligent agents, and collaborative diagnosis of anomaly detection and root cause analysis, it solves the problems of low coverage, fragile scripts, single detection dimensions, and unintelligent resource scheduling in existing technologies, significantly improving the degree of test automation and efficiency. Attached Figure Description

[0013] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a mobile APP testing method based on an intelligent agent system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the mobile APP testing method based on an intelligent agent system according to the present invention. Figure 3This is a flowchart illustrating step S400 in one embodiment of the mobile APP testing method based on an intelligent agent system according to the present invention. Figure 4 This is a flowchart illustrating step S600 in one embodiment of the mobile APP testing method based on an intelligent agent system of the present invention. Figure 5 This is a flowchart illustrating step S700 in one embodiment of the mobile APP testing method based on an intelligent agent system of the present invention. Figure 6 This is a schematic diagram of the functional modules of a preferred embodiment of the mobile APP testing device based on an intelligent agent system of the present invention; Figure 7 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 8 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0014] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0015] The mobile app testing method based on an intelligent agent system provided in this invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can allocate test tasks to various sub-agents for parallel execution by the main agent based on the Contract Network protocol. The anomaly detection agent monitors system metrics and publishes events to the main agent and root cause analysis agent when an anomaly is triggered. The main agent instructs the scenario reconstruction agent to capture context data packets, extract anomaly features from the context, match them with historical graphs, select candidate cause nodes, and perform counterfactual inference verification to generate a root cause analysis report. This invention can be applied to business scenarios such as fintech and healthcare. By constructing a functional knowledge graph to load historical anomaly patterns, dynamically allocating tasks by the main agent based on the Contract Network protocol, targeted execution by sub-agents, and collaborative diagnosis of anomaly detection and root cause analysis, it solves the problems of low coverage, fragile scripts, single detection dimensions, and unintelligent resource scheduling in existing technologies, significantly improving the degree of test automation and efficiency. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The following detailed description of specific embodiments further illustrates this invention.

[0016] Please see Figure 2 , Figure 2This is a flowchart illustrating an embodiment of the mobile app testing method based on an intelligent agent system provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0017] like Figure 2 As shown, the mobile app testing method based on an intelligent agent system proposed in this invention includes the following steps: S100. The global main agent decomposes the global test task into multiple atomic sub-tasks according to the test objectives, and issues task bidding to the interface exploration agent, stress test agent, anomaly detection agent, root cause analysis agent and scene reconstruction agent through a cooperative communication mechanism. S200, the global main agent receives bid responses from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent based on their own capabilities and current load, and sends the task parameters of the atomic subtasks to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent respectively according to the bid responses; S300. When the interface exploration agent and the stress test agent receive the task parameters, they execute the atomic subtasks corresponding to the task parameters in parallel. S400: The anomaly detection agent detects the system operation indicators of the App under test in real time according to the task parameters. When an anomaly event is detected, the anomaly event message is published to the global main agent and the root cause analysis agent. S500. After receiving the abnormal event message, the global main agent instructs the scene reconstruction agent to transmit the context data packets within the specified time window before and after the abnormality to the root cause analysis agent. S600. The root cause analysis agent extracts an abnormal feature set from the context data packet, performs similarity matching between the abnormal feature set and historical cases in the historical abnormal pattern knowledge graph, selects multiple candidate cause nodes based on the matching degree, performs counterfactual inference on each candidate cause node, and generates a root cause analysis report. S700: The global main agent collects execution data from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent, performs statistical analysis on the execution data, and generates a comprehensive stability result for the App under test.

[0018] In one embodiment, after obtaining the installation package of the application under test (App), a static parser is invoked to perform in-depth analysis of its internal code files and resource description files, extracting key information such as page classes, user interface (UI) components, business interfaces, and data entities, and defining this information as entity nodes in the knowledge graph. Simultaneously, jump declarations between pages, the relationship between components and pages, interface dependencies, and data flow between entities are defined as relationship edges between entities, thereby initially constructing a topological knowledge graph describing the App's functional structure based on a pre-defined ontology model. At the same time, the system initiates a search in the global knowledge base based on the App's current business type tag (such as finance, e-commerce, or social), loading a historical anomaly pattern knowledge graph that highly matches that type, providing a priori experience foundation for subsequent anomaly diagnosis. Based on this, the system pre-constructs a global main agent and multiple specialized sub-agents. The main agent loads a Belief-Desire-Intention (BDI) cognitive model framework and is responsible for global decision-making and resource scheduling, while the specialized sub-agents include different functional units such as interface exploration, stress testing, anomaly detection, root cause analysis, and scenario reconstruction. Meanwhile, the system constructs a global state sharing space based on the blackboard model and establishes an event bus mechanism to configure the collaborative communication protocol between the main agent and each sub-agent, ensuring that all subsequent state information and instructions can flow efficiently and transparently between units.

[0019] The execution of the test task begins with the global main agent breaking down the user-defined test objectives. The main agent decomposes the global test task into multiple independent atomic subtasks and issues a task bidding announcement to all registered professional sub-agents via the Contract Network protocol. Each sub-agent responds with a bid based on its current algorithm capabilities, load status, and available resources. The main agent then makes a comprehensive evaluation based on the bidding information and distributes each subtask and its detailed parameters to the optimal winning sub-agent. Following this, the system enters the concurrent execution phase: the interface exploration agent extracts visual features from the current interface's visual screenshot and UI hierarchy tree using a convolutional neural network (CNN), and combines this with system resource usage data and historical access path records to generate a unified state vector. This vector is then input into a reinforcement learning decision network based on the Proximal Policy Optimization (PPO) algorithm. The network selects and executes the optimal action from twelve preset basic operations (such as click, swipe, long press, zoom, and text input) and their accompanying parameters. Subsequently, it calculates a multi-objective weighted reward value based on metrics such as the discovery of new pages, interaction with new components, and improvement in code coverage. The combined quadruple of state, action, reward, and next state is stored in the experience replay pool for incremental training of the decision network at fixed intervals. Meanwhile, the stress testing agent, following instructions from the main agent, simulates multi-user concurrent operations and extreme environmental conditions such as network fluctuations and insufficient power, applying high-intensity stress loads to high-risk business modules such as payment and order submission. The anomaly detection agent, on the other hand, continuously collects time-series data on memory usage, CPU utilization, frame rate, and network latency at millisecond-level sampling frequencies, storing this data in a circular buffer queue. It then analyzes the changing trajectories of these indicators in real time using mutation detection and trend detection algorithms. When any indicator exceeds an adaptive dynamic threshold calculated in real time based on historical data, the anomaly detection agent immediately generates an anomaly event message and synchronously publishes it to the global main agent and the root cause analysis agent via the event bus.

[0020] Upon receiving an anomaly event message, the global lead agent immediately interrupts the current routine testing process and switches to deep diagnostic mode. The lead agent instructs the scenario reconstruction agent to rapidly capture all contextual data within a specified time window—30 seconds before and 10 seconds after the anomaly. This includes a complete sequence of user actions, the trajectory of system resource changes at each moment, all backend interface call records, and continuous screenshots. This data constitutes a complete information package capable of retracing the entire event. Subsequently, the root cause analysis agent extracts a multi-dimensional set of anomaly features from this contextual data package, including memory growth rate, call stack information, operation sequence patterns, and current business scenario identifiers. The agent first calculates the similarity between these features and historical cases in a historical anomaly pattern knowledge graph loaded from the global knowledge base. It then filters out historical cases with a matching degree higher than a preset threshold and extracts the prior probability distributions of each root cause type associated with these cases, using this as prior input for subsequent Bayesian inference. Simultaneously, it maps the extracted anomaly features to a pre-constructed anomaly causal graph, corresponding to specific phenomenon nodes and intermediate nodes in the causal graph, serving as observational evidence for Bayesian network inference. Based on the directed edge weights and conditional probability tables defined in the causal graph, and combined with the aforementioned prior probabilities and observational evidence, the root cause analysis agent uses a Bayesian network inference algorithm to calculate the posterior confidence of each potential cause node in the causal graph, i.e., the probability that each cause is true given the occurrence of the anomaly. The system selects several nodes with the highest posterior confidence as candidate root causes according to a preset screening strategy. Furthermore, it performs counterfactual inference on each candidate cause node, simulating the removal of the cause node from the causal graph and observing whether the probability of the corresponding phenomenon node occurs significantly. If the decrease exceeds the severity threshold, the candidate cause is verified as a valid root cause of the anomaly. Finally, this valid root cause, which has undergone double verification (statistical inference and causal intervention), and its complete chain of evidence are written into the root cause analysis report.

[0021] At the end of the entire testing cycle, the global master AI will issue a data aggregation command to all specialized sub-AI agents. Each sub-AI agent will report its execution logs, discovered anomaly records, and internal model statistics to the master AI agent. The master AI agent will perform comprehensive statistical analysis on this data, calculating a comprehensive stability assessment result that includes code coverage, the number of anomaly discoveries, and the risk levels of various resource leaks. In terms of knowledge accumulation and updating, the system will dynamically add all newly discovered page nodes, UI component nodes, and page navigation and component inclusion relationships discovered during this round of testing to the App's functional knowledge graph as new entities and relationships, allowing the graph to continuously improve with each test iteration. Simultaneously, the effective root causes from the root cause analysis report, the corresponding anomaly characteristic patterns, and the executable script test case numbers generated by the scenario reconstruction agent for one-click replay will be updated to the anomaly pattern knowledge graph as new anomaly pattern entities and relationships. This mechanism not only completes the closed loop of the current test task, but also allows historical test experience and fault diagnosis knowledge to be structurally accumulated. In subsequent tests on the same type or other similar apps, loading this map can enable cross-project and cross-version knowledge reuse, significantly shortening the initialization and diagnostic preparation time for new test tasks.

[0022] This embodiment constructs a collaborative architecture between a global master agent and specialized sub-agents. It performs static analysis on the app under test to build a functional knowledge graph and loads a historical anomaly pattern knowledge graph. Test tasks are decomposed and dynamically allocated to each agent for parallel execution. Each sub-agent performs interface exploration, stress testing, and anomaly detection. When an anomaly is detected, context capture is triggered. The root cause analysis agent locates the root cause through similarity matching and counterfactual inference. Finally, the global master agent aggregates all execution data to generate a comprehensive stability assessment and updates the newly discovered knowledge to both the functional and anomaly graphs, achieving structured accumulation and reuse of testing experience. This addresses the four core shortcomings of traditional random testing: poor targeting, low script flexibility, single-dimensional anomaly detection, and unintelligent resource scheduling.

[0023] In stability testing of healthcare apps, the installation package of the medical app can be statically analyzed to construct a functional graph. An anomaly pattern knowledge graph from similar medical applications is loaded as a priori foundation. An interface exploration agent focuses on traversing the consultation process and report viewing path, while a stress testing agent simulates high-concurrency scenarios with a large number of patients simultaneously registering and consulting during peak hours. When the anomaly detection agent detects image loading memory overflow or data synchronization thread deadlock, the scenario reconstruction agent records the complete operation path and system state changes. The root cause analysis agent quickly locates the issue—whether it's unreleased image cache or a network retry strategy defect—through causal reasoning. Finally, a root cause report containing reproduction scripts and repair suggestions is automatically generated and stored in the anomaly pattern knowledge graph for direct reuse in subsequent versions of similar medical apps.

[0024] In stability testing of fintech apps, static analysis of the app's installation package can extract key entities such as payment interfaces and order state machines to construct a functional graph. Simultaneously, it loads historical cases of application-specific anomalies, such as distributed transaction timeouts and inconsistent accounting data, from a global knowledge base. During testing, the interface exploration agent prioritizes high-risk paths like account opening, card binding, and subscription / redemption. The stress testing agent simulates the extreme load of tens of thousands of people simultaneously purchasing wealth management products. The anomaly detection agent monitors transaction latency and memory changes with millisecond-level precision. When an anomaly is detected, the root cause analysis agent, using Bayesian causal reasoning, accurately distinguishes between insufficient database connection pools and cache penetration from the call stack and environmental metrics. The generated root cause report directly links to replayable scripts and code-level fix suggestions, and updates the anomaly pattern to the financial-specific knowledge graph. This reduces the initialization time of subsequent tests by approximately 70%, and compresses the stability verification cycle before major sales events from several weeks to several days.

[0025] In one embodiment, before S100, the following steps are included: After receiving the installation package of the App under test, the code files and resource description files in the installation package are parsed to extract key data and test parameters; The page classes, UI components, business interfaces, and data entities in the key data are defined as entity nodes of the knowledge graph; The page navigation target declaration, the relationship between components and pages, the dependency relationship between interfaces and pages, and the data flow relationship between entities in the key data are defined as relationship edges between entities; An initial App function knowledge graph is constructed based on the entity nodes and relation edges using a preset graph ontology model; Based on the App business type tag in the test parameters, a retrieval request is initiated to the global knowledge base; Based on the retrieval request, obtain one or more historical anomaly pattern knowledge graphs that match the App's business type tags.

[0026] In this embodiment, the static parser integrated within the system immediately performs a comprehensive scan and parsing of the code files (including bytecode or intermediate code) and resource description files (such as layout files, manifest files, and resource configurations) in the installation package of the App under test. The parser traverses all class structures, method declarations, resource references, and configuration declarations, extracting two types of core information: one type is the key data necessary for building a knowledge graph, including page classes (such as activities or fragments), user interface (UI) components (such as buttons, input boxes, and lists), business interfaces (such as endpoint definitions for network requests), and data entities (such as object models and their fields); the other type is the test parameters that affect the test execution strategy, such as the business type tag, package name, version number, and dependent third-party framework types of the current App.

[0027] After extracting the aforementioned key data, the system defines entities and relationships according to a pre-defined knowledge graph ontology model. Specifically, page classes, UI components, business interfaces, and data entities are uniformly identified as entity nodes in the knowledge graph, with each node accompanied by its own attribute information (such as class name, component type, interface address, or field structure). Simultaneously, the system extracts various relationships between entities from the static analysis results: the declaration of navigation targets between pages (e.g., navigation from page A to page B) is defined as a "navigation relationship" edge; the nested structure between UI components and their respective pages is defined as an "inclusion relationship" edge; the fact that a business interface is called or depends on by a specific page is defined as a "dependency relationship" edge; and the direction of data entity flow between pages or interfaces (e.g., data transfer from the input page to the submission interface) is defined as a "data flow relationship" edge. All entity nodes and relationship edges are subject to type constraints and attribute annotations based on the pre-defined ontology model to ensure the consistency and reasonability of the knowledge graph structure. After completing these definitions, the system instantiates the nodes and edges based on the storage structure of the graph database, thereby constructing an initial App functional knowledge graph. This graph comprehensively depicts the static interface topology, component layout, and business data flow path of the current App in a structured manner.

[0028] Meanwhile, the system extracts the App's business type tags from the parsed test parameters, such as categories like "financial payment," "e-commerce retail," "social entertainment," or "game application." Based on these tags, the system initiates a search request to a global knowledge base. This global knowledge base, independent of the current test environment, stores historical anomaly pattern knowledge graphs accumulated from numerous past App testing projects. The search process employs a semantic matching mechanism, not only accurately matching business type tags but also considering the hierarchical relationships of tags and synonym expansion to obtain the most relevant historical knowledge. Ultimately, the system retrieves one or more versions of historical anomaly pattern knowledge graphs that match the business type tag. These graphs contain structured information such as various anomaly types (e.g., memory leaks, thread deadlocks, interface timeouts), typical root causes, symptoms, and remediation solutions that have occurred in similar Apps in the past. After loading these historical knowledge graphs, the current test system possesses prior experience across projects and versions, eliminating the need to accumulate anomaly diagnostic knowledge from scratch and providing an immediately usable reasoning foundation for subsequent real-time anomaly detection and root cause analysis. At this point, the initial knowledge layer is ready, containing both the functional structure diagram of the current App and prior knowledge of similar abnormal patterns. Together, they support the subsequent collaborative decision-making and diagnostic tasks of the intelligent agent.

[0029] In this embodiment, a static parser is used to parse the code and resources of the app installation package under test, extracting page classes, UI components, business interfaces, and data entities as entity nodes. Simultaneously, page navigation, component affiliation, interface dependencies, and data flow are extracted as relationship edges. An initial functional knowledge graph is constructed based on a preset ontology model. Simultaneously, the global knowledge base is searched based on business type tags, and a matching historical anomaly pattern knowledge graph is loaded. This achieves automated extraction and structured modeling of app structural information, eliminating the need for manual topology analysis during subsequent testing. Furthermore, the loading of historical knowledge graphs provides prior experience from similar applications for anomaly diagnosis, significantly shortening test initialization preparation time.

[0030] In testing healthcare apps, the static parser, after parsing the installation package, automatically extracts the page classes, UI components, and interface entities corresponding to core business modules such as online consultation, electronic medical records, image viewing, and prescription circulation. This constructs a complete functional topology map, clearly presenting the entire link from patient registration to doctor prescription and pharmacist review, including interface navigation and data flow. The synchronously loaded medical-specific anomaly pattern map includes the characteristics and root causes of typical problems found in similar apps, such as image loading memory overflow, real-time heart rate data synchronization delay, and frequent Bluetooth device disconnections. This allows the agent to possess structural awareness and anomaly priors when subsequent tests begin. The first round of interface exploration can cover the complete path from registration to consultation to report viewing. Furthermore, by leveraging historical anomaly maps, key monitoring can be deployed in advance for high-risk aspects such as image loading and Bluetooth communication, effectively improving the targeting of tests in healthcare scenarios.

[0031] In testing fintech apps, the static parser, after parsing, automatically extracts page classes, payment interfaces, and data entities corresponding to fund security-sensitive businesses such as account login, fund transfers, wealth management product purchases, real-time market data updates, and transaction cancellations. It constructs a functional knowledge graph covering the entire transaction chain, clearly mapping the complete data flow and interface dependency chain from user authentication to transaction confirmation and fund settlement. Simultaneously, a financial-specific anomaly pattern graph is loaded, containing characteristics of high-risk cases from similar financial apps, such as distributed transaction timeouts, inconsistent accounting data, market data delays caused by cache penetration, and overselling of inventory under concurrent buying. This allows subsequent testing to directly inherit the unique anomaly diagnosis experience in the financial field. The intelligent agent, upon startup, knows to focus on monitoring key nodes such as transaction interface response time, fund value consistency, and multi-terminal data synchronization, laying a structured knowledge foundation for ensuring fund security and transaction compliance.

[0032] In one embodiment, prior to S100, the following steps are included: A global main agent is pre-built for task decomposition and scheduling based on the test objectives; Construct an interface exploration agent, a stress testing agent, an anomaly detection agent, a root cause analysis agent, and a scenario reconstruction agent, respectively; A global state sharing space based on the blackboard model is constructed. The global state sharing space is divided into a global state area, a task scheduling area, and an abnormal event area. The interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent are registered to the global state sharing space and granted data read and write permissions to the corresponding areas. An event bus is established, and the collaborative communication mechanism between the global main agent and the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent is configured through the event bus.

[0033] In this embodiment, a global master agent is pre-built, and a belief-desire-intention cognitive model framework is loaded onto this master agent. This framework enables the master agent to possess human-like rational reasoning and decision-making abilities. At the belief layer, the system initializes a global test state cache to store the current test's global progress, the operational health status of each sub-agent, the overall stability evaluation score of the App, and the latest values ​​of all observed system metrics in real time. Simultaneously, a general knowledge dictionary is initialized, storing common-sense knowledge shared across sub-agents in key-value pairs, such as general feature templates for various anomaly types, interaction behavior patterns of common components, and platform-related system constraint parameters. At the desire layer, the system reads the test target parameters submitted by the user through the test access layer. These parameters include the expected code coverage target (e.g., 85%), the names of the business modules to be prioritized for coverage, the preset maximum total test duration, and the minimum requirement for the number of anomaly discoveries. The desire layer formalizes these targets into quantifiable optimization objective functions. At the intent layer, the system constructs a priority task queue to store atomic subtasks to be executed and their status identifiers. At the same time, it instantiates a Contract Net Protocol processor, which is responsible for managing the entire lifecycle of all subsequent task bidding, tendering, and awarding, including the formatted publication of bidding announcements, timeout control of bid responses, and triggering logic for awarding decisions.

[0034] After the global main agent is built, the system constructs five specialized sub-agents: an interface exploration agent, a stress testing agent, an anomaly detection agent, a root cause analysis agent, and a scene reconstruction agent. When constructing each sub-agent, the system loads the corresponding decision model and configuration strategy. The interface exploration agent loads a proximal policy optimization reinforcement learning model, including an actor-critic dual network structure, capacity parameters for the experience replay pool, and an exploration rate decay plan. It also configures pre-trained weights for the convolutional neural network feature extractor for visual encoding of interface screenshots. The stress testing agent loads a concurrent user generation model, an operation frequency regulator, and a set of extreme environment simulation parameters (including network rate limiting templates, battery decay curves, and memory level trigger conditions). The anomaly detection agent loads dynamic threshold calculators for various system indicators, time-series mutation detection operators (such as statistical process control-based methods), and trend analysis filters (such as exponentially weighted moving average algorithms), as well as classifier configurations for explicit and implicit anomaly types. The root cause analysis agent loads pre-built abnormal causal graph structure data, Bayesian network inference engine parameter configurations, and the intervention simulator required for counterfactual inference. The scene reconstruction agent loads an operation sequence recorder, an interface state difference comparison algorithm, and an executable script generation template (compatible with the script syntax of mainstream automated testing frameworks). Each sub-agent enters a standby state after loading, awaiting task assignment instructions from the main agent.

[0035] Meanwhile, the system constructs a global state sharing space based on the blackboard model. This blackboard model is a distributed shared memory mechanism that allows different agents to achieve implicit communication and information synchronization by reading and writing to a common data area. The system divides the blackboard space into three core functional areas: the global state area stores global information for the current test, including the Uniform Resource Locator (URL) or page identifier set for all accessed pages, a snapshot of the status of all currently active devices, the cumulative global code coverage value, and the test completion status of each business module; the task scheduling area stores detailed information for all currently pending and in-process tasks, including the sub-agent identifier to which each task belongs, task priority, execution start and end timestamps, and the current execution progress percentage; and the anomaly event area stores detailed records of all detected anomalies, including anomaly type code, occurrence time, severity level, associated operation sequence identifier, and a status flag indicating whether it has been processed by the root cause analysis agent. After completing the region division, the system registers each professional sub-agent to the global state sharing space one by one. During the registration process, the system grants differentiated data read and write permissions to each sub-agent: all sub-agents have read permissions to the global state area, but only the interface exploration agent has write permissions to the page access records in the global state area; write permissions to the task scheduling area are only granted to the global master agent, and sub-agents can only read the task parameters related to themselves in this area and update the task progress; write permissions to the abnormal event area are granted to the anomaly detection agent and the root cause analysis agent, while read permissions are open to all sub-agents so that they can perceive the current health status of the system.

[0036] Finally, the system establishes an event bus mechanism, a message middleware based on a publish-subscribe pattern that supports asynchronous and decoupled event delivery. The system configures the collaborative communication mechanism between the global master agent and various specialized sub-agents through the event bus: the master agent, as the publisher of task instructions, sends control commands such as task start, task pause, policy adjustment, and emergency interruption to specific sub-agents or all sub-agents via the event bus; each sub-agent, as the consumer of events, subscribes to event types relevant to its responsibilities, and simultaneously acts as the producer of events, publishing events such as state changes, progress updates, and anomaly detection to the event bus during execution. The event bus internally maintains an event type routing table to ensure that each type of event is only received by agents that have subscribed to that event type, avoiding message overload. Through the above mechanism, the master agent can publish a policy adjustment event to the event bus at any time, such as "Memory pressure is increasing, increase the testing intensity of this page." The stress testing agent, having subscribed to the policy adjustment event, receives this instruction and dynamically increases the frequency of concurrent operations. When the anomaly detection agent detects an anomaly, it publishes an anomaly event. The master agent and the root cause analysis agent, having subscribed to the anomaly event, synchronously receive this message and initiate their respective response processes. The blackboard model is responsible for the static storage and sharing of data, while the event bus is responsible for the real-time transmission of dynamic messages. Together, they constitute a complete communication infrastructure between agents that is both real-time and decoupled.

[0037] This embodiment constructs a global master agent and loads the BDI cognitive model (Belief-Desire-Intention, or BDI for short). The belief layer caches states, the desire layer sets goals, and the intention layer manages task queues and contract network protocols, achieving hierarchical decision-making and task scheduling. Simultaneously, five specialized sub-agents are constructed and their corresponding decision models are loaded. A shared space based on a blackboard model is established, dividing the space into three zones: state, scheduling, and events. An event bus is configured to enable collaborative communication between agents. This architecture endows the system with hierarchical cognitive decision-making capabilities and an efficient parallel collaboration mechanism, enabling agents to achieve real-time information exchange and flexible task scheduling through a shared space and asynchronous events.

[0038] In healthcare app testing, after the global main agent loads the BDI model, the belief layer can store key indicators such as the memory status of the patient's consultation page and the depth of the image loading queue in real time. The wish layer sets "full coverage of the consultation process and an image rendering frame rate of no less than 30fps" as the test target. The intent layer assigns the task of exploring the registration-consultation-report viewing path to the interface exploration agent through the contract network protocol, and assigns the stress test task of 1,000 concurrent consultations during peak hours to the stress test agent. The blackboard model's state area records the access progress of each page, the task scheduling area tracks the execution status of the consultation and image sub-tasks, the abnormal event area collects real-time alarms such as memory leaks and rendering stutters, and the event bus ensures that the anomaly detection agent immediately notifies the root cause analysis agent and the main agent after capturing image loading delays. The main agent then schedules the scene reconstruction agent to capture the operation context, realizing multi-task collaborative diagnosis in the medical scenario.

[0039] In fintech app testing, the global main agent's belief layer continuously caches key data such as transaction interface response time and distributed transaction status. The wish layer sets "full coverage of the transaction chain and a payment interface success rate of no less than 99.99%" as its core objectives. The intent layer uses the contract network protocol to tender and assign sub-tasks such as account opening and card binding, fund transfer and payment, and wealth management subscription to the corresponding interface exploration agents. At the same time, it assigns extreme load tasks such as tens of thousands of concurrent purchases to the stress test agents. The blackboard model's state area records the progress of transaction chain coverage, the task scheduling area coordinates the concurrent execution of the payment and market data task flows, the abnormal event area captures alarms such as transaction timeouts and data inconsistencies in real time, and the event bus ensures that when the anomaly detection agent detects that the transaction delay exceeds the dynamic threshold, it immediately notifies the root cause analysis agent. The main agent simultaneously suspends non-critical tasks and schedules the scenario reconstruction agent to capture the scene, ensuring the real-time response to anomalies and the integrity of transaction verification in financial scenarios.

[0040] In one embodiment, when the interface exploration agent receives the task parameters, the parallel execution of the atomic subtasks corresponding to the task parameters includes: The interface exploration agent obtains a screenshot of the current interface and the UI hierarchy tree; The interface visual features are extracted from the screenshots, the component types, positions and interactivity information of the current page are extracted from the UI hierarchy tree, the system resource usage values ​​are read, and the accessed page path records are read from the global state shared space. The state vector is generated by concatenating the interface visual features, component information, system resource usage values, and accessed page path records. The state vector is input into the decision network of a preset reinforcement learning model, and the value evaluation results of each candidate operation in the operation action space are output. Based on the value assessment results, select the type of operation to be executed and its accompanying parameters, and send the operation to be executed to the target device for execution; After execution, the interface exploration agent obtains the new interface state, the new UI hierarchy tree, and the updated system resources. Determine whether the page corresponding to the new interface state is an unvisited new page, determine whether there are any uninterrupted new components in the new UI hierarchy tree, and determine whether the system resource update value shows an abnormal trend. The total reward value for this operation is calculated based on the page access judgment results, new component judgment results, and abnormal change trend judgment results. The experience quadruple, consisting of the state vector, the selected operation and related parameters, the total reward value, the new interface state after execution, and the system resource update value, is stored in the experience replay pool. Every preset training cycle, a batch of experience quadruples are sampled from the experience replay pool to incrementally train the decision network of the reinforcement learning model, update the network parameters, and synchronize the updated network parameters to the global state sharing space.

[0041] In this embodiment, the workflow of the interface exploration agent runs continuously in a loop during test execution. Its core objective is to autonomously explore the App's interface space through reinforcement learning, maximizing code coverage and anomaly detection rate. In each decision iteration, the interface exploration agent first obtains a complete screenshot of the current interface and the UI hierarchy tree through the test access layer. The screenshot is a raw image capture of the current screen pixels, while the UI hierarchy tree is a tree structure of interface elements described in Extensible Markup Language (XML) or a similar structured format. It includes the type of all user interface (UI) components on the current screen (such as buttons, text boxes, list items, image views, etc.), their position and size in the screen coordinate system, visibility status, and whether they are interactive (such as clickable, long-pressable, or swipeable). The test access layer obtains the above data through a lightweight proxy service running on the target device and sends it back to the data preprocessing module of the interface exploration agent through a communication channel.

[0042] After acquiring the screenshot and UI hierarchy tree, the interface exploration agent initiates a multi-source feature fusion process. First, the screenshot is input into a pre-trained convolutional neural network. This network, trained offline on a large number of interface images, can compress and encode high-dimensional pixel input into a fixed-length feature vector. This vector abstractly expresses visual semantic information such as the visual layout, color distribution, and spatial arrangement of controls in the current interface. Simultaneously, the agent parses and extracts the type codes, position coordinates (including the coordinates of the top-left and bottom-right corners or the center point), and interactivity flags of all UI components on the current page from the UI hierarchy tree. This discrete structured information is converted into a continuous vector representation through an embedding layer and then horizontally concatenated with the visual feature vector. Building upon this foundation, the agent further reads system resource usage values ​​reported by the test access layer at the same time, including current memory usage (in megabytes), CPU utilization percentage, frame rate (frames per second), and network latency, among other key indicators. These values ​​are normalized and appended to the end of the feature vector. Simultaneously, the agent reads the visited page path records from the global state area in the global state sharing space. This record is a cumulative set of page identifiers and statistics on the number of times each page has been accessed, representing the exploration history of the current test. Finally, the agent concatenates all the above information—interface visual features, component structured encoding, system resource values, and visited path records—into a unified multi-dimensional state vector according to a preset feature dimension order. This vector fully describes the current environmental situation, encompassing both the app's external interface performance and its internal system operating state and historical exploration progress.

[0043] The state vector is then fed into the decision network of the reinforcement learning model. This decision network employs an actor-critic architecture, where the actor network outputs a policy distribution based on the current state, assigning a selection probability to each candidate action in the action space; the critic network evaluates the value of the current state or the advantage function of each action. The action space predefines twelve basic action types, including tap, long press, double tap, swipe up, swipe down, swipe left, swipe right, pinch-to-zoom, text input, back button, home button, and multitasking button. The text input action includes preset test text parameters, the swipe action includes swipe distance and speed parameters, and the tap and long press actions include target coordinate parameters. The actor network calculates the value evaluation result of each candidate action and its reasonable parameter combination based on the current state vector, typically quantifying the expected cumulative benefit of each action in the current environment as an advantage value or Q-value. Based on these value assessments, and combined with an exploration-utilization balance strategy (such as an ε-greedy strategy or an exploration mechanism based on policy entropy), the agent selects a specific operation type and its associated parameters from the action space. Once selected, the agent sends the operation instruction (e.g., "perform a click operation at coordinates (350, 720)") to the test access layer. The test access layer converts this instruction into a low-level input event recognizable by the target device's operating system (such as an injection event in Android or a touch event in iOS), sends it to the target device via a remote control protocol, and executes it, simulating the touch interaction behavior of a real user.

[0044] After the operation is completed, the App interface and system state on the target device change accordingly. The interface exploration agent obtains a screenshot of the new interface and the new UI hierarchy tree again through the test access layer, as well as the updated system resource values ​​(including the latest memory, CPU, frame rate, etc.). At this point, the agent enters the reward calculation phase to quantify the utility brought by this operation. First, the agent compares the page identifier corresponding to the new interface state with the historical page set in the visited page path record to determine whether the page is a completely new page that has never been visited before—if so, a high new page reward is triggered. Second, the agent traverses all components in the new UI hierarchy tree, comparing them one by one with the historically interacted component records to identify whether there are any new components that have never been clicked, swiped, or entered before—if so, a medium-sized new component reward is given. Next, the agent compares the updated system resource values ​​after execution with the system resource values ​​before execution and analyzes their trends. For example, it determines whether there is an abnormally significant increase in memory usage, an unreasonable decrease in frame rate, or an abnormal spike in CPU usage. If any abnormal trend is detected (even if it has not reached the severity threshold for triggering an anomaly), different levels of anomaly detection rewards are given based on the severity of the anomaly, with the highest reward being equivalent to that of a formal anomaly. Furthermore, the reward function includes a code coverage reward, meaning that if the operation improves the global code coverage metric, a corresponding reward is given; and a repetitive operation penalty, meaning that if the operation repeatedly visits a page that has been visited multiple times or repeatedly executes the same component interaction, a negative penalty is applied. Finally, the agent calculates the total reward value for this operation according to a preset weighted summation formula: Total Reward = New Page Reward Weight multiplied by New Page Judgment Result + New Component Reward Weight multiplied by New Component Judgment Result + Anomaly Detection Reward Weight multiplied by Anomaly Trend Judgment Result + Code Coverage Reward Increment - Repetitive Operation Penalty Weight multiplied by Repetition Degree Coefficient. This multi-objective reward function is designed to guide the agent to strike a balance between exploring unknown interfaces, discovering potential anomalies, and improving coverage, while suppressing ineffective repetitive operations.

[0045] After calculating the total reward, the interface exploration agent encapsulates all the data generated in the current iteration into an experience quadruple. This quadruple contains four core elements: the initial state vector (i.e., the state before the operation), the selected action and its parameters, the total reward value obtained, and the new interface state and system resource update value after execution (as a description of the next state). This experience quadruple is appended to the experience replay pool. The experience replay pool is a first-in, first-out buffer queue with a fixed maximum capacity, used to store historical interaction experiences from the most recent time steps. After the storage operation is completed, the current decision loop ends, and the interface exploration agent uses the new interface state as the current state for the next loop, continuing the above process to achieve continuous interface traversal exploration. In the long-term operation, the interface exploration agent triggers an incremental model training process every preset training cycle (e.g., after executing a certain number of operation steps, or at fixed time intervals). In this process, the agent randomly samples a batch (i.e., mini-batch) of experience quadruples from the experience replay pool and updates the gradients of the actor-critic network using a pruning variant of the proximal policy optimization algorithm (PPO-Clip). During training, the critic network learns to predict more accurate value estimates based on the state, while the actor network adjusts its policy parameters based on the advantage estimate and the pruning loss function, making the policy evolve towards higher cumulative rewards, while limiting the magnitude of each update to avoid instability caused by policy mutations. After incremental training is completed, the interface exploration agent serializes the updated network parameters (including the weight matrices and bias terms of the actor and critic networks) and synchronizes them to the predefined model parameter storage area in the global state sharing space through the write interface, so that the global master agent and other sub-agents that need them can read the latest model parameters at any time.

[0046] Furthermore, the stress testing agent runs independently and in parallel with the interface exploration agent during test execution. Its core function is to simulate scenarios of simultaneous multi-user operation and extreme load conditions in the real world to verify whether the App under test exhibits stability issues such as resource contention, deadlock, response timeout, or crashes under high pressure. During the initialization phase, the stress testing agent receives task parameters from the global main agent. These parameters include the target range of concurrent users, upper and lower limits of operation frequency, a list of key business modules to be stressed, and trigger rules for various extreme environmental conditions. During test execution, the agent does not rely on reinforcement learning models for autonomous decision-making but follows the strategy configuration dynamically issued by the main agent based on the real-time system status, executing stress injection tasks in a controllable load generation mode. At the concurrent user simulation level, the stress testing agent creates multiple virtual user instances through a thread pool or multi-process simulator. Each virtual user independently executes a preset operation sequence template. These templates are not fixed but dynamically generated based on high-risk business modules (such as payment settlement, order submission, login authentication, data synchronization, etc.) marked in the App's functional knowledge graph. Each template contains key operation steps for the complete process of that business module. The operation frequency of virtual users is controlled by a rate regulator within the intelligent agent. This regulator can dynamically switch between normal and high-pressure loads based on the strategy commands issued in real time by the main agent through the event bus—for example, operating at a frequency of several operations per second during normal periods, and increasing to tens or even hundreds of concurrent operations during peak pressure periods. This dynamic adjustment capability allows the stress testing agent to form a closed loop with the monitoring results of the anomaly detection agent: when the anomaly detection agent detects that the system resource usage is at a safe level, the main agent may instruct the stress testing agent to gradually increase the concurrency intensity to explore the system limits; when resource indicators approach the warning threshold, the main agent instructs it to appropriately reduce the load to avoid the app becoming completely unusable due to excessive stress.

[0047] Simulating resource contention is another core capability of this intelligent agent. Besides simulating multi-user parallel operations, the stress testing agent proactively constructs resource contention scenarios, causing multiple virtual users to initiate concurrent access requests to the same shared resource at similar times. Specifically, the agent maintains a resource contention scheduler that identifies shared resource dependencies marked in the App's functional knowledge graph—such as database connection pools shared by multiple pages, global cache areas, file system locks, or network request channels. Based on these dependencies, the scheduler aligns the operation sequences of multiple virtual users, causing them to trigger a sequence of operations involving the same shared resource intensively within a preset time window. Taking an e-commerce scenario as an example, the stress testing agent can have dozens of virtual users submit orders almost simultaneously, triggering database write lock contention and atomicity verification of inventory deduction; or it can have multiple virtual users frequently refresh and add items to their carts on the same product details page, inducing network request queue congestion and thread blocking in the session state, thereby exposing concurrency defects at the business logic level under high concurrency—such as overselling, infinite waiting due to deadlocks, or memory accumulation caused by resource leaks. Injecting extreme environmental conditions is also an important responsibility of the stress testing agent. This agent, in collaboration with the environment simulation module in the test access layer, can dynamically change the external condition parameters of the target device, including network bandwidth limits, battery percentage drops, memory warning signal injection, and CPU frequency limits. These changes in environmental conditions are usually superimposed on concurrent operations—for example, maintaining a high intensity of concurrent request injection while simulating a weak network environment, in order to test the stability of the App under network timeout and retry mechanisms.

[0048] At the collaborative execution level, the stress testing agent and the interface exploration agent share the same device operating environment. Their combined operation sequences create a realistic mixed load scenario. The exploratory operations performed by the interface exploration agent provide a dynamically changing interface context for stress testing—when the interface exploration agent navigates to a new high-risk page, the stress testing agent can automatically identify the corresponding business module type and dynamically adjust its virtual user's operation template, shifting the stress focus to the relevant business processes on the new page. Simultaneously, the high-intensity concurrent requests generated by the stress testing agent keep the system environment in which the interface exploration agent operates under constant high-pressure fluctuations. The operation execution and reward feedback of the interface exploration agent under this environment naturally incorporate the influence of stress factors—for example, performing a page jump operation when memory is low, if it causes a significant drop in frame rate or triggers a memory warning, will give a higher positive incentive to the abnormal trend item in the reward value of that operation, thus guiding the reinforcement learning model to explore paths that expose stability problems under high load. Both reinforce each other, jointly verifying the overall stability of the app in real-world complex scenarios. During operation, the stress testing agent continuously writes its generated concurrent operation logs, resource contention trigger records, environmental condition change events, and success rate statistics for each virtual user into the task scheduling area of ​​the global state sharing space, which is available for real-time reading by the global master agent and the anomaly detection agent. When the anomaly detection agent triggers an anomaly event due to abnormal system metrics, the master agent, upon receiving the event, comprehensively judges the nature of the anomaly based on the current operational intensity and concurrency configuration of the stress testing agent. If the anomaly occurs at a time when the concurrent operation intensity is at a historical peak and the resource contention scheduler has just triggered a dense lock contention window, the master agent tends to attribute the anomaly to a resource contention problem induced by high load. Conversely, if the anomaly occurs in a time window with low concurrency intensity, the master agent believes that the anomaly is more likely due to a defect in the function itself and is unrelated to the load. This ability to differentiate allows subsequent root cause analysis to select different diagnostic focuses based on the load context in which the anomaly occurs, significantly improving the accuracy and efficiency of root cause localization.

[0049] This embodiment uses an interface exploration agent to acquire screenshots and UI hierarchy trees, extracts visual and component features, and combines them with system resources and access history to form a state vector. This vector is then input into a reinforcement learning decision network to evaluate the value of actions and execute them. Multi-objective rewards are calculated based on new pages, new components, and abnormal trends. Experience is stored in a replay pool and the network is periodically incrementally trained. This enables the interface exploration agent to possess goal-oriented autonomous learning capabilities, with code coverage exceeding 85%, and continuous self-optimization as testing progresses.

[0050] In testing healthcare apps, the interface exploration agent acquires screenshots of the online consultation homepage and the UI hierarchy tree. It extracts visual layout features such as department entrances and report lists from the screenshots, and parses the location information of consultation forms, image viewing buttons, and interactive components from the hierarchy tree. Simultaneously, it reads memory usage and visited page records, concatenating these into a state vector input to a reinforcement learning network. The decision network evaluates the expected benefits of each operation, such as entering an online consultation, viewing image reports, and filling out health records, prioritizing actions that cover new functional paths. After execution, it determines whether a new page has been entered, whether new interactive components have been discovered, and whether there has been abnormal memory usage. Higher rewards are given to new pages, guiding the model to focus on exploring the entire consultation process and image browsing link, ensuring the test covers the core paths of real-world user healthcare scenarios.

[0051] In fintech app testing, the interface exploration agent obtains screenshots of the transaction homepage and the UI hierarchy tree. It then extracts visual layout elements such as the transfer entry and wealth management product list from the screenshots. From the hierarchy tree, it analyzes the location and interactivity of input boxes, confirmation buttons, and payment components. Simultaneously, it reads CPU usage and visited transaction paths to generate a complete state vector. The decision network evaluates the expected returns of each operation, such as fund transfers, wealth management subscriptions, and bill inquiries, prioritizing high-risk paths involving fund flows. After execution, reward signals such as new pages and abnormal trends guide the agent to repeatedly explore key steps like payment password input and transaction confirmation. High rewards are given when memory usage is abnormal, effectively improving the coverage depth and anomaly detection probability across the entire financial transaction chain.

[0052] In one embodiment, S400 includes: S401. The anomaly detection agent receives system resource indicators and performance indicators of the App under test at a preset fixed sampling interval according to the task parameters. S402. Combine the system resource indicators and performance indicators at each sampling time to generate time-series data points, and store the time-series data points in a circular buffer queue. S403. The anomaly detection agent performs mutation detection analysis and trend detection analysis on the time-series data in the circular buffer queue to obtain mutation detection results and trend detection results. S404. Compare the mutation detection results and trend detection results with the preset dynamic thresholds of the corresponding indicators; S405. When the mutation detection result and / or trend detection result exceed the dynamic threshold, the anomaly detection agent generates an anomaly event message. S406. The abnormal event message is published to the global main agent and the root cause analysis agent through the event bus.

[0053] In this embodiment, as Figure 3As shown, the anomaly detection agent, based on task parameters (including sampling frequency, key indicator types, and initial dynamic threshold values ​​for each indicator) issued by the global main agent, actively receives real-time system resource and performance indicators reported by the app under test during its operation through the test access layer at a preset fixed sampling interval. System resource indicators cover the current process's memory usage (including heap memory and local memory), CPU utilization, number of active threads, and input / output operation frequency; performance indicators include UI rendering frame rate, main thread message queue waiting time, network request response latency, and disk read / write speed. The test access layer collects this raw data on the app side using a non-intrusive Software Development Kit (SDK), and after preliminary format standardization and unit standardization, reports it to the anomaly detection agent's data receiving port through the inter-process communication channel.

[0054] After receiving multi-dimensional indicator data at each sampling moment, the anomaly detection agent first aligns and combines these system resource and performance indicators from different dimensions according to a unified timestamp, generating a structured time-series data point. This data point contains the instantaneous values ​​of all monitored indicators at the same moment, forming a multi-dimensional vector. Subsequently, the agent appends this time-series data point to a circular buffer queue in chronological order. This circular buffer queue is a fixed-length First-In-First-Out (FIFO) storage structure, with its length preset to accommodate all sampling data points within the most recent few minutes. When the queue is full, the oldest historical data point is overwritten by the newly arrived data point. This design ensures that the agent can always access the latest time-series window data for trend analysis while effectively controlling memory usage and avoiding infinitely growing data storage overhead.

[0055] After data storage is completed, the anomaly detection agent performs two types of parallel analysis operations on the time-series data in the circular buffer queue. The first type is mutation detection analysis, where the agent compares the value of the indicator at the latest sampling moment with the mean of the previous moment or a previous short time window, and calculates its standard deviation multiple to identify whether the system indicator has undergone a drastic change in a very short period of time—for example, memory usage suddenly surges by tens of megabytes within hundreds of milliseconds, or the frame rate drops precipitously from a stable value. Such mutations often correspond to explicit, immediate abnormal events. The second type is trend detection analysis, where the agent performs sliding regression or exponentially weighted moving average calculations on the indicator sequence in the queue over a longer time window (e.g., the past 30 seconds to one minute) to extract the slope direction and magnitude of the indicator changes, thereby identifying those abnormal trends that change slowly but accumulate continuously—for example, memory usage continuously increases linearly at a fixed rate without falling back within tens of seconds, or the frame rate shows a gradual degradation that slowly decreases second by second. Such trends often correspond to implicit stability problems such as memory leaks or gradual resource exhaustion. The two detection algorithms complement each other, ensuring that they can capture both instantaneous catastrophic anomalies and slowly escalating hidden dangers.

[0056] After completing the mutation detection and trend detection calculations in each sampling cycle, the anomaly detection agent compares the two types of detection results with the adaptive dynamic thresholds of the corresponding indicators. These adaptive dynamic thresholds are not fixed values ​​but are calculated in real-time based on the statistical characteristics of historical data in the circular buffer queue. For example, the average of the indicator over a relatively long time window is used as a benchmark, with the standard deviation added or subtracted as upper and lower warning lines, or a dynamic interval estimation method based on historical quantiles is used. This means that the thresholds will adaptively adjust according to the App's operating status, maintaining reasonable sensitivity within the normal system operating range. When the overall system load generally increases, the thresholds are appropriately relaxed to avoid frequent false alarms due to environmental fluctuations. When the indicator shows abnormal deviations beyond the normal fluctuation range, the threshold mechanism ensures that an alarm is triggered. During the above comparison process, if either the mutation detection result (such as a sudden drop in the current frame rate exceeding the maximum allowable drop limit of the dynamic threshold) or the trend detection result (such as the memory growth slope exceeding the maximum allowable growth rate limit of the dynamic threshold in the past 30 seconds) exceeds the dynamic threshold range of the corresponding indicator, the anomaly detection agent immediately determines that the current system is in an abnormal state and generates a structured abnormal event message. The message includes an anomaly type code (used to distinguish between sudden anomalies and trend anomalies), the specific indicator name that exceeds the threshold and its current value, the threshold boundary, the timestamp of the time the anomaly occurred, and the index position pointing to the relevant data segment in the circular buffer queue.

[0057] After an anomaly event message is generated, the anomaly detection agent does not perform any root cause analysis or intervention on its own. Instead, it uses the message as an event payload and asynchronously publishes it to the global master agent and the root cause analysis agent via an event bus mechanism. The event bus uses a publish-subscribe model, ensuring that once a message is published, all agents subscribed to that anomaly event type will receive a copy of the message almost simultaneously. Upon receiving the anomaly event message, the global master agent uses it as a trigger signal to initiate real-time adjustments to the testing strategy—for example, increasing the testing priority of the anomaly occurrence area and pausing low-value tasks to free up resources for in-depth diagnostics. The root cause analysis agent, upon receiving the same message, uses it as a start signal to prepare to receive the context data packets subsequently captured by the scenario reconstruction agent and enter the root cause localization process. Through this parallel notification mechanism, the system's anomaly response and regular test execution are decoupled. The anomaly detection agent resumes its continuous monitoring and sampling responsibilities immediately after publishing the event, without affecting subsequent indicator data collection, thus ensuring the continuity and real-time performance of the entire anomaly monitoring loop.

[0058] This embodiment uses an anomaly detection agent to collect system resource and performance indicators at fixed sampling intervals, combines them into time-series data points, stores them in a circular buffer queue, and performs mutation detection and trend detection on them. The detection results are compared with adaptive dynamic thresholds. When the threshold is exceeded, an anomaly event is generated and published to the main agent and the root cause analysis agent through an event bus. This achieves millisecond-level real-time anomaly perception, can simultaneously capture sudden crashes and progressive memory leaks, and realizes instantaneous parallel distribution of anomaly information through the event bus.

[0059] In testing of healthcare apps, an anomaly detection agent continuously collects metrics such as memory usage, CPU utilization, frame rate, and network latency at 100ms intervals. The multi-dimensional metrics at each sampling moment are combined into time-series data points and stored in a circular buffer queue. For online consultation and image viewing scenarios, the agent performs trend detection on the frame rate sequence over the past 30 seconds in the queue. When continuously scrolling through images, the frame rate shows a gradual decreasing trend. Simultaneously, abrupt change detection captures a sudden increase in memory usage exceeding a dynamic threshold after a single image loading. The system immediately generates an event message containing the anomaly type and the time of occurrence, which is simultaneously published to the main agent and the root cause analysis agent via the event bus. Based on this, the main agent suspends non-critical exploration tasks and prioritizes scheduling the scenario reconstruction agent to capture the complete operational context before and after image loading. This allows the root cause analysis agent to promptly locate unreleased bitmap cache objects, effectively preventing consultation interruptions due to image resource leaks.

[0060] In fintech app testing, an anomaly detection agent continuously collects key metrics such as transaction interface response time, active database connection pool count, memory usage, and GC frequency with millisecond-level precision. These metrics are combined into time-series data points and stored in a circular buffer queue. For flash sale scenarios, the agent performs abrupt change detection on the transaction response time series over the past 60 seconds. When it detects an interface latency jump from an average of 200ms to 3000ms, exceeding the dynamic threshold, and trend analysis reveals that memory usage is linearly increasing at a rate of 5% every 5 seconds for 30 seconds during the promotional event, the system immediately generates an anomaly event message and publishes it synchronously via the event bus. Upon receiving this message, the main agent immediately suspends low-priority tasks such as transfer verification. The root cause analysis agent, combining the time-series evidence in the queue, quickly locates the database connection pool exhaustion and large object non-reclaiming issues caused by cache breach, ensuring that anomalies in the fund transaction chain are detected and responded to within seconds.

[0061] In one embodiment, S600 includes: S601, The root cause analysis agent extracts an abnormal feature set from the context data packet; S602. Perform similarity matching between the abnormal feature set and historical cases in the historical abnormal pattern knowledge graph to obtain the root cause prior probability distribution associated with historical cases whose matching degree exceeds a preset matching threshold. S603. Map each feature value in the abnormal feature set to the corresponding intermediate node and phenomenon node in the pre-constructed abnormal cause-effect graph; S604. Based on the root cause prior probability distribution, intermediate nodes, phenomenon nodes, and directed edge weights and conditional probability tables of the abnormal cause-effect graph, the posterior confidence of each cause node in the abnormal cause-effect graph is calculated using a Bayesian network inference algorithm. S605. The root cause analysis agent selects multiple candidate cause nodes based on the screening strategy and posterior confidence. S606. Perform counterfactual deduction on each candidate cause node. If the probability of occurrence of the phenomenon node decreases by more than the judgment threshold, then the candidate cause node is confirmed as a valid root cause. S607. Generate a root cause analysis report based on the effective root causes and the corresponding evidence paths.

[0062] In this embodiment, as Figure 4As shown, the root cause analysis agent is fully responsible for performing deep diagnostics on the captured context data packets. First, the root cause analysis agent extracts a structured set of abnormal features from the context data packets provided by the scene reconstruction agent. This context data packet contains all the key information within a time window, such as the period from 30 seconds before the anomaly to 10 seconds after it occurs. From this, the root cause analysis agent systematically extracts feature data in four dimensions: system indicator features—including the change trajectory of indicators such as memory usage, CPU utilization, and frame rate within this time window, such as quantitative indicators like memory growth rate (in megabytes per second) and frame rate decline slope; operation features—the complete user operation sequence before the anomaly occurs, including the type of each operation, the target component identifier, and the time interval between operations; code features—the call stack information, thread state, and hash signature of the code execution path captured by the system when the anomaly occurs; and business features—the identifier of the current business scenario (such as the payment page or order list page), page routing parameters, and active user session data. These features together constitute a multi-dimensional high-dimensional feature vector, serving as the input basis for all subsequent analysis steps.

[0063] After feature extraction, the root cause analysis agent initiates a similarity matching process based on historical experience. The agent calculates the similarity between the extracted set of abnormal features and each historical case in a pre-loaded historical anomaly pattern knowledge graph in the global knowledge base. Each case in the historical anomaly pattern knowledge graph contains anomaly feature vectors recorded in past tests of similar apps, confirmed root cause types, and their frequency statistics. The similarity calculation uses a multi-dimensional weighted distance algorithm, calculating sub-similarity for system indicator features, operational features, code features, and business features, and then summing the results with weights. The call stack similarity within the code features is given the highest weight because stack information is usually the strongest criterion for distinguishing different anomaly types. The agent filters out all historical cases with similarity exceeding a preset matching threshold and extracts their respective associated root cause types and their prior probability distributions from these high-matching cases—that is, the baseline frequency of each root cause (such as memory leak, thread deadlock, interface timeout, or resource contention) in historical tests of that type of app. This prior probability distribution reflects the general tendency of various anomalies in long-term historical experience, providing initial beliefs for subsequent Bayesian inference.

[0064] While acquiring the prior probability distribution, the root cause analysis agent maps each feature value in the set of abnormal features to the corresponding intermediate nodes and phenomenon nodes in a pre-constructed anomaly causal graph. This anomaly causal graph is a directed acyclic graph, pre-constructed based on a large amount of historical anomaly data and domain expert experience. The graph contains three types of nodes: causal nodes (such as fundamental defects like memory leaks, thread deadlocks, interface timeouts, and resource contention), intermediate nodes (such as transitional states like objects failing to be garbage collected, main thread message queue blocking, and heap memory availability falling below the safe level), and phenomenon nodes (such as directly observable anomalies like application crashes, application unresponsiveness, sudden frame rate drops, and continuous memory spikes). Directed edges point from causal nodes to intermediate nodes, from intermediate nodes to phenomenon nodes, and directly from causal nodes to phenomenon nodes. Each edge is assigned a weight representing the strength of the causal relationship. Each node is also associated with a conditional probability table to quantify the conditional probability of the node being in each state given the state of its parent node. The mapping process is as follows: The system metric characteristic "memory growth rate exceeding 5 megabytes per second" is mapped to the intermediate node "continuous reduction of available heap memory space" in the causal graph; the "frame rate dropping from 60 frames per second to below 20 frames per second" is mapped to the intermediate node "interface rendering pipeline blockage"; the "memory allocation failure exception" appearing in the call stack is mapped to the phenomenon node "memory overflow error"; and the operation sequence "repeatedly entering and exiting the same deep page" is mapped to the resource reference node associated with that page. Through this mapping, abstract anomaly characteristics are transformed into state observation evidence of specific nodes in the causal graph.

[0065] After feature mapping is completed, the root cause analysis agent initiates the Bayesian network inference process. Bayesian network inference is an uncertain reasoning method based on a probabilistic graphical model. It can calculate the posterior confidence of other unobserved nodes (i.e., cause nodes) given the known states of some nodes (i.e., observed phenomenon nodes and intermediate nodes)—that is, the conditional probability of each potential root cause being true given observed evidence. Specifically, the agent uses the prior probability distribution of root causes obtained from historical cases as the initial prior probability of cause nodes in the Bayesian network, and inputs the states of intermediate and phenomenon nodes obtained from anomaly feature mapping as observed evidence into the network. Then, based on the directed connections of each edge in the anomaly causal graph, the weights attached to each edge, and the conditional probability table of each node, it uses Bayes' theorem and the chain rule to perform probability propagation calculations throughout the entire network. The calculation process traverses all cause nodes in the causal graph. For each cause node, the algorithm comprehensively considers its prior probability, all observed evidence of causal path associations with it, and the strength coefficient of each causal relationship along the path. Finally, it outputs the posterior confidence of each cause node—that is, the probability estimate that the cause is the true root cause given the currently observed combination of anomalous features. For example, after calculation, the posterior confidence of the cause node memory leak might reach 85%, thread deadlock 10%, and interface timeout 5%.

[0066] After obtaining the posterior confidence scores of all causal nodes, the root cause analysis agent selects multiple candidate causal nodes according to a pre-defined screening strategy. This strategy typically involves selecting the top three causal nodes with the highest posterior confidence scores as the candidate set, while also requiring that the posterior confidence scores of these candidate nodes exceed a certain absolute threshold to ensure statistical reliability. This mechanism ensures that computational resources in the subsequent deep validation phase are concentrated on the few most probable root causes, avoiding the efficiency degradation caused by exhaustively listing all possibilities. After selecting candidate causal nodes, the agent independently performs counterfactual inference verification for each candidate node. Counterfactual inference is a hypothetical reasoning technique based on a causal model that asks "what if things were different?" Its core operation is to forcibly change the state of the candidate causal node in the causal graph from "occurred" to "not occurred" (i.e., assuming the defect was fixed), and then rerun the Bayesian network inference while keeping all other node states and conditional probability relationships unchanged, calculating the probability of occurrence of each phenomenon node under this intervention condition. Subsequently, the agent compares the probability of the phenomenon obtained through counterfactual reasoning with the actual probability of the phenomenon observed in the original study, calculating the decrease magnitude—that is, the degree to which the observed anomaly can be eliminated if the root cause is assumed to be absent. If the decrease magnitude exceeds a preset judgment threshold (e.g., set at 50%), the candidate cause node is identified as a valid root cause of the anomaly, because this means that removing the cause has a very high probability of eliminating the anomaly, establishing a sufficient causal relationship between the two. Conversely, if the decrease magnitude is below the threshold, the candidate cause is judged as a spurious association with insufficient relevance and is excluded. Through this verification step based on causal intervention, the valid root cause ultimately confirmed by the system has the dual support of statistical correlation and causal necessity.

[0067] After completing the counterfactual inference verification, the root cause analysis agent generates a structured root cause analysis report for all confirmed valid root causes and their corresponding evidence paths. The report includes a description of the anomaly and its severity assessment, a ranking of the posterior confidence scores of each candidate cause calculated using Bayesian inference, a final list of valid root causes confirmed by counterfactual inference, a complete causal evidence chain from observed features to intermediate states to the root cause (presented as a graphical directed path, such as "memory allocation stack shows bitmap object not being garbage collected → object reference chain points to image cache manager → image cache manager did not call cleanup method when page is destroyed → determined to be a memory leak"), and specific code modification suggestions based on the remediation solution field in the historical anomaly pattern knowledge graph. This report not only records "what caused the anomaly," but more importantly, it demonstrates "why this is the cause" through the evidence chain, enabling developers to directly understand the essence of the problem without relying on personal experience. After the report is generated, the root cause analysis agent synchronizes the report content to the anomaly event area in the global state sharing space. Simultaneously, it notifies the global master agent via the event bus that the root cause analysis is complete. The master agent then decides, based on the report content, whether to adjust the testing strategy (e.g., generate a specific verification task for the confirmed root cause) or output the final diagnostic results to the user. The entire root cause analysis process, from anomaly triggering to report output, demonstrates a level of automation and inference depth that surpasses the limitations of traditional tools that only provide stack trace information, reducing the average diagnostic time from the industry standard of several hours to minutes.

[0068] This embodiment extracts anomalous features from contextual data packets through a root cause analysis agent, matches them with a historical anomalous pattern knowledge graph to obtain prior probabilities, maps these features to an anomalous causal graph, and combines prior, observational evidence, and causal graph structure parameters. Bayesian network inference is then used to calculate the posterior confidence of each causal node. Candidate nodes are selected according to a screening strategy, and counterfactual inference verification is performed. After confirming a valid root cause, an analysis report containing a chain of evidence is generated. This mechanism reduces root cause localization time from 24 hours to within 30 minutes, achieving dual verification of statistical association and causal necessity.

[0069] In testing of healthcare apps, when the anomaly detection agent detected a continuous increase in memory usage during image viewing, ultimately triggering a crash, the root cause analysis agent extracted a set of features from the context data packet, including the memory growth rate (approximately 8MB / s), image decoding methods in the call stack, operation sequences (repeatedly entering and exiting the image browsing page), and the current business scenario (reading room). These features were then matched with historical cases in a medical anomaly pattern knowledge graph to obtain the prior probability distribution of this type of memory anomaly. The features were then mapped to a causal graph—"memory growth rate exceeding 5MB / s" was mapped to the intermediate node "continuous reduction in available heap memory," and "call stack hitting decoding classes" was mapped to the cause node association path "bitmap object not being recycled." Bayesian inference, combining prior and observational evidence, calculated a posterior confidence level of 87% for "bitmap object not being recycled" and 65% for "caching strategy not cleaning according to page lifecycle." Counterfactual analysis verified that fixing bitmap recycling reduced memory growth by approximately 76%, exceeding the threshold and confirming it as a valid root cause. A report containing the evidence chain was generated to help the development team quickly pinpoint the specific line of code.

[0070] In fintech app testing, when the anomaly detection agent detected a sudden spike in transaction interface response time from an average of 200ms to 5000ms during a major promotional event, accompanied by timeouts in some orders, the root cause analysis agent extracted a set of features from the context data packets, including the interface latency spike curve, the database connection pool reaching its maximum active count, lock waiting methods in the call stack, and the current business scenario (flash sale). After matching these features with a financial anomaly pattern knowledge graph to obtain the prior distribution, the "database connection pool active count = maximum value" was mapped to the intermediate node "connection resource exhaustion," and the "call stack hit keyword" was mapped to the cause node association path "thread lock contention." Bayesian inference calculated a posterior confidence level of 82% for "insufficient database connection pool configuration" and 40% for "cache avalanche leading to database penetration." Counterfactual analysis verified that the latency decreased by approximately 81% after expanding the connection pool, confirming it as a valid root cause. Simultaneously, related scenarios such as transaction log verification and account balance consistency were incorporated into the evidence chain, generating a report containing specific configuration parameter adjustment suggestions.

[0071] In one embodiment, S700 includes: S701, The global main agent sends a data aggregation command to the interface exploration agent, stress test agent, anomaly detection agent, root cause analysis agent and scene reconstruction agent. S702, the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent and scene reconstruction agent respond to the data aggregation command and report their respective execution logs, discovered anomaly records and model internal statistics to the global main agent; S703. Perform statistical analysis on the execution data and calculate the overall stability result of the App under test; S704. The page nodes and UI component nodes in the comprehensive stability results, as well as the jump relationships between pages and the inclusion relationships between components, are added as new entities and edges to the initial App function knowledge graph. S705. Based on the comprehensive stability results and the root cause analysis report, the valid root causes verified by the root cause analysis agent, the corresponding abnormal feature patterns, and the executable script use case numbers generated by the scenario reconstruction agent are added to the abnormal pattern knowledge graph as new abnormal pattern entities and relationships.

[0072] In this embodiment, as Figure 5 As shown, the global master agent is responsible for coordinating the data collection and knowledge accumulation of all specialized sub-agents. First, the global master agent simultaneously sends a data aggregation command to all registered specialized sub-agents via the event bus. This command includes a list of data types to be reported and format requirements. Upon receiving the aggregation command, each specialized sub-agent responds and packages and reports the execution data accumulated during the test execution to the global master agent. Specifically, the data reported by the interface exploration agent includes a complete list of page identifiers it has visited, a set of user interface component identifiers it has interacted with, detailed timestamps of each operation, internal statistics of the reinforcement learning model (such as the current capacity of the experience replay pool, the number of incremental training iterations, and the average loss value of the most recent training), and the reward value change trajectory for each round of decision-making; the data reported by the stress testing agent includes the real-time change curve of the number of concurrent users, statistics on the success and failure rates of each virtual user's operations, the trigger time of resource contention events and the types of shared resources involved, the start and end times of environmental condition injections and their parameter configurations; and the data reported by the anomaly detection agent... This includes complete time-series records of all system resource and performance metrics throughout the entire testing cycle, the basis for dynamic threshold calculations and threshold values ​​at each moment, a list of all events identified as abnormal, and their severity ratings; data reported by the root cause analysis agent includes root cause analysis reports for all abnormal events discovered in this test, posterior confidence values ​​of each cause node during Bayesian network inference, verification results of counterfactual inference, and reasons for excluding invalid candidate causes; data reported by the scenario reconstruction agent includes the test case number, script version identifier, and description of the corresponding trigger conditions for each confirmed abnormal event's reproducible test script. All reported data is aggregated to the global master agent's data aggregation buffer via a reliable transmission channel on the event bus, ensuring that even if a sub-agent reports a large amount of data, it will not block the normal communication of other agents.

[0073] After collecting all execution data, the global lead agent enters the comprehensive statistical analysis phase. The lead agent aggregates and calculates the data from multiple dimensions to generate a comprehensive stability result for the application under test. This comprehensive stability result is not a single numerical value, but a multi-dimensional evaluation vector, encompassing code coverage metrics—including global code coverage (i.e., the percentage of lines or branches of code covered by the test execution in the entire App code), the detailed coverage of each business module, and the cumulative curve of coverage growth over time; page coverage metrics—including the proportion of pages actually visited in this test to the total number of pages in the App, the average dwell time on each page, and the breadth and depth distribution of page navigation paths; anomaly detection metrics—including statistics on the number of anomalies grouped by anomaly type, the first occurrence time of each type of anomaly, the average frequency of anomaly occurrence, and the ratio of explicit anomalies (such as crashes and application unresponsiveness) to implicit anomalies (such as slow memory growth and gradual frame rate decline); resource health metrics—including peak and average memory usage, average CPU utilization, frame rate fluctuation variance, and the average response latency range of network requests throughout the test; and a risk-weighted comprehensive score—this score is obtained by weighting and summing the above-mentioned metrics according to preset risk weight coefficients, where implicit anomalies and coverage gaps are given higher negative weights to reflect their potential threat to the long-term stability of the App. After the main agent completes all calculations, it packages and encapsulates this structured data into a comprehensive stability result object and persists it in the global state sharing space for subsequent querying and analysis by testers.

[0074] After generating the overall stability results, the global lead agent initiates incremental updates to the initial App functional knowledge graph. This knowledge graph, initially built based solely on static analysis, only includes statically declared page classes, UI components, interfaces, and data entities from the installation package and their interrelationships. However, it fails to cover the actual interface structure and interaction paths discovered only during dynamic runtime. In this test, the interface exploration agent traversed a large number of runtime pages using reinforcement learning. Many of these pages' specific UI component combinations and inter-page navigation paths were not fully captured during the static analysis phase. The global lead agent extracts descriptions of all actually visited page nodes and interacted UI component nodes from the execution data reported by the interface exploration agent. This includes the actual instantiation identifier of the page class at runtime, the dynamically loaded component types, and their positions in the interface hierarchy tree. These newly discovered nodes are added as new entities to the App functional knowledge graph, with each new entity node carrying contextual information about its discovery (such as the first occurrence's operation sequence and access frequency). Simultaneously, the main agent extracts dynamic navigation relationships not declared in the static analysis from page navigation records—such as page switching triggered by asynchronous interface responses or cross-module navigation implemented through deep links—and adds these newly added navigation relationships as new "navigation relationship" edges to the graph. It also extracts "inclusion relationship" edges between dynamically attached components and their respective pages from the UI hierarchy tree traversal records. Furthermore, if new interface call paths or data flows are discovered during testing, the corresponding "dependency relationship" and "data flow relationship" edges are updated accordingly. All newly added entities and edges are accompanied by a trust weight recorded during testing. This weight is dynamically calculated based on the number of times the node is accessed and the diversity of access scenarios. Nodes with more accesses and those appearing in different testing phases receive higher trust, providing a quantitative reference for the reliability of knowledge reuse in subsequent testing tasks.

[0075] Building upon this foundation, the global lead agent initiates an update process for the anomaly pattern knowledge graph, distilling newly discovered stability issues and their solutions from this test into reusable structured knowledge. The lead agent extracts valid root cause descriptions verified through counterfactual reasoning from the root cause analysis reports submitted by the root cause analysis agent. These descriptions include the root cause type encoding (e.g., standard classifications such as memory leaks, thread deadlocks, and interface timeouts), specific defect triggering conditions, and the root cause's location at the code level (e.g., the class names and method signatures involved). Simultaneously, the lead agent extracts anomaly feature patterns corresponding to these valid root causes from the list of anomaly events reported by the anomaly detection agent—namely, typical changes in system metrics, operation sequence characteristics, and code execution path signatures observed at the time of the anomaly. These feature patterns are aggregated to form standardized feature vector templates, serving as the core basis for subsequent similarity matching in the anomaly pattern knowledge graph. Furthermore, the main agent associates the test case numbers of the reproducible test scripts generated by the scenario reconstruction agent with the corresponding exception types. Each executable script test case number uniquely identifies a complete operation sequence script that can reliably trigger a specific exception event. This script is stored in the test case management library, and its test case number is recorded as an entity attribute in the knowledge graph, allowing the script to be directly retrieved and executed for one-click replay verification at any time in the future. Based on this extracted information, the main agent adds new exception pattern entities (including exception type, root cause, phenomenon description, and severity level) and new relationships (including "causing relationship"—pointing the effective root cause to the exception type, "manifestation relationship"—pointing the exception type to the feature pattern, "reproduced by relationship"—pointing the exception type to the executable script test case number, and "resolved by relationship"—pointing the root cause to the repair suggestion description) to the exception pattern knowledge graph, thereby organically embedding all the new exception patterns discovered in this test into the global knowledge system. After completing all the above updates, the App's functional knowledge graph is more complete and accurate than before the test started because it integrates both static declarations and dynamic runtime discoveries. The anomaly pattern knowledge graph is continuously enriched by adding valid root causes and corresponding feature patterns that have been verified through causal analysis. This allows subsequent test tasks for similar or related Apps to benefit from all the knowledge accumulated in this test by directly loading the updated graph, without having to start from scratch to accumulate anomaly diagnosis experience. This significantly shortens the initialization time of new tests and the judgment path for root cause localization.

[0076] This embodiment sends data aggregation commands to various specialized sub-agents through a global master agent, collecting execution logs, anomaly records, and model statistics. Statistical analysis generates a comprehensive stability result, updating newly discovered pages, components, and navigation relationships to the functional knowledge graph. Simultaneously, effective root causes, anomaly characteristic patterns, and executable script test case numbers are added to the anomaly pattern knowledge graph. This mechanism achieves comprehensive aggregation of test data and bidirectional knowledge accumulation, enabling the functional graph to continuously improve with test iterations. Anomaly experience can be reused across projects, and subsequent test initialization time is reduced by approximately 70%.

[0077] After testing of the healthcare app, the global main agent collects execution logs and memory anomaly records from the image viewing and online consultation sub-agents. Statistical analysis generates comprehensive stability results, including indicators such as approximately 85% coverage of the image module and memory leak risk level. Subsequently, new UI nodes dynamically discovered during testing, such as image magnification components and report sharing buttons, as well as new paths from the consultation page to image details, are added as entities and relationships to the functional knowledge graph. Simultaneously, the root cause confirmed by root cause analysis—"bitmap object not recycled," the corresponding abnormal feature patterns, and the test case numbers of the image browsing reproduction scripts generated by scene reconstruction—are added to the abnormal pattern knowledge graph. Subsequent tests for new versions of this app or similar imaging apps can directly load the two updated graphs, quickly reusing the accumulated structured knowledge.

[0078] After testing of fintech apps, the global main agent summarizes the interface latency logs and transaction timeout records of the transaction link verification and stress testing sub-agents. The comprehensive stability results generated by statistical analysis include transaction payment module coverage, peak interface latency during flash sales, and the number of connection pool exhaustions. Subsequently, new UI nodes discovered during testing, such as dynamically loaded wealth management pop-ups and large-amount transfer confirmation components, as well as new jump paths from the wealth management product list to the payment confirmation page, are added to the functional knowledge graph. Simultaneously, the root cause confirmed by root cause analysis—"insufficient database connection pool configuration"—and the characteristic pattern of "interface latency spikes combined with connection pool activity reaching its limit," along with the test case numbers of the order submission concurrency scenario reproduction scripts generated by scenario reconstruction, are added to the anomaly pattern knowledge graph. During regression testing before the next major promotion or testing of similar fintech apps, the system automatically loads this graph, reducing the test preparation time for flash sales scenarios from several days to several hours, and allowing for direct reuse of accumulated features for anomaly diagnosis.

[0079] In one embodiment, a mobile app testing device based on an intelligent agent system is provided, which corresponds one-to-one with the mobile app testing method based on an intelligent agent system described in the above embodiments. (Refer to...) Figure 6 , Figure 6This is a schematic diagram of the functional modules of a preferred embodiment of the mobile APP testing device based on an intelligent agent system according to the present invention. The modules include a task bidding module 10, a task publishing module 20, a subtask execution module 30, an anomaly monitoring module 40, an anomaly data acquisition module 50, a root cause analysis module 60, and a data update module 70. Detailed descriptions of each functional module are as follows: The task bidding module 10 is used to decompose the global test task into multiple atomic sub-tasks according to the test objectives through the global main agent, and to issue task bidding to the interface exploration agent, stress test agent, anomaly detection agent, root cause analysis agent and scene reconstruction agent through a cooperative communication mechanism. The task publishing module 20 is used by the global main intelligent agent to receive the bidding responses from the interface exploration intelligent agent, stress testing intelligent agent, anomaly detection intelligent agent, root cause analysis intelligent agent and scene reconstruction intelligent agent based on their own capabilities and current load, and to distribute the task parameters of the atomic subtasks to the interface exploration intelligent agent, stress testing intelligent agent, anomaly detection intelligent agent, root cause analysis intelligent agent and scene reconstruction intelligent agent respectively according to the bidding responses; Subtask execution module 30 is used to execute atomic subtasks corresponding to the task parameters in parallel when the interface exploration agent and the stress test agent receive the task parameters; The anomaly monitoring module 40 is used by the anomaly detection agent to detect the system operation indicators of the App under test in real time according to the task parameters. When an anomaly event is detected, the anomaly event message is published to the global main agent and the root cause analysis agent. The abnormal data acquisition module 50 is used to instruct the scene reconstruction agent to transmit the context data packets within a specified time window before and after the abnormality occurs to the root cause analysis agent after the global main agent receives the abnormal event message. The root cause analysis module 60 is used to extract an abnormal feature set from the context data packet through the root cause analysis agent, match the abnormal feature set with historical cases in the historical abnormal pattern knowledge graph, select multiple candidate cause nodes according to the matching degree, perform counterfactual inference on each candidate cause node, and generate a root cause analysis report. The data update module 70 is used to collect execution data from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent by the global main agent, perform statistical analysis on the execution data, and generate a comprehensive stability result of the App under test.

[0080] In one embodiment, the map construction module includes: After receiving the installation package of the App under test, the code files and resource description files in the installation package are parsed to extract key data and test parameters; The page classes, UI components, business interfaces, and data entities in the key data are defined as entity nodes of the knowledge graph; The page navigation target declaration, the relationship between components and pages, the dependency relationship between interfaces and pages, and the data flow relationship between entities in the key data are defined as relationship edges between entities; An initial App function knowledge graph is constructed based on the entity nodes and relation edges using a preset graph ontology model; Based on the App business type tag in the test parameters, a retrieval request is initiated to the global knowledge base; Based on the retrieval request, obtain one or more historical anomaly pattern knowledge graphs that match the App's business type tags.

[0081] In one embodiment, the agent construction module includes: A global main agent is pre-built for task decomposition and scheduling based on the test objectives; Construct an interface exploration agent, a stress testing agent, an anomaly detection agent, a root cause analysis agent, and a scenario reconstruction agent, respectively; A global state sharing space based on the blackboard model is constructed. The global state sharing space is divided into a global state area, a task scheduling area, and an abnormal event area. The interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent are registered to the global state sharing space and granted data read and write permissions to the corresponding areas. An event bus is established, and the collaborative communication mechanism between the global main agent and the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent is configured through the event bus.

[0082] In one embodiment, the subtask execution module 30 includes: The interface exploration agent obtains a screenshot of the current interface and the UI hierarchy tree; The interface visual features are extracted from the screenshots, the component types, positions and interactivity information of the current page are extracted from the UI hierarchy tree, the system resource usage values ​​are read, and the accessed page path records are read from the global state shared space. The state vector is generated by concatenating the interface visual features, component information, system resource usage values, and accessed page path records. The state vector is input into the decision network of a preset reinforcement learning model, and the value evaluation results of each candidate operation in the operation action space are output. Based on the value assessment results, select the type of operation to be executed and its accompanying parameters, and send the operation to be executed to the target device for execution; After execution, the interface exploration agent obtains the new interface state, the new UI hierarchy tree, and the updated system resources. Determine whether the page corresponding to the new interface state is an unvisited new page, determine whether there are any uninterrupted new components in the new UI hierarchy tree, and determine whether the system resource update value shows an abnormal trend. The total reward value for this operation is calculated based on the page access judgment results, new component judgment results, and abnormal change trend judgment results. The experience quadruple, consisting of the state vector, the selected operation and related parameters, the total reward value, the new interface state after execution, and the system resource update value, is stored in the experience replay pool. Every preset training cycle, a batch of experience quadruples are sampled from the experience replay pool to incrementally train the decision network of the reinforcement learning model, update the network parameters, and synchronize the updated network parameters to the global state sharing space.

[0083] In one embodiment, the anomaly monitoring module 40 includes: The anomaly detection agent receives system resource metrics and performance metrics of the app under test at a preset fixed sampling interval based on task parameters. The system resource indicators and performance indicators at each sampling time are combined to generate time-series data points, and the time-series data points are stored in a circular buffer queue. The anomaly detection agent performs mutation detection analysis and trend detection analysis on the time-series data in the circular buffer queue to obtain mutation detection results and trend detection results. The mutation detection results and trend detection results are compared with the preset dynamic thresholds of the corresponding indicators; When the mutation detection result and / or trend detection result exceed the dynamic threshold, the anomaly detection agent generates an anomaly event message; The abnormal event message is published to the global main agent and the root cause analysis agent via the event bus.

[0084] In one embodiment, the root cause analysis module 60 includes: The root cause analysis agent extracts a set of abnormal features from the context data packet; The abnormal feature set is matched with historical cases in the historical abnormal pattern knowledge graph to obtain the root cause prior probability distribution associated with historical cases whose matching degree exceeds a preset matching threshold. Each feature value in the set of abnormal features is mapped to the corresponding intermediate node and phenomenon node in the pre-constructed abnormal cause-effect graph; Based on the root cause prior probability distribution, intermediate nodes, phenomenon nodes, and directed edge weights and conditional probability tables of the abnormal cause-effect graph, the posterior confidence of each cause node in the abnormal cause-effect graph is calculated using a Bayesian network inference algorithm. The root cause analysis agent selects multiple candidate cause nodes based on a screening strategy and posterior confidence. Perform counterfactual deduction on each candidate cause node. If the probability of occurrence of the phenomenon node decreases by more than the judgment threshold, then the candidate cause node is confirmed as a valid root cause. A root cause analysis report is generated based on the valid root causes and the corresponding evidence paths.

[0085] In one embodiment, the data update module 70 includes: The global main agent sends data aggregation instructions to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent; The interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scenario reconstruction agent respond to the data aggregation command by reporting their respective execution logs, discovered anomaly records, and internal model statistics to the global main agent. Perform statistical analysis on the execution data to calculate the overall stability result of the App under test; The page nodes and UI component nodes from the comprehensive stability results, as well as the jump relationships between pages and the inclusion relationships between components, are added as new entities and edges to the initial App functional knowledge graph. Based on the comprehensive stability results and the root cause analysis report, the valid root causes verified by the root cause analysis agent, the corresponding abnormal feature patterns, and the executable script use case numbers generated by the scenario reconstruction agent are added to the abnormal pattern knowledge graph as new abnormal pattern entities and relationships.

[0086] Specific limitations regarding the mobile app testing device based on intelligent agent systems can be found in the aforementioned limitations on the mobile app testing method based on intelligent agent systems, and will not be repeated here. Each module in the aforementioned mobile app testing device based on intelligent agent systems can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0087] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a server-side testing method for a mobile application based on an intelligent agent system.

[0088] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the client-side functions or steps of a mobile application testing method based on an intelligent agent system.

[0089] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: The global master agent decomposes the global test task into multiple atomic sub-tasks according to the test objectives, and issues task bidding to the interface exploration agent, stress test agent, anomaly detection agent, root cause analysis agent and scene reconstruction agent through a cooperative communication mechanism. The global main agent receives bid responses from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent based on their own capabilities and current load, and distributes the task parameters of the atomic subtasks to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent respectively according to the bid responses. When the interface exploration agent and the stress testing agent receive the task parameters, they execute the atomic subtasks corresponding to the task parameters in parallel. The anomaly detection agent detects the system operation indicators of the App under test in real time according to the task parameters. When an anomaly event is detected, the anomaly event message is published to the global main agent and the root cause analysis agent. After receiving the abnormal event message, the global main agent instructs the scene reconstruction agent to pass the context data packets within a specified time window before and after the abnormality to the root cause analysis agent. The root cause analysis agent extracts an abnormal feature set from the context data packet, performs similarity matching between the abnormal feature set and historical cases in the historical abnormal pattern knowledge graph, selects multiple candidate cause nodes based on the matching degree, performs counterfactual inference on each candidate cause node, and generates a root cause analysis report. The global main agent collects execution data from the exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scenario reconstruction agent. Statistical analysis is performed on the execution data to generate a comprehensive stability result for the App under test.

[0090] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: The global master agent decomposes the global test task into multiple atomic sub-tasks according to the test objectives, and issues task bidding to the interface exploration agent, stress test agent, anomaly detection agent, root cause analysis agent and scene reconstruction agent through a cooperative communication mechanism. The global main agent receives bid responses from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent based on their own capabilities and current load, and distributes the task parameters of the atomic subtasks to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent respectively according to the bid responses. When the interface exploration agent and the stress testing agent receive the task parameters, they execute the atomic subtasks corresponding to the task parameters in parallel. The anomaly detection agent detects the system operation indicators of the App under test in real time according to the task parameters. When an anomaly event is detected, the anomaly event message is published to the global main agent and the root cause analysis agent. After receiving the abnormal event message, the global main agent instructs the scene reconstruction agent to pass the context data packets within a specified time window before and after the abnormality to the root cause analysis agent. The root cause analysis agent extracts an abnormal feature set from the context data packet, performs similarity matching between the abnormal feature set and historical cases in the historical abnormal pattern knowledge graph, selects multiple candidate cause nodes based on the matching degree, performs counterfactual inference on each candidate cause node, and generates a root cause analysis report. The global main agent collects execution data from the exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scenario reconstruction agent. Statistical analysis is performed on the execution data to generate a comprehensive stability result for the App under test.

[0091] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0092] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0093] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0094] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0095] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A mobile app testing method based on an intelligent agent system, characterized in that, Includes the following steps: The global master agent decomposes the global test task into multiple atomic sub-tasks according to the test objectives, and issues task bidding to the interface exploration agent, stress test agent, anomaly detection agent, root cause analysis agent and scene reconstruction agent through a cooperative communication mechanism. The global main agent receives bid responses from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent based on their own capabilities and current load, and distributes the task parameters of the atomic subtasks to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent respectively according to the bid responses. When the interface exploration agent and the stress testing agent receive the task parameters, they execute the atomic subtasks corresponding to the task parameters in parallel. The anomaly detection agent detects the system operation indicators of the App under test in real time according to the task parameters. When an anomaly event is detected, the anomaly event message is published to the global main agent and the root cause analysis agent. After receiving the abnormal event message, the global main agent instructs the scene reconstruction agent to pass the context data packets within a specified time window before and after the abnormality to the root cause analysis agent. The root cause analysis agent extracts an abnormal feature set from the context data packet, performs similarity matching between the abnormal feature set and historical cases in the historical abnormal pattern knowledge graph, selects multiple candidate cause nodes based on the matching degree, performs counterfactual inference on each candidate cause node, and generates a root cause analysis report. The global main agent collects execution data from the exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scenario reconstruction agent. Statistical analysis is performed on the execution data to generate a comprehensive stability result for the App under test.

2. The mobile app testing method based on an intelligent agent system as described in claim 1, characterized in that, Before the global master agent decomposes the global test task into multiple atomic sub-tasks based on the test objectives, and issues task bidding to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scenario reconstruction agent through a cooperative communication mechanism, the following steps are taken: After receiving the installation package of the App under test, the code files and resource description files in the installation package are parsed to extract key data and test parameters; The page classes, UI components, business interfaces, and data entities in the key data are defined as entity nodes of the knowledge graph; The page navigation target declaration, the relationship between components and pages, the dependency relationship between interfaces and pages, and the data flow relationship between entities in the key data are defined as relationship edges between entities; An initial App function knowledge graph is constructed based on the entity nodes and relation edges using a preset graph ontology model; Based on the App business type tag in the test parameters, a retrieval request is initiated to the global knowledge base; Based on the retrieval request, obtain one or more historical anomaly pattern knowledge graphs that match the App's business type tags.

3. The mobile app testing method based on an intelligent agent system as described in claim 1, characterized in that, Before the global master agent decomposes the global test task into multiple atomic sub-tasks based on the test objectives, and issues task bidding to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scenario reconstruction agent through a cooperative communication mechanism, the following steps are taken: A global main agent is pre-built for task decomposition and scheduling based on the test objectives; Construct an interface exploration agent, a stress testing agent, an anomaly detection agent, a root cause analysis agent, and a scenario reconstruction agent, respectively; A global state sharing space based on the blackboard model is constructed. The global state sharing space is divided into a global state area, a task scheduling area, and an abnormal event area. The interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent are registered to the global state sharing space and granted data read and write permissions to the corresponding areas. An event bus is established, and the collaborative communication mechanism between the global main agent and the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent is configured through the event bus.

4. The mobile app testing method based on an intelligent agent system as described in claim 1, characterized in that, When the interface exploration agent receives the task parameters, it executes the atomic subtasks corresponding to the task parameters in parallel, including: The interface exploration agent obtains a screenshot of the current interface and the UI hierarchy tree; The interface visual features are extracted from the screenshots, the component types, positions and interactivity information of the current page are extracted from the UI hierarchy tree, the system resource usage values ​​are read, and the accessed page path records are read from the global state shared space. The interface visual features, component types, locations, interactivity information, system resource usage values, and visited page path records are concatenated to generate a state vector; The state vector is input into the decision network of a preset reinforcement learning model, and the value evaluation results of each candidate operation in the operation action space are output. Based on the value assessment results, select the type of operation to be executed and its accompanying parameters, and send the operation to be executed to the target device for execution; After execution, the interface exploration agent obtains the new interface state, the new UI hierarchy tree, and the updated system resources. Determine whether the page corresponding to the new interface state is an unvisited new page, determine whether there are any uninterrupted new components in the new UI hierarchy tree, and determine whether the system resource update value shows an abnormal trend. The total reward value for this operation is calculated based on the page access judgment results, new component judgment results, and abnormal change trend judgment results. The experience quadruple, consisting of the state vector, the selected operation and related parameters, the total reward value, the new interface state after execution, and the system resource update value, is stored in the experience replay pool. Every preset training cycle, a batch of experience quadruples are sampled from the experience replay pool to incrementally train the decision network of the reinforcement learning model, update the network parameters, and synchronize the updated network parameters to the global state sharing space.

5. The mobile app testing method based on an intelligent agent system as described in claim 1, characterized in that, The anomaly detection agent monitors the system performance metrics of the App under test in real time based on the task parameters. When an anomaly is detected, it publishes an anomaly event message to the global main agent and the root cause analysis agent, including: The anomaly detection agent receives system resource metrics and performance metrics of the app under test at a preset fixed sampling interval based on task parameters. The system resource indicators and performance indicators at each sampling time are combined to generate time-series data points, and the time-series data points are stored in a circular buffer queue. The anomaly detection agent performs mutation detection analysis and trend detection analysis on the time-series data in the circular buffer queue to obtain mutation detection results and trend detection results. The mutation detection results and trend detection results are compared with the preset dynamic thresholds of the corresponding indicators; When the mutation detection result and / or trend detection result exceed the dynamic threshold, the anomaly detection agent generates an anomaly event message; The abnormal event message is published to the global main agent and the root cause analysis agent via the event bus.

6. The mobile app testing method based on an intelligent agent system as described in claim 1, characterized in that, The root cause analysis agent extracts anomaly feature sets from the context data packets, performs similarity matching between these anomaly feature sets and historical cases in the historical anomaly pattern knowledge graph, selects multiple candidate cause nodes based on the matching degree, performs counterfactual inference on each candidate cause node, and generates a root cause analysis report, including: The root cause analysis agent extracts a set of abnormal features from the context data packet; The abnormal feature set is matched with historical cases in the historical abnormal pattern knowledge graph to obtain the root cause prior probability distribution associated with historical cases whose matching degree exceeds a preset matching threshold. Each feature value in the set of abnormal features is mapped to the corresponding intermediate node and phenomenon node in the pre-constructed abnormal cause-effect graph; Based on the root cause prior probability distribution, intermediate nodes, phenomenon nodes, and directed edge weights and conditional probability tables of the abnormal cause-effect graph, the posterior confidence of each cause node in the abnormal cause-effect graph is calculated using a Bayesian network inference algorithm. The root cause analysis agent selects multiple candidate cause nodes based on a screening strategy and posterior confidence. Perform counterfactual deduction on each candidate cause node. If the probability of occurrence of the phenomenon node decreases by more than the judgment threshold, then the candidate cause node is confirmed as a valid root cause. A root cause analysis report is generated based on the valid root causes and the corresponding evidence paths.

7. The mobile app testing method based on an intelligent agent system as described in claim 1, characterized in that, The global main agent collects execution data from the exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent. Statistical analysis is performed on this execution data to generate a comprehensive stability result for the app under test, including: The global main agent sends data aggregation instructions to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent; The interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scenario reconstruction agent respond to the data aggregation command by reporting their respective execution logs, discovered anomaly records, and internal model statistics to the global main agent. Perform statistical analysis on the execution data to calculate the overall stability result of the App under test; The page nodes and UI component nodes from the comprehensive stability results, as well as the jump relationships between pages and the inclusion relationships between components, are added as new entities and edges to the initial App functional knowledge graph. Based on the comprehensive stability results and the root cause analysis report, the valid root causes verified by the root cause analysis agent, the corresponding abnormal feature patterns, and the executable script use case numbers generated by the scenario reconstruction agent are added to the abnormal pattern knowledge graph as new abnormal pattern entities and relationships.

8. A mobile APP testing device based on an intelligent agent system, characterized in that, The mobile app testing device based on the intelligent agent system includes: The task bidding module is used to decompose the global test task into multiple atomic sub-tasks according to the test objectives by the global main agent, and to issue task bidding to the interface exploration agent, stress test agent, anomaly detection agent, root cause analysis agent and scene reconstruction agent through a collaborative communication mechanism. The task publishing module is used by the global main agent to receive bid responses from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent based on their own capabilities and current load, and to distribute the task parameters of the atomic subtasks to the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent respectively according to the bid responses. The subtask execution module is used to execute the atomic subtasks corresponding to the task parameters in parallel when the interface exploration agent and the stress testing agent receive the task parameters. The anomaly monitoring module is used by the anomaly detection agent to detect the system operation indicators of the App under test in real time according to the task parameters. When an anomaly event is detected, the anomaly event message is published to the global main agent and the root cause analysis agent. An abnormal data acquisition module is used to instruct the scene reconstruction agent to transmit the context data packets within a specified time window before and after the abnormality occurs to the root cause analysis agent after the global main agent receives an abnormal event message. The root cause analysis module is used to extract an abnormal feature set from the context data packet through the root cause analysis agent, match the abnormal feature set with historical cases in the historical abnormal pattern knowledge graph, select multiple candidate cause nodes based on the matching degree, perform counterfactual inference on each candidate cause node, and generate a root cause analysis report. The data update module is used to collect execution data from the interface exploration agent, stress testing agent, anomaly detection agent, root cause analysis agent, and scene reconstruction agent by the global main agent, perform statistical analysis on the execution data, and generate a comprehensive stability result of the App under test.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a mobile APP testing program based on an intelligent agent system stored in the memory and capable of running on the processor. When the mobile APP testing program based on an intelligent agent system is executed by the processor, it implements the steps of the mobile APP testing method based on an intelligent agent system as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a mobile APP test program based on an intelligent agent system. When the mobile APP test program based on an intelligent agent system is executed by a processor, it implements the steps of the mobile APP test method based on an intelligent agent system as described in any one of claims 1-7.

Images