Compatibility testing method and system based on application program of swan Mongolia

Abstract

The invention relates to a compatibility testing method and system based on a swan gap application program, and the method comprises the steps: collecting the attribute data of terminal equipment through a distributed equipment attribute library, and constructing an equipment capability graph; obtaining a current version installation package of the target swan application, and extracting application metadata and application code features; matching reasoning is carried out through the equipment capability atlas, and a compatibility test case set is generated; executing the compatibility test case set, and collecting operation performance data and stability data; carrying out compatibility evaluation based on the operation performance data and the stability data, and generating a quantitative evaluation report; in conclusion, deep matching reasoning of application features and equipment capabilities is realized by constructing the equipment capability graph, and the problems of equipment coverage blind areas, insufficient association analysis and dynamic pressure simulation deficiency in a traditional test method are effectively solved in combination with a dynamic scene simulation and quantitative evaluation mechanism in a distributed test environment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a Harmony application compatibility testing method and system. BACKGROUND

[0002] With the wide application of the Harmony operating system and its distributed capabilities, the device environment faced by the application ecosystem presents high complexity, covering a large number of terminal device models, diversified hardware configurations, multi-version software systems, and distributed service scenarios of dynamic interaction between devices.

[0003] Currently, the compatibility verification process of the Harmony application mainly relies on test personnel to manually screen a limited number of terminal devices and uses general test scripts to verify basic functions. This traditional method excessively relies on the subjective experience of test personnel and is difficult to systematically cover the differences in device capabilities and the breadth and depth of distributed interaction, resulting in a large number of blind spots in the test range, which cannot effectively cope with the combination complexity of hardware resource access mode, system API call sequence, and distributed service call path. At the same time, due to the lack of in-depth analysis of the internal correlation between application metadata and device capabilities, the existing test process only focuses on surface function checking and cannot truly simulate common dynamic stress scenarios in the user environment, making it difficult to trigger and identify deep compatibility defects such as performance fluctuations and stability failures.

[0004] The above defects may result in a large number of potential problems not being discovered in the testing phase, which are exposed on actual user devices after the application is put into operation, not only causing a significant decline in user experience, but also forcing developers to invest additional resources for emergency repair, significantly increasing maintenance costs and time costs. SUMMARY

[0005] In order to solve the above defects, the present application provides a Harmony application compatibility testing method and system.

[0006] The above invention purpose of the present application is realized by the following technical scheme: A Harmony application compatibility testing method, comprising the steps 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; Obtaining a current version installation package of a target Harmony application, and extracting application metadata and application code features; Matching and reasoning the application metadata and the application code features through the device capability graph to generate a compatibility test case set corresponding to the target Harmony application; The compatibility test case set is executed in the distributed test environment, and the running performance data and the stability data of the target Harmony application are collected. The compatibility of the target Harmony application is evaluated based on the running performance data and the stability data, and a quantitative evaluation report is generated.

[0007] In a preferred example, the application can be further configured to: the attribute data includes standardized capability data and non-standardized performance parameters, the attribute data of the terminal device is collected through the distributed device attribute library, and the device capability graph is constructed based on the attribute data, the nodes of the device capability graph include device entities, hardware capabilities, software configurations, and distributed service characteristics, and the steps include: The standardized capability data of the terminal device is collected through the distributed device attribute library, and the hardware specification information corresponding to the terminal device is obtained, and the non-standardized performance parameters in the hardware specification information are extracted; A basic attribute layer with device entities is constructed based on the standardized capability data and the non-standardized performance parameters; The technical specification information of the Harmony distributed service is obtained, and the device capability rules are defined based on the technical specification information; Logical reasoning is performed on the basic attribute layer based on the device capability rules, and a relationship layer representing the interaction capabilities between devices is generated; The device capability graph is constructed based on the basic attribute layer and the relationship layer.

[0008] In a preferred example, the application can be further configured to: before the step of performing logical reasoning on the basic attribute layer based on the device capability rules to generate a relationship layer representing the interaction capabilities between devices, the step further includes: Based on the device entities in the basic attribute layer, the corresponding mainstream application program list is associated and generated; Based on the device entities and the mainstream application program list, the corresponding multi-source text data is obtained; The multi-source text data is parsed through natural language processing technology, and the compatibility behavior patterns are recognized and extracted, which are converted into implicit capability rules, and the implicit capability rules are incorporated into the device capability rules.

[0009] In a preferred example, the application can be further configured to: the step of matching and reasoning the application metadata and the application code features through the device capability graph to generate the compatibility test case set corresponding to the target Harmony application includes the steps of: The device requirement capability information in the application metadata is identified, and the device requirement capability information is matched with the device entities in the device capability graph, and an initial device set satisfying the basic running conditions is screened out; analyzing the application code features to identify a calling sequence of system APIs, a hardware resource access pattern, and a potential distributed service calling path; reasoning, based on the identified hardware resource access pattern, a device capability combination and an interaction scenario in the initial device set that have potential compatibility conflicts; parameterizing the reasoned device capability combination and the interaction scenario into a test script, and automatically mutating key parameters in the test script to generate a compatibility test case set.

[0010] In a preferred example, the application can be further configured to include the following steps after the step of parameterizing the reasoned device capability combination and the interaction scenario into a test script, and automatically mutating key parameters in the test script to generate a compatibility test case set: obtaining market shares of each device node in the device capability graph, identifying the execution frequency of the key path in the application code features, obtaining historical test cases and identifying the defect detection rate of the historical test cases; based on the market share, the key path execution frequency, and the defect detection rate, calculating the priority weight of each test case in the compatibility test case set; based on the pre-set resource allocation strategy and the priority weight, generating an execution scheduling instruction with an execution priority for the compatibility test case set.

[0011] In a preferred example, the application can be further configured to include the following steps in the step of executing the compatibility test case set in the distributed test environment, and collecting the running performance data and the stability data of the target Harmony application: deploying a chaos injection controller in the distributed test environment, and performing corresponding injection operations through the chaos injection controller according to the distributed interaction scenario defined by the compatibility test case set, the injection operations including network disturbance injection, resource competition injection, and distributed service disturbance injection; synchronously monitoring and collecting the running performance data and the stability data of the target Harmony application during the execution of the injection operations; when the running performance data deviates from the pre-set running performance threshold or the stability data deviates from the pre-set stability threshold, triggering an adaptive fault injection adjustment mechanism, wherein the adaptive fault injection adjustment mechanism includes: identifying the injection parameter combination of the injection operation that causes the deviation, and setting the identified injection parameter combination as a compatibility risk critical point; associating the compatibility risk critical point with the application code features, defining it as a compatibility risk mode, and updating the compatibility risk mode as a new attribute of the corresponding device entity to the device capability graph.

[0012] The application can be further configured in a preferred example that each test case in the compatibility test case set is associated with a corresponding device capability combination, the step of performing compatibility evaluation on the target Harmony application based on the running performance data and the stability data and generating a quantitative evaluation report includes the steps of: Based on the running performance data and the stability data, the performance performance dispersion of the target Harmony application for each device capability combination is calculated. Device capability combinations with performance performance dispersion greater than a preset dispersion threshold are marked as adversarial verification combinations; An adversarial test objective function is constructed for the adversarial verification combination, and the adversarial test objective function aims to maximize application performance fluctuations or trigger stability failures; Based on the adversarial test objective function, a preset optimization search algorithm is used to generate extreme test cases; The stable running boundary of the target Harmony application for each device capability combination is determined according to the execution result of the extreme test case, and an adversarial verification report is generated.

[0013] The second application purpose of the application is achieved by the following technical scheme: A Harmony application program compatibility test system based on a Harmony application program compatibility test system, comprising: A graph construction module for 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; A feature extraction module for obtaining a current version installation package of a target Harmony application and extracting application metadata and application code features; A test case generation module for matching and reasoning the application metadata and application code features through the device capability graph to generate a compatibility test case set corresponding to the target Harmony application; A test case execution module for executing the compatibility test case set in a distributed test environment and collecting running performance data and stability data of the target Harmony application; A compatibility evaluation module for performing compatibility evaluation on the target Harmony application based on the running performance data and the stability data and generating a quantitative evaluation report.

[0014] The application also relates to a computer device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned Harmony application program compatibility test method when executing the computer program.

[0015] The application also relates to a computer readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-mentioned application program compatibility testing method based on the Hongmeng system.

[0016] To sum up, the application provides a Hongmeng application program compatibility testing method and system, which realizes deep matching inference of application characteristics and device capabilities by constructing a device capability map, combines dynamic scene simulation and quantitative evaluation mechanisms in a distributed testing environment, effectively solves the problems of device coverage blind area, insufficient correlation analysis and lack of dynamic pressure simulation in traditional testing methods, realizes comprehensive coverage of device capability differences and distributed interactive scenes, deeply analyzes the internal correlation between application metadata and device capabilities, and truly simulates a dynamic pressure environment to effectively identify deep compatibility defects. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 is a flowchart of an embodiment of the application based on a Hongmeng application program compatibility testing method; Figure 2 is an implementation flowchart of step S10 in an embodiment of the application based on a Hongmeng application program compatibility testing method; Figure 3 is an implementation flowchart of step S30 in an embodiment of the application based on a Hongmeng application program compatibility testing method. DETAILED DESCRIPTION

[0018] The following will be described in detail in combination with the accompanying drawings Figures 1-3 The application will be further described in detail.

[0019] In the traditional existing Hongmeng application compatibility testing process, due to the complexity of the device environment involving a large number of device models, hardware configuration differences, software version diversity and dynamic characteristics of distributed interaction between devices, the testing method mainly relies on test personnel to manually select limited terminal devices and execute general test scripts; the existing testing method highly depends on personal experience, and it is difficult to systematically cover a large number of device combinations and interactive scenes, resulting in that the testing coverage is limited to local device types; further, due to the lack of analysis of the deep correlation between application characteristics and device capabilities in the existing testing method, the testing process cannot effectively simulate the resource competition state and network fluctuation condition in the real user environment, so it is difficult to trigger deep compatibility defects, affecting the completeness of the test results and the evaluation accuracy of the application stability.

[0020] For example, when testing a multi-device collaborative supported Harmony video playback application, the tester selected mainstream mobile phones and tablet devices based on experience for verification, but did not include low-end memory configuration mobile phones and high-resolution display devices in weak network environment interaction scenarios. In the test execution, due to the lack of simulation of network fluctuations and resource competition between devices, the memory management exception of the application during device switching was not detected, resulting in frequent running interruption phenomenon of the application in actual user environment after the application was released, thereby affecting the normal use of the application function by the user.

[0021] If the above problems are not solved, compatibility defects will be exposed after the application deployment stage, which will lead to weakened application stability, reduced user satisfaction, and increased developer post-maintenance burden; at the same time, unidentified deep defects may have a persistent negative impact on the overall reliability of the Harmony application ecosystem, hindering the widespread application of distributed capabilities.

[0022] To this end, in an embodiment, as shown in Figure 1 The application discloses a Harmony application program compatibility testing method, which specifically includes the following steps: S10: Collect attribute data of terminal devices through a distributed device attribute library, and construct 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; In this embodiment, the distributed device attribute library refers to a dynamically updated database or knowledge base, and its core function is to store and manage standardized description information of all terminal devices in the Harmony ecosystem. In this embodiment, the distributed device attribute library is different from a simple device list, but rather normatively describes various attributes of the device through a unified model or interface. It may be maintained by Harmony officials or formed by aggregating data reported by major device manufacturers. The device capability graph refers to a data model used to structurally represent the capabilities of terminal devices, and its nodes include device entities, hardware capabilities, software configurations, and distributed service characteristics. In actual applications, the device capability graph can be implemented using graph database technology, such as Neo4j or JanusGraph, where the device entity is the central node, and the hardware capability, software configuration, and distributed service characteristic are associated nodes. Alternatively, it can be defined by a relational database table structure, such as using a MySQL table to store the mapping relationship between the device entity and the capability attribute. The device entity table records device model information, the hardware capability table stores processor performance parameters, the software configuration table records operating system version, and the distributed service characteristic table describes the communication capability between devices. For example, a "device A" node can be connected to an "NPU computing power" node through a "has" relationship, and the "NPU computing power" node can be connected to a "specific driver version" node through a "depends on" relationship. This graph structure enables logical reasoning by computers to discover potential compatibility constraints between devices.

[0023] S20: Obtain a current version installation package of the target Harmony application, and extract application metadata and application code features; In the present embodiment, the target Harmony application refers to an application program developed for the Harmony operating system (especially its distributed characteristics) to be tested, specifically a specific object application of the current test task. Such an application is usually developed using the SDK of Harmony and can call the distributed software bus, distributed data management and other unique capabilities to realize cross-device service flow, data synchronization and multi-end collaboration functions. The application metadata refers to the declarative data embedded in the application installation package for describing the application information and running requirements. The application metadata is usually stored in a fixed configuration file and does not need to run the application to extract. The application metadata includes application identity information, permission declaration, device capability requirement, etc. The application code features refer to the deep information reflecting the inherent technical selection and behavior pattern of the application extracted from the executable code and resources of the application installation package through static or dynamic analysis technology. The application code features may contain implicit dependencies that are not declared in the metadata.

[0024] Further, the application code features include: API call sequence: the system API actually called in the code, especially the sensitive API related to distributed capabilities and hardware access; Resource usage pattern: such as the adaptation of pictures and layout files to different screen densities and sizes, reflecting the compatibility of the UI; Dynamic behavior features: such as the use of specific hardware instruction sets, thread models, memory allocation strategies, etc. analyzed at runtime.

[0025] S30: Match and infer the application metadata and application code features through the device capability graph to generate a compatibility test case set corresponding to the target Harmony application; In the present embodiment, the matching and inference process refers to the operation of comparing the application metadata and the application code features with the device capability graph to generate a compatibility test case set. Specifically, the matching can be performed based on a rule engine, for example, the Drools rule engine parses the application requirements and matches the device capabilities. Or the matching degree of the application features and the device capabilities is calculated through semantic analysis technology, for example, the natural language processing tool is used to extract the application description keywords and calculate the similarity with the device capability labels. For example, the inference can be: if the application declares that it needs "function X", and "function 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 test task set automatically generated by matching and inference.

[0026] S40: Execute the compatibility test case set in the distributed test environment, and collect the running performance data and stability data of the target Harmony application; In this embodiment, the running performance data refers to quantitative indicators that can reflect the resource utilization efficiency and task processing speed of the target Harmony application under a specific device capability combination, which are collected by a monitoring tool during test execution. The running performance data is usually dynamic and quantifiable. The running performance data includes resource consumption, response efficiency, throughput, etc. The stability data refers to indicators reflecting the continuous normal service providing capability and fault tolerance recovery capability of the target Harmony application, which are collected during test execution. The stability data includes fault indicators, recovery indicators, state consistency, etc.

[0027] S50: Perform compatibility evaluation on the target Harmony application based on the running performance data and the stability data, and generate a quantitative evaluation report.

[0028] In this embodiment, the compatibility evaluation refers to a comprehensive analysis process of determining the comprehensive adaptation degree of the target Harmony application in the Harmony device ecosystem based on the collected running performance data and stability data, combined with predefined compatibility standards (such as performance thresholds, stability baselines, etc.). The quantitative evaluation report refers to the final output of the compatibility evaluation process, which is usually a structured document with data as the core evidence. Its core feature is objectivity and measurability, providing direct support for decision-making.

[0029] Further, the quantitative evaluation report usually includes: Overall score and level: one or more quantitative compatibility scores or levels, for example: compatibility score 92 / 100, rated A; Dimension details: detailed performance and stability data comparison under different device types (such as mobile phones, watches, tablets) and different distributed scenarios; Problem list and risk prompt: clearly list the discovered compatibility defects, and prioritize them according to their severity and impact on user experience; Decision suggestion: based on the data, give clear conclusions, such as "the current version has reached the release standard", "suggest to prioritize the repair of a defect on a certain device", or "performance optimization is needed on certain low-end devices".

[0030] Specifically, the application effectively solves the problems of limited coverage of traditional manual testing and inability to simulate complex conditions of real user environment through the above scheme. Specifically, the structured representation of the device capability graph avoids dependence on artificial experience, enabling modeling of a large number of device models, hardware configurations, software versions, and distributed interaction scenarios. The matching inference mechanism accurately identifies potential conflicts in hardware resource access patterns and distributed service call paths from the application's own needs, generating test cases that cover the basic running conditions and complex interaction scenarios. The test is executed in a distributed test environment, and performance data and stability data are collected to ensure that the test process can simulate the real user environment. Based on the collected data, a quantitative evaluation report is generated to convert the test results into objective and quantifiable indicators, helping to locate the root cause of the problem.

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

[0032] Illustratively, as a specific embodiment, a video conference HarmonyOS application is tested. The distributed device attribute library collects attribute data of terminal devices such as Huawei certain model smartphones and Honor certain model tablet computers, including hardware capabilities such as processor model and memory capacity, software configurations (such as HarmonyOS 3.0 version), and distributed service characteristics (such as multi-device collaboration capability). Based on the above data, a device capability graph is constructed, in which the device entity nodes are associated with the corresponding hardware capabilities, software configurations, and distributed service characteristics. The installation package of the target HarmonyOS application is obtained, and the application metadata (such as the required minimum OS version of 3.0, support for 1080p video) and application code features (such as camera API call sequence, network resource access pattern) are extracted. Through matching inference based on the device capability graph, the device requirement capability information in the application metadata is identified, and matched with the device entities in the device capability graph to filter out an initial device set that meets the basic running conditions; at the same time, the application code features are analyzed to identify the hardware resource access pattern, and the device capability combinations and interaction scenarios in the initial device set that have potential compatibility conflicts are inferred, and then a compatibility test case set is generated, including simulating multi-device video call and network fluctuation scenarios. In the distributed test environment composed of the above devices, the compatibility test case set is executed, and performance data such as frame rate and delay and stability data such as crash frequency are collected. Based on the collected data, parameters such as performance dispersion are calculated to evaluate the target HarmonyOS application and generate a quantitative evaluation report, pointing out the compatibility problems under specific device combinations.

[0033] Therefore, the embodiment scheme realizes multi-aspect coverage of diversified device environments and complex distributed interaction scenarios by systematically integrating device capabilities and application features, effectively solves the problem of limited test coverage, and generates test cases that match reasoning to simulate complex situations in a real user environment, thereby triggering deep compatibility defects and avoiding the limitations of traditional testing methods that only stay at the basic function verification level. The finally generated quantitative evaluation report provides objective basis to help developers quickly locate the root cause of the problem, and significantly reduces the user experience risk and maintenance cost caused by compatibility problems after the application is released.

[0034] In an embodiment, the attribute data includes standardized capability data and non-standardized performance parameters, such as Figure 2 As shown in FIG. 10, step S10 includes: S11: Collect the standardized capability data of the terminal device through the distributed device attribute library, and obtain the hardware specification information corresponding to the terminal device, and extract the non-standardized performance parameters in the hardware specification information; In this embodiment, the standardized capability data refers to the device capability information that can be obtained through the standard interface (such as device management service) officially provided by the Hongmeng operating system. The standardized capability data has high standardization and comparability, and is the basis of device compatibility. For example, the screen resolution, memory size, operating system version number, and supported distributed protocol version obtained through the standard API; the hardware specification information refers to the technical document or data set officially published or provided by the device manufacturer, which is used to accurately and completely describe the hardware components, technical indicators, performance parameters, interface specifications, and electrical characteristics of the product; the non-standardized performance parameters refer to the deep parameters that can reflect the performance boundary of the device, which cannot be directly obtained from the standardized interface and need to be extracted from other channels (such as hardware specification manual, white paper) or obtained by actual measurement. The non-standardized performance parameters are often a deepening and quantification supplement of the capability-related data, which reveals the real performance of the device under specific load, for example, the stability of the continuous rendering frame rate of the GPU, the sensor accuracy under different working conditions, the power consumption and heating of the specific chip set when decoding high code rate video, etc.

[0035] For example, the hardware specification information usually includes: Component list and basic parameters: clearly list all the core hardware components included in the device, for example: Processor: specific model, core number, main frequency, architecture; Graphics processor: specific model, rendering core number, supported graphics API version; Memory and storage: type, capacity, speed; Screen: specific size, resolution, refresh rate, material; Sensors: specific models and precision of gyroscopes, accelerometers, magnetometers, light sensors, proximity sensors, etc. Communication modules: specific chip models and supported standards of cellular networks (5G / 4G), Wi-Fi, Bluetooth, GPS, etc.

[0036] Performance boundaries and characteristic parameters: describe the performance of components under specific conditions, usually as the main source of non-standardized performance parameters, such as: Performance boundaries: continuous performance of CPU / GPU under different power consumption walls, battery life under different usage scenarios; Characteristic parameters: aperture size, focal length, supported focusing methods (such as laser focusing, phase focusing) of camera sensors; output power, frequency response range of speakers; Interfaces and connectivity: detailed definition of physical and electrical characteristics of hardware interfaces, such as USB interface types, video output capabilities, earphone jack specifications, etc.

[0037] S12: Based on standardized capability data and non-standardized performance parameters, build a basic attribute layer with device as entity; In this embodiment, the basic attribute layer refers to the data foundation layer of the device capability map, which is essentially a structured database. Its core is to take each terminal device as an independent entity, and mount and associate the obtained standardized capability data and non-standardized performance parameters as the attributes of the entity. The basic attribute layer mainly describes the static attributes of the device.

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

[0039] Exemplarily, typical services of the distributed services of the Hongmeng include: Distributed Soft Bus: the underlying communication foundation, responsible for automatic discovery, high-speed connection and data transmission between devices, and is the "pipeline" of other distributed services; Distributed Data Management: provides cross-device data synchronization and sharing capabilities, so that user data is consistent on multiple devices; Distributed Device Virtualization: virtualizes the capabilities of remote devices (such as cameras) as local resources for direct application calls; Distributed Task Scheduling: intelligently migrates tasks (such as continuous reading and navigation) to the most suitable device according to the location, state, load and other factors of the device.

[0040] The technical specification information includes: API interface specification: clearly defines which programmable interfaces (APIs) are provided by each distributed service, as well as the methods, parameters and return values for calling these interfaces; Protocol and process specification: specifies in detail the communication protocols and interaction processes that must be followed during the process of establishing a connection between devices, service discovery, task migration, data synchronization, etc. Capability and constraint declaration: defines which permissions and capabilities need to be declared in the application configuration file if an application wants to use a certain distributed service, and which preconditions (such as minimum system version requirements) need to be met; Security and permission model: specifies the identity authentication, data encryption and user authorization mechanisms for cross-device access, ensuring 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 performing automated logical operations and path exploration on the device capability graph based on device capability rules, thereby discovering the implicit, non-obvious compatibility relationships (such as dependencies, conflicts, and compatibility) between devices. It is not just a simple attribute matching.

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

[0043] In the embodiment, the relationship layer refers to a network structure generated for describing how devices interact and correlate with each other after logical reasoning is performed on the device capability rules. The relationship layer is composed of nodes (devices) and edges (relationships), and the types of edges can include "collaborative", "dependent", "conflicting", etc. For example, through rule reasoning, the system can establish a relationship edge of "collaborative distributed audio call" between "device A" with a high-performance microphone and "device B" with a high-quality speaker. The relationship layer makes the device capability map change from a static device list to a dynamic interaction network.

[0044] Specifically, first, the standardized capability data of the terminal device is collected through the distributed device attribute library, and the non-standardized performance parameters are extracted from the hardware specification information, so as to ensure that the device attribute data covers both the standard capabilities defined in the specification and the real hardware performance differences. Then, the basic attribute layer with devices as entities is constructed based on the standardized capability data and the non-standardized performance parameters, so as to form a structured device capability representation. Next, the technical specification information of the distributed service of the Hongmeng is obtained, and the device capability rules are defined, so that the rules closely fit the distributed characteristics of the system. Then, logical reasoning is performed on the basic attribute layer based on the device capability rules, and the relationship layer representing the interaction capabilities between devices is generated, so as to deduce the resource collaboration or conflict scenarios of the devices in the distributed service. Finally, the basic attribute layer and the relationship layer are integrated to construct the device capability map, so as to provide comprehensive device capability description for compatibility testing. The above layered construction mechanism organically combines static attributes and dynamic interaction capabilities, so that the device capability map can accurately reflect the actual performance and potential compatibility risks of the devices in a complex environment.

[0045] Exemplarily, as a preferred embodiment, the scheme of the application is implemented as follows: when testing a certain model of smart phone, the list of supported Hongmeng operating system APIs is collected as standardized capability data through the distributed device attribute library, and the actual processor frequency and memory bandwidth are extracted as non-standardized performance parameters from the hardware specification document. Based on these data, the basic attribute layer is constructed, the smart phone is taken as a device entity, and its hardware capabilities and software configurations are associated. The technical specifications of the distributed service of the Hongmeng are obtained, and the device capability rules are defined, such as that when the device supports distributed task scheduling and the memory capacity meets certain requirements, the tasks can be collaboratively processed. Based on the device capability rules, logical reasoning is performed on the basic attribute layer, and the relationship layer representing the scenarios in which the devices can collaboratively work is generated. Finally, the basic attribute layer and the relationship layer are integrated to construct the device capability map, which is used to generate the compatibility test cases.

[0046] By the above scheme, the device capability map can more truly reflect the actual performance of the terminal device in a complex environment, avoiding environment simulation distortion caused by relying only on standardized data; at the same time, the interaction capability between devices is generated through systematic logical reasoning, effectively capturing compatibility risks in real interactions such as resource competition and network fluctuations, thereby significantly improving the coverage depth and breadth of compatibility test cases, ensuring that deep compatibility defects are effectively discovered in the test phase.

[0047] Further, for example, the following is a logical reasoning process in a specific situation: Scenario one is to find a compatible combination, and the specific process includes: Known facts: application X declares the need for a "cross-device flow" function, the "distributed soft bus version" of device A is 3.1, and the version of device B is 3.2; Reasoning process: according to the above rules, the versions of devices A and B both meet the conditions; Reasoning result: it is inferred that "application X can perform cross-device flow between device A and device B", which is a positive reasoning, discovering an effective and testable interaction scenario.

[0048] Scenario two is to find incompatible / conflict risks, and the specific process includes: Known facts: application Y declares the need for a "cross-device flow" function, device C has a version of 3.0, and device D has a version of 2.0; Reasoning process: matching rules, it is found that the version of device D does not meet the conditions; Reasoning result: it is inferred that "application Y cannot implement cross-device flow between device C and device D", or it is marked that this combination has compatibility conflict risks, which is a conflict detection reasoning, helping to avoid testing blind spots in advance.

[0049] Scenario three is to find implicit dependencies, and the specific process includes: Known facts: 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 facts: the "system version" of device E is 2.0; Reasoning process (chain reasoning): multiple steps of reasoning are performed, 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", and further, it is inferred that device E cannot support the "cross-device flow" function; Reasoning result: an implicit dependency is found, even if there is no direct indication in the configuration files of the application and the device, the deep compatibility constraints can be inferred.

[0050] In some embodiments of the present application, the device capability rule is defined based on the technical specification to construct the device capability map. However, in the implementation process, only relying on the technical specification may ignore the compatibility behavior patterns existing in the actual user environment, resulting in that the device capability rule is not comprehensive and cannot accurately reflect the interaction capability of the device in the real scene, thereby affecting the coverage and effectiveness of the compatibility test.

[0051] To this end, the present application further proposes that in an embodiment, before step S14, further comprising: S131: associating and generating a corresponding mainstream application list based on the device entity in the basic attribute layer; In the present embodiment, the mainstream application list refers to a set of commonly used applications that are highly matched with the characteristics of the device entity, which can be generated in a manner of screening from the application store popular list, device pre-installed application directory or user installation behavior statistics.

[0052] S132: obtaining corresponding multi-source text data based on the device entity and the mainstream application list; In the present embodiment, the multi-source text data refers to unstructured text information containing actual user feedback obtained from multiple different source channels, which can come from social media platforms, developer community forums or application store review libraries.

[0053] S133: analyzing the multi-source text data through natural language processing technology, identifying and extracting compatibility behavior patterns, converting them into implicit capability rules, and incorporating the implicit capability rules into the device capability rule.

[0054] In the present embodiment, the natural language processing technology refers to a method for automatically extracting structured knowledge from unstructured text, which can be implemented by using a pre-trained language model based on the Transformer architecture or a rule matching engine; the compatibility behavior pattern specifically refers to the abnormal law exhibited by the device in distributed interaction, which can be manifested as the context features of application crashes or sequence patterns of service call failures under specific hardware configurations; for example, when the descriptions of “application A”, “a certain model of sensor of device B” and “reading error” frequently appear in the text at the same time, a pattern can be extracted: there is a data accuracy problem in the combination of application A and the specific sensor of device B; the implicit capability rule refers to the compatibility constraint condition that actually exists in the real ecology and is extracted from user feedback. The implicit capability rule is the result of formalizing and structuring the identified compatibility behavior pattern, so that it can be understood and processed by the computer, and finally incorporated into the device capability rule library, wherein the implicit capability rule can be configured as a logical expression or a decision tree rule to be integrated into the device capability rule system.

[0055] Specifically, the embodiment scheme realizes dynamic perfection of the rule system by integrating real user environment data in the device capability rule construction stage; before performing logical reasoning based on the basic attribute layer to generate the relationship layer, a list of mainstream application programs is generated according to the device entity association, ensuring the pertinence and representativeness of subsequent data collection; then, multi-source text data corresponding to the device entity and the application program list are obtained, which cover real user interaction scenarios not recorded in the technical specification; the multi-source text data are analyzed by natural language processing technology, and compatibility behavior patterns are automatically identified and extracted, which reflect the actual performance of the device in distributed service invocation; finally, the compatibility behavior patterns are converted into implicit capability rules and incorporated into the device capability rules, so that the rule system not only contains official technical specifications, but also integrates experience knowledge; through the above mechanism, when generating the relationship layer representing the interaction capability between devices, logical reasoning can be based on more comprehensive rules, thereby constructing a device capability graph that more accurately reflects real scenarios.

[0056] Exemplarily, as a specific implementation, the scheme of the application is implemented as follows: when processing a smartphone device entity, a list of mainstream application programs including instant messaging applications, video playback applications, etc. is generated; based on the device entity and the application program list, multi-source text data are obtained from social media platforms and application store reviews; through natural language processing technology, a compatibility behavior pattern of "application crash when multitasking under low memory state" is identified, and is converted into an implicit capability rule of "limiting the depth of distributed service invocation when the device memory capacity is lower than a threshold value"; the implicit capability rule is then incorporated into the device capability rules for subsequent logical reasoning process.

[0057] Through the above scheme, the application can effectively compensate for the limitations of device capability rules relying only on technical specifications, make the device capability graph more accurately depict the device interaction capability in real scenarios, thereby expanding the coverage of compatibility testing, reducing the testing blind area, and improving the pertinence of test case generation and defect detection capability.

[0058] In some embodiments of the application described above, it is proposed to generate a compatibility test case set by matching and reasoning application metadata and application code features through the device capability graph. However, in the implementation process, relying only on metadata matching may not be able to deeply mine potential hardware resource access conflicts and distributed service invocation risks in the application code, resulting in narrow test case coverage, difficulty in simulating complex interaction and resource competition scenarios that may occur in real user environments, and thus missing deep compatibility defects, affecting the comprehensiveness and effectiveness of testing.

[0059] To this end, the application further proposes that, in an embodiment, as shown in Figure 3 Step S30 includes: S31: Identify the device requirement capability information in the application metadata and match the device requirement capability information with the device entities in the device capability graph to screen out an initial device set that meets the basic running conditions; In this embodiment, the device requirement capability information refers to the device hardware specifications and software environment requirements declared in the application metadata, which can be implemented by using the device compatibility declaration field or the runtime permission configuration information in the application manifest file, and the purpose is to accurately locate the basic compatible device range and avoid wasting test resources on devices that do not support; the initial device set refers to a set of all devices that can theoretically install and start the application after matching the device requirement capability information of the application with the device entities in the device capability graph, and the initial device set is used as a candidate device list for subsequent in-depth testing.

[0060] S32: Analyze the application code features to identify the system API call sequence, hardware resource access mode and potential distributed service call path; In this embodiment, the system API call sequence refers to the order and combination mode of the application program calling the system API identified by static or dynamic analysis of the application code, and the focus is on analyzing its call logic, for example, the application may first call connectDevice(), and then call startStreaming() in the callback function. A specific call sequence may imply specific dependencies on device state and resource allocation order, which are prone to cause problems on incorrect devices or in concurrent situations; the hardware resource access mode refers to the usage habits and rules of the application for hardware resources (such as CPU, memory, GPU, sensors, network I / O) during runtime, which is usually derived by analyzing code features, for example: intensive access (whether continuously and high-frequency reading of sensor data in the rendering loop), exclusive access (whether occupying the camera or microphone in exclusive mode to prevent other applications from using), resource competition mode (whether applying a large amount of memory in multiple threads at the same time) and the like; the potential distributed service call path refers to a series of consecutive operation steps, i.e. path, that the application may execute during runtime and involve cross-device collaboration, which are inferred by static or dynamic analysis of the application code. These paths may not be triggered every time the application runs, but they exist in the code structure and may be activated once certain conditions are met.

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

[0062] Exemplarily, potential compatibility conflicts can include: Resource conflict: the application code exhibits a high-frequency calling pattern to the GPU (such as continuous rendering of a complex 3D model), and the GPU driver of a certain device has a known heat dissipation bottleneck, i.e., there is a potential conflict of performance degradation or device overheating; Dependency conflict: a distributed calling path of the application requires high-precision geographic coordinates, but the GPS module of the collaborative device has low precision, i.e., there is a potential conflict of data quality.

[0063] Exemplarily, "mobile phone A, smart TV B, and sound box C" can constitute a device capability combination for "video cross-end streaming and output of high-quality audio"; "watch D and mobile phone E" can constitute a device capability combination for "health data synchronization and alarm".

[0064] S34: parameterize the inferred device capability combination and interaction scenario into a test script, and automatically mutate the key parameters in the test script to generate a compatibility test case set.

[0065] In this embodiment, parameterizing into a test script means converting an abstract test scenario into an executable and specific test script. Specifically, the variable factors in the inferred device capability combination and interaction scenario are extracted 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 a logic flow that processes these parameters, and parameterization allows a script template to generate a large number of test cases covering different situations by passing in different parameter values. Automatic mutation refers to systematically adjusting the parameters of the test script to generate variant test cases to cover normal, boundary, and abnormal situations. Genetic algorithm-based parameter perturbation strategies or targeted mutation rules based on historical defect data can be used to achieve this, with the goal of simulating edge conditions in real environments and effectively triggering deep compatibility problems.

[0066] Specifically, first, based on the device requirement capability information in the application metadata and the device capability graph matching, an initial device set meeting the basic running conditions is screened out to determine the test range; then the application code characteristics are analyzed in depth to identify system API call sequences, hardware resource access patterns and potential distributed service call paths to obtain the behavior characteristics of the application runtime; based on these behavior characteristics, especially the hardware resource access patterns, the potential compatibility conflict device capability combinations and interaction scenarios in the initial device set are inferred to convert the abstract risks into specific measurable scenarios; finally, these scenario parameters are parameterized into test scripts, and diversified test cases are generated through the automatic variation of key parameters; through the above steps, a closed-loop logic chain is formed: the initial device set provides the target range for code analysis, the hardware resource access pattern provides the basis for conflict inference, and the parameterization and variation process converts the risk scenarios into executable test cases, thereby realizing the complete technical path from basic device screening to deep risk exposure.

[0067] Exemplarily, as a specific implementation, the scheme of the application is implemented as follows: when the target Hongmeng application is a video conference application, its application metadata declares the need for camera and microphone support; by matching the device capability graph, a device set with camera and microphone is screened out; the application code analysis finds that it frequently calls high-resolution camera API and real-time audio processing API; based on the hardware resource access pattern inference, resource competition is easy to occur in device combinations with large differences in camera frame rate (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 delay variation, to generate test cases for resource competition.

[0068] Through the above technical scheme, the application can deeply mine the potential hardware resource access conflict and distributed service call risk in the application code, significantly expand the coverage of test cases, effectively simulate complex interaction and resource competition scenarios in the real user environment, thereby reducing the omission of deep compatibility defects and improving the comprehensiveness and effectiveness of testing.

[0069] In some embodiments of the application described above, the priority weight is calculated after generating the compatibility test case set, and the execution scheduling instruction is generated to optimize the test resource allocation. However, in this process, there may be a lack of comprehensive consideration mechanism for device popularity, application core function use frequency and historical defect discovery efficiency in the test case set, which makes it difficult for the test resource to dynamically focus on high-risk scenarios, and may miss key compatibility problems due to priority confusion, especially in the case of complex distributed device environment and limited test resources, it is difficult to efficiently identify stability defects affecting a wide range of users.

[0070] To this end, the application further proposes that in an embodiment, after step S34, further comprising: S341: Obtain the market share of each device node in the device capability graph, identify the key path execution frequency in the application code feature, obtain the historical test cases and identify the defect detection rate of the historical test cases; In this embodiment, the market share refers to the popularity distribution of the device in the target user group, which can be obtained by integrating third-party market analysis platform data, device sales statistics information or user activity logs, aiming to match the test coverage range with the real user device distribution, and avoid missing universal compatibility problems due to neglecting mainstream device types; the key path execution frequency refers to the frequency of execution of the core business process in the target application in typical user scenarios, which is obtained by static code analysis or runtime profiling technology, wherein the key path execution frequency can be understood as the call frequency of the core business logic of the application in user operations, for example, for a shopping application, "browsing goods, adding goods to the shopping cart, and settling payment" is a key path, and the execution frequency of this path is usually much higher than that of "modifying personal avatar" and other secondary functions, because the compatibility problems of high-frequency execution paths will affect a wider range of users, and therefore the test priority is higher; the defect detection rate of the historical test cases specifically refers to the probability of successfully revealing software defects in the past test cycles, which can be extracted by analyzing the defect association records or automated test result logs in the test report database, aiming to screen high-risk detection points that have been verified effectively in the history, and avoid repeating the execution of low-efficiency test cases.

[0071] S342: Based on the market share, the key path execution frequency and the defect detection rate, calculate the priority weight of each test case in the compatibility test case set; In this embodiment, the priority weight refers to a quantitative score synthesized by an algorithm for executing the test case, which takes into account multiple dimensions such as market influence, code importance, historical performance, etc., rather than just the experience of the test personnel, wherein the higher the priority weight, the more important the test case, and the more it should be executed first.

[0072] S343: Based on the pre-set resource allocation strategy and the priority weight, generate an execution scheduling instruction with execution priority for the compatibility test case set.

[0073] In this embodiment, the pre-set resource allocation strategy refers to a pre-defined rule set for guiding how to allocate limited computing resources (such as test equipment machine time, network bandwidth, execution time) to test cases of different priorities, for example, the resource allocation strategy can stipulate: "the test case group with a priority of 'high' is allocated 70% of concurrent execution resources, and is allowed to exceed the standard time limit by 150%"; the execution scheduling instruction can be understood as an instruction set for controlling the execution order of test cases, which can be generated by a task queue management module or a resource scheduling engine, and the purpose is to dynamically coordinate limited test resources and case priority to ensure that high-risk scenarios are verified first; further, the execution scheduling instruction includes the execution order of test tasks, the number of concurrent executions, resource quotas, timeout settings, etc., for example: "preferentially execute the case group X on the device pool A in a concurrent manner, occupying 50% of the resources; after its completion, execute the case group Y on the device pool B", which realizes the automation and optimization of the test process.

[0074] Specifically, first, the market share of each device node in the device capability graph, the execution frequency of the key path in the application code feature, and the defect detection rate of the historical test case are obtained, which represent the test risk from three dimensions of device popularity, functional importance, and historical effectiveness; then, based on the market share, the key path execution frequency, and the defect detection rate, the priority weight of each test case is calculated, the device user base, the core function usage intensity, and the historical defect discovery efficiency are quantitatively fused to form a comprehensive risk assessment index; finally, the execution scheduling instruction is generated in combination with the pre-set resource allocation strategy and the priority weight, and the execution sequence of the test case is dynamically adjusted, so that the high-weight case can obtain execution resources first when resources are scarce, thereby realizing precise allocation and efficient use of test resources in a distributed test environment.

[0075] Exemplarily, as a specific implementation, the scheme of the application is implemented as follows: in the process of Harmony application compatibility testing, the device capability graph includes three types of device nodes: smartphones, tablet computers, and smart TVs, wherein the market share data of the smartphone node is obtained by integrating industry market reports, showing that it covers more than 70% of the target user group; based on the analysis and identification of the application code features, it is found that the video playback function is a key path, and its execution frequency is significantly higher than that of other functional modules; the test records in the historical test case library for the video playback function show a high defect detection rate; based on this, when calculating the priority weight of the test case, the test case for the video playback function on the smartphone is given a higher weight value, and the execution scheduling instruction preferentially arranges the execution of this case in the distributed test environment, ensuring that the core function scenarios affecting a wide range of users are verified first under the condition of limited test resources.

[0076] By the technical solution, the test resource can be dynamically focused on a high-risk scene with high equipment popularity, frequent use of core application functions, and significant historical defect detection rate, effectively reducing the occurrence of missing key compatibility problems due to the absence of a priority mechanism, especially under the condition that the distributed equipment environment is complex and the test resource is limited, significantly improving the identification efficiency and test process optimization capability of stability defects affecting a wide range of users.

[0077] In an embodiment, step S40 comprises: S41: deploying a chaos injection controller in a distributed test environment, and performing corresponding injection operations through the chaos injection controller according to the distributed interaction scenes defined by the compatibility test case set, the injection operations including network disturbance injection, resource competition injection, and distributed service disturbance injection; In this embodiment, the chaos injection controller refers to a control module for actively simulating a fault environment, which can be implemented by a software agent or a hardware simulator, and the purpose is to accurately reproduce abnormal conditions in the user environment; the distributed interaction scenes defined by the compatibility test case set refer to the cross-device task execution processes most likely to expose compatibility problems that are accurately located based on intelligent analysis of application behavior and device capabilities, and these distributed interaction scenes are described in detail in the test case as the "target" or requirement for the chaos injection controller to perform fault injection; the injection operation refers to a technical means for interfering with the normal operation of the system through a specific mechanism, which can be implemented in the form of network delay injection, CPU load increase, or service interruption, and the purpose is to cover complex scenes such as resource competition and network fluctuation, wherein the injection operation includes network disturbance injection, resource competition injection, and distributed service disturbance injection; network disturbance injection refers to the chaos controller simulating various abnormal conditions existing in the real network to test the resilience and fault tolerance capability of the application when the network condition is poor, and the specific operation includes artificially creating network delay, packet loss, bandwidth limitation, or even simulating complete network connection interruption and reconnection, aiming to verify whether the application can maintain the availability of basic functions when the network service quality decreases; resource competition injection refers to the chaos controller simulating a high-load environment on the test device to create a resource scarcity state, and then observing the performance of the application, and the specific operation includes suddenly starting a high CPU / memory / disk I / O occupying interference process, or quickly switching the foreground application to simulate frequent memory swapping, aiming to expose stability problems of the application when the resources are preempted, such as performance sharp decline, freezing, or crash, etc.; distributed service disturbance injection refers to the chaos controller simulating the failure of core services in a distributed architecture, and the specific operation includes randomly terminating or restarting key distributed services (such as distributed data management, device discovery service), simulating service response timeout, or forging false service state information, aiming to verify the fault tolerance and self-recovery capability of the application when the foundation of the distributed system has a problem.

[0078] S42: During the execution of the injection operation, the running performance data and the stability data of the target application are synchronously monitored and collected; In this embodiment, synchronous monitoring and data collection refers to the process of real-time data capture while fault injection is performed, which can be implemented using a distributed log collection system or a performance monitoring agent. The purpose is to ensure accurate association of faults and performance fluctuations.

[0079] S43: When the running performance data deviates from the preset running 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 combination of the injection operation that causes the deviation, and set the identified injection parameter combination as a compatibility risk critical point; Associate the compatibility risk critical point with the application code features, define it as a compatibility risk mode, and update the compatibility risk mode as a new attribute of the corresponding device entity to 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 completely defines all technical details of an "attack"; the compatibility risk critical point refers to the injection parameter combination that causes significant deviation in performance, which can be identified by parameter scanning or regression analysis methods, and the purpose is to locate the specific conditions that trigger faults, for example, the test results may show: "for video streaming application X, when the network delay is continuously higher than 450ms, its video frame rate will drop from 60FPS to below 20FPS", this "450ms" is a specific risk critical point; the compatibility risk mode refers to a reusable knowledge unit formed by associating the risk critical point with the application code features, specifically referring to associating a specific application code feature (such as a certain API call mode), a specific device capability combination, and a specific fault critical point to form a reusable experience rule, for example, the risk mode formed may be: "applications using VideoDecoderAPI and buffer size less than 2MB, on devices with less than 4GB of memory, when the network delay is greater than 450ms, there is a high risk of high performance degradation".

[0081] Specifically, the scheme realizes active simulation of real user environment abnormalities by executing directional fault injection according to a distributed interaction scene defined by a test case through a chaos injection controller; real-time correlation between fault injection and data collection is ensured by synchronously monitoring running performance data and stability data during the execution of the injection operation, so as to avoid missing of transient fluctuations caused by monitoring lag; when the monitoring data deviates from a preset threshold, an adaptive fault injection adjustment mechanism is triggered, the specific injection parameter combination causing the deviation is identified and is set as a compatibility risk critical point, and the fault triggering condition is accurately located; the risk critical point is further associated with an application code feature to define a compatibility risk mode, and is updated to a device capability graph as a new attribute of a device entity, so that the device capability graph can dynamically accumulate historical risk experience, and provide reusable intelligent decision basis for subsequent testing, thereby forming a complete closed loop from fault simulation, data collection to knowledge sedimentation.

[0082] Exemplarily, as a specific implementation, the scheme of the application is implemented as follows: when testing a Harmony application running in cooperation between a smart watch and a mobile phone, a chaos injection controller executes network disturbance injection operation to simulate signal interruption according to a Bluetooth communication scene defined by a test case, and simultaneously triggers resource competition injection operation to simulate a high load state of a CPU; during the injection process, application interface response delay and service crash logs are monitored in real time; when it is detected that the response delay exceeds a preset threshold, an adaptive fault injection adjustment mechanism identifies a specific combination of Bluetooth interruption duration and CPU occupancy rate as a compatibility risk critical point, and associates the combination to a communication module call sequence in the application code to define a compatibility risk mode; the risk mode is updated to a device capability graph as a new attribute of the smart watch device entity, and is used for priority adjustment of subsequent testing of similar applications.

[0083] Through the above technical solution, the application realizes active simulation of complex fault scenes such as resource competition and network fluctuation in a real user environment, effectively triggers deep compatibility defects, and significantly improves the depth and adaptability of compatibility testing.

[0084] In some embodiments of the application described above, compatibility evaluation of a target Harmony application is performed based on running performance data and stability data, and a quantitative evaluation report is generated. However, in the implementation process, relying only on conventional performance indicators may not effectively capture the performance fluctuation difference between device capability combinations, resulting in that the evaluation result is difficult to reflect the limit compatibility risk of the application in a real distributed environment, and the boundary condition of a high-risk device combination cannot be accurately identified, so that the compatibility verification lacks active detection ability for deep defects.

[0085] To this end, the application further proposes that in an embodiment, each test case in the compatibility test case set is associated with a corresponding device capability combination, and step S50 comprises: S51: Calculate the performance dispersion of the target Harmony application for each device capability combination based on the performance data and stability data; In this embodiment, the device capability combination refers to a specific terminal device configuration set associated with the compatibility test case, which can be implemented by a combination of device entities, hardware capabilities, software configurations and distributed service characteristics, aiming to accurately represent the device environment of the test scene; the performance dispersion refers to the fluctuation degree of the performance data and stability data of the target Harmony application under different device capability combinations, which can be implemented by statistical indicators such as standard deviation, variance or coefficient of variation, aiming to quantify the performance instability.

[0086] S52: Mark the device capability combination corresponding to the performance dispersion greater than the preset dispersion threshold as the adversarial verification combination; In this embodiment, the dispersion threshold refers to a preset performance fluctuation critical value, which can be implemented by historical test data statistical analysis or a dynamic threshold setting method based on device market distribution, aiming to scientifically select high-risk device combinations; the adversarial verification combination refers to a specific device capability combination identified according to the performance dispersion index, which has higher uncertainty or risk, and the adversarial verification combination is regarded as a key object that needs to be deeply tested and stress verified, and the purpose of marking is to concentrate limited test resources to the key area that can find problems most.

[0087] S53: Construct an adversarial test objective function for the adversarial verification combination, and the adversarial test objective function aims to maximize the application performance fluctuation or trigger stability failure; In this embodiment, the adversarial test objective function refers to a mathematical expression aiming to maximize application performance fluctuations or trigger stability failures, which is used to guide the generation of test cases, and changes the test objective from "verifying function correctness" to "actively seeking system vulnerabilities". The adversarial test objective function maps the running state of the application (performance data, whether it crashes, etc.) into a calculable score, and its optimization direction is to maximize "instability", that is, to pursue the maximum performance fluctuation or directly trigger failures. The adversarial test objective function can be constructed using a gradient optimization framework or reinforcement learning strategy, with the purpose of actively guiding the test process to explore the failure boundary. Specifically, maximizing application performance fluctuations is a stress testing strategy, which aims to actively find and amplify the instability of the performance of the application, rather than verifying the stable performance of the application. For example, during the test process, various input parameters and environmental conditions (such as network delay, data packet size, number of concurrent requests, system resource occupancy, etc.) are intelligently adjusted, and the degree of change in the performance indicators (such as response time, frame rate, CPU usage, etc.) of the application is observed. The goal is to find the parameter combination that can cause the performance indicators to produce the maximum amplitude of oscillation or degradation. Specifically, triggering stability failures is a destructive testing strategy, which aims to actively induce various unexpected failures of the application, that is, to find "bugs". For example, during the test process, various extreme, abnormal or non-conventional logic input and state combinations are tried to attempt to interrupt the core services of the application, cause process crashes, appear unresponsive, data errors or resource leaks, etc.

[0088] S54: Based on the adversarial test objective function, a preset optimization search algorithm is used to generate extreme test cases; In this embodiment, the optimization search algorithm refers to an algorithm for efficiently exploring a vast test input space to find test parameters that can maximize the value of the adversarial test objective function. Algorithms such as particle swarm optimization or Bayesian optimization can be used to implement it. Generally, the optimization search algorithm does not rely on exhaustion, but intelligently adjusts the search direction based on feedback, thereby efficiently discovering system boundary and unusual test parameter combinations, with the purpose of quickly approaching the system limit condition. The extreme test case refers to a test case generated by adversarial testing. The extreme test case simulates extreme, rare but possible conditions, and its purpose is not to verify normal functions, but to detect the breaking point of the system and find the critical condition of its failure, for example, simulating extreme network delay, maximum number of concurrent users, resource depletion, etc.

[0089] S55: Determine the stable running boundary of the target Hongmeng application for each device capability combination according to the execution result of the extreme test case, 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 size of the serial number of each step in the above embodiments does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0095] In an embodiment, a Harmony application compatibility test system based on the Harmony application compatibility test method described above is provided. The Harmony application compatibility test system based on the Harmony application compatibility test method described above corresponds one-to-one. The Harmony application compatibility test system based on the Harmony application compatibility test method described above comprises: A graph construction module is configured to collect attribute data of a terminal device 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. A feature extraction module is configured to obtain a current version installation package of a target Harmony application, and extract application metadata and application code features. A test case generation module is configured to match and infer the application metadata and the application code features through the device capability graph, and generate a compatibility test case set corresponding to the target Harmony application. A test case execution module is configured to execute the compatibility test case set in a distributed test environment, and collect running performance data and stability data of the target Harmony application. A compatibility evaluation module is configured to evaluate the compatibility of the target Harmony application based on the running performance data and the stability data, and generate a quantitative evaluation report.

[0096] For specific limitations of a Harmony application compatibility test system, refer to the limitations of a Harmony application compatibility test method described above, which will not be repeated here. Each module in the Harmony application compatibility test system described above can be realized by software, hardware, and combinations thereof, in whole or in part. Each module described above can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0097] In an embodiment, a computer device is provided, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the computer program to implement a Harmony application compatibility test method.

[0098] In an embodiment, a computer readable storage medium is provided, which stores a computer program. The computer program is executed by a processor to implement a Harmony application compatibility test method.

[0099] The above-described embodiments are only used to illustrate the technical solutions of the present application, but not limit them; although the present application is described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement to part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for testing application compatibility based on a HongMeng, the method comprising: The method comprises the steps 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 nodes of the device capability graph include device entities, hardware capabilities, software configurations, and distributed service characteristics; Obtaining a current version installation package of a target Harmony application, and extracting application metadata and application code features; Matching and reasoning the application metadata and the application code features through the device capability graph, to generate a compatibility test case set corresponding to the target Harmony application; Executing the compatibility test case set in a distributed test environment, and collecting running performance data and stability data of the target Harmony application; Performing compatibility evaluation on the target Harmony application based on the running performance data and the stability data, and generating a quantitative evaluation report. 2.The method of claim 1, wherein the method further comprises: The attribute data includes standardized capability data and non-standardized performance parameters, and 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 nodes of the device capability graph include device entities, hardware capabilities, software configurations, and distributed service characteristics, comprises the steps of: Collecting standardized capability data of terminal devices through a distributed device attribute library, and obtaining hardware specification information corresponding to the terminal devices, and extracting non-standardized performance parameters in the hardware specification information; Constructing a basic attribute layer taking devices as entities based on the standardized capability data and the non-standardized performance parameters; Obtaining technical specification information of a Harmony distributed service, and defining device capability rules based on the technical specification information; Performing logical reasoning on the basic attribute layer based on the device capability rules, to generate a relationship layer representing interactive capabilities between devices; Constructing a device capability graph based on the basic attribute layer and the relationship layer. 3.The method of claim 2, wherein the method further comprises: Before the step of performing logical reasoning on the basic attribute layer based on the device capability rules, to generate a relationship layer representing interactive capabilities between devices, the method further comprises the steps of: Associating and generating a corresponding mainstream application program list based on device entities in the basic attribute layer; Obtaining corresponding multi-source text data based on the device entities and the mainstream application program list; Analyzing the multi-source text data through natural language processing technology, identifying and extracting compatibility behavior patterns, converting the compatibility behavior patterns into implicit capability rules, and incorporating the implicit capability rules into the device capability rules.

4. The method of claim 1, wherein the method further comprises: The step of matching and reasoning the application metadata and the application code features through the device capability graph, to generate a compatibility test case set corresponding to the target Harmony application, comprises the steps of: Identifying device demand capability information in the application metadata, and matching the device demand capability information with device entities in the device capability graph, to screen an initial device set meeting basic running conditions; Analyzing the application code features, to identify a calling sequence of system APIs, a hardware resource access mode, and a potential distributed service calling path; Inferencing, based on the identified hardware resource access mode, a device capability combination and an interactive scenario in the initial device set that have potential compatibility conflicts; Parameterizing the inferred device capability combination and the interactive scenario into a test script, and automatically mutating key parameters in the test script, to generate a compatibility test case set.

5. The method of claim 4, wherein the method further comprises: The step of combining the inferred device capability set and the interaction scenario parameterization into a test script, and automatically mutating key parameters in the test script to generate a compatibility test case set, further comprises the steps of: Obtaining the market share of each device node in the device capability graph, identifying the execution frequency of the key path in the application code characteristics, obtaining the historical test cases and identifying the defect detection rate of the historical test cases; Based on the market share, the key path execution frequency and the defect detection rate, the priority weight of each test case in the compatibility test case set is calculated; Based on the pre-set resource allocation strategy and the priority weight, an execution scheduling instruction with execution priority is generated for the compatibility test case set.

6. The method of claim 1, wherein the method further comprises: The step of executing the compatibility test case set in the distributed test environment and collecting the running performance data and stability data of the target Harmony application comprises the steps of: Deploying a chaos injection controller in the distributed test environment, and performing corresponding injection operations through the chaos injection controller according to the distributed interaction scenarios defined by the compatibility test case set, the injection operations including network disturbance injection, resource competition injection and distributed service disturbance injection; During the execution of the injection operation, the running performance data and stability data of the target Harmony application are synchronously monitored and collected; When the running performance data deviates from the pre-set running performance threshold or the stability data deviates from the pre-set stability threshold, an adaptive fault injection adjustment mechanism is triggered, wherein the adaptive fault injection adjustment mechanism comprises: Identifying the injection parameter combination of the injection operation that causes the deviation, and setting the identified injection parameter combination as a compatibility risk critical point; Associating the compatibility risk critical point with the application code characteristics to define a compatibility risk mode, and updating the compatibility risk mode as a new attribute of the corresponding device entity to the device capability graph.

7. The method of claim 1, wherein the method further comprises: Each test case in the compatibility test case set is associated with a corresponding device capability combination, and the step of performing compatibility evaluation on the target Harmony application based on the running performance data and stability data and generating a quantitative evaluation report comprises the steps of: Based on the running performance data and stability data, the performance performance dispersion of the target Harmony application for each device capability combination is calculated; Marking the device capability combination corresponding to the performance performance dispersion greater than the pre-set dispersion threshold as an adversarial verification combination; Constructing an adversarial test objective function for the adversarial verification combination, the adversarial test objective function aiming to maximize the application performance fluctuation or trigger stability failure; Based on the adversarial test objective function, a preset optimization search algorithm is used to generate a limit test case; According to the execution result of the limit test case, the stable running boundary of the target Harmony application for each device capability combination is determined, and an adversarial verification report is generated. 8.A system for testing application compatibility based on a HongMeng, characterized in that, Comprise: The graph construction module is used for collecting attribute data of terminal devices through a distributed device attribute library, and constructing a device capability graph based on the attribute data, the nodes of the device capability graph including device entities, hardware capabilities, software configurations and distributed service characteristics; The feature extraction module is configured to obtain a current version installation package of a target Harmony application, and extract application metadata and application code features; The test case generation module is configured to match and infer the application metadata and the application code features through a device capability map, and generate a compatibility test case set corresponding to the target Harmony application. The test case execution module is configured to execute the compatibility test case set in a distributed test environment, and collect running performance data and stability data of the target Harmony application. The compatibility evaluation module is configured to evaluate the compatibility of the target Harmony application based on the running performance data and the stability data, and generate a quantitative evaluation report.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the steps of the Harmony application program compatibility test method according to any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program is executed by the processor to implement the steps of the Harmony application program compatibility test method according to any one of claims 1-7.

Images