Method and system for testing compatibility of a honkong application

Abstract

The application relates to a method and system for testing the compatibility of a Hongmeng application, comprising the following steps: collecting attribute data of a terminal device through a distributed device attribute library, and constructing a device capability map; obtaining a current version installation package of a target Hongmeng application, and extracting application metadata and application code features; performing matching reasoning through the device capability map to generate a compatibility test case set; executing the compatibility test case set, and collecting running performance data and stability data; performing compatibility evaluation based on the running performance data and the stability data, and generating a quantitative evaluation report; in summary, the application realizes deep matching reasoning of application features and device capabilities by constructing a device capability map, and effectively solves the problems of device coverage blind area, insufficient correlation analysis and missing dynamic pressure simulation in traditional testing methods by combining dynamic scene simulation and quantitative evaluation mechanisms in a distributed testing environment.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and system for testing compatibility of HarmonyOS applications. Background Technology

[0002] With the widespread application of the HarmonyOS operating system and its distributed capabilities, the device environment faced by the application ecosystem has become highly complex, encompassing a massive number of terminal device models, diverse hardware configurations, multiple versions of software systems, and distributed service scenarios with dynamic interactions between devices.

[0003] Currently, the compatibility verification process for HarmonyOS applications mainly relies on testers manually selecting a limited number of terminal devices and using general test scripts for basic functional verification. This traditional method relies excessively on the subjective experience of testers and is difficult to systematically cover the breadth and depth of differences in device capabilities and distributed interactions. This results in a large number of blind spots in the testing scope and cannot effectively cope with the combined complexity of hardware resource access patterns, system API call sequences, and distributed service call paths. At the same time, due to the lack of in-depth analysis of the intrinsic relationship between application metadata and device capabilities, the existing testing process only focuses on surface functional checks and cannot realistically simulate common dynamic stress scenarios in the user environment. This makes it difficult to trigger and identify deep-seated compatibility defects such as performance fluctuations and stability failures.

[0004] The aforementioned defects may cause a large number of potential problems to go undetected during the testing phase, only to be exposed on actual user devices after the application is launched. This not only results in a significant decline in user experience but also forces developers to invest additional resources in emergency fixes, greatly increasing maintenance and time costs. Summary of the Invention

[0005] To address the aforementioned shortcomings, this application provides a method and system for testing the compatibility of HarmonyOS applications.

[0006] The above-mentioned objective of this application is achieved through the following technical solution: A method for compatibility testing of HarmonyOS-based applications, including the following steps: Attribute data of terminal devices are collected through a distributed device attribute library, and a device capability map is constructed based on the attribute data. The nodes of the device capability map include device entities, hardware capabilities, software configurations, and distributed service characteristics. Obtain the current version installation package of the target HarmonyOS application, and extract application metadata and application code characteristics; By matching and reasoning application metadata and application code features through device capability maps, a set of compatibility test cases corresponding to the target HarmonyOS application is generated. Execute a set of compatibility test cases in a distributed testing environment and collect runtime performance and stability data of the target HarmonyOS application; Based on performance and stability data, a compatibility assessment of the target HarmonyOS application is conducted, and a quantitative assessment report is generated.

[0007] In a preferred embodiment, this application can be further configured as follows: the attribute data includes standardized capability data and non-standardized performance parameters; the step of collecting attribute data of terminal devices through a distributed device attribute library and constructing a device capability graph based on the attribute data, wherein the nodes of the device capability graph include device entities, hardware capabilities, software configurations, and distributed service characteristics, includes the following steps: Standardized capability data of terminal devices are collected through a distributed device attribute library, and the corresponding hardware specification information of the terminal devices is obtained. Non-standardized performance parameters in the hardware specification information are then extracted. A basic attribute layer with equipment as the entity is constructed based on standardized capability data and non-standardized performance parameters; Obtain the technical specifications of HarmonyOS distributed services and define device capability rules based on the technical specifications. Logical reasoning is performed on the basic attribute layer based on device capability rules to generate a relationship layer representing the interaction capabilities between devices. A device capability map is constructed based on the basic attribute layer and the relationship layer.

[0008] In a preferred embodiment, this application can be further configured such that, before the step of performing logical reasoning on the basic attribute layer based on device capability rules to generate a relationship layer representing the interaction capabilities between devices, the application further includes the following step: Based on the device entities in the basic attribute layer, associate and generate the corresponding list of mainstream applications; Based on the device entity and the list of mainstream applications, obtain the corresponding multi-source text data; Natural language processing technology is used to parse multi-source text data, identify and extract compatibility behavior patterns, transform them into implicit capability rules, and incorporate the implicit capability rules into device capability rules.

[0009] In a preferred embodiment, this application can be further configured as follows: the step of generating a compatibility test case set corresponding to the target HarmonyOS application by matching and reasoning application metadata and application code features through device capability maps includes the following steps: Identify the device requirement and capability information in the application metadata, match the device requirement and capability information with the device entities in the device capability map, and filter out the initial set of devices that meet the basic operating conditions. Analyze the characteristics of the application code to identify the call sequence of system APIs, hardware resource access patterns, and potential distributed service call paths; Based on the identified hardware resource access patterns, infer the combination of device capabilities and interaction scenarios in the initial set of devices that have potential compatibility conflicts. The inferred combinations of device capabilities and interaction scenarios are parameterized into test scripts, and key parameters in the test scripts are automatically mutated to generate a set of compatibility test cases.

[0010] In a preferred embodiment, this application may be further configured as follows: after the steps of parameterizing the inferred combination of device capabilities and interaction scenarios into test scripts, and automatically mutating the key parameters in the test scripts to generate a set of compatibility test cases, the application further includes the step of: Obtain the market share of each device node in the device capability map, identify the execution frequency of critical paths in application code characteristics, obtain historical test cases and identify the defect detection rate of historical test cases; Based on market share, critical path execution frequency, and defect detection rate, calculate the priority weight of each test case in the compatibility test case set; Based on pre-set resource allocation strategies and priority weights, execution scheduling instructions with execution priorities are generated for the compatibility test case set.

[0011] In a preferred embodiment, this application can be further configured as follows: the step of executing a set of compatibility test cases in a distributed testing environment and collecting runtime performance data and stability data of the target HarmonyOS application includes the following steps: Deploy a chaos injection controller in a distributed testing environment, and execute corresponding injection operations through the chaos injection controller according to the distributed interaction scenarios defined in the compatibility test case set. The injection operations include network disturbance injection, resource contention injection, and distributed service disturbance injection. During the injection operation, the runtime performance data and stability data of the target HarmonyOS application are monitored and collected simultaneously. When operational performance data deviates from a preset operational performance threshold or stability data deviates from a preset stability threshold, an adaptive fault injection adjustment mechanism is triggered, wherein the adaptive fault injection adjustment mechanism includes: Identify the injection parameter combinations that cause deviations in the injection operation and set the identified injection parameter combinations as the compatibility risk threshold. The compatibility risk threshold is associated with application code characteristics and defined as a compatibility risk pattern. The compatibility risk pattern is then added as a new attribute to the corresponding device entity and updated in the device capability map.

[0012] In a preferred embodiment, this application can be further configured such that: each test case in the compatibility test case set is associated with a corresponding combination of device capabilities; the step of performing a compatibility assessment of the target HarmonyOS application based on runtime performance data and stability data, and generating a quantitative assessment report, includes the following steps: Based on operational performance data and stability data, the performance dispersion of the target HarmonyOS application for each combination of device capabilities is calculated. Device capability combinations whose performance dispersion exceeds a preset dispersion threshold are marked as adversarial verification combinations; An adversarial test objective function is constructed for the adversarial verification combination, the adversarial test objective function aiming to maximize application performance fluctuations or trigger stability failures; Based on the adversarial testing objective function, a preset optimization search algorithm is used to generate extreme test cases; Based on the execution results of the extreme test cases, determine the stable operating boundary of the target HarmonyOS application for each combination of device capabilities, and generate an adversarial verification report.

[0013] The second objective of this invention is achieved through the following technical solution: A HarmonyOS-based application compatibility testing system includes: The graph construction module is used to collect attribute data of terminal devices through a distributed device attribute library and construct a device capability graph based on the attribute data. The nodes of the device capability graph include device entities, hardware capabilities, software configurations and distributed service characteristics. The feature extraction module is used to obtain the current version installation package of the target HarmonyOS application and extract application metadata and application code features; The test case generation module is used to match and reason about application metadata and application code features through device capability graphs to generate a set of compatibility test cases for the target HarmonyOS application. The test case execution module is used to execute a set of compatibility test cases in a distributed testing environment and collect runtime performance and stability data of the target HarmonyOS application. The compatibility assessment module is used to assess the compatibility of target HarmonyOS applications based on runtime performance data and stability data, and generate a quantitative assessment report.

[0014] This application also relates to a computer device, 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 implement the steps of the HarmonyOS-based application compatibility testing method described above.

[0015] This application also relates to a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described HarmonyOS application compatibility testing method.

[0016] In summary, the HarmonyOS application compatibility testing method and system provided in this application achieve deep matching and reasoning between application features and device capabilities by constructing a device capability map. Combined with dynamic scenario simulation and quantitative evaluation mechanisms in a distributed testing environment, it effectively solves the problems of device coverage blind spots, insufficient correlation analysis, and lack of dynamic stress simulation in traditional testing methods. It achieves comprehensive coverage of device capability differences and distributed interaction scenarios, while deeply analyzing the intrinsic relationship between application metadata and device capabilities, and realistically simulating dynamic stress environments to effectively identify deep-seated compatibility defects. Attached Figure Description

[0017] Figure 1 This is a flowchart of an embodiment of a HarmonyOS application compatibility testing method according to this application; Figure 2 This is a flowchart of an implementation of step S10 in an embodiment of a HarmonyOS application compatibility testing method of this application; Figure 3 This is a flowchart of step S30 in an embodiment of the HarmonyOS application compatibility testing method of this application. Detailed Implementation

[0018] The following is in conjunction with the appendix Figures 1-3 This application will be described in further detail.

[0019] In traditional HarmonyOS application compatibility testing, the complexity of the device environment involves a massive number of device models, differences in hardware configurations, diversity of software versions, and the dynamic characteristics of distributed interactions between devices. The testing methods primarily rely on testers manually selecting a limited number of terminal devices and executing general test scripts. This existing testing method is highly dependent on personal experience and struggles to systematically cover a vast array of device combinations and interaction scenarios, resulting in test coverage being limited to specific device types. Furthermore, because existing testing methods lack in-depth analysis of the relationship between application characteristics and device capabilities, the testing process cannot effectively simulate resource contention and network fluctuations in a real user environment. This makes it difficult to trigger deep-seated compatibility defects, affecting the completeness of test results and the accuracy of application stability assessments.

[0020] For example, when testing a HarmonyOS video playback application that supports multi-device collaboration, testers selected mainstream mobile phones and tablets for verification based on experience. However, they did not include the interaction scenario between low-end memory-configured mobile phones and high-resolution display devices in a weak network environment. During the test execution, because network fluctuations and resource competition between devices were not simulated, memory management anomalies during device switching were not detected. This resulted in frequent interruptions in the application's operation in real-world user environments after its release, thus affecting users' normal use of the application's functions.

[0021] If the above issues are not addressed, compatibility defects will be exposed after the application deployment phase, which will weaken application stability, reduce user satisfaction, and increase the maintenance burden on developers. At the same time, unidentified deep defects may have a lasting negative impact on the overall reliability of the HarmonyOS application ecosystem and hinder the widespread application of distributed capabilities.

[0022] In one embodiment, such as Figure 1 As shown, this application discloses a compatibility testing method for HarmonyOS applications, which specifically includes the following steps: S10: Collect attribute data of terminal devices through a distributed device attribute library, and construct a device capability map based on the attribute data. The nodes of the device capability map include device entities, hardware capabilities, software configurations, and distributed service characteristics. In this embodiment, the distributed device attribute library refers to a dynamically updated database or knowledge base. Its core function is to store and manage standardized description information of all terminal devices in the HarmonyOS ecosystem. In this embodiment, the distributed device attribute library differs from a simple device list; instead, it describes various attributes of devices in a standardized manner through a unified model or interface. It may be maintained by the HarmonyOS official team or formed by aggregating data reported by various device manufacturers. The device capability graph refers to a data model used to structurally represent the capabilities of terminal devices. Its nodes include device entities, hardware capabilities, software configurations, and distributed service characteristics. In practical applications, the device capability graph can be implemented using graph database technology, such as Neo4j or JanusGraph. The device entity serves as the central node, with hardware capabilities, software configurations, and distributed service characteristics acting as associated nodes. Alternatively, a relational database table structure can be defined, such as using MySQL tables to store the mapping relationship between device entities and capability attributes. The device entity table records device model information, the hardware capability table stores processor performance parameters, the software configuration table records operating system versions, and the distributed service characteristic table describes the communication capabilities between devices. For example, a "device A" node can connect to an "NPU computing power" node through an "ownership" relationship, while the "NPU computing power" node may connect to a "specific driver version" node through a "dependency" relationship. This graph structure enables the computer to perform logical reasoning and discover potential compatibility constraints between devices.

[0023] S20: Obtain the current version installation package of the target HarmonyOS application and extract application metadata and application code characteristics; In this embodiment, the target HarmonyOS application refers to the application being tested, specifically developed for the HarmonyOS operating system (especially its distributed characteristics). It specifically refers to the application being tested in the current task. These applications are typically developed using the HarmonyOS SDK and can utilize unique capabilities such as distributed soft bus and distributed data management to achieve cross-device service flow, data synchronization, and multi-device collaboration. Application metadata refers to declarative data embedded in the application installation package that describes the application's own information and operational requirements. Application metadata is usually stored in a fixed configuration file and can be extracted without running the application. Application metadata includes application identity information, permission declarations, and device capability requirements. Application code features refer to deep information extracted from the executable code and resources of the application installation package through static or dynamic analysis techniques, reflecting its inherent technology choices and behavioral patterns. Application code features may contain implicit dependencies not declared in the metadata.

[0024] Furthermore, application code characteristics include: API call sequence: The system APIs actually called in the code, especially sensitive APIs related to distributed capabilities and hardware access; Resource usage patterns: such as the adaptation of images and layout files to different screen densities and sizes, reflecting UI compatibility; Dynamic behavioral characteristics: These are characteristics analyzed at runtime, such as the use of specific hardware instruction sets, thread models, and memory allocation strategies.

[0025] S30: By matching and reasoning application metadata and application code features through the device capability map, a set of compatibility test cases corresponding to the target HarmonyOS application is generated; In this embodiment, the matching inference process refers to the operation of comparing application metadata and application code features with the device capability map to generate a compatibility test case set. Specifically, matching can be performed based on a rule engine, such as the Drools rule engine, which parses application requirements and matches device capabilities; or the matching degree between application features and device capabilities can be calculated through semantic analysis technology, such as using natural language processing tools to extract application description keywords and perform similarity calculations with device capability tags. For example, the inference might be: if the application declares that it needs "feature X", and "feature X" depends on "system API version ≥ 7", then any device with a system version lower than 7 will be marked as "incompatible". The compatibility test case set refers to the set of test tasks automatically generated through matching inference.

[0026] S40: Execute compatibility test case sets in a distributed testing environment and collect runtime performance and stability data of the target HarmonyOS application; In this embodiment, operational performance data refers to quantitative indicators collected by monitoring tools during the test execution process that reflect the resource utilization efficiency and task processing speed of the target HarmonyOS application under a specific combination of device capabilities. Operational performance data is usually dynamic and quantifiable; it includes resource consumption, response efficiency, throughput, etc. Stability data refers to indicators collected during the test execution process that reflect the target HarmonyOS application's ability to continuously provide normal services and its fault tolerance and recovery capabilities; it includes fault indicators, recovery indicators, state consistency, etc.

[0027] S50: Based on runtime performance data and stability data, perform compatibility assessments on target HarmonyOS applications and generate quantitative assessment reports.

[0028] In this embodiment, compatibility assessment refers to a comprehensive analysis process that determines the overall adaptability of a target HarmonyOS application in the HarmonyOS device ecosystem based on collected operational performance data and stability data, combined with predefined compatibility standards (such as performance thresholds, stability baselines, etc.). The quantitative assessment report is the final output of the compatibility assessment process. It is usually a structured document with data as the core evidence. Its core characteristics are objectivity and measurability, providing direct support for decision-making.

[0029] Furthermore, quantitative assessment reports typically include: Overall rating and grade: One or more quantified compatibility scores or grades, for example: a compatibility score of 92 / 100 and a rating of A; Detailed breakdown by dimension: A detailed comparison of performance and stability data across different device types (such as mobile phones, watches, and tablets) and different distributed scenarios; Issue list and risk warning: Clearly list the discovered compatibility defects and prioritize them according to their severity and impact on user experience; Decision recommendations: Based on the data, provide clear conclusions, such as "the current version has met the release standards", "it is recommended to prioritize fixing a certain defect on a certain device", or "performance optimization is needed on a certain type of low-end device", etc.

[0030] Specifically, this application effectively solves the problems of limited coverage and inability to simulate complex real-world user environments through the aforementioned solution. Specifically, the structured representation of the device capability map avoids reliance on human experience, enabling multi-faceted modeling of massive device models, hardware configurations, software versions, and distributed interaction scenarios. The matching inference mechanism starts from the application's own needs, accurately identifying potential conflicts in hardware resource access patterns and distributed service call paths, generating test cases covering basic operating conditions and complex interaction scenarios. Tests are executed in a distributed testing environment, collecting performance and stability data to ensure the testing process simulates real-world user environments. A quantitative evaluation report generated based on the collected data transforms test results into objective and quantifiable indicators, helping to pinpoint the root cause of problems.

[0031] As a preferred implementation, compatibility test case sets can be generated by an automated testing framework, such as defining parameterized test scripts based on the JUnit framework, thereby improving test execution efficiency.

[0032] For example, as a specific implementation, a HarmonyOS video conferencing application is tested. A distributed device attribute library collects attribute data from terminal devices such as a Huawei smartphone and an Honor tablet, including hardware capabilities such as processor model and memory capacity, software configuration (e.g., HarmonyOS 3.0 version), and distributed service features (e.g., multi-device collaboration capabilities). Based on this data, a device capability graph is constructed, where device entity nodes are associated with corresponding hardware capabilities, software configurations, and distributed service features. The installation package of the target HarmonyOS application is obtained, and application metadata (e.g., minimum required OS version 3.0, support for 1080p video) and application code characteristics (e.g., camera API call sequences, network resource access patterns) are extracted. Matching and reasoning are performed using the device capability graph to identify the device requirement capability information in the application metadata and match it with the device entities in the device capability graph, filtering out an initial set of devices that meet the basic operating conditions. Simultaneously, application code characteristics are analyzed to identify hardware resource access patterns, inferring potential compatibility conflict combinations and interaction scenarios of device capabilities in the initial device set, thereby generating a compatibility test case set, including simulating multi-device video calls and network fluctuation scenarios. In a distributed testing environment comprised of the aforementioned devices, a set of compatibility test cases is executed, collecting performance data such as frame rate and latency, as well as stability data such as the number of crashes. Based on the collected data, parameters such as performance dispersion are calculated to evaluate the target HarmonyOS application and generate a quantitative evaluation report, indicating compatibility issues under specific device combinations.

[0033] Therefore, this embodiment of the solution achieves comprehensive coverage of diverse device environments and complex distributed interaction scenarios by systematically integrating device capabilities and application characteristics, effectively solving the problem of limited test coverage. The test cases generated by matching inference can simulate complex situations in real user environments, thereby triggering deep-seated compatibility defects and avoiding the limitations of traditional testing methods that only stay at the level of basic function verification. The final generated quantitative evaluation report provides objective evidence to help developers quickly locate the root cause of problems and significantly reduce the user experience risks and maintenance costs caused by compatibility issues after application release.

[0034] In one embodiment, the attribute data includes standardized capability data and non-standardized performance parameters, such as... Figure 2 As shown, step S10 includes: S11: Collect standardized capability data of terminal devices through a distributed device attribute library, obtain the corresponding hardware specification information of the terminal devices, and extract non-standardized performance parameters from the hardware specification information. In this embodiment, standardized capability data refers to device capability information that can be obtained through standard interfaces (such as device management services) provided by the HarmonyOS official website. Standardized capability data has a high degree of standardization and comparability, and is the basis for device compatibility. For example, screen resolution, memory size, operating system version number, and supported distributed protocol versions obtained through standard APIs. Hardware specification information refers to technical documents or data sets officially released or provided by the device manufacturer to accurately and completely describe the hardware components, technical indicators, performance parameters, interface specifications, and electrical characteristics of its products. Non-standardized performance parameters refer to in-depth parameters that cannot be directly obtained from standardized interfaces and need to be extracted from other channels (such as hardware specification manuals and white papers of device manufacturers) or obtained through actual testing. These parameters can reflect the performance boundaries of the device. Non-standardized performance parameters are often a deepening and quantitative supplement to capability-related data, revealing the true performance of the device under specific loads. For example, the continuous rendering frame rate stability of the GPU, the sensor accuracy under different working conditions, and the power consumption and heat generation of a specific chipset when decoding high bitrate video.

[0035] For example, hardware specification information typically includes: Component List and Basic Parameters: Clearly list all the core hardware components included in the device, such as: Processor: Specific model, number of cores, clock speed, architecture; Graphics Processing Unit (GPU): Specific model, number of rendering cores, and supported graphics API versions; Memory and storage: type, capacity, speed; Screen: Specific size, resolution, refresh rate, and material; Sensors: Specific models and accuracy of gyroscopes, accelerometers, magnetometers, light sensors, proximity sensors, etc.; Communication module: Specific chip models and supported standards for cellular network (5G / 4G), Wi-Fi, Bluetooth, GPS, etc.

[0036] Performance boundaries and characteristic parameters: These describe the performance of a component under specific conditions and are typically the primary source of non-standardized performance parameters, such as: Performance boundaries: the sustained performance of CPU / GPU under different power limits, and the battery life under different usage scenarios; Key features: camera sensor aperture size, focal length, supported focusing methods (e.g., laser autofocus, phase detection autofocus); speaker output power, frequency response range; Interfaces and Connectivity: Defines in detail the physical and electrical characteristics of the hardware interface, such as USB interface type, video output capability, headphone jack specifications, etc.

[0037] S12: Construct a basic attribute layer with equipment as the entity based on standardized capability data and non-standardized performance parameters; In this embodiment, the basic attribute layer refers to the data foundation layer of the device capability map. Essentially, it is a structured database. Its core is to treat each terminal device as an independent entity and to mount and associate the acquired standardized capability data and non-standardized performance parameters as attributes of the entity. The basic attribute layer mainly describes the static attributes of the device.

[0038] S13: Obtain the technical specification information of HarmonyOS distributed services and define device capability rules based on the technical specification information; In this embodiment, HarmonyOS Distributed Services refers to a basic capability framework and runtime environment provided by the HarmonyOS operating system to achieve cross-device collaboration. It allows a HarmonyOS application to decompose its own functions into multiple independent service modules and distribute these service modules to run on other HarmonyOS devices under the same network, thereby jointly completing a complex task. Technical specification information refers to the set of technical documents and standards officially released to clearly define how "HarmonyOS Distributed Services" works, how applications can access it, and what rules need to be followed. Device capability rules refer to the constraints and reasoning criteria on the logical relationships between device capabilities defined by the HarmonyOS Distributed technical specifications. Device capability rules are usually defined by converting the textual descriptions in the official technical documents into logical statements that can be understood and executed by computers. For example, it can be defined as: "To support the 'cross-device camera call' function, the device needs to have 'camera hardware' capabilities, and the 'distributed soft bus' protocol version on it must be greater than or equal to 2.0."

[0039] For example, typical services of HarmonyOS distributed services include: Distributed soft bus: the underlying communication infrastructure, responsible for automatic device discovery, high-speed connection and data transmission, and serves as the "pipeline" for other distributed services; Distributed data management: Provides cross-device data synchronization and sharing capabilities, ensuring that user data remains consistent across multiple devices; Distributed device virtualization: virtualizes the capabilities of remote devices (such as cameras) as local resources for applications to directly access; Distributed task scheduling: intelligently migrates tasks (such as continuing reading or navigation) to the most suitable device based on factors such as device location, status, and load.

[0040] Technical specifications include: API Interface Specification: Clearly defines which programmable interfaces (APIs) each distributed service provides, as well as the methods, parameters, and return values ​​for calling these interfaces; Protocol and process specifications: These specifications detail the communication protocols and interaction processes that must be followed during the establishment of connections between devices, service discovery, task migration, and data synchronization. Capability and Constraint Declarations: Defines which permissions and capabilities an application needs to declare in its application configuration file to use a distributed service, as well as the prerequisites (such as minimum system version requirements) that need to be met. Security and Access Control Model: Defines the authentication, data encryption, and user authorization mechanisms for cross-device access to ensure the security of the collaboration process.

[0041] S14: Perform logical reasoning on the basic attribute layer based on device capability rules to generate a relationship layer representing the interaction capabilities between devices; In this embodiment, logical reasoning refers to the automated logical operation and path exploration on the device capability map based on device capability rules, thereby discovering implicit, non-explicit compatibility relationships (such as dependencies, conflicts, and compatibility) between devices, which is not just a simple attribute matching.

[0042] S15: Construct a device capability map based on the basic attribute layer and the relationship layer.

[0043] In this embodiment, the relationship layer refers to the network structure generated after logical reasoning by executing device capability rules, which describes how device entities interact and associate. The relationship layer consists of nodes (devices) and edges (relationships). The types of edges can include "cooperative", "dependent", "conflicting", etc. For example, through rule reasoning, the system can establish a "cooperative distributed audio call" relationship edge between "device A" with a high-performance microphone and "device B" with a high-quality speaker. The relationship layer transforms the device capability graph from a static device list into a dynamic interactive network.

[0044] Specifically, the process begins by collecting standardized capability data from terminal devices through a distributed device attribute library, and extracting non-standardized performance parameters from hardware specifications. This ensures that the device attribute data covers both the standard capabilities defined in the specifications and incorporates real-world hardware performance differences. Next, a basic attribute layer is constructed based on the standardized capability data and non-standardized performance parameters, with devices as the entities, forming a structured representation of device capabilities. Then, technical specification information for HarmonyOS distributed services is obtained, and device capability rules are defined to closely align with the distributed characteristics of the system. Following this, logical reasoning is performed on the basic attribute layer based on the device capability rules to generate a relationship layer representing the interaction capabilities between devices, thereby deriving resource collaboration or conflict scenarios for devices in distributed services. Finally, the basic attribute layer and the relationship layer are integrated to construct a device capability graph, providing a comprehensive description of device capabilities for compatibility testing. This layered construction mechanism organically combines static attributes with dynamic interaction capabilities, enabling the device capability graph to accurately reflect the actual performance and potential compatibility risks of devices in complex environments.

[0045] For example, as a preferred embodiment, the solution of this application is implemented as follows: When testing a certain model of smartphone, the list of HarmonyOS APIs supported by the smartphone is collected through a distributed device attribute library as standardized capability data, and the actual processor frequency and memory bandwidth are extracted from the hardware specification document as non-standardized performance parameters; based on these data, a basic attribute layer is constructed, and the smartphone is treated as a device entity, associating its hardware capabilities and software configuration; the technical specifications of HarmonyOS distributed services are obtained, and device capability rules are defined, such as when a device supports distributed task scheduling and its memory capacity meets specific requirements, it can collaboratively process tasks; based on the device capability rules, logical reasoning is performed on the basic attribute layer to generate a relationship layer representing the scenarios in which devices can work collaboratively; finally, the basic attribute layer and the relationship layer are integrated to construct a device capability graph, which is used to generate compatibility test cases.

[0046] Through the above-mentioned approach, this application enables the device capability map to more realistically reflect the actual performance of terminal devices in complex environments, avoiding the distortion of environment simulation caused by relying solely on standardized data. At the same time, by generating inter-device interaction capabilities through systematic logical reasoning, it effectively captures compatibility risks in real interactions such as resource competition and network fluctuations, thereby significantly improving the coverage depth and breadth of compatibility test cases and ensuring that deep-seated compatibility defects are effectively discovered during the testing phase.

[0047] Furthermore, exemplarily, the following is a logical reasoning process in a specific context: Scenario 1 involves discovering compatible combinations, and the specific process includes: Known facts: Application X declares that it needs "cross-device flow" functionality, device A's "distributed soft bus version" is 3.1, and device B's version is 3.2; Reasoning process: According to the above rules, both versions of devices A and B meet the conditions; Reasoning result: It is inferred that "application X can move between devices A and B", which is a positive reasoning and has found a valid and testable interaction scenario.

[0048] Scenario 2 involves identifying incompatibility / conflict risks, and its specific process includes: Given the following facts: Application Y declares a need for "cross-device transfer" functionality; device C is version 3.0; device D is version 2.0. Reasoning process: Matching rules, it was found that the version of device D does not meet the conditions; Reasoning result: It is inferred that "application Y cannot achieve cross-device flow between device C and device D", or it is marked that this combination has a compatibility conflict risk. This is a conflict detection reasoning that helps to avoid testing blind spots in advance.

[0049] Scenario 3 involves discovering implicit dependencies, and its specific process includes: Known fact: There is another rule in the rule base: "Distributed soft bus version greater than or equal to 3.0" depends on "System version greater than or equal to HarmonyOS version 3.0"; Known fact: Device E's "System Version" is 2.0; Reasoning process (chain reasoning): Perform multi-step reasoning. First, since the system version of device E does not meet the conditions of the second rule, it is inferred that device E does not meet the requirement of "distributed soft bus version greater than or equal to 3.0". Therefore, it is inferred that device E cannot support the "cross-device transfer" function. Reasoning results: An implicit dependency was discovered, and a deep compatibility constraint can be inferred even though it is not directly stated in the application and device configuration files.

[0050] In some of the embodiments described above in this application, a device capability map is constructed by defining device capability rules based on technical specifications. However, in its implementation, relying solely on technical specifications may ignore compatibility behavior patterns existing in the actual user environment, resulting in incomplete device capability rules that cannot accurately reflect the device's interaction capabilities in real scenarios, thereby affecting the coverage and effectiveness of compatibility testing.

[0051] In this regard, this application further proposes that, in one embodiment, before step S14, the following steps are included: S131: Based on the device entities in the basic attribute layer, associate and generate the corresponding list of mainstream applications; In this embodiment, the mainstream application list refers to a collection of commonly used applications that are highly matched with the characteristics of the device entity. It can be generated by filtering from the app store's popular lists, the device's pre-installed application catalog, or user installation behavior statistics.

[0052] S132: Based on the device entity and the list of mainstream applications, obtain the corresponding multi-source text data; In this embodiment, multi-source text data refers to unstructured text information obtained from multiple different sources and channels, which includes actual user feedback. It may originate from social media platforms, developer community forums, or app store review libraries.

[0053] S133: Use natural language processing technology to parse multi-source text data, identify and extract compatibility behavior patterns, transform them into implicit capability rules, and incorporate the implicit capability rules into device capability rules.

[0054] In this embodiment, natural language processing technology refers to a method for automatically extracting structured knowledge from unstructured text, which can be implemented using a pre-trained language model based on the Transformer architecture or a rule matching engine. Compatibility behavior patterns specifically refer to the abnormal patterns exhibited by devices in distributed interactions. These can manifest as contextual features of application crashes or sequential patterns of service call failures under specific hardware configurations. For example, when descriptions such as "application A," "a certain model of sensor in device B," and "inaccurate readings" frequently appear simultaneously in the text, a pattern can be extracted: a specific sensor combination of application A and device B has data accuracy issues. Implicit capability rules refer to compatibility constraints extracted from user feedback that actually exist in the real-world ecosystem. Implicit capability rules are the result of formalizing and structuring the identified compatibility behavior patterns, enabling them to be understood and processed by computers, and ultimately incorporated into the device capability rule base. Implicit capability rules can be configured as logical expressions or decision tree rules to integrate into the device capability rule system.

[0055] Specifically, this embodiment integrates real user environment data during the device capability rule construction phase to dynamically improve the rule system. Before generating the relationship layer based on the basic attribute layer using logical reasoning, a list of mainstream applications is first generated based on device entity associations to ensure the relevance and representativeness of subsequent data collection. Subsequently, multi-source text data corresponding to the device entities and application lists is acquired. This multi-source text data covers real user interaction scenarios not recorded in the technical specifications. Natural language processing technology is used to parse the multi-source text data, automatically identifying and extracting compatibility behavior patterns, which reflect the actual performance of devices in distributed service calls. Finally, the compatibility behavior patterns are transformed into implicit capability rules and incorporated into the device capability rules, so that the rule system not only includes official technical specifications but also integrates empirical knowledge. Through this mechanism, it is ensured that when generating the relationship layer representing the interaction capabilities between devices, logical reasoning can be based on more comprehensive rules, thereby constructing a more accurate device capability map that reflects real-world scenarios.

[0056] For example, as a specific implementation method, the solution of this application is implemented as follows: When processing a smartphone device entity, a list of mainstream applications, including instant messaging applications and video playback applications, is generated; based on the device entity and the application list, multi-source text data is obtained from social media platforms and app store reviews; through natural language processing technology, the compatibility behavior pattern of "application crashes when switching between multiple tasks in a low memory state" is identified and transformed into an implicit capability rule of "limiting the depth of distributed service calls when the device memory capacity is below a threshold"; this implicit capability rule is then incorporated into the device capability rule for subsequent logical reasoning processes.

[0057] Through the above solution, this application can effectively make up for the limitations of relying solely on technical specifications for device capability rules, enabling the device capability map to more accurately depict the device interaction capabilities in real-world scenarios, thereby expanding the coverage of compatibility testing, reducing testing blind spots, and improving the relevance of test case generation and defect detection capabilities.

[0058] In some of the embodiments described above in this application, a method is proposed to generate a set of compatibility test cases by matching and reasoning application metadata and application code features through device capability graphs. However, in its implementation, relying solely on metadata matching may make it difficult to deeply explore potential hardware resource access conflicts and distributed service call risks in the application code, resulting in a narrow test case coverage. This makes it difficult to simulate complex interactions and resource competition scenarios that may occur in real user environments, thereby missing deep-seated compatibility defects and affecting the comprehensiveness and effectiveness of the test.

[0059] In this regard, this application further proposes: in one embodiment, as... Figure 3 As shown, step S30 includes: S31: Identify the equipment requirement and capability information in the application metadata, match the equipment requirement and capability information with the equipment entities in the equipment capability map, and filter out the initial set of equipment that meets the basic operating conditions. In this embodiment, the device requirement capability information refers to the device hardware specifications and software environment requirements declared in the application metadata. It can be implemented using the device compatibility declaration field in the application manifest file or runtime permission configuration information. The purpose is to accurately locate the basic compatible device range and avoid wasting test resources on unsupported devices. The initial device set refers to the set of all devices that can theoretically install and start the application after matching the application's device requirement capability information with the device entities in the device capability map. The initial device set is used as a candidate device list for subsequent in-depth testing.

[0060] S32: Analyze application code characteristics to identify system API call sequences, hardware resource access patterns, and potential distributed service call paths; In this embodiment, the system API call sequence refers to the order and combination pattern of applications calling HarmonyOS system APIs, identified through static or dynamic analysis of application code. The focus is on analyzing the call logic. For example, an application might first call `connectDevice()`, and then call `startStreaming()` in the callback function. A specific call sequence may implicitly contain specific dependencies on device state and resource allocation order, which can easily cause problems on incorrect devices or under concurrent conditions. Hardware resource access patterns refer to the application's use of hardware resources (such as CPU, memory, GPU, sensors, and network I / O) during runtime. Habits and patterns are usually derived by analyzing code characteristics, such as: intensive access (whether sensor data is continuously and frequently read in the rendering loop), exclusive access (whether the camera or microphone is occupied in exclusive mode, preventing other applications from using it), resource contention patterns (whether a large amount of memory is requested simultaneously in multiple threads), etc. Potential distributed service call paths refer to a series of continuous operation steps involving cross-device collaboration that the application may execute at runtime, inferred through static or dynamic analysis of the application code. These paths are not necessarily triggered every time the application runs, but they exist in the code structure and may be activated once certain conditions are met.

[0061] S33: Based on the identified hardware resource access patterns, infer the combination of device capabilities and interaction scenarios in the initial set of devices that have potential compatibility conflicts; In this embodiment, potential compatibility conflicts refer to compatibility issues between an application and a specific device or combination of devices that have not yet occurred but are highly likely to occur. Potential compatibility conflicts are a risk prediction based on logical reasoning, rather than a record of failures that have already occurred. Device capability combinations refer to a temporary combination of two or more terminal devices working together to complete a specific task in a distributed testing scenario. Interaction scenarios refer to a series of ordered and cross-device operation processes executed on a specific combination of device capabilities to achieve a specific user goal.

[0062] For example, potential compatibility conflicts may include: Resource conflict: The application code exhibits a high-frequency call pattern to the GPU (such as continuous rendering of complex 3D models), while the GPU driver of a certain device has a known heat dissipation bottleneck, which means there is a potential conflict of performance degradation or device overheating. Dependency conflict: A distributed call path of the application requires high-precision geographic coordinates, but the GPS module of the cooperating device has low accuracy, which means there is a potential data quality conflict.

[0063] For example, “phone A, smart screen B and speaker C” may constitute a combination of device capabilities for “cross-device video streaming and outputting high-quality audio”; “watch D and phone E” may constitute a combination of device capabilities for “health data synchronization and alarms”.

[0064] S34: Parameterize the inferred combination of device capabilities and interaction scenarios into test scripts, and automatically mutate the key parameters in the test scripts to generate a set of compatibility test cases.

[0065] In this embodiment, parameterization into a test script refers to transforming an abstract test scenario into an executable and concrete test script. Specifically, it involves extracting the inferred combination of device capabilities and variable factors in the interaction scenario as parameters. For example, a "cross-device file transfer" scenario can be parameterized as: source device type, target device type, file size, network type, etc. The test script is the logical flow for processing these parameters. Parameterization allows a script template to generate a large number of test cases covering different situations by passing in different parameter values. Automated mutation refers to systematically adjusting the test script parameters to generate variant test cases to cover various situations such as normal, boundary, and abnormal. This can be achieved by using a parameter perturbation strategy based on a genetic algorithm or by using directional mutation rules based on historical defect data. The purpose is to simulate edge conditions in a real environment and effectively trigger deep-seated compatibility issues.

[0066] Specifically, the process begins by matching the device requirement and capability information in the application metadata with the device capability map to select an initial set of devices that meet the basic operating conditions, thus defining the test scope. Next, a deep analysis of the application code characteristics is conducted to identify system API call sequences, hardware resource access patterns, and potential distributed service call paths, obtaining the application's runtime behavioral characteristics. Based on these behavioral characteristics, especially hardware resource access patterns, the system infers potential compatibility conflicts in the initial device set, including device capability combinations and interaction scenarios, transforming abstract risks into concrete and measurable scenarios. Finally, these scenarios are parameterized into test scripts, and diverse test cases are generated through automated mutation of key parameters. These steps form a closed-loop logical chain: the initial device set provides the target scope for code analysis, hardware resource access patterns provide the basis for conflict inference, and the parameterization and mutation process transforms risk scenarios into executable test cases, thus achieving a complete technical path from basic device selection to in-depth risk exposure.

[0067] For example, as a specific implementation method, the solution of this application is implemented as follows: When the target HarmonyOS application is a video conferencing application, its application metadata declaration requires camera and microphone support; by matching the device capability map, a set of devices with cameras and microphones is selected; analysis of the application code reveals that it frequently calls the high-resolution camera API and the real-time audio processing API; based on hardware resource access pattern reasoning, resource contention is likely to occur in device combinations with large differences in camera frame rates (such as high-end mobile phones and low-end tablets); these scenarios are parameterized into test scripts, such as setting camera resolution switching and network latency variation, to generate test cases for resource contention.

[0068] Through the above technical solutions, this application can deeply explore potential hardware resource access conflicts and distributed service call risks in application code, significantly expand the coverage of test cases, effectively simulate complex interaction and resource competition scenarios in real user environments, thereby reducing the omission of deep-seated compatibility defects and improving the comprehensiveness and effectiveness of testing.

[0069] In some of the embodiments described above in this application, priority weights are calculated and execution scheduling instructions are generated after generating compatibility test case sets to optimize test resource allocation. However, in this process, the test case sets may lack a comprehensive consideration mechanism for device popularity, frequency of use of core application functions, and efficiency of historical defect discovery, making it difficult to dynamically focus test resources on high-risk scenarios. Key compatibility issues may be missed due to priority confusion. Especially in the case of complex distributed device environments and limited test resources, it is difficult to efficiently identify stability defects that affect a wide range of users.

[0070] In this regard, this application further proposes that, in one embodiment, after step S34, the method further includes: S341: Obtain the market share of each device node in the device capability map, identify the execution frequency of critical paths in application code characteristics, obtain historical test cases and identify the defect detection rate of historical test cases; In this embodiment, market share refers to the distribution of device prevalence among the target user group. It can be obtained by integrating data from third-party market analysis platforms, device sales statistics, or user activity logs. The purpose is to match the test coverage with the actual distribution of user devices and avoid overlooking common compatibility issues by ignoring mainstream device types. Critical path execution frequency refers to the frequency with which the core business process in the target application is executed in typical user scenarios, as statistically determined through static code analysis or runtime profiling techniques. Critical path execution frequency can be understood as the frequency of calls to the application's core business logic in user operations. For example, for a shopping application, "browsing products, adding to cart, and payment" is a critical path. The execution frequency of this path is usually much higher than that of secondary functions such as "changing profile picture." Because compatibility issues of high-frequency execution paths will affect a wider range of users, they have a higher testing priority. The defect detection rate of historical test cases specifically refers to the probability that a certain historical test case has successfully revealed software defects in previous test cycles. It can be extracted by analyzing defect association records in the test report database or automated test result logs. The purpose is to screen high-risk detection points that have been verified in the past and avoid repeatedly executing inefficient test cases.

[0071] S342: Calculate the priority weight of each test case in the compatibility test case set based on market share, critical path execution frequency, and defect detection rate; In this embodiment, priority weight refers to a quantitative score synthesized by an algorithm to rank test cases for execution. It takes into account multiple dimensions, such as market impact, code importance, and historical performance, rather than just the tester's experience judgment. The higher the priority weight, the more important the test case is and the more it should be executed first.

[0072] S343: Generate execution scheduling instructions with execution priorities for the compatibility test case set based on the pre-set resource allocation strategy and priority weights.

[0073] In this embodiment, the pre-set resource allocation strategy refers to a predefined set of rules that guides how to allocate limited computing resources (such as test device time, network bandwidth, and execution time) to test cases of different priorities. For example, the resource allocation strategy can stipulate that "the test case group with a priority of 'high' is allocated 70% of the concurrent execution resources, and its execution time is allowed to exceed 150% of the standard time limit." The execution scheduling instruction can be understood as a set of instructions that control the execution order of test cases. It can be generated by the task queue management module or the resource scheduling engine. Its purpose is to dynamically coordinate limited test resources and test case priorities to ensure that high-risk scenarios are verified first. Furthermore, the execution scheduling instruction includes the execution order of test tasks, the number of concurrent tasks, resource quotas, timeout settings, etc. For example, "prioritize the concurrent execution of test case group X on device pool A, occupying 50% of the resources; after it is completed, execute test case group Y on device pool B." This realizes the automation and optimization of the testing process.

[0074] Specifically, the process begins by acquiring the market share of each device node in the device capability map, the critical path execution frequency in application code characteristics, and the defect detection rate of historical test cases. These data characterize testing risks from three dimensions: device prevalence, functional importance, and historical effectiveness. Subsequently, based on market share, critical path execution frequency, and defect detection rate, the priority weight of each test case is calculated. This quantitatively integrates the device user base, the intensity of core function usage, and historical defect discovery efficiency to form a comprehensive risk assessment index. Finally, combined with pre-set resource allocation strategies and priority weights, execution scheduling instructions are generated to dynamically adjust the execution sequence of test cases. This ensures that high-weight test cases receive priority execution resources when resources are scarce, thereby achieving precise allocation and efficient utilization of test resources in a distributed testing environment.

[0075] For example, as a specific implementation method, the solution of this application is implemented as follows: During the HarmonyOS application compatibility testing process, the device capability map includes three types of device nodes: smartphones, tablets, and smart TVs. Among them, the market share data of smartphone nodes is obtained by integrating industry market reports, showing that it covers more than 70% of the target user group; based on application code feature analysis, the video playback function is identified as a critical path, and its execution frequency is significantly higher than other functional modules; the test records for the video playback function in the historical test case library show a high defect detection rate; based on this, when calculating the test case priority weight, the test case for the video playback function on smartphones is assigned a higher weight value, and the execution scheduling instruction prioritizes the execution of this test case in the distributed test environment, ensuring that core functional scenarios affecting a wide range of users are verified first under limited test resources.

[0076] Through the above technical solutions, testing resources can be dynamically focused on high-risk scenarios with high device prevalence, frequent use of core application functions, and significant historical defect detection rates. This effectively reduces the occurrence of missed critical compatibility issues due to the lack of a priority mechanism. Especially in complex distributed device environments with limited testing resources, it significantly improves the efficiency of identifying stability defects affecting a wide range of users and the ability to optimize testing processes.

[0077] In one embodiment, step S40 includes: S41: Deploy a chaos injection controller in a distributed testing environment, and execute corresponding injection operations through the chaos injection controller according to the distributed interaction scenarios defined in the compatibility test case set. The injection operations include network disturbance injection, resource contention injection, and distributed service disturbance injection. In this embodiment, the chaos injection controller refers to a control module used to actively simulate fault environments. It can be implemented using a software agent or a hardware simulator, with the aim of accurately reproducing abnormal conditions in the user environment. The distributed interaction scenarios defined in the compatibility test case set refer to the cross-device task execution processes most likely to expose compatibility issues, accurately located based on intelligent analysis of application behavior and device capabilities. These distributed interaction scenarios are described in detail in the test cases, serving as "targets" or requirements for the chaos injection controller to perform fault injection. Injection operations refer to technical means of interfering with the normal operation of the system through specific mechanisms. These can be implemented by methods such as network latency injection, increased CPU load, or service interruption, with the aim of covering complex scenarios such as resource contention and network fluctuations. Injection operations include network disturbance injection, resource contention injection, and distributed service disturbance injection. Network disturbance injection refers to the chaos controller simulating various abnormal situations existing in a real network to test the resilience of the application under poor network conditions. The system's performance and fault tolerance capabilities are tested through various methods. Specific operations include: artificially creating network latency, packet loss, bandwidth limitations, and even simulating complete network connection interruptions and reconnections to verify whether the application can maintain basic functionality when network service quality degrades. Resource contention injection involves the chaos controller simulating a high-load environment on test equipment to create resource scarcity and observe application performance. Specific operations include: suddenly launching a disruptive process with high CPU / memory / disk I / O usage, or quickly switching foreground applications to simulate frequent memory swapping, aiming to expose stability issues when resources are preempted, such as sharp performance drops, stuttering, or crashes. Distributed service disturbance injection involves the chaos controller simulating failures in core services within a distributed architecture. Specific operations include: randomly terminating or restarting critical distributed services (such as distributed data management and device discovery services), simulating service response timeouts, or forging erroneous service status information, aiming to verify the application's fault tolerance and self-recovery capabilities when the foundation of the distributed system suffers problems.

[0078] S42: During the execution of the injection operation, synchronously monitor and collect the running performance data and stability data of the target HarmonyOS application; In this embodiment, synchronous monitoring and data collection refers to the process of real-time data capture at the same time as fault injection. This can be achieved using a distributed log collection system or a performance monitoring agent, with the aim of ensuring an accurate correlation between faults and performance fluctuations.

[0079] S43: When the operating performance data deviates from the preset operating performance threshold or the stability data deviates from the preset stability threshold, an adaptive fault injection adjustment mechanism is triggered, wherein the adaptive fault injection adjustment mechanism includes: Identify the injection parameter combinations that cause deviations in the injection operation and set the identified injection parameter combinations as the compatibility risk threshold. The compatibility risk threshold is associated with application code characteristics and defined as a compatibility risk pattern. The compatibility risk pattern is then added as a new attribute to the corresponding device entity and updated in the device capability map.

[0080] In this embodiment, the injection parameter combination refers to the set of configurable parameters used to implement the injection operation, which fully defines all the technical details of an "attack". The compatibility risk threshold refers to the injection parameter combination that causes a significant deviation in performance. It can be identified through parameter scanning or regression analysis methods to locate the specific conditions that trigger the fault. For example, the test results may show: "For video streaming application X, when the network latency is consistently higher than 450ms, its video frame rate will drop sharply from 60FPS to below 20FPS". This "450ms" is a specific risk threshold. The compatibility risk pattern refers to a reusable knowledge unit formed by associating the risk threshold with application code characteristics. Specifically, it refers to a reusable rule of experience formed by associating specific application code characteristics (such as a certain API call pattern), specific device capability combinations, and specific fault thresholds. For example, the risk pattern formed may be: "Applications using the VideoDecoder API with a buffer setting of less than 2MB have a high risk of performance degradation when the network latency is greater than 450ms on devices with less than 4GB of memory."

[0081] Specifically, this solution uses a chaotic injection controller to perform targeted fault injection based on the distributed interaction scenarios defined in the test cases, thereby proactively simulating anomalies in the real user environment. During the injection operation, performance and stability data are monitored simultaneously to ensure real-time correlation between fault injection and data acquisition, avoiding the omission of instantaneous fluctuations due to monitoring lag. When the monitored data deviates from a preset threshold, an adaptive fault injection adjustment mechanism is triggered. By identifying the specific injection parameter combinations that cause the deviation and setting them as compatibility risk thresholds, the fault triggering conditions are accurately located. Furthermore, the risk thresholds are associated with application code characteristics to define a compatibility risk pattern, which is then updated as a new attribute of the device entity in the device capability graph. This allows the device capability graph to dynamically accumulate historical risk experience, providing reusable intelligent decision-making basis for subsequent testing, thus forming a complete closed loop from fault simulation and data acquisition to knowledge accumulation.

[0082] For example, as a specific implementation method, the solution of this application is implemented as follows: When testing the HarmonyOS application that runs collaboratively between a smartwatch and a mobile phone, the chaos injection controller performs a network disturbance injection operation to simulate signal interruption according to the Bluetooth communication scenario defined in the test case, and simultaneously triggers a resource contention injection operation to simulate a high CPU load state; during the injection process, the application interface response latency and service crash logs are monitored in real time; when the response latency is detected to exceed a preset threshold, the adaptive fault injection adjustment mechanism identifies a specific combination of Bluetooth interruption duration and CPU utilization as a compatibility risk threshold, and associates this combination with the communication module call sequence in the application code, defining it as a compatibility risk mode; this risk mode is added as a new attribute of the smartwatch device entity and updated to the device capability map for subsequent priority adjustment of similar applications.

[0083] Through the above technical solution, this application achieves proactive simulation of complex fault scenarios such as resource competition and network fluctuations in real user environments, effectively triggering deep-seated compatibility defects and significantly improving the depth and adaptability of compatibility testing.

[0084] In some of the embodiments described above in this application, a compatibility assessment of the target HarmonyOS application based on runtime performance data and stability data is proposed, and a quantitative assessment report is generated. However, in the implementation process, relying solely on conventional performance indicators may not be able to effectively capture the performance fluctuation differences between device capability combinations, making it difficult for the assessment results to reflect the extreme compatibility risks of the application in a real distributed environment, and unable to accurately identify the boundary conditions of high-risk device combinations. As a result, compatibility verification lacks the ability to actively detect deep-seated defects.

[0085] In this regard, this application further proposes: In one embodiment, each test case in the compatibility test case set is associated with a corresponding combination of device capabilities, and step S50 includes: S51: Based on operational performance data and stability data, calculate the performance dispersion of the target HarmonyOS application for various combinations of device capabilities; In this embodiment, the device capability combination refers to the set of specific terminal device configurations associated with the compatibility test cases. It can be achieved by combining device entities, hardware capabilities, software configurations, and distributed service characteristics, with the aim of accurately characterizing the device environment of the test scenario. The performance dispersion refers to the degree of fluctuation in the performance and stability data of the target HarmonyOS application under different device capability combinations. It can be achieved by using statistical indicators such as standard deviation, variance, or coefficient of variation, with the aim of quantifying performance instability.

[0086] S52: Mark the device capability combinations whose performance dispersion is greater than the preset dispersion threshold as adversarial verification combinations; In this embodiment, the dispersion threshold refers to a preset performance fluctuation threshold, which can be achieved by statistical analysis of historical test data or by setting a dynamic threshold based on the distribution of equipment in the market. The purpose is to scientifically screen high-risk equipment combinations. The adversarial verification combination refers to a specific equipment capability combination that has high uncertainty or risk, identified based on the performance dispersion index. The adversarial verification combination is regarded as a key object that needs to be tested and stress verified in depth. The purpose of marking it is to concentrate limited testing resources on the key areas where problems can be found most effectively.

[0087] S53: Construct an adversarial test objective function for the adversarial verification combination, wherein the adversarial test objective function aims to maximize application performance fluctuations or trigger stability failures; In this embodiment, the adversarial testing objective function is a mathematical expression aimed at maximizing application performance fluctuations or triggering stability failures. It guides the generation of test cases, shifting the testing objective from "verifying functional correctness" to "actively seeking system vulnerabilities." This adversarial testing objective function maps the application's operational state (performance data, crash status, etc.) to a calculable score, optimizing to maximize "instability," i.e., pursuing the greatest performance fluctuations or directly triggering failures. The adversarial testing objective function can be constructed using a gradient optimization framework or reinforcement learning strategy, aiming to actively guide the testing process towards the failure boundary. Specifically, maximizing application performance fluctuations is a stress testing strategy whose goal is not to verify the application's stable performance, but rather to actively seek and amplify these vulnerabilities. Its performance instability, for example, involves intelligently adjusting various input parameters and environmental conditions (such as network latency, packet size, concurrent requests, system resource utilization, etc.) during the testing process, and observing the drastic changes in the application's performance indicators (such as response time, frame rate, CPU utilization, etc.). The goal is to find the parameter combination that causes the performance indicators to fluctuate or deteriorate the most. Specifically, triggering stability failures is a destructive testing strategy. Its goal is to actively induce various unexpected failures in the application, which is commonly referred to as "bug hunting". For example, during the testing process, various extreme, abnormal, or illogical combinations of inputs and states are tried to cause serious problems such as interruption of the application's core services, process crashes, unresponsiveness, data errors, or resource leaks.

[0088] S54: Based on the adversarial test objective function, limit test cases are generated using a preset optimization search algorithm; In this embodiment, the optimization search algorithm refers to an algorithm used to efficiently explore a large test input space to find test parameters that maximize the objective function value of adversarial testing. It can be implemented using algorithms such as particle swarm optimization or Bayesian optimization. Typically, the optimization search algorithm does not rely on exhaustive search but intelligently adjusts the search direction based on feedback, thereby efficiently discovering test parameter combinations that can reach the system boundary and unusual combinations, with the aim of quickly approximating the system's extreme conditions. Extreme test cases refer to test cases generated through adversarial testing. Extreme test cases simulate extreme, rare, but possible conditions. Their purpose is not to verify normal functionality but to detect the system's breakpoints and find its critical failure conditions. For example, simulating extreme network latency, the maximum number of concurrent users, resource exhaustion, and other scenarios.

[0089] S55: Determine the stable operating boundary of the target HarmonyOS application for each combination of device capabilities based on the execution results of the extreme test cases, and generate an adversarial verification report.

[0090] In this embodiment, the stable operating boundary refers to the core output of the adversarial verification process. Specifically, it is a precise quantitative description of the critical conditions under which an application can maintain stable or acceptable performance across various combinations of device capabilities. The stable operating boundary is usually defined by the threshold of one or more key parameters, such as defining the critical values ​​of network latency, data throughput, or resource consumption to clarify the parameter space for stable application operation. The adversarial verification report is a specialized analysis document generated based on the results of adversarial verification. Its core content does not list all test results, but focuses on explaining the application vulnerabilities discovered through extreme testing, the precisely measured stable operating boundary, and the root causes that lead to a sharp decline or failure of system performance.

[0091] Specifically, the process begins by calculating the performance dispersion of the target HarmonyOS application across various device capability combinations, quantifying the performance fluctuation differences under different device environments, and revealing the variation points masked by average indicators in conventional assessments. Then, based on a preset dispersion threshold, device capability combinations with performance dispersion exceeding limits are selected and marked as adversarial verification combinations, achieving precise focus of test resources. On this basis, an adversarial test objective function is constructed with the goal of maximizing performance fluctuations or triggering faults, proactively driving the testing process towards the system's extreme boundaries. Subsequently, an optimized search algorithm is used to efficiently search the test parameter space, generating extreme test cases that can approach the fault threshold. Finally, by executing the extreme test cases, the stable operating boundaries of the target HarmonyOS application under various device capability combinations are determined, forming an adversarial verification report containing boundary conditions, thus realizing a technological shift from passive assessment to proactive risk detection.

[0092] For example, as a preferred embodiment, the solution of this application is specifically implemented as follows: For compatibility testing of a HarmonyOS video conferencing application, the performance dispersion of the combination of mobile phone and smartwatch is identified as significantly higher than that of other combinations, and it is marked as an adversarial verification combination; an adversarial test objective function is constructed to maximize audio transmission delay fluctuation and trigger video rendering interruption; a particle swarm optimization algorithm is used to iteratively search parameters such as network jitter and Bluetooth connection strength to generate extreme test cases simulating extreme network fluctuations; after executing the test cases, it is observed that when network jitter continues to increase and Bluetooth connection strength is lower than a stable threshold, the application experiences audio and video desynchronization failure, thereby determining the stable operating boundary of the device capability combination and generating an adversarial verification report containing specific boundary conditions.

[0093] Through the above scheme, this application can effectively capture the performance fluctuation differences between equipment capability combinations, accurately identify the boundary conditions of high-risk equipment combinations, thereby enhancing the compatibility verification's ability to actively detect deep-seated defects and improving the applicability and reliability of the evaluation results in real distributed environments.

[0094] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0095] In one embodiment, a HarmonyOS-based application compatibility testing system is provided, which corresponds one-to-one with the HarmonyOS-based application compatibility testing method described in the above embodiments. The HarmonyOS-based application compatibility testing system includes: The graph construction module is used to collect attribute data of terminal devices through a distributed device attribute library and construct a device capability graph based on the attribute data. The nodes of the device capability graph include device entities, hardware capabilities, software configurations and distributed service characteristics. The feature extraction module is used to obtain the current version installation package of the target HarmonyOS application and extract application metadata and application code features; The test case generation module is used to match and reason about application metadata and application code features through device capability graphs to generate a set of compatibility test cases for the target HarmonyOS application. The test case execution module is used to execute a set of compatibility test cases in a distributed testing environment and collect runtime performance and stability data of the target HarmonyOS application. The compatibility assessment module is used to assess the compatibility of target HarmonyOS applications based on runtime performance data and stability data, and generate a quantitative assessment report.

[0096] For specific limitations regarding a HarmonyOS-based application compatibility testing system, please refer to the limitations of a HarmonyOS-based application compatibility testing method described above, which will not be repeated here. Each module in the aforementioned HarmonyOS-based application compatibility testing system 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, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0097] 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. When the processor executes the computer program, it implements a method for testing compatibility of HarmonyOS applications.

[0098] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements a method for testing compatibility of HarmonyOS applications.

[0099] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 this application, and should all be included within the protection scope of this application.

Claims

1. A method for testing the compatibility of HarmonyOS applications, characterized in that, Including the following steps: Attribute data of terminal devices are collected through a distributed device attribute library, and a device capability map is constructed based on the attribute data. The nodes of the device capability map include device entities, hardware capabilities, software configurations, and distributed service characteristics. Obtain the current version installation package of the target HarmonyOS application, and extract application metadata and application code characteristics; By matching and reasoning application metadata and application code features through device capability maps, a set of compatibility test cases corresponding to the target HarmonyOS application is generated. Execute a set of compatibility test cases in a distributed testing environment and collect runtime performance and stability data of the target HarmonyOS application; Based on runtime performance data and stability data, a compatibility assessment of the target HarmonyOS application is conducted, and a quantitative assessment report is generated. The step of generating a compatibility test case set corresponding to the target HarmonyOS application by matching and reasoning application metadata and application code features through device capability maps includes the following steps: Identify the device requirement and capability information in the application metadata, match the device requirement and capability information with the device entities in the device capability map, and filter out the initial set of devices that meet the basic operating conditions. Analyze the characteristics of the application code to identify the call sequence of system APIs, hardware resource access patterns, and potential distributed service call paths; Based on the identified hardware resource access patterns, infer the combination of device capabilities and interaction scenarios in the initial set of devices that have potential compatibility conflicts. The inferred combination of device capabilities and interaction scenarios are parameterized into test scripts, and the key parameters in the test scripts are automatically mutated to generate a set of compatibility test cases. The potential compatibility conflict refers to a compatibility issue between the application and a specific device or combination of devices that has not yet occurred but is highly likely to occur. The potential compatibility conflict includes resource conflicts and dependency conflicts.

2. The method for testing compatibility of HarmonyOS applications according to claim 1, characterized in that: The attribute data includes standardized capability data and non-standardized performance parameters. The step of collecting attribute data of terminal devices through a distributed device attribute library and constructing a device capability map based on the attribute data, wherein the nodes of the device capability map include device entities, hardware capabilities, software configurations, and distributed service characteristics, includes the following steps: Standardized capability data of terminal devices are collected through a distributed device attribute library, and the corresponding hardware specification information of the terminal devices is obtained. Non-standardized performance parameters in the hardware specification information are then extracted. A basic attribute layer with equipment as the entity is constructed based on standardized capability data and non-standardized performance parameters; Obtain the technical specifications of HarmonyOS distributed services and define device capability rules based on the technical specifications. Logical reasoning is performed on the basic attribute layer based on device capability rules to generate a relationship layer representing the interaction capabilities between devices. A device capability map is constructed based on the basic attribute layer and the relationship layer.

3. The method for testing compatibility of HarmonyOS applications according to claim 2, characterized in that: Before the step of performing logical reasoning on the basic attribute layer based on device capability rules to generate a relationship layer representing the interaction capabilities between devices, the following step is also included: Based on the device entities in the basic attribute layer, associate and generate the corresponding list of mainstream applications; Based on the device entity and the list of mainstream applications, obtain the corresponding multi-source text data; Natural language processing technology is used to parse multi-source text data, identify and extract compatibility behavior patterns, transform them into implicit capability rules, and incorporate the implicit capability rules into device capability rules.

4. The method for testing compatibility of HarmonyOS applications according to claim 1, characterized in that: After the steps of parameterizing the inferred device capability combinations and interaction scenarios into test scripts, and automatically mutating the key parameters in the test scripts to generate a set of compatibility test cases, the method further includes the following steps: Obtain the market share of each device node in the device capability map, identify the execution frequency of critical paths in application code characteristics, obtain historical test cases and identify the defect detection rate of historical test cases; Based on market share, critical path execution frequency, and defect detection rate, calculate the priority weight of each test case in the compatibility test case set; Based on pre-set resource allocation strategies and priority weights, execution scheduling instructions with execution priorities are generated for the compatibility test case set.

5. The method for testing compatibility of HarmonyOS applications according to claim 1, characterized in that: The steps of executing compatibility test case sets in a distributed testing environment and collecting runtime performance and stability data of the target HarmonyOS application include the following steps: Deploy a chaos injection controller in a distributed testing environment, and execute corresponding injection operations through the chaos injection controller according to the distributed interaction scenarios defined in the compatibility test case set. The injection operations include network disturbance injection, resource contention injection, and distributed service disturbance injection. During the injection operation, the runtime performance data and stability data of the target HarmonyOS application are monitored and collected simultaneously. When operational performance data deviates from a preset operational performance threshold or stability data deviates from a preset stability threshold, an adaptive fault injection adjustment mechanism is triggered, wherein the adaptive fault injection adjustment mechanism includes: Identify the injection parameter combinations that cause deviations in the injection operation and set the identified injection parameter combinations as the compatibility risk threshold. The compatibility risk threshold is associated with application code characteristics and defined as a compatibility risk pattern. The compatibility risk pattern is then added as a new attribute to the corresponding device entity and updated in the device capability map.

6. The method for testing compatibility of HarmonyOS applications according to claim 1, characterized in that: Each test case in the compatibility test case set is associated with a corresponding combination of device capabilities. The step of conducting a compatibility assessment of the target HarmonyOS application based on runtime performance data and stability data, and generating a quantitative assessment report, includes the following steps: Based on operational performance data and stability data, the performance dispersion of the target HarmonyOS application for each combination of device capabilities is calculated. Device capability combinations whose performance dispersion exceeds a preset dispersion threshold are marked as adversarial verification combinations; An adversarial test objective function is constructed for the adversarial verification combination, the adversarial test objective function aiming to maximize application performance fluctuations or trigger stability failures; Based on the adversarial testing objective function, a preset optimization search algorithm is used to generate extreme test cases; Based on the execution results of the extreme test cases, determine the stable operating boundary of the target HarmonyOS application for each combination of device capabilities, and generate an adversarial verification report.

7. A HarmonyOS-based application compatibility testing system, used to perform the steps of the HarmonyOS-based application compatibility testing method as described in any one of claims 1-6, characterized in that, include: The graph construction module is used to collect attribute data of terminal devices through a distributed device attribute library and construct a device capability graph based on the attribute data. The nodes of the device capability graph include device entities, hardware capabilities, software configurations and distributed service characteristics. The feature extraction module is used to obtain the current version installation package of the target HarmonyOS application and extract application metadata and application code features; The test case generation module is used to match and reason about application metadata and application code features through device capability graphs to generate a set of compatibility test cases for the target HarmonyOS application. The test case execution module is used to execute a set of compatibility test cases in a distributed testing environment and collect runtime performance and stability data of the target HarmonyOS application. The compatibility assessment module is used to assess the compatibility of target HarmonyOS applications based on runtime performance data and stability data, and generate a quantitative assessment report.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the HarmonyOS-based application compatibility testing method as described in any one of claims 1-6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the HarmonyOS-based application compatibility testing method as described in any one of claims 1-6.

Images