Radio frequency test method and device, storage medium and program product

Abstract

The embodiment of the invention provides a radio frequency test method and device, a storage medium and a program product. The method comprises the steps of obtaining test scene data of a to-be-tested device, determining an execution sequence of a plurality of test scenes based on the scene dependency and resource occupation information, generating a control instruction according to the execution sequence, and sending the control instruction to the to-be-tested device, the control instruction is used for controlling the to-be-tested equipment to enter equipment states corresponding to the multiple test scenes in sequence, and controlling the radio frequency test equipment to perform radio frequency test on the to-be-tested equipment in the equipment states to obtain a corresponding radio frequency test result. According to the method provided by the embodiment of the invention, the problems of resource conflict and execution efficiency in multiple test scenes can be effectively solved, the coverage rate and the execution efficiency of radio frequency testing are remarkably improved, and the manual configuration and intervention cost is reduced.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a radio frequency testing method, device, storage medium, and program product. Background Technology

[0002] In the research and development and production of 5G terminal devices (such as smartphones and IoT modules), radio frequency sensitivity testing is a key step in verifying the communication performance of the devices under different working scenarios.

[0003] In related technologies, testing is typically conducted by operators manually switching between multiple scenarios. This method relies heavily on manual labor and has low testing efficiency. Summary of the Invention

[0004] This application provides an RF testing method, device, storage medium, and program product to improve testing efficiency.

[0005] In a first aspect, embodiments of this application provide a radio frequency testing method, including:

[0006] Acquire test scenario data for the device under test; the test scenario data includes the scenario names, scenario dependencies, and resource usage information for multiple test scenarios for radio frequency testing;

[0007] The execution order of multiple test scenarios is determined based on the scenario dependencies and resource usage information;

[0008] According to the execution order, control instructions are generated; the control instructions are used to control the device under test to sequentially enter the device states corresponding to the multiple test scenarios, and control the RF test equipment to perform RF tests on the device under test in the device states to obtain the corresponding RF test results.

[0009] In one possible design, determining the execution order of multiple test scenarios based on the scenario dependencies and the resource usage information includes:

[0010] A topology sorting graph is constructed for multiple test scenarios based on the scenario dependencies; the topology sorting graph is used to represent the sequential execution constraints between test scenarios;

[0011] The priority of each of the test scenarios is determined based on resource usage information; the priority is related to the execution time and hardware resource requirements of the corresponding test scenario.

[0012] Based on the priorities corresponding to the multiple test scenarios, the execution order of the scenarios in the topology sorting graph is adjusted to obtain the execution order of the multiple test scenarios.

[0013] In one possible design, determining the execution order of multiple test scenarios based on the scenario dependencies and the resource usage information includes:

[0014] Resource conflicts between multiple test scenarios are detected to obtain conflict detection results; the resource conflicts include hardware resource conflicts, which include at least one of the following: front and rear camera contention, same frequency band radio frequency channel contention, and high-load components operating at full load simultaneously.

[0015] Based on the conflict detection results, multiple test scenarios that have no dependencies and occupy independent resources are identified as composite test scenarios for parallel execution.

[0016] Test scenarios with resource conflicts will be determined to be executed sequentially or at intervals.

[0017] In one possible design, the method further includes:

[0018] For each of the aforementioned test scenarios, the execution process of the test scenario is controlled in stages through a state machine management module; the staged control includes controlling at least one of the following stages: pre-check stage, trigger stage, verification stage, and post-delay stage;

[0019] For each of the aforementioned stages, if the completion time of a stage exceeds a preset time, the stage will be retested a preset number of times; the preset number of times is determined based on the importance of the test scenario.

[0020] In one possible design, the method further includes:

[0021] For each of the aforementioned test scenarios, if an abnormal situation is detected during the execution of the test scenario, the abnormal data corresponding to the abnormal situation is input into the first model to obtain the corresponding recovery strategy; the first model is trained based on historical abnormal data; the abnormal situation includes at least one of the following: system crash, application unresponsiveness, abnormal sensor data, and exhaustion of hardware resources; the recovery strategy includes at least one of the following: restarting the test scenario, restarting the device, switching the test path, and sending alarm information.

[0022] In one possible design, the method further includes:

[0023] Determine the device model and hardware configuration information of the device to be tested;

[0024] Execution parameters for multiple test scenarios are determined based on the device model and the hardware configuration information; the execution parameters include at least one of the following: the CPU load limit and the camera frame rate;

[0025] The step of generating control instructions according to the execution order includes:

[0026] Control instructions are generated based on the execution parameters and execution order of the multiple test scenarios.

[0027] In one possible design, the RF test results include RF receiver sensitivity values, and the method further includes:

[0028] For each of the aforementioned test scenarios, before executing the test scenario, the device under test is controlled to enter a preset benchmark test state, and the corresponding benchmark RF receiving sensitivity value is obtained;

[0029] During the execution of the test scenario, multi-sensor data is acquired; the multi-sensor data includes at least one of the following: temperature data, humidity data, and light intensity.

[0030] The compensation value for the radio frequency receiving sensitivity value of the test scenario is determined based on the multi-sensor data;

[0031] The change in radio frequency performance in the test scenario is determined based on the compensation value, the radio frequency receiving sensitivity value, and the reference radio frequency receiving sensitivity value.

[0032] Secondly, embodiments of this application provide a radio frequency testing device, including:

[0033] The acquisition module is used to acquire test scenario data of the device under test; the test scenario data includes the scenario names, scenario dependencies and resource usage information of multiple test scenarios for radio frequency testing;

[0034] The determination module is used to determine the execution order of multiple test scenarios based on the scenario dependencies and the resource usage information;

[0035] The generation module is used to generate control instructions according to the execution order; the control instructions are used to control the device under test to sequentially enter the device states corresponding to the multiple test scenarios, and control the RF test equipment to perform RF tests on the device under test in the device states to obtain the corresponding RF test results.

[0036] Thirdly, embodiments of this application provide a radio frequency testing device, including: at least one processor and a memory;

[0037] The memory stores computer-executed instructions;

[0038] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method described in the first aspect above and various possible designs of the first aspect.

[0039] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method described in the first aspect and various possible designs of the first aspect.

[0040] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect above and various possible designs of the first aspect.

[0041] This embodiment provides an RF testing method, device, storage medium, and program product. The method includes acquiring test scenario data for the device under test (DUT). This test scenario data includes scenario names, scenario dependencies, and resource usage information for multiple test scenarios for RF testing. Based on the scenario dependencies and resource usage information, the execution order of the multiple test scenarios is determined. According to the execution order, control instructions are generated. These control instructions control the DUT to sequentially enter the device states corresponding to the multiple test scenarios, and control the RF testing device to perform RF testing on the DUT in the device states, obtaining the corresponding RF test results. The method provided in this embodiment automatically analyzes the logical dependencies and hardware resource usage between test scenarios, intelligently generates the execution order, and converts it into executable control instructions, achieving automated orchestration and scheduling of the test process. It effectively solves resource conflicts and execution efficiency problems in multiple test scenarios, significantly improves the coverage and execution efficiency of RF testing, reduces manual configuration and intervention costs, and is suitable for automated RF testing in large-scale, complex scenarios. Attached Figure Description

[0042] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0043] Figure 1 This is a schematic diagram illustrating an application scenario of the radio frequency testing method provided in the embodiments of this application;

[0044] Figure 2 A flowchart illustrating the radio frequency testing method provided in the embodiments of this application. Figure 1 ;

[0045] Figure 3 A system architecture diagram of the radio frequency testing method provided in the embodiments of this application;

[0046] Figure 4This is a schematic diagram of the structure of the radio frequency test equipment provided in the embodiments of this application;

[0047] Figure 5 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0048] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

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

[0050] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0051] It should be noted that the RF testing methods, equipment, storage media, and program products provided in this application can be used in the field of testing technology, or in any field other than testing technology. The application fields of the RF testing methods, equipment, storage media, and program products provided in this application are not limited.

[0052] In the research and development and production of 5G terminal equipment (such as smartphones, IoT modules, etc.), radio frequency sensitivity testing is a key step in verifying the communication performance of the equipment under different working scenarios.

[0053] Radio frequency (RF) testing requires simulating various complex scenarios (such as screen off, screen on, camera preview, high CPU load operation, charging status, etc.) to evaluate the device's signal reception capability under different power consumption modes and hardware loads.

[0054] In related technologies, operators need to manually switch between multiple scenarios and monitor the output data of the RF test equipment in real time, while recording the test results and manually calculating the deviation from the reference value. This process not only relies on the operator's experience but is also limited by the stability of the test environment (such as temperature changes, equipment movement, etc.).

[0055] As the complexity of 5G devices increases, the number of test scenarios is growing exponentially, making the inefficiency, high error rate, and low consistency of manual testing increasingly prominent. For example, when testing complex scenarios such as "full CPU load + camera preview" simultaneously, operators find it difficult to accurately synchronize the execution of multiple tasks, leading to significant deviations in test results.

[0056] Furthermore, the lack of an automatic recovery mechanism means that testing must be restarted when equipment malfunctions (such as system crashes or sensor failures) or scene switching fails, further extending the testing cycle. Therefore, there is an urgent need for an automated and intelligent RF testing solution to address the core pain points of existing technologies, such as low efficiency, poor consistency, and insufficient coverage.

[0057] To address the aforementioned technical problems, the inventors of this application have discovered, based on the pain points of existing technologies,

[0058] First, an analysis of the diverse requirements of RF testing reveals that the core problem with traditional manual operations lies in the lack of dynamic optimization for different scenarios. To address the efficiency issue, the scenario switching process can be abstracted into state nodes, and the optimal test sequence can be dynamically generated through preset scenario dependencies and resource conflict detection mechanisms. Furthermore, to address data consistency issues, environmental interference compensation algorithms (such as real-time temperature sensor correction) and automatic baseline calibration technology are introduced. Based on this, this application provides an RF testing method.

[0059] Figure 1 This is a schematic diagram illustrating an application scenario of the radio frequency testing method provided in the embodiments of this application. For example... Figure 1 As shown, the test system may include a terminal device 101, an RF test device 102, and a device under test (DUT) 103. The terminal device 101 and the RF test device 102 are communicatively connected, and the terminal device 101 is used to send control commands to the RF test device 102. Optionally, the test system may also include a data acquisition device 104, which is communicatively connected to the terminal 101 and is used to send the acquired data to the terminal device 101.

[0060] In the specific implementation process, the terminal device 101 obtains the test scenario data of the device under test 103. The test scenario data may include the scenario name, scenario dependency relationship and resource occupation information of multiple test scenarios for radio frequency testing. Based on the scenario dependency relationship and resource occupation information, the execution order of multiple test scenarios is generated. According to the execution order, control instructions are generated and sent to the radio frequency test device 102 and the device under test 103. The device under test 103 enters the device state corresponding to multiple test scenarios in sequence according to the control instructions. The radio frequency test device 102 performs radio frequency testing on the device under test 103 in the device state and obtains the corresponding radio frequency test results.

[0061] The RF testing method provided in this application automatically analyzes the logical dependencies and hardware resource usage between test scenarios, intelligently generates the execution sequence, and converts it into executable control instructions, thereby achieving automated orchestration and scheduling of the test process. It effectively solves resource conflicts and execution efficiency problems in multiple test scenarios, significantly improves the coverage and execution efficiency of RF testing, reduces manual configuration and intervention costs, and is suitable for automated RF testing in large-scale, complex scenarios.

[0062] It should be noted that, Figure 1 The schematic diagram shown is merely an example. The radio frequency testing methods and scenarios described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of the system and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0063] The technical solutions of this application will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0064] Figure 2 A flowchart illustrating the radio frequency testing method provided in the embodiments of this application. Figure 1 .like Figure 2 As shown, the method may include:

[0065] 201. Obtain test scenario data for the device under test; the test scenario data may include the scenario name, scenario dependency relationship and resource usage information of multiple test scenarios for RF testing.

[0066] In this embodiment, acquiring the test scenario data of the device under test is the initialization and configuration step for executing automated RF testing. The test scenario data can be a set of structured test metadata, providing a basis for decision-making in subsequent intelligent scheduling and execution control.

[0067] The scenario name can be a unique identifier for each test case, used for identification and recall within the system. For example, it could be "4G Band3 maximum power transmission test", "Wi-Fi 2.4GHz receiver sensitivity test", or "interference scenario test where Bluetooth and Wireless Fidelity (Wi-Fi) coexist".

[0068] Scenario dependency refers to the logical execution order constraints between different test scenarios. This dependency may stem from the test logic itself, such as the requirement to complete RF calibration before performance testing, or from device status requirements, such as the need to activate a specific network mode or application first. Dependencies can be described in the form of a directed graph and are crucial in determining whether the test process can execute correctly.

[0069] Resource usage information refers to the hardware and system resources required by each test scenario during runtime. This information may include, but is not limited to: specific RF front-end channels used, such as the main antenna and diversity antenna; sensors that need to be accessed, such as front and rear cameras and proximity sensors; processor or memory load requirements; and exclusive resources that may conflict with other scenarios, such as RF resources in the same frequency band. Resource usage information is fundamental for assessing the parallelism potential between scenarios, preventing resource conflicts, and optimizing overall execution efficiency.

[0070] The test scenario data can be obtained in various ways, such as loading from a predefined test configuration file (which can be in Extensible Markup Language (XML), JavaScript Object Notation (JSON), or YAML format); obtaining it through database queries; or dynamically obtaining it through interaction with the device under test and the test management platform. Its comprehensiveness and accuracy directly determine the rationality of the execution order in subsequent steps and the effectiveness of the test execution.

[0071] 202. Determine the execution order of multiple test scenarios based on scenario dependencies and resource usage information.

[0072] In this embodiment, after obtaining the test scenario data, the execution order of multiple test scenarios can be generated based on scenario dependencies and resource usage information, so as to transform the unordered or semi-ordered test scenario set into an efficient, conflict-free and logically constrained executable sequence.

[0073] For example, the process of generating the execution order may include first constructing a logical execution skeleton based on scenario dependencies. Dependencies define the order between scenarios; for example, scenario A must be executed before scenario B. By analyzing these dependencies, a directed graph model representing all scenarios and their constraints can be constructed, and algorithms such as topological sorting can be used to initially determine a basic execution order that satisfies all dependencies.

[0074] Based on this, the initial sequence can be further optimized and adjusted by incorporating resource usage information. Resource usage information reveals the hardware resource requirements (such as specific RF channels, sensors, processor cores, etc.) for each scenario. The core objective of optimization is to resolve resource conflicts and improve execution efficiency. For example, two test scenarios with no dependency and completely independent resource requirements can be identified as "composite test scenarios" that can be executed in parallel, thereby shortening the overall test time. Conversely, for scenarios with resource contention (such as both needing to use the same RF front-end), even if there is no logical dependency between them, the system needs to arrange them for sequential execution or staggered execution in time (interval execution) to avoid hardware conflicts leading to test failure.

[0075] In addition, the optimization process can introduce more strategies, such as assigning priorities to scenarios based on their execution time, importance, or resource consumption intensity. Under the premise of satisfying dependencies and resource constraints, high-priority or time-consuming scenarios are executed first to further optimize the overall efficiency of the testing process.

[0076] In some embodiments, determining the execution order of multiple test scenarios based on scenario dependencies and resource usage information may include: constructing a topology sorting graph of multiple test scenarios based on scenario dependencies; the topology sorting graph is used to represent the sequential execution constraints between test scenarios; determining the priority of each of the multiple test scenarios based on resource usage information; the priority is related to the execution time and hardware resource requirements of the corresponding test scenario; and adjusting the execution order of the scenarios in the topology sorting graph according to the priorities of the multiple test scenarios to obtain the execution order of the multiple test scenarios.

[0077] In this embodiment, the execution order of multiple test scenarios is determined based on scenario dependencies and resource usage information. An optimization strategy combining topology sorting and priority scheduling can be adopted. This strategy first constructs a topology sorting graph based on the dependencies between scenarios. This topology sorting graph can represent test scenarios with nodes and directive edges to represent the sequential execution constraints between scenarios. This ensures that any scenario is only scheduled after all its predecessor scenarios have been completed, forming the basic logical framework that the execution order must follow.

[0078] Building upon topology constraints, a resource-aware prioritization mechanism can be introduced. Priorities are dynamically calculated based on resource usage information for each test scenario, typically related to the scenario's execution time and hardware resource requirements. For example, a scenario with a long execution time or requiring exclusive access to high-load hardware resources might be assigned a higher priority to start execution earlier, thereby reducing its blocking impact on the overall test cycle.

[0079] Furthermore, the initial sequence derived from the topological sorting graph can be intelligently adjusted based on the calculated priorities. The adjustment process, while strictly adhering to dependencies, prioritizes high-priority scenarios within the sequence. This adjustment is not a simple global rearrangement, but rather a local optimization within a window allowed by the dependencies.

[0080] The method provided in this application combines dependency constraints with resource priorities, which can intelligently optimize the test sequence while ensuring the correctness of the test logic, effectively reduce the waiting time on the critical path, and thus improve the overall test throughput and execution efficiency.

[0081] In some embodiments, determining the execution order of multiple test scenarios based on scenario dependencies and resource usage information may include: detecting resource usage conflicts between multiple test scenarios and obtaining conflict detection results; resource usage conflicts may include hardware resource conflicts, which may include at least one of the following: contention for front and rear cameras, contention for the same frequency band radio frequency channel, and simultaneous full-load operation of high-load components; based on the conflict detection results, multiple test scenarios that have no dependencies and whose resource usage is independent are identified as composite test scenarios for parallel execution; and test scenarios with resource usage conflicts are identified as sequential or intermittent execution.

[0082] In this embodiment, the execution order can be determined through resource conflict detection and parallel scheduling. For example, resource conflicts between multiple test scenarios can be systematically detected first to obtain the conflict detection results. Resource conflicts can refer to hardware resource conflicts, such as front and rear cameras being contested by different scenarios, multiple scenarios needing to occupy the same frequency band radio frequency channel, or causing high-load components to run at full load simultaneously.

[0083] Based on the conflict detection results, different scheduling strategies can be adopted. For example, multiple test scenarios that have no dependencies and occupy independent resources can be identified as composite test scenarios, and multiple test scenarios can be scheduled to be executed in parallel, thereby making full use of hardware resources and shortening the overall test time. For test scenarios that have resource conflicts, even if there is no logical dependency between them, they can be determined to be executed sequentially or at time intervals to avoid test failures or inaccurate results caused by hardware conflicts.

[0084] This application embodiment, by actively detecting resource conflicts and implementing differentiated parallel and serial scheduling strategies, can maximize the concurrent utilization of hardware resources while ensuring test reliability, effectively improving the overall efficiency and throughput of test execution.

[0085] 203. Generate control instructions according to the execution order; the control instructions are used to control the device under test to enter the device state corresponding to multiple test scenarios in sequence, and control the RF test equipment to perform RF tests on the device under test in the device state to obtain the corresponding RF test results.

[0086] In this embodiment, the generated control commands can be a structured instruction set, the content of which can correspond to each test scenario in the execution sequence. For each scenario, the instruction set can contain commands at two levels: First, commands sent to the device under test (DUT) to control the DUT to enter the target device state required by the test scenario. For example, commands may include: setting a specific network standard (e.g., switching to 5G SA mode), adjusting the transmit power level, activating a specified sensor (e.g., enabling a camera for image transmission), or running a background application to simulate a load. Second, commands synchronously sent to the RF test equipment to control the execution of preset RF measurement items. For example, commands may include: setting the center frequency and bandwidth of the spectrum analyzer, starting the vector signal generator to transmit a test signal of a specific format, or commanding the comprehensive test instrument to perform a receiver sensitivity scan.

[0087] Optionally, based on the execution order, the corresponding device control parameters and test instrument configuration parameters can be instantiated for each scenario sequentially, and encapsulated into standard remote control protocol formats, such as Standard Commands for Programmable Instruments (SCPI) commands, Application Programming Interface (API) calls based on Transmission Control Protocol / Internet Protocol (TCP / IP), or specific message queue formats. The timing and synchronization of commands are crucial, ensuring that the RF test equipment only initiates measurement after the device under test is ready, thus guaranteeing the accuracy of the test results.

[0088] The RF testing method provided in this embodiment automates the analysis of logical dependencies and hardware resource usage between test scenarios, intelligently generates execution sequences, and transforms them into executable control instructions, thereby achieving automated orchestration and scheduling of the test process. It effectively resolves resource conflicts and execution efficiency issues in multiple test scenarios, significantly improves the coverage and execution efficiency of RF testing, reduces manual configuration and intervention costs, and is suitable for automated RF testing in large-scale, complex scenarios.

[0089] In some embodiments, the method may further include: for each test scenario, performing phased control of the execution process of the test scenario through a state machine management module; the phased control may include controlling at least one of the following phases: pre-check phase, trigger phase, verification phase, and post-delay phase; for each phase, if the completion time of the phase is longer than a preset time, the phase is retested a preset number of times; the preset number of times is determined according to the importance of the test scenario.

[0090] In this embodiment, the execution process of each test scenario can be finely controlled in stages through a state machine management module. For example, the execution of a single test scenario can be divided into multiple logical stages, such as at least one of a pre-check stage, a trigger stage, a verification stage, and a post-delay stage. The pre-check stage can be used to confirm that the test environment and equipment are ready; the trigger stage can execute core test actions; the verification stage can confirm the validity of the test results; and the post-delay stage can perform necessary state recovery or waiting.

[0091] For each stage, a stage completion timeout monitoring mechanism can be set up. If the execution time of a stage exceeds the preset threshold for that stage, the stage is considered to have failed. Then, based on the pre-defined importance of the test scenario, it can be determined whether and how many times to retest. Higher-importance scenarios will receive more retry opportunities. Retry will restart from the current failed stage or its logical starting point.

[0092] The method provided in this application significantly enhances the robustness and fault tolerance of the testing process through phased state management and an intelligent retry mechanism based on importance. It can automatically handle occasional anomalies, ensuring the full execution of critical tests while preventing the entire testing process from being interrupted by temporary failures, thereby improving the stability and success rate of automated testing.

[0093] In some embodiments, the method may further include: for each test scenario, if an abnormal situation is detected during the execution of the test scenario, inputting the abnormal data corresponding to the abnormal situation into the first model to obtain the corresponding recovery strategy; the first model is trained based on historical abnormal data; the abnormal situation may include at least one of the following: system crash, application unresponsiveness, abnormal sensor data, and exhaustion of hardware resources; the recovery strategy may include at least one of the following: restarting the test scenario, restarting the device, switching the test path, and sending alarm information.

[0094] In this embodiment, a model-based intelligent recovery mechanism can be adopted to address abnormal situations that occur during test execution.

[0095] In the specific implementation process, when an abnormal situation is detected during the execution of any test scenario, such as system crash, application unresponsiveness, abnormal sensor data, or exhaustion of hardware resources, the system can record detailed abnormal data corresponding to the abnormality.

[0096] The abnormal data can then be input into the first model for analysis. This first model can be a machine learning model pre-trained based on a large amount of historical abnormal data and successful handling experience, capable of identifying abnormal patterns and predicting effective recovery measures. The recovery strategy output by the model is dynamic and targeted, and may include one or more combined operations such as restarting the current test scenario, restarting the device under test, switching to an alternative test execution path, or sending specific alarm information to the operator.

[0097] The method provided in this application introduces an intelligent model trained on historical data for anomaly diagnosis and recovery decision-making, enabling rapid and accurate response to sudden failures in complex testing environments. It not only automatically performs routine recovery operations but also selects the optimal recovery path based on anomaly characteristics, thereby significantly reducing manual intervention and improving the adaptability and overall reliability of the automated testing system.

[0098] In some embodiments, the method may further include: determining the device model and hardware configuration information of the device to be tested; determining the execution parameters of multiple test scenarios based on the device model and hardware configuration information; the execution parameters may include at least one of the following: the load limit of the central processing unit and the camera frame rate.

[0099] Based on the execution order, control instructions can be generated, which may include generating control instructions based on the execution parameters and execution order of multiple test scenarios.

[0100] In this embodiment, the execution parameters of the test scenario can be customized according to the specific model and hardware configuration information of the device under test.

[0101] In the specific implementation process, you can first determine the device model and detailed hardware configuration information of the device under test, such as processor model, memory capacity, camera specifications, and RF front-end architecture.

[0102] Based on this information, execution parameters can then be determined for each test scenario. Execution parameters are key values ​​in the control commands that directly affect the device state, such as the maximum load the central processing unit is allowed to reach during testing, the specific frame rate the camera needs to maintain, or the level of RF transmission power. These execution parameters ensure that the test commands match the actual hardware capabilities of the device, avoiding test failures or equipment damage due to inappropriate parameters.

[0103] When generating control commands, the optimized execution order and execution parameters can be combined to generate the final control command set. This ensures that each command sent to the device under test has a clear operational target value that matches the device's hardware characteristics.

[0104] The method provided in this application uses device model and hardware configuration as the core basis for setting test parameters, thereby achieving precise customization of test instructions. This effectively improves the accuracy and reliability of testing, avoids incompatibility or performance bottlenecks caused by "one-size-fits-all" parameter settings, and ensures that automated testing can adapt to diverse device hardware ecosystems.

[0105] In some embodiments, the RF test results may include RF receiving sensitivity values, and the method may further include: for each test scenario, before executing the test scenario, controlling the device under test to enter a preset benchmark test state and obtaining the corresponding benchmark RF receiving sensitivity value; during the execution of the test scenario, acquiring multi-sensor data; the multi-sensor data may include at least one of the following: temperature data, humidity data, and light intensity; determining a compensation value for the RF receiving sensitivity value of the test scenario based on the multi-sensor data; and determining the RF performance change of the test scenario based on the compensation value, the RF receiving sensitivity value, and the benchmark RF receiving sensitivity value.

[0106] In this embodiment, environmental compensation and performance change analysis can be performed on the RF receiver sensitivity test results to improve the accuracy and comparability of the test results.

[0107] In practice, for each test scenario, before performing the core test of that test scenario, the device under test can be controlled to enter a preset, standardized benchmark test state, and the corresponding benchmark RF receiver sensitivity value can be measured and recorded in this state.

[0108] During the execution of this test scenario, multi-sensor data from built-in or external sensors can be acquired simultaneously, such as temperature, humidity, and light intensity data from inside the device or the environment. Changes in these environmental parameters may affect radio frequency performance.

[0109] Furthermore, based on the acquired multi-sensor data, a compensation value for the RF receiver sensitivity under the current environmental conditions can be determined using a predetermined compensation model or lookup table. This compensation value is used to correct for deviations in instantaneous measurement results caused by environmental factors.

[0110] Finally, by combining the compensation value, the actual tested RF receiver sensitivity value, and the previously recorded baseline RF receiver sensitivity value, the true change in RF performance under this test scenario can be calculated. This change excludes the influence of environmental fluctuations and better reflects performance changes caused by the device itself or by the load of the test scenario.

[0111] In this embodiment, by introducing baseline state measurements and environmental data compensation, the normalization of RF receiver sensitivity test results is achieved. This reduces the interference of environmental variables on the test results, making the performance data obtained at different times and under different conditions more comparable and valuable for analysis, thus improving the accuracy of test evaluation.

[0112] The following combination Figure 3 The working process of the radio frequency testing method provided in the embodiments of this application is illustrated by example.

[0113] like Figure 3 As shown, the test system comprises a support layer, a control layer, and an execution layer. The support layer may include an exception handling engine, a scenario library, and device adapters. The control layer may include a test management platform, a scenario orchestration engine, and a device control agent. The execution layer may include RF test equipment, a device under test (DUT), and a data acquisition module.

[0114] Optionally, the modules of the support layer and the control layer can be deployed on the same hardware device, for example... Figure 1 The terminal device 101 shown.

[0115] In the actual work process, the test management platform can load predefined test plans from the scenario library of the support layer. These plans can contain multiple test scenarios and their dependencies and resource usage information.

[0116] The scenario orchestration engine can intelligently analyze and optimize based on the loaded test scenario information, combined with its dependencies and resource usage information, to generate an efficient and conflict-free execution order for test scenarios.

[0117] According to the execution order, the device control agent synchronously sends control commands to the device under test and RF test equipment in the execution layer through the device adapter in the support layer, driving them to execute each test scenario in sequence.

[0118] During the test execution, the data acquisition module can collect RF measurement data from the RF test equipment in real time and record relevant test context information synchronously.

[0119] The exception handling engine can monitor the test status throughout the process. If an exception such as system crash, application unresponsiveness, or hardware resource exhaustion is detected, it can automatically make decisions and execute recovery strategies based on the model trained on historical data, such as restarting the scenario or device, to ensure the robustness of the test process.

[0120] After all tests are completed, the system can automatically analyze and process the collected data to generate a standardized test report, which includes RF performance indicators, test pass status, and any abnormal events.

[0121] In this embodiment, the hierarchical architecture of the testing system clarifies the responsibilities and collaborative relationships of each module, and realizes full-process automation from test plan loading, intelligent orchestration, precise execution, data collection to anomaly fault tolerance, ensuring the efficiency, reliability and maintainability of the testing system.

[0122] In summary, the radio frequency testing method and system provided in this application have achieved significant technological advancements and improved efficiency in multiple dimensions.

[0123] In terms of testing efficiency, the system significantly reduces the average testing time for a single device from 40 minutes to less than 10 minutes through intelligent orchestration and parallel scheduling, improving overall testing efficiency by more than 300%. Simultaneously, the system architecture supports multi-device parallel testing capabilities, enabling efficient testing of up to five devices at the same time.

[0124] Regarding data quality, the system uses environmental parameter compensation and precise process control to stably control the deviation of RF test results within ±0.3dB, ensuring high data consistency. Furthermore, the success rate of automated scene switching reaches over 99.5%.

[0125] In terms of test coverage, the system supports composite scenario testing including more than 10 scenarios, and can simulate abnormal operating conditions such as low power and high temperature for testing, realizing a more comprehensive and rigorous evaluation of the device's RF performance.

[0126] In terms of operational and maintenance costs, the system's fully automated process reduces the need for manual intervention by about 70%, while also reducing the training costs for test personnel by about 50%.

[0127] In terms of quality traceability and analysis, the system achieves complete recording of data throughout the entire testing process, including environmental parameters and equipment status, and supports comparative analysis of historical test data, providing a solid data foundation for continuous improvement of product quality.

[0128] Figure 4 This is a schematic diagram of the structure of the radio frequency test equipment provided in an embodiment of this application. Figure 4 As shown, the radio frequency test device 40 may include: an acquisition module 401, a determination module 402, and a generation module 403.

[0129] The acquisition module 401 is used to acquire test scenario data of the device under test; the test scenario data may include the scenario name, scenario dependency relationship and resource usage information of multiple test scenarios for radio frequency testing.

[0130] The determination module 402 is used to determine the execution order of multiple test scenarios based on scenario dependencies and resource usage information.

[0131] The generation module 403 is used to generate control instructions according to the execution order. The control instructions are used to control the device under test to enter the device state corresponding to multiple test scenarios in sequence, and to control the RF test equipment to perform RF tests on the device under test in the device state to obtain the corresponding RF test results.

[0132] The RF testing equipment provided in this application automatically analyzes the logical dependencies and hardware resource usage between test scenarios, intelligently generates the execution sequence, and converts it into executable control instructions, thus realizing the automated orchestration and scheduling of the test process. It effectively solves resource conflicts and execution efficiency problems in multiple test scenarios, significantly improves the coverage and execution efficiency of RF testing, reduces manual configuration and intervention costs, and is suitable for automated RF testing in large-scale, complex scenarios.

[0133] In some embodiments, the determining module 402 is specifically used to: construct a topology sorting graph of multiple test scenarios based on scenario dependencies; the topology sorting graph is used to represent the sequential execution constraints between test scenarios.

[0134] The priority of each test scenario is determined based on resource usage information; the priority is related to the execution time and hardware resource requirements of the corresponding test scenario.

[0135] Based on the priorities of the multiple test scenarios, the execution order of the scenarios in the topology sorting graph is adjusted to obtain the execution order of the multiple test scenarios.

[0136] In some embodiments, the determining module 402 is specifically used to: detect resource occupancy conflicts between multiple test scenarios and obtain conflict detection results; resource occupancy conflicts may include hardware resource conflicts, which may include at least one of the following: front and rear camera contention, same frequency band radio frequency channel contention, and high-load components operating at full load simultaneously.

[0137] Based on the conflict detection results, multiple test scenarios that have no dependencies and consume independent resources are identified as composite test scenarios and executed in parallel.

[0138] Test scenarios with resource conflicts will be determined to be executed sequentially or at intervals.

[0139] In some embodiments, the determining module 402 is further configured to: control the execution process of each test scenario in stages through the state machine management module; the staged control may include controlling at least one of the following stages: pre-check stage, trigger stage, verification stage, and post-delay stage.

[0140] For each stage, if the completion time of a stage exceeds the preset time, the stage will be retested a preset number of times; the preset number of times is determined based on the importance of the test scenario.

[0141] In some embodiments, the determining module 402 is further configured to: for each test scenario, if an abnormal situation is detected during the execution of the test scenario, input the abnormal data corresponding to the abnormal situation into the first model to obtain the corresponding recovery strategy; the first model is trained based on historical abnormal data; the abnormal situation may include at least one of the following: system crash, application unresponsiveness, sensor data abnormality, hardware resource exhaustion; the recovery strategy may include at least one of the following: restarting the test scenario, restarting the device, switching the test path, and sending alarm information.

[0142] In some embodiments, the determining module 402 is further configured to: determine the device model and hardware configuration information of the device to be tested.

[0143] The execution parameters for multiple test scenarios are determined based on the device model and hardware configuration information; the execution parameters may include at least one of the following: the CPU load limit and the camera frame rate.

[0144] The generation module 403 is used to generate control instructions based on the execution parameters and execution order of multiple test scenarios.

[0145] In some embodiments, the RF test results may include RF receiving sensitivity values. The determining module 402 is further configured to: for each test scenario, before executing the test scenario, control the device under test to enter a preset benchmark test state and obtain the corresponding benchmark RF receiving sensitivity value.

[0146] During the execution of the test scenario, data from multiple sensors is acquired; the data from multiple sensors may include at least one of the following: temperature data, humidity data, and light intensity.

[0147] The compensation value for the RF receiver sensitivity of the test scenario is determined based on multi-sensor data.

[0148] Based on the compensation value, the RF receiver sensitivity value, and the reference RF receiver sensitivity value, the change in RF performance in the test scenario is determined.

[0149] The radio frequency testing equipment provided in this application embodiment can be used to execute the above-described method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0150] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment may include at least one processor 501 and a memory 502. Optionally, the electronic device 50 may further include a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus.

[0151] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0152] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0153] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0154] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0155] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0156] This application also provides a computer program product that may include a computer program that, when executed by a processor, implements the above-described method.

[0157] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0158] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0159] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0160] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0161] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0162] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0163] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and may include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium may include: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code.

[0164] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the execution may include the steps of the above-described method embodiments; and the aforementioned storage medium may include various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0165] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and may include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A radio frequency testing method, characterized in that, include: Acquire test scenario data for the device under test; The test scenario data includes the scenario names, scenario dependencies, and resource usage information for multiple test scenarios for radio frequency testing. The execution order of multiple test scenarios is determined based on the scenario dependencies and resource usage information; Control instructions are generated according to the execution order; The control command is used to control the device under test to sequentially enter the device states corresponding to the multiple test scenarios, and to control the radio frequency test equipment to perform radio frequency tests on the device under test in the device states to obtain the corresponding radio frequency test results.

2. The method according to claim 1, characterized in that, Determining the execution order of multiple test scenarios based on the scenario dependencies and resource usage information includes: A topology sorting graph is constructed for multiple test scenarios based on the scenario dependencies; the topology sorting graph is used to represent the execution order constraints between test scenarios. The priority of each of the test scenarios is determined based on resource usage information; the priority is related to the execution time and hardware resource requirements of the corresponding test scenario. Based on the priorities corresponding to the multiple test scenarios, the execution order of the scenarios in the topology sorting graph is adjusted to obtain the execution order of the multiple test scenarios.

3. The method according to claim 1, characterized in that, Determining the execution order of multiple test scenarios based on the scenario dependencies and resource usage information includes: Resource conflicts between multiple test scenarios are detected to obtain conflict detection results; the resource conflicts include hardware resource conflicts, which include at least one of the following: front and rear camera contention, same frequency band radio frequency channel contention, and high-load components operating at full load simultaneously. Based on the conflict detection results, multiple test scenarios that have no dependencies and occupy independent resources are identified as composite test scenarios for parallel execution. Test scenarios with resource conflicts will be determined to be executed sequentially or at intervals.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: For each of the aforementioned test scenarios, the execution process of the test scenario is controlled in stages through a state machine management module; the staged control includes controlling at least one of the following stages: pre-check stage, trigger stage, verification stage, and post-delay stage; For each of the aforementioned stages, if the completion time of a stage exceeds a preset time, the stage will be retested a preset number of times; the preset number of times is determined based on the importance of the test scenario.

5. The method according to claim 4, characterized in that, The method further includes: For each of the aforementioned test scenarios, if an abnormal situation is detected during the execution of the test scenario, the abnormal data corresponding to the abnormal situation is input into the first model to obtain the corresponding recovery strategy; the first model is trained based on historical abnormal data; the abnormal situation includes at least one of the following: system crash, application unresponsiveness, abnormal sensor data, and exhaustion of hardware resources; the recovery strategy includes at least one of the following: restarting the test scenario, restarting the device, switching the test path, and sending alarm information.

6. The method according to any one of claims 1-3, characterized in that, The method further includes: Determine the device model and hardware configuration information of the device to be tested; Execution parameters for multiple test scenarios are determined based on the device model and the hardware configuration information; the execution parameters include at least one of the following: the CPU load limit and the camera frame rate; The step of generating control instructions according to the execution order includes: Control instructions are generated based on the execution parameters and execution order of the multiple test scenarios.

7. The method according to any one of claims 1-3, characterized in that, The radio frequency test results include radio frequency receiver sensitivity values, and the method further includes: For each of the aforementioned test scenarios, before executing the test scenario, the device under test is controlled to enter a preset benchmark test state, and the corresponding benchmark RF receiving sensitivity value is obtained; During the execution of the test scenario, multi-sensor data is acquired; the multi-sensor data includes at least one of the following: temperature data, humidity data, and light intensity. The compensation value for the radio frequency receiving sensitivity value of the test scenario is determined based on the multi-sensor data; The change in radio frequency performance in the test scenario is determined based on the compensation value, the radio frequency receiving sensitivity value, and the reference radio frequency receiving sensitivity value.

8. A radio frequency testing device, characterized in that, include: The acquisition module is used to acquire test scenario data of the device under test. The test scenario data includes the scenario names, scenario dependencies, and resource usage information for multiple test scenarios for radio frequency testing. The determination module is used to determine the execution order of multiple test scenarios based on the scenario dependencies and the resource usage information; The generation module is used to generate control instructions according to the execution order; the control instructions are used to control the device under test to sequentially enter the device states corresponding to the multiple test scenarios, and control the RF test equipment to perform RF tests on the device under test in the device states to obtain the corresponding RF test results.

9. A radio frequency testing device, characterized in that, include: At least one processor and memory; The memory stores computer-executed instructions; The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the radio frequency test method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by the processor, implement the radio frequency testing method as described in any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the radio frequency testing method according to any one of claims 1 to 7.

Images