Application testing method and system based on a honkong operating system, and storage medium

Abstract

The application relates to the field of software testing, in particular to an application testing method and system based on a Hongmeng operating system and a storage medium, a function list of a target Hongmeng application is acquired, the function list of the target Hongmeng application is analyzed, and the correlation between function modules is identified; based on the correlation, a dynamic test list is generated; a device capability matrix is constructed, and the device capability matrix is used to represent the screen characteristics, sensor configuration and distributed capability of a plurality of terminal devices; based on the dynamic test list and the device capability matrix, a differentiated test case for different device forms is generated; according to the differentiated test case, a function interaction protocol model of an external device is constructed through protocol reverse analysis, and based on the constructed result, external device compatibility testing and stress testing under an abnormal scene are performed through the function interaction protocol model. Through the differentiated test case, the problems of high adaptation cost and limited coverage range in cross-device compatibility testing are solved.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to an application testing method, system and storage medium based on the HarmonyOS operating system. Background Technology

[0002] With the widespread adoption of the HarmonyOS operating system and its "develop once, deploy across multiple devices" architecture, application testing faces new challenges. HarmonyOS applications need to run seamlessly on various hardware forms such as mobile phones, tablets, and wearable devices, and collaborate in a distributed manner with a wide range of peripherals. This dramatically increases the complexity, diversity, and dynamism of testing scenarios, placing higher demands on existing testing methods.

[0003] First, in addressing the basic testing needs of HarmonyOS applications, traditional testing methods typically rely on manual analysis to construct test scenarios, making it difficult to generate test paths that cover complex functional interactions and business processes. Simultaneously, given the diverse device ecosystem, existing solutions lack effective means to identify and adapt to the hardware capability differences of different devices, resulting in inefficient and incomplete cross-device compatibility testing. Furthermore, peripheral testing often remains at the functional connectivity level, failing to delve into their communication protocols and reliability for systematic verification.

[0004] Secondly, when dealing with the dynamic adaptive characteristics of the HarmonyOS system, HarmonyOS can adaptively adjust its interaction strategies or peripheral operating modes according to its runtime state. Existing testing methods are mostly based on static assumptions, making it difficult to dynamically perceive and respond to such changes. They also lack effective means to model and verify the system's adaptive logic itself, making it impossible for testing to cover key scenarios triggered by intelligent decision-making and difficult to guarantee the overall robustness of the application in real dynamic environments.

[0005] Therefore, existing technologies have shortcomings and need to be improved. Summary of the Invention

[0006] In order to solve one or more problems in the prior art, the main purpose of this application is to provide an application testing method, system and storage medium based on the HarmonyOS operating system.

[0007] To achieve the aforementioned objectives, this application proposes an application testing method based on the HarmonyOS operating system, the method comprising: Obtain the feature list of the target HarmonyOS application, parse the feature list of the target HarmonyOS application, and identify the relationships between the feature modules; Based on the aforementioned relationships, a dynamic test list is generated; Construct a device capability matrix, which is used to characterize the screen characteristics, sensor configuration, and distributed capabilities of multiple terminal devices; Based on the dynamic test list and the device capability matrix, differentiated test cases are generated for different device forms. Based on the differentiated test cases, a functional interaction protocol model for peripherals is constructed through protocol reverse analysis. Based on the constructed results, peripheral compatibility testing and stress testing under abnormal scenarios are performed through the functional interaction protocol model.

[0008] This application also provides an application testing system based on the HarmonyOS operating system, including: The acquisition module is used to obtain the feature list of the target HarmonyOS application, parse the feature list of the target HarmonyOS application, and identify the relationship between the feature modules. The first generation module is used to generate a dynamic test list based on the aforementioned relationship; A construction module is used to construct a device capability matrix, which is used to characterize the screen characteristics, sensor configurations and distributed capabilities of multiple terminal devices. The second generation module is used to generate differentiated test cases for different device forms based on the dynamic test list and the device capability matrix. The testing module is used to construct a functional interaction protocol model for peripherals through reverse engineering based on the differentiated test cases. Based on the constructed results, peripheral compatibility testing and stress testing under abnormal scenarios are performed through the functional interaction protocol model.

[0009] This application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0010] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0011] The application testing method, system, and storage medium based on the HarmonyOS operating system in this application embodiment automatically identify explicit and implicit relationships between functional modules through intelligent parsing and monitoring, and generate dynamic test lists. This fundamentally solves the shortcomings of traditional manual test scenario construction, such as low efficiency and difficulty in covering complex business flows and distributed call chains. It achieves intelligent generation of test paths, ensuring the completeness and context relevance of test coverage. Secondly, by constructing a device capability matrix and generating differentiated test cases based on it, it solves the problems of high adaptation costs and limited coverage in cross-device compatibility testing. It realizes the automatic derivation from unified functional logic to specific instructions for multiple devices, making large-scale testing of "one-time generation, multi-terminal adaptation" possible, significantly improving the breadth and depth of testing. Finally, by constructing a peripheral interaction model through protocol reverse analysis and performing in-depth testing based on the model, it overcomes the bottleneck that peripheral testing has long remained at the functional connectivity level, unable to deeply verify protocol compatibility, long-term stability, and the reliability of system adaptive behavior. This enables testing to reach and guarantee the underlying quality of distributed ecosystem collaboration. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating an application testing method based on the HarmonyOS operating system according to an embodiment of this application. Figure 2 This is a flowchart illustrating an application testing method based on the HarmonyOS operating system according to an embodiment of this application. Figure 3 This is a schematic block diagram of an application testing system based on the HarmonyOS operating system according to an embodiment of this application; Figure 4 This is a schematic block diagram of the structure of a computer device according to an embodiment of this application.

[0013] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0015] Reference Figure 1 This application provides an application testing method based on the HarmonyOS operating system, the method comprising: S1. Obtain the function list of the target HarmonyOS application, parse the function list of the target HarmonyOS application, and identify the relationship between the function modules; S2. Based on the aforementioned relationship, generate a dynamic test list; S3. Construct a device capability matrix, which is used to characterize the screen characteristics, sensor configuration, and distributed capabilities of multiple terminal devices; S4. Based on the dynamic test list and the device capability matrix, generate differentiated test cases for different device forms; S5. Based on the differentiated test cases, construct a functional interaction protocol model for the peripheral device through protocol reverse analysis. Based on the constructed results, perform peripheral device compatibility testing and stress testing under abnormal scenarios through the functional interaction protocol model.

[0016] As described in steps S1-S3 above, step one transforms the high-level functional description of the application into a computable and analyzable module relationship network. The core lies in breaking through the limitations of traditional methods based solely on static code analysis. By combining declarative dependency analysis of application configuration files (such as module.json5) with monitoring of dynamic interaction behaviors generated during application runtime through mechanisms such as event buses and distributed soft buses, an "application interaction topology graph" covering explicit and implicit calls is constructed. This is not simply code analysis, but rather an understanding and modeling of the HarmonyOS application's unique component model (Ability / Service) and distributed communication patterns. It solves the problems of insufficient intelligence in test scenario construction and omission of implicit relationships caused by traditional manual sorting or static analysis. Through automated and in-depth relationship identification, a precise data foundation is laid for generating test scenarios that comprehensively reflect real business flows and distributed interaction paths, improving the completeness and reliability of test coverage from the source. Step two transforms the static relationship graph obtained in the previous step into an executable sequence of test tasks. Its essence is to traverse and extract paths from the "application interaction topology graph" based on graph theory algorithms (such as depth-first search and critical path analysis) to derive a test execution sequence covering core modules and key edges. This list is "dynamic," meaning it can be updated according to changes in relationships, such as plugin loading, and has context awareness. It realizes the automated conversion from "relationship network" to "test path." It overcomes the shortcomings of low efficiency in test scenario construction, avoids the one-sidedness and high cost of manually writing test cases, and ensures that the test list can systematically cover complex business integration points and distributed call chains, providing clear navigation for subsequent accurate testing. Step three establishes a unified environment model for "one-to-many adaptation" testing. The device capability matrix is ​​a structured data model that systematically abstracts and encapsulates the key parameters of various HarmonyOS terminals in the three dimensions of display, perception, and connectivity. For example, the screen not only records resolution but also dynamic parameters in the foldable state; sensors record type and accuracy mode; distributed capabilities record protocol version and real-time link quality. This matrix is ​​a standardized description of the heterogeneous device ecosystem and serves as an input benchmark for achieving differentiated testing. It solves the problem of lacking effective methods for testing adaptation to diverse hardware ecosystems. By centrally managing device capability data through a unified model, it changes the inefficient model of maintaining test cases separately for each device, providing core support for the subsequent automated and large-scale generation of test content for different device characteristics. It is a key infrastructure for achieving efficient cross-device compatibility testing.

[0017] As described in steps S4-S5 above, step four is the "adaptation layer" of the test logic. By matching and mapping each test task (derived from a functional module) in the dynamic test list with the parameters of the target device in the device capability matrix using an algorithm, concrete test instructions are automatically derived. For example, the same "play video" task generates touch swipe instructions on a mobile phone and remote control button instructions on a smart screen; tasks involving sensors will generate different calling instructions based on the actual sensor types and precision supported by the device. This directly addresses the shortcomings of high cost and incomplete coverage in cross-device compatibility testing. It achieves "one-to-many" test cases, that is, from a single functional test logic, it automatically derives a set of specific executable test instructions covering multiple device forms. This greatly improves the balance between the breadth and depth of testing, ensuring that the specific behavior of the application under each device form can be verified. Step five extends the testing scope from the application and main device to the peripheral ecosystem. First, through protocol reverse engineering technology, the communication data flow between peripherals (such as printers) and the HarmonyOS system is analyzed to construct a protocol model that can simulate peripheral behavior or verify its response. Subsequently, using this model as the driving engine, two levels of testing were performed: first, standard compatibility testing based on historical baseline data; and second, long-term stability stress testing by actively injecting protocol anomalies or simulating distributed network anomalies. This overcame the dual shortcomings of weak deep verification capabilities for peripheral compatibility and reliability, and a lack of verification methods for system adaptive behavior. It enabled testing to penetrate to the protocol layer, not only verifying basic functions but also systematically evaluating the performance of peripherals under various anomaly, stress, and adaptive mode switching scenarios.

[0018] As mentioned above, through intelligent parsing and monitoring, explicit and implicit relationships between functional modules are automatically identified, and dynamic test lists are generated. This fundamentally solves the shortcomings of traditional manual test scenario construction, such as low efficiency and difficulty in covering complex business flows and distributed call chains. It achieves intelligent generation of test paths, ensuring the completeness and context relevance of test coverage. Secondly, by constructing a device capability matrix and generating differentiated test cases based on it, the problem of high adaptation costs and limited coverage in cross-device compatibility testing is solved. It enables automatic derivation from unified functional logic to specific instructions for multiple devices, making large-scale testing of "one-time generation, multi-terminal adaptation" possible, significantly improving the breadth and depth of testing. Finally, by constructing a peripheral interaction model through protocol reverse analysis and performing in-depth testing based on the model, the bottleneck of peripheral testing, which has long remained at the functional connectivity level and cannot deeply verify protocol compatibility, long-term stability, and the reliability of system adaptive behavior, is overcome. This allows testing to reach and guarantee the underlying quality of distributed ecosystem collaboration.

[0019] Reference Figure 2In one embodiment, the step of generating differentiated test cases for different device forms based on the dynamic test list and the device capability matrix includes: S41. Based on the device capability matrix, extract the screen resolution, sensor list and distributed connection protocol of each terminal device; S42. Match each functional module in the dynamic test list with the screen resolution, sensor list and distributed connection protocol of the terminal device, and determine the matching result; S43. If the matching result is a successful match, it is determined that the functional module can be tested on the current device. The interface layout test instruction is generated according to the screen resolution of the current device, the sensor call test instruction is generated according to the sensor list, and the device collaboration test instruction is generated according to the distributed connection protocol. S44. Combine the interface layout test instructions, sensor call test instructions, and device collaboration test instructions to form a test subset of the functional module on the current device; S45. If the matching result is a failure, it is determined that the functional module is not testable on the current device, and the generation of test cases for the functional module on the current device is skipped. S46. Perform iterative processing on all functional modules in the dynamic test list and all terminal devices in the device capability matrix, and summarize the test subsets generated on each device to form a differentiated test case library covering multiple device forms.

[0020] As described above, Step One is the data preparation phase before performing precise matching. From the comprehensive device capability matrix constructed at the upper layer, three core capability dimensions directly related to functional testing are located and extracted. This is equivalent to establishing a standardized capability summary for each device, transforming complex device characteristics into discrete parameters that can be directly processed by automated processes. This solves the problem of fragmented and inconsistent device capability descriptions in traditional testing. Step Two is the core decision-making step for achieving automated adaptation. Its principle lies in predefining or analyzing the runtime capability conditions required by functional modules and comparing these conditions with the device capability summary using rules. This step systematically replaces the experience-based work of manually judging whether a function can run on a specific device, producing matching results with objective logical rules, thereby ensuring the consistency and repeatability of test decisions and effectively avoiding human oversight. In Steps Three and Four, after confirming that the function can run on the device, this step completes the visualization generation of test cases. Its principle is to derive specific test instructions based on the specific parameters of the current device. For example, interface test instructions will adapt to the specific screen resolution, and sensor tests will call specific sensor types. Subsequently, test instructions for the same function across different dimensions are combined to form a complete verification scenario. This changes the traditional, extensive approach of using generic test cases in cross-device testing, enabling in-depth verification of the device-specific hardware and software interactions, thus improving the effectiveness and relevance of testing. Step five embodies the principle of test resource optimization. Its principle is to proactively abandon generating invalid test content for devices and functional combinations that clearly lack the necessary support capabilities. This is a rule-based intelligent filtering mechanism. Its direct benefit is the purification of the final generated test case set, preventing test resources from being consumed by a large number of inevitably failing test cases, thereby allowing test execution to focus on truly feasible verification points and significantly improving overall testing efficiency. Step six is ​​a systems engineering approach to achieve comprehensive coverage. Through a double-loop iteration, it ensures that every functional module and every terminal device undergoes the aforementioned complete decision-making process. Finally, all generated test subsets scattered across various devices are aggregated to construct a structured test case repository covering all device forms. This achieves automated construction from single-point adaptation to global coverage, making systematic compatibility verification of a vast device ecosystem a scalable engineering practice. In this embodiment, the proposed solution addresses the core shortcomings of high cost, low efficiency, and lack of systematic methodology in cross-device test adaptation. This solution provides a technical solution for "one-to-many adaptation" through an "extraction-matching-generation-filtering-summarizing" approach. This not only enables differentiated generation of test cases but also ensures the efficiency of the generation process through an intelligent skipping mechanism.

[0021] In one embodiment, the steps of constructing a functional interaction protocol model for the peripheral device through protocol reverse engineering based on the differentiated test cases, and performing peripheral device compatibility testing and stress testing under abnormal scenarios based on the constructed results through the functional interaction protocol model, include: From the differentiated test cases, identify the target peripheral categories that need to be tested for peripheral interaction. For each target peripheral category, obtain the interaction protocol data between it and the HarmonyOS system through protocol reverse analysis. The interaction protocol data includes at least the instruction set, data format, and status response code. Based on the interaction protocol data, construct the functional interaction protocol model and establish a performance baseline based on historical interaction data; Based on the differentiated test cases, extract test tasks related to peripheral device interaction; Based on the functional interaction protocol model and the performance baseline, generate a peripheral test instruction sequence for each test task; In the HarmonyOS distributed environment, the peripheral device test instruction sequence is executed by the functional interaction protocol model, the actual response data of the peripheral device is recorded, and the actual response data is compared and analyzed with the performance baseline. In the HarmonyOS distributed environment, the functional interaction protocol model injects protocol anomaly data or simulates abnormal states in the distributed environment into the peripheral device test instruction sequence, and drives the execution of long-term stress tests to monitor the stability and resource consumption of the peripheral devices.

[0022] As described above, Step One achieves precise positioning of the test target and data acquisition at the protocol layer. The principle is to analyze generated, differentiated test cases tailored to specific device scenarios to identify test tasks involving peripheral collaborative operations, thereby determining the types of peripherals requiring in-depth testing. Subsequently, for these peripherals, protocol reverse engineering techniques are used to monitor and parse their actual communication flow with the HarmonyOS system, extracting the instruction set, data format, and status response codes that constitute the core of the interaction logic. This solves the shortcomings of traditional peripheral testing, which relies on manual target identification and cannot automatically acquire deep protocol information, providing a data source for building high-fidelity test models. Step Two completes the abstract modeling and quantitative calibration of peripheral interaction behavior. The principle is to structure the captured protocol data to construct a logical model capable of simulating or verifying peripheral protocol layer behavior. Simultaneously, historical normal interaction data is analyzed to statistically determine the reasonable range of key performance indicators (such as response latency and data transmission rate), establishing a performance baseline. This changes the previous situation where peripheral testing lacked a precise reference model, transforming testing from black-box functional verification to white-box and gray-box verification based on clear protocol specifications and performance expectations. Step three ensures the consistency between the test scenario and the upper-layer application logic. This is achieved by further extracting tasks that explicitly require calling peripheral functions from a differentiated test case library already bound to specific devices. This ensures that peripheral testing is not conducted in isolation, but rather verified as part of the application's complete workflow on a specific device. This guarantees the realism and business relevance of the peripheral test scenarios, avoiding ineffective testing detached from actual usage scenarios. Step four implements the protocol layer instantiation of test cases. This is achieved by using the constructed functional interaction protocol model to translate the abstract test tasks extracted in the previous step into specific instruction sequences that the peripheral can understand and respond to, conforming to its protocol specifications. Simultaneously, the expected results and performance requirements of the instructions are set with reference to the established performance baseline. This achieves automated conversion from business logic test requirements to specific protocol instructions, generating executable test payloads with clearly expected results. Step five is the core execution and evaluation phase of compatibility testing. This is achieved by having the constructed functional interaction protocol model act as a driving engine or intelligent comparator, sending test instruction sequences in a real HarmonyOS distributed environment and receiving and recording the actual responses from the peripherals. Subsequently, the correctness, completeness, and timeliness of the response are automatically compared and analyzed against the performance baseline. This achieves automated verification of protocol layer compatibility, enabling rapid and accurate detection of peripheral devices that are incompatible with protocol specifications or fail to meet performance standards, thus solving the pain points of low efficiency and difficulty in quantitative evaluation of manual testing. Step six involves in-depth verification of reliability and robustness.The principle is the same: utilizing a functional interaction protocol model, it proactively inserts erroneous protocol data into the test command sequence, simulating distributed abnormal states such as network interruptions, delays, or resource contention, and runs the test for an extended period. Simultaneously, it monitors the peripheral's behavior, stability indicators, and resource consumption under abnormal stress. This breaks through the limitations of traditional testing that only focuses on normal functional processes, proactively constructing and verifying the peripheral's fault tolerance and long-term operational reliability in harsh and complex environments, directly addressing the weakness in deep reliability verification capabilities of existing technologies for peripherals.

[0023] In one embodiment, the step of parsing the function list of the target HarmonyOS application and identifying the relationships between function modules includes: The code structure and application configuration files of the target HarmonyOS application are analyzed to extract the declarative dependencies between functional modules and form a static dependency graph. Run the target HarmonyOS application and monitor the module interaction behavior during runtime. The monitored objects include messages transmitted through the event bus, dynamically loaded modules, and cross-process or cross-device communication through the HarmonyOS distributed soft bus. Analyze the monitored cross-process or cross-device communication data and deconstruct it into business call relationships between functional modules; By integrating the static dependency graph, the monitored message interaction relationships, and the business call relationships obtained through reverse engineering, an interaction topology graph is generated to represent the complete association relationships between functional modules. In this embodiment, As mentioned above, the first step is to perform static structure analysis. The basic attributes, startup methods, and response rules for external requests of HarmonyOS application components, such as Ability and ExtensionAbility, are typically explicitly defined in application configuration files such as module.json5. For example, a payment Ability declares that it supports handling specific payment intent actions. Meanwhile, explicit calls in the code, such as a UI Ability calling a data query Service through a clear interface, constitute direct code-level dependencies. This step, by parsing these configuration files and source code, constructs a static relationship network reflecting "who declared which capability" and "who directly called whom in the code." This is similar to drawing an architectural structural diagram based on blueprints and fixed connecting lines. It establishes the basic framework of application relationships. It systematically acquires all module connections determined during the coding phase, providing indispensable benchmarks and anchors for subsequent analysis, solving the inefficiency and inaccuracy of relying entirely on manual code analysis. The second step aims to capture the dynamic relationships generated by the application in its actual runtime state. Many HarmonyOS applications adopt an event-driven architecture, with modules communicating loosely coupled through event bus message publishing and subscription. This relationship is often implicit in static code. For example, after a "user login successful" event is published, the shopping cart module and the personalized recommendation module may simultaneously subscribe to and trigger their own operations, even though there is no direct call between them. Furthermore, the application may dynamically load functional plugins, or through the HarmonyOS distributed soft bus, allow one module on the phone to directly call the service of another module on the smart screen. This step, by embedding probes at runtime, listens to these critical interaction channels, recording the relationships formed in real time under specific user operation flows or device collaboration scenarios that are not visible in static analysis. This reveals the dynamic network of connections in the application's actual working state. It can discover those crucial implicit interaction paths triggered by user behavior, device environment, or asynchronous events, filling a significant blind spot in static analysis and allowing the understanding of application complexity to deepen from the "design state" to the "runtime state." Step three is an in-depth interpretation of this complex dynamic behavior of distributed communication. Monitoring the distributed soft bus may capture low-level, non-business semantic data packets. The principle of this step is to map the captured low-level communication data to specific business logic by understanding the framework protocol of HarmonyOS distributed communication. For example, analysis reveals that a piece of data sent from process X on device A to process Y on device B has protocol characteristics consistent with a remote service call. By associating the process identifier with the application component model, it can be deduced that "the main interface Ability of the map application on device A is requesting the in-vehicle navigation Service on device B to calculate the route." This is equivalent to translating machine language into business language, achieving semantic understanding of distributed cross-device interactions.The underlying communication traffic, which is difficult to understand directly, is transformed into clear business call relationships between functional modules. This makes the internal logic of HarmonyOS's core feature of cross-device collaboration traceable and analyzable, providing a crucial basis for building end-to-end distributed test scenarios. Step four is information integration and knowledge graph construction. The relationships collected from different dimensions (static design, internal dynamic events, and external distributed calls) in the first three steps are merged, deduplicated, conflict-resolved, and relationship-strengthening. This ultimately generates a unified "interaction topology graph." In this graph, nodes represent functional modules, and edges represent various types of relationships. For example, one edge might represent a static startup dependency based on a configuration file, another might represent a dynamic message subscription relationship based on an event bus, and yet another might represent a cross-device remote procedure call. This graph comprehensively depicts all possible connection methods between modules, generating a comprehensive, three-dimensional, and context-rich panoramic view of application module relationships. It breaks through the limitations of a single analytical dimension, integrating all static and dynamic, internal and cross-device relationship information, providing an incredibly accurate and complete "map" for subsequently generating dynamic test lists that can cover complex integration scenarios, especially distributed interaction scenarios. In this embodiment, traditional methods, relying solely on inefficient manual analysis or limited to static code scanning, are unable to address the complex and hidden runtime dependencies arising from event-driven, dynamic loading, and especially distributed collaboration in HarmonyOS applications. This solution constructs a multi-layered analysis system, from static parsing to dynamic monitoring and deep protocol reverse engineering, ultimately merging to generate a unified interaction topology graph. This provides a comprehensive view of the intricate dependencies within the application, particularly at the runtime and cross-device levels.

[0024] In one embodiment, the step of constructing the device capability matrix includes: Collect baseline capability data of the screen, sensors and distributed connections of each terminal device, and initialize the device capability matrix based on the baseline capability data; When a change in the screen shape of a terminal device is detected, the changed screen shape parameters and their corresponding actual display area and pixel density are collected and updated to the corresponding entries in the device capability matrix. When a change in the available operating mode of the terminal device's sensor is detected, the accuracy, sampling rate, and power consumption parameters of each mode are collected and updated to the corresponding entries in the device capability matrix. When a distributed connection is established between terminal devices or the link status changes, the protocol details, encoding / decoding format, and real-time link quality data of the connection are collected and updated to the corresponding entries in the device capability matrix. Based on the baseline capability data and continuously updated dynamic data, a dynamically evolving device capability matrix is ​​determined.

[0025] As mentioned above, the first step establishes a static starting point and unified framework for describing device capabilities. The principle is that when a HarmonyOS device, such as a newly launched foldable phone, first connects to the testing system, the system obtains its inherent, unchanging basic capability parameters by querying device system information and hardware configuration lists. This includes its nominal screen physical parameters, a list of factory-supported sensor types, and hardware-supported wireless connection protocol standards. This data constitutes the device's "factory settings" profile and is structured and entered into a unified data model, namely, the initialized device capability matrix. This is similar to creating an initial "technology passport" for each device, achieving standardized and structured cognitive management of heterogeneous device groups. It abstracts a wide variety of devices with different parameters into entries in the matrix, providing an authoritative and consistent initial data source for all subsequent testing activities, laying the data foundation for automated adaptation. The second step aims to dynamically capture the real-time status of the device's display capabilities. Its principle is based on listening to HarmonyOS system screen management events. For example, when a user unfolds a foldable phone from its closed state, the system triggers a screen form change event. The mechanism in this step immediately responds to this event, calling the system display service interface to obtain the effective resolution, actual usable display area, and pixel density in the current state, and using these new parameters to overwrite or supplement the old information in the device's screen capability entries in the matrix. This means that for the same foldable device, the matrix dynamically maintains two different sets of screen parameters for its "folded" and "unfolded" states. This solves the problem that traditional static parameters cannot describe variable-form screens. It ensures that the testing system can perceive and respond to dynamic changes in the device's display state in real time, enabling the generated interface test instructions to be based on the device's current actual, rather than theoretical, display capabilities, thus performing accurate UI adaptation verification and avoiding layout test errors caused by parameter lag. Step three focuses on the refined and scenario-based description of sensor capabilities. Modern devices' sensors often support multiple operating modes to adapt to different application scenarios and power consumption requirements. For example, the gyroscope of the same mobile phone might operate in a high-precision, high-sampling-rate mode when used in a navigation application to ensure accurate direction determination; while when running in the background as a pedometer, it might automatically switch to a low-precision, low-sampling-rate power-saving mode. This step identifies such mode switching by monitoring relevant APIs or system logs of the sensor manager. When the mode changes, the specific performance indicators of the sensor in the new mode are immediately collected and updated in the device capability matrix, thus refining the general description of "supports gyroscope" into a precise description of "supports gyroscope high-precision mode and low-power mode and their respective specific parameters." This achieves dynamic and refined modeling of the device's sensor capabilities.This allows the testing system to understand and differentiate the true capability boundaries of sensors in different usage scenarios, thereby generating more accurate sensor call tests to verify whether the application can correctly request and process sensor data in different modes, or whether it can adapt to automatic sensor degradation caused by system policies. Step four models the dynamics and uncertainties of distributed capabilities. This is based on monitoring the distributed connection lifecycle and network status. For example, when a mobile phone establishes a distributed screen mirroring connection with a smart TV via Wi-Fi, this step not only records that the connection has been established, but also delves into the specific protocol version actually used in the negotiation of this connection, the list of supported audio and video codecs, and continuously probes or receives link quality data such as current network bandwidth, latency, and jitter from system feedback. This information is dynamically updated in the device capability matrix as a description of the "current" distributed collaborative capability between the two devices. If network conditions deteriorate, causing a decrease in link quality, the corresponding data in the matrix will also be updated accordingly. This elevates distributed capabilities from a static "support or not" to a dynamic "current quality". This enables the testing system to generate or adjust distributed collaborative tests based on the real-time network environment and negotiated protocol details. For example, it can test application degradation strategies when bandwidth is insufficient, or verify compatibility under specific codec formats, enhancing the realism and effectiveness of distributed testing. Step five summarizes and abstracts the entire construction process. The principle is to integrate and manage the static baseline data obtained in the preceding steps with the continuously flowing dynamic state update data, forming a living, dynamically evolving device capability matrix whose internal state is constantly refreshed by time and service conditions. This matrix is ​​no longer a static data table created after creation, but a dynamic knowledge base that can accurately reflect the actual capability status of the device at the current moment. Ultimately, a core data model that can realistically, comprehensively, and in real-time reflect device capabilities is constructed. It provides the entire testing scheme with high-fidelity dynamic awareness of the testing environment, and is the fundamental prerequisite for all subsequent intelligent matching, differentiated test case generation, and reliable test execution. In this embodiment, the "device capability matrix" is transformed from a static, one-time configuration list into a dynamically evolving living model with environmental awareness and real-time update capabilities. This solution addresses the shortcomings of existing testing models, which are ill-suited to dynamic runtime environments and insensitive to device state drift. Traditional methods use fixed device parameters, causing test cases to quickly become invalid when real-world changes occur, such as screen folding, sensor degradation, or network fluctuations, resulting in numerous false positives due to environmental distortion. This solution systematically solves this problem through an event-driven dynamic data acquisition and update mechanism (monitoring three key changes: screen shape, sensor mode, and connection status). It not only describes the device's basic capabilities but also answers the core question in real-time: "What can the device currently use, and at what level?"Therefore, the entire invention is given dynamic environmental adaptability, which enables automated testing to closely match the real and changing operating conditions of the equipment, thereby improving the accuracy and reliability of the test results.

[0026] In one embodiment, the step of constructing a functional interaction protocol model for the peripheral device through protocol reverse analysis based on the differentiated test cases, and performing peripheral device compatibility testing and stress testing under abnormal scenarios based on the constructed results through the functional interaction protocol model, further includes: During the continuous interaction between the target peripheral and the HarmonyOS system, interaction protocol data generated under different system states or task loads is collected, and the accompanying state parameters when collecting the interaction protocol data are recorded. The collected interaction protocol data is analyzed for patterns to identify the various protocol working modes supported by the peripheral device. Based on the change sequence of the accompanying state parameters and protocol working modes, analyze the conversion and triggering relationship between different protocol working modes; Based on the aforementioned multiple protocol working modes and the aforementioned conversion and triggering relationships, a protocol state map is constructed to describe the complete protocol capabilities of the peripheral device. Based on the protocol state graph, a set of test tasks covering the working modes of the various protocols and the transitions between modes is generated to guide peripheral compatibility testing and stress testing under abnormal scenarios.

[0027] As mentioned above, Step One aims to acquire comprehensive data on peripheral protocol behavior through long-term, multi-scenario monitoring, rather than a snapshot. The test system acts as a passive observer, continuously monitoring all communication traffic between the target peripheral, such as a multifunction printer and a HarmonyOS device. Crucially, this is not random collection, but rather deliberate collection when the peripheral is performing different tasks or the system is in different states. For example, communication data for printing plain text documents is collected when the system is idle, while communication data for printing high-resolution images is collected when the system is under high load (e.g., high CPU utilization). The system state (CPU / memory utilization) and task characteristics (document type, image complexity) are recorded simultaneously for each collection. This is equivalent to labeling each segment of protocol data with a "scenario tag," overcoming the limitations of single-shot reverse analysis results being one-sided and highly random. By accumulating protocol data and its context covering multiple working scenarios, a solid and comprehensive data foundation is laid for subsequent analysis of the diversity and conditional dependencies of peripheral behavior, ensuring the representativeness and completeness of the analysis results. Step Two involves clustering and feature extraction of the original protocol data to discover its inherent patterns. The principle is to analyze a large amount of collected protocol data streams through algorithms, comparing their differences in instruction set structure, data encapsulation format, and interaction timing. For example, analysis revealed that when the printer interacts with the mobile phone, there are two completely different sets of instruction sequences and data packet formats: one set of instructions is concise with small data packets; the other set of instructions is complex with large data packets and contains special control fields. Combined with the previously recorded "scene tags," it can be inferred that the former may correspond to "basic text printing mode," while the latter corresponds to "high-quality graphics printing mode." In this way, the different protocol working states inherent in the peripheral are identified from the mixed data. This achieves a deep insight into the peripheral's protocol capabilities, going beyond the superficial understanding of "being able to communicate." It clearly reveals that the peripheral may support multiple different working logics, answering the first part of the question "how will the peripheral work under what circumstances," and providing a key structured understanding of its adaptive behavior. Step three aims to decipher the "decision logic" of the HarmonyOS system or the peripheral itself driving mode switching. The principle is to arrange the protocol working modes identified in step two according to their chronological order of appearance in the actual monitoring data, forming a mode change sequence. Then, correlation analysis was performed on the accompanying state parameters recorded before and during each mode change. For example, analysis of multiple sequences revealed that whenever the data volume of a printing task exceeded a certain threshold and the system load fell below a certain level, the protocol mode would always switch from "basic text printing mode" to "high-quality graphics printing mode." This suggests that task complexity and available system resources are the key conditions triggering this mode transition. This is essentially a reverse derivation of the decision rules of the adaptive framework, revealing the patterns and driving forces behind the dynamic changes in peripheral protocol behavior.It connects isolated protocol modes, understanding when and why modes transition, thus establishing a predictable and describable model of the peripheral's intelligent adaptive behavior—a prerequisite for in-depth verification. Step four involves the systematic integration and visual modeling of knowledge. The principle is to use all protocol operating modes identified in step two as "state nodes," and the transition conditions and temporal relationships between modes analyzed in step three as "directed edges" and "trigger condition labels on the edges," drawing a finite state machine-like graph. This graph clearly depicts all possible protocol states of the peripheral, as well as all paths for state transitions and the required "passes" (trigger conditions). For example, the graph includes nodes such as "idle mode," "basic printing mode," and "high-quality printing mode," along with edges connecting them, labeled with conditions such as "receiving a complex graphics task and system load <50%." This generates a panoramic and structured knowledge model of the peripheral's protocol capabilities. This graph is the ultimate abstraction and generalization of the complex interactive behavior of peripherals. It makes the seemingly unpredictable adaptive behavior of peripherals clear, traceable, and reasonable, providing a precise "roadmap" for designing systematic test plans. Step five is to use the graph model to guide the engineering practice of test design. According to test coverage criteria (such as state coverage and edge coverage), test paths are selected systematically in the protocol state graph. For example, to cover all modes, test tasks need to be designed to make the peripheral enter each protocol working mode node in sequence; to cover all transitions, test tasks need to be designed to create specific conditions to trigger each transition edge marked in the graph. The final generated set of test tasks contains specific scenario descriptions and condition setting instructions that drive the peripheral to traverse key states and transitions. This ensures that the generated tests are no longer random or only focus on a single mode, but can purposefully verify the correctness, robustness, and performance of each protocol capability of the peripheral and its adaptive switching, thus qualitatively improving the depth and breadth of the tests. In this embodiment, traditional methods attempt to apply a static, single protocol model to peripherals that may have multi-mode adaptive capabilities, which inevitably leads to incomplete test coverage and verification failure. This approach abandons the illusion of instant modeling and instead adopts a scientific process of continuous observation, pattern mining, relationship analysis, and graph construction. First, it acknowledges and actively explores the diversity and dynamism of peripheral protocol behavior. Then, by constructing a powerful model called a "protocol state graph," it clearly depicts the seemingly unpredictable adaptive logic of peripherals. Finally, based on this graph, it generates comprehensive test tasks that can be "guided by the graph."

[0028] In one embodiment, the step of analyzing the transition and triggering relationship between different protocol operating modes based on the change sequence of the accompanying state parameters and protocol operating modes includes: Extract any two adjacent mode transition records from the change sequence of the protocol's working modes to form a transition sample set. Each transition sample includes the first working mode before the transition, the second working mode after the transition, as well as a snapshot of the state parameters and interaction event records when the transition occurs. The transformed sample set is divided into multiple transformation types based on the combination of working modes before and after the transformation; Based on the partitioning results, if in the snapshot of the state parameters corresponding to the conversion type, there is at least one parameter value that shows a continuous changing trend among multiple samples, then the range of change of that parameter is determined as the state condition that triggers the conversion of that type. If at least one predefined conversion instruction or event appears repeatedly in multiple samples in the interaction event record corresponding to the conversion type, then the instruction or event is determined as the event condition that triggers the conversion of that type. The analyzed state and event conditions are associated with the corresponding transformation types to construct a transformation and triggering relationship model between the protocol's working modes.

[0029] As described above, the first step is to prepare atomic data for conversion relationship analysis. The obtained, chronologically ordered "protocol operating mode change sequence" is segmented into individual "conversion events" for observation. For example, observing a printer change from "idle mode" to "high-speed printing mode" in the sequence constitutes a conversion. This step records this conversion event as an independent data sample. This sample not only includes the start and end points of the conversion (first and second operating modes), but more importantly, it acts like a precise "on-site evidence package," containing a snapshot of system state parameters taken at the moment the conversion occurred (such as CPU utilization, memory usage, and network latency), as well as records of all interactive events captured in the short period before and after (such as whether a specific "start high-speed printing" command was received). This ensures that each conversion event is analyzed within its specific context. Continuous, complex behavioral sequences are decomposed into discrete, independently analyzable "conversion cases." This provides structured data units for subsequent discovery of conversion patterns based on statistics and association rules, allowing analysis to start from specific instances rather than relying on a vague overall sequence, thus improving the granularity and reliability of the analysis. Step two involves classifying transition events, a prerequisite for discovering commonalities. The principle is to group transition samples according to the pair "from which mode" to "which mode." For example, all samples transitioning from "idle mode" to "high-speed printing mode" are grouped into one category (A->B), and all samples returning from "high-speed printing mode" to "idle mode" are grouped into another category (B->A). This means that even if these transitions occur at different times or under different tasks, as long as their starting and ending modes are the same, they are considered to be the same "type" of transition and their triggering conditions are studied together. This achieves a scientific classification of transition events. It clarifies that the analytical objective is not to study "transitions" in general, but to specifically study each type of transition, such as initiating high-speed printing or downgrading to energy-saving mode. This allows subsequent searches for triggering conditions to focus on the common causes behind the same type of transition, avoiding interference between different transition types and making the analytical conclusions clearer and more accurate. Steps three and four are the core of discovering and determining the transition triggering mechanism, employing a differentiated attribution strategy. State Conditions: For some conversion types, the trigger may depend on a continuous quantitative change in the system or environment state reaching a certain threshold. For example, analyzing all samples downgrading from "high-quality printing mode" to "normal quality printing mode," it was found that before each conversion, the system's memory usage consistently increased and exceeded 75%. Even though the specific timing of each conversion differed, the state characteristic of "high memory usage" was common and showed a trend of increasing from low to high across the threshold. In this case, "memory usage exceeding 75%" can be identified as the state condition triggering this type of conversion. Event Conditions: For other conversion types, the trigger may be directly caused by a specific discrete instruction or external event.For example, analyzing all samples waking from "standby mode" to "working mode" reveals that a "wake-up" command from the system is always present in the interaction event log before each transition. This command is discrete, explicit, and recurring in similar samples. Therefore, this "wake-up" command can be identified as the event condition triggering this type of transition. Two fundamentally different triggering mechanisms are accurately identified. It distinguishes between adaptive transitions triggered by accumulated environmental changes and reactive transitions triggered by specific commands or signals. This distinction makes the constructed trigger relationship model more consistent with real-world logic and can more accurately guide testing: to test state-triggered transitions, changes in relevant state parameters need to be simulated in the test; to test event-triggered transitions, predefined transition commands need to be sent in the test. Step five treats each triggering condition obtained in steps three and four (such as "memory > 75%" or "received wake-up command") as a clear rule and associates it with the specific transition type (such as "high quality -> normal quality" or "standby -> working") defined in step two. Ultimately, all the "conversion type - trigger condition" pairs together constitute a rule-based "conversion and trigger relationship model." This model explicitly states: under what state conditions or when what events occur, the peripheral's protocol operating mode is expected to transition from A to B. This produces a clear, interpretable, and directly applicable decision rule model to guide testing. Transforming the conclusions of data analysis into explicit logic that engineers and testing systems can understand and execute makes the prediction and verification of peripheral adaptive behavior possible.

[0030] In one feasible embodiment, a single business function is not completed independently by a single terminal device, but rather through the organic combination of heterogeneous capabilities of multiple devices, connected by a distributed soft bus, forming a virtual "super device" to achieve the same functionality. For example, scenarios such as "multi-device collaborative shooting," "cross-screen file drag-and-drop," and "distributed gaming" rely heavily on the real-time collaboration, data synchronization, and instruction timing coordination between devices. However, existing methods are still insufficient for such scenarios. The core logic of existing methods is based on a "single-device capability adaptation" model, which finds a terminal device with corresponding operational capabilities for a functional module and generates test instructions to be executed on that device. This model excels at verifying the performance of a function within a single device space, but cannot characterize and verify the "emergent" behavior of a function across devices. Therefore, this embodiment proposes to systematically solve the problem that single-device matching logic cannot cover cross-device collaborative function testing by extending the device capability model, introducing collaborative scenario identification and combination matching logic, and generating multi-device integrated test instructions. The solution includes: generating differentiated test cases for different device forms based on the dynamic test list and the device capability matrix, and further includes the following steps: In the dynamic test list, identify functional modules in which the business logic depends on the collaborative capabilities of multiple terminal devices, and denot them as collaborative dependency modules; For each collaborative dependency module, a set of terminal devices that can meet all the capability requirements of the module are selected from the device capability matrix to form a candidate device set. The device capability matrix also contains information characterizing the collaborative connection status between devices. Based on the collaborative connection status between devices in the candidate device set, determine the collaborative device group for performing the test; An integration test instruction sequence is generated for the collaborative device group. The integration test instruction sequence includes: an initialization instruction that drives the collaborative device group to establish a collaborative relationship, a distributed operation instruction that executes corresponding functional operations on each device in the group, and a collaborative assertion instruction that verifies cross-device operation timing or data consistency.

[0031] In this embodiment, step one, based on the generated interaction topology graph and runtime monitoring data, automatically identifies functional modules that clearly require multiple devices to collaborate in terms of business logic through a combination of static analysis and dynamic behavior pattern recognition. It analyzes whether the module call relationships involve cross-device service binding, event subscription, or data stream distribution. For example, by parsing distributed API calls (such as distributedAbility) in the application code or monitoring persistent connections established between runtime modules via a distributed soft bus, typical collaborative dependency modules such as "collaborative shooting" and "multi-screen collaboration" are identified. Step two takes as input the set of capabilities required by the collaborative dependency modules (such as {camera, large screen, low-latency remote control}) and the capabilities and states of all devices in the device pool (from an enhanced device capability matrix, which already includes the collaborative connection states between devices, such as pairing relationships and historical collaborative latency). The algorithm needs to find a subset of devices from the device pool such that the union of the device capabilities in this subset covers all the capabilities required by the module, while the pairwise connection states between devices meet the basic conditions for collaboration (such as being paired and network reachable). This is achieved through graph matching or set coverage algorithms. Step three, determining the final execution device group from the candidate set, is an optimal or feasible selection process based on real-time status. It selects the group with the optimal current collaborative status (e.g., lowest latency, most stable connection) from multiple candidate combinations that may meet the capability requirements, based on the real-time updated "cooperative connection status" information (such as current network RTT, bandwidth, and connection stability) in the device capability matrix, or randomly selects a group of devices that meets the minimum feasibility requirements, as the physical basis for test execution. This ensures that the test can be conducted in a practically usable collaborative environment. Step four decomposes a cross-device service flow into three stages of executable scripts: Initialization instructions: Simulate user operations or call system interfaces to drive the selected device group to establish the specific collaborative relationships required for this test (e.g., establishing a screen mirroring session between a mobile phone and a tablet, or binding a remote control relationship between a mobile phone and a watch). Distributed operation instructions: Based on the established collaborative relationships, send specific functional operation commands to each device in the group according to the service sequence. These commands are context-dependent (e.g., the "shutter button" click event displayed on the tablet is semantically bound to the mobile phone's camera service). Collaborative assertion instructions: Used to verify the correctness of cross-device operations. It includes: Timing assertions: verifying whether an operation on device B occurred within a specific time window after an operation on device A. Data consistency assertions: verifying whether data generated on device A (such as a photo) has been correctly and completely synchronized to device B. State synchronization assertions: verifying whether a state (such as "playing") is consistent across all relevant devices in the collaborative device group.

[0032] Reference Figure 3 This application also provides an application testing system based on the HarmonyOS operating system, including: Module 1 is used to obtain the function list of the target HarmonyOS application, parse the function list of the target HarmonyOS application, and identify the relationship between the function modules. The first generation module 2 is used to generate a dynamic test list based on the association relationship; Module 3 is used to construct a device capability matrix, which is used to characterize the screen characteristics, sensor configuration and distributed capabilities of multiple terminal devices. The second generation module 4 is used to generate differentiated test cases for different device forms based on the dynamic test list and the device capability matrix. Test module 5 is used to construct a functional interaction protocol model for peripherals through protocol reverse analysis based on the differentiated test cases, and to perform peripheral compatibility testing and stress testing under abnormal scenarios based on the constructed results through the functional interaction protocol model.

[0033] As described above, it is understood that each component of the application testing system based on the HarmonyOS proposed in this application can realize the function of any of the application testing methods based on the HarmonyOS described above, and the specific structure will not be repeated.

[0034] Reference Figure 4 This application also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 4 As shown, this computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-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 stored in the non-volatile storage media. The database stores monitoring data and other data. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements an application testing method based on the HarmonyOS operating system.

[0035] One embodiment of this application also provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements an application testing method based on the HarmonyOS operating system, including the following steps: obtaining a function list of a target HarmonyOS application; parsing the function list of the target HarmonyOS application to identify the relationships between functional modules; generating a dynamic test list based on the relationships; constructing a device capability matrix, the device capability matrix being used to characterize the screen characteristics, sensor configurations, and distributed capabilities of multiple terminal devices; generating differentiated test cases for different device forms based on the dynamic test list and the device capability matrix; constructing a peripheral functional interaction protocol model through protocol reverse analysis according to the differentiated test cases; and performing peripheral compatibility testing and stress testing under abnormal scenarios based on the constructed results through the functional interaction protocol model.

[0036] 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. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in this application and in the embodiments 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 a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0037] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0038] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An application testing method based on the HarmonyOS operating system, characterized in that, The method includes: Obtain the feature list of the target HarmonyOS application, parse the feature list of the target HarmonyOS application, and identify the relationships between the feature modules; Based on the aforementioned relationships, a dynamic test list is generated; Construct a device capability matrix, which is used to characterize the screen characteristics, sensor configuration, and distributed capabilities of multiple terminal devices; Based on the dynamic test list and the device capability matrix, differentiated test cases are generated for different device forms. Based on the differentiated test cases, a functional interaction protocol model for peripherals is constructed through protocol reverse analysis. Based on the constructed results, peripheral compatibility testing and stress testing under abnormal scenarios are performed through the functional interaction protocol model.

2. The application testing method based on the HarmonyOS operating system according to claim 1, characterized in that, The step of generating differentiated test cases for different device types based on the dynamic test list and the device capability matrix includes: Based on the device capability matrix, extract the screen resolution, sensor list, and distributed connection protocol of each terminal device; Each functional module in the dynamic test list is matched with the screen resolution, sensor list, and distributed connection protocol of the terminal device, and the matching result is determined. If the matching result is successful, it is determined that the functional module can be tested on the current device. The interface layout test instruction is generated according to the screen resolution of the current device, the sensor call test instruction is generated according to the sensor list, and the device collaboration test instruction is generated according to the distributed connection protocol. The interface layout test instructions, sensor call test instructions, and device collaboration test instructions are combined to form a test subset of the functional module on the current device; If the matching result is a failure, it is determined that the functional module is not testable on the current device, and the generation of test cases for the functional module on the current device is skipped. For all functional modules in the dynamic test list and all terminal devices in the device capability matrix, perform iterative processing, summarize the test subsets generated on each device, and form a differentiated test case library covering multiple device forms.

3. The application testing method based on the HarmonyOS operating system according to claim 1, characterized in that, The steps include: constructing a functional interaction protocol model for the peripheral device through reverse engineering based on the differentiated test cases; and performing peripheral device compatibility testing and stress testing under abnormal scenarios based on the constructed result. From the differentiated test cases, identify the target peripheral categories that need to be tested for peripheral interaction. For each target peripheral category, obtain the interaction protocol data between it and the HarmonyOS system through protocol reverse analysis. The interaction protocol data includes at least the instruction set, data format, and status response code. Based on the interaction protocol data, construct the functional interaction protocol model and establish a performance baseline based on historical interaction data; Based on the differentiated test cases, extract test tasks related to peripheral device interaction; Based on the functional interaction protocol model and the performance baseline, generate a peripheral test instruction sequence for each test task; In the HarmonyOS distributed environment, the peripheral device test instruction sequence is executed by the functional interaction protocol model, the actual response data of the peripheral device is recorded, and the actual response data is compared and analyzed with the performance baseline. In the HarmonyOS distributed environment, the functional interaction protocol model injects protocol anomaly data or simulates abnormal states in the distributed environment into the peripheral device test instruction sequence, and drives the execution of long-term stress tests to monitor the stability and resource consumption of the peripheral devices.

4. The application testing method based on the HarmonyOS operating system according to claim 1, characterized in that, The steps of parsing the function list of the target HarmonyOS application and identifying the relationships between function modules include: The code structure and application configuration files of the target HarmonyOS application are analyzed to extract the declarative dependencies between functional modules and form a static dependency graph. Run the target HarmonyOS application and monitor the module interaction behavior during runtime. The monitored objects include messages transmitted through the event bus, dynamically loaded modules, and cross-process or cross-device communication through the HarmonyOS distributed soft bus. Analyze the monitored cross-process or cross-device communication data and deconstruct it into business call relationships between functional modules; By integrating the static dependency graph, the monitored message interaction relationships, and the business call relationships obtained through reverse decomposition, an interaction topology graph is generated to represent the complete association relationship between functional modules.

5. The application testing method based on the HarmonyOS operating system according to claim 1, characterized in that, The steps for constructing the device capability matrix include: Collect baseline capability data of the screen, sensors and distributed connections of each terminal device, and initialize the device capability matrix based on the baseline capability data; When a change in the screen shape of a terminal device is detected, the changed screen shape parameters and their corresponding actual display area and pixel density are collected and updated to the corresponding entries in the device capability matrix. When a change in the available operating mode of the terminal device's sensor is detected, the accuracy, sampling rate, and power consumption parameters of each mode are collected and updated to the corresponding entries in the device capability matrix. When a distributed connection is established between terminal devices or the link status changes, the protocol details, encoding / decoding format, and real-time link quality data of the connection are collected and updated to the corresponding entries in the device capability matrix. Based on the baseline capability data and continuously updated dynamic data, a dynamically evolving device capability matrix is ​​determined.

6. The application testing method based on the HarmonyOS operating system according to claim 3, characterized in that, The step of constructing a functional interaction protocol model for the peripheral device through reverse engineering based on the differentiated test cases, and performing peripheral device compatibility testing and stress testing under abnormal scenarios based on the constructed results and the functional interaction protocol model, further includes: During the continuous interaction between the target peripheral and the HarmonyOS system, interaction protocol data generated under different system states or task loads is collected, and the accompanying state parameters when collecting the interaction protocol data are recorded. The collected interaction protocol data is analyzed for patterns to identify the various protocol working modes supported by the peripheral device. Based on the change sequence of the accompanying state parameters and protocol working modes, analyze the conversion and triggering relationship between different protocol working modes; Based on the aforementioned multiple protocol working modes and the aforementioned conversion and triggering relationships, a protocol state map is constructed to describe the complete protocol capabilities of the peripheral device. Based on the protocol state graph, a set of test tasks covering the working modes of the various protocols and the transitions between modes is generated to guide peripheral compatibility testing and stress testing under abnormal scenarios.

7. The application testing method based on the HarmonyOS operating system according to claim 6, characterized in that, The step of analyzing the transition and triggering relationship between different protocol working modes based on the change sequence of the accompanying state parameters and protocol working modes includes: Extract any two adjacent mode transition records from the change sequence of the protocol's working modes to form a transition sample set. Each transition sample includes the first working mode before the transition, the second working mode after the transition, as well as a snapshot of the state parameters and interaction event records when the transition occurs. The transformed sample set is divided into multiple transformation types based on the combination of working modes before and after the transformation; Based on the partitioning results, if in the snapshot of the state parameters corresponding to the conversion type, there is at least one parameter value that shows a continuous changing trend among multiple samples, then the range of change of that parameter is determined as the state condition that triggers the conversion of that type. If at least one predefined conversion instruction or event appears repeatedly in multiple samples in the interaction event record corresponding to the conversion type, then the instruction or event is determined as the event condition that triggers the conversion of that type. The analyzed state and event conditions are associated with the corresponding transformation types to construct a transformation and triggering relationship model between the protocol's working modes.

8. An application testing system based on the HarmonyOS operating system, characterized in that, include: The acquisition module is used to obtain the feature list of the target HarmonyOS application, parse the feature list of the target HarmonyOS application, and identify the relationship between the feature modules. The first generation module is used to generate a dynamic test list based on the aforementioned relationship; A construction module is used to construct a device capability matrix, which is used to characterize the screen characteristics, sensor configurations and distributed capabilities of multiple terminal devices. The second generation module is used to generate differentiated test cases for different device forms based on the dynamic test list and the device capability matrix. The testing module is used to construct a functional interaction protocol model for peripherals through reverse engineering based on the differentiated test cases. Based on the constructed results, peripheral compatibility testing and stress testing under abnormal scenarios are performed through the functional interaction protocol model.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images