Automated power consumption test method and system based on kylin operating system

Abstract

The application relates to an automatic power consumption test method based on a Kylin operating system, and comprises the following steps: S100, a test environment configuration module is constructed to eliminate the interference of environment differences on power consumption test results; S200, a test scene library is established to realize decoupling of test logic and system core code; S300, a scene execution engine is developed, test cases of corresponding test scenes are automatically executed according to an execution sequence defined by a configuration file through the scene execution engine, and power consumption data of a terminal to be tested are collected in real time at a fixed sampling frequency during the execution process; S400, a data analysis module is constructed to generate a standardized power consumption test report; and S500, power consumption test full-process automation is realized based on the above modules, batch test of multiple test scenes and comparative analysis of multiple version test results are supported. The application aims to solve the problems of low test efficiency and poor data accuracy in the prior art.

Description

Technical Field

[0001] This invention relates to the field of operating system technology, and specifically to an automated power consumption testing method and system based on the Kylin operating system. Background Technology

[0002] With the increasing popularity of domestically produced operating system terminals, users have higher and higher requirements for the battery life of these terminals. Currently, power consumption testing of the Kylin operating system mainly relies on manual operation, which suffers from problems such as low testing efficiency, inconsistent testing conditions, and inaccurate data recording.

[0003] Traditional power consumption testing methods have the following shortcomings: 1. The test scenario execution relies on manual operation, resulting in low testing efficiency; 2. It is difficult to ensure consistency in test environment settings, which affects the comparability of test results; 3. The process of collecting and analyzing power consumption data is cumbersome and prone to human error; 4. Lack of systematic test scenario management and automated execution capabilities. Summary of the Invention

[0004] The purpose of this invention is to provide an automated power consumption testing method based on the Kylin operating system, which solves the problems of low testing efficiency and poor data accuracy in the prior art.

[0005] To achieve the above objectives, this invention provides an automated power consumption testing method based on the Kylin operating system, comprising the following steps: S100: Build a test environment configuration module. Through the test environment configuration module, a unified test precondition is automatically set for the terminal under test running the Kylin operating system, eliminating the interference of environmental differences on power consumption test results. S200: Establish a test scenario library, classify test scenarios into single application scenarios and composite application scenarios. Test scenarios in the test scenario library are defined and managed through hierarchical structured configuration files to decouple test logic from the core system code. S300: Develop a scenario execution engine. The scenario execution engine automatically executes test cases for the corresponding test scenario according to the execution sequence defined in the configuration file, and collects power consumption data of the terminal under test in real time at a fixed sampling frequency during the execution process. S400: Construct a data analysis module to process the collected power consumption data, automatically calculate preset power consumption indicators, and generate a standardized power consumption test report based on the calculation results; S500: Based on the above modules, the power consumption test process is fully automated, supporting batch testing of multiple test scenarios and comparative analysis of test results from multiple versions.

[0006] Preferably, the preconditions for testing in step S100 include: The screen brightness is set to a preset fixed value, the desktop background is set to a preset uniform image, the WIFI is connected to the same specified network and the Bluetooth status remains consistent, the system volume is set to a preset uniform level, and the system process list is initialized in the same state.

[0007] Preferably, the scenario execution engine in step S300 includes a device control submodule, a power consumption monitoring submodule, and a timing control submodule; wherein, the device control submodule is used to control the terminal under test to perform preset test operations, the power consumption monitoring submodule is used to collect the current and voltage data of the terminal under test in real time and calculate the power data in real time, and the timing control submodule is used to control the execution duration and operation interval of the test operations; the scenario execution engine performs corresponding automated operations for different test scenarios.

[0008] Preferably, the preset power consumption indicators in step S400 include average power, average current, and power consumption optimization magnitude; wherein, average power is the arithmetic mean of all instantaneous power during the test period, average current is the arithmetic mean of all instantaneous current during the test period, and power consumption optimization magnitude is the percentage ratio of the difference in average current between the test version and the baseline version under the same test scenario to the average current of the baseline version.

[0009] Preferably, the hierarchical structured configuration file in step S200 includes a scenario definition layer, an execution sequence layer, a monitoring rule layer, and an assertion and report layer. The configuration file adopts YAML or JSON format. The definition and loading of new test scenarios can be completed by editing the configuration file without modifying the core system code.

[0010] This invention also provides an automated power consumption testing system based on the Kylin operating system, including an environment configuration module, a scene management module, an execution control module, a data acquisition module, and an analysis report module; wherein, The environment configuration module is used to automatically set uniform pre-test conditions for the terminal under test that runs the Kylin operating system. The scenario management module is used to build a test scenario library, classify and manage test scenarios, and complete the definition, parsing and loading of test scenarios through a hierarchical structured configuration file; The execution control module is used to automatically control the terminal under test to execute test cases for the corresponding test scenario according to the execution sequence defined in the configuration file. The data acquisition module is used to collect raw power consumption data of the terminal under test in real time at a fixed sampling frequency during the execution of test cases. The analysis report module is used to process the collected raw power consumption data, automatically calculate preset power consumption indicators, and generate standardized power consumption test reports based on the calculation results. The automated power consumption testing system is based on the above modules to automate the entire power consumption testing process, and supports batch testing of multiple test scenarios and comparative analysis of test results from multiple versions.

[0011] Preferably, the environment configuration module includes a brightness setting unit, a network configuration unit, a volume control unit, and a wallpaper setting unit, which respectively complete the automated and unified configuration of screen brightness, network and Bluetooth status, system volume, and desktop background.

[0012] Preferably, the execution control module includes an application control unit, an input simulation unit, a timing management unit, and an exception handling unit; the application control unit is used to control the startup, operation, and shutdown of the application; the input simulation unit is used to simulate the user's click, swipe, and text input operations; the timing management unit is used to control the execution timing of the test operations; and the exception handling unit is used to detect abnormal situations during the test process and execute the corresponding exception handling logic.

[0013] Preferably, the data acquisition module includes a current acquisition unit, a voltage acquisition unit, and a power calculation unit. The data acquisition module is used to synchronously acquire current and voltage data and calculate power data in real time. The analysis report module includes an average power calculation unit, an average current calculation unit, an optimization amplitude analysis unit, and a report generation unit. The analysis report module is used to complete the calculation of power consumption indicators and the generation of test reports.

[0014] Preferably, the test scenarios managed by the scenario management module are divided into single application scenarios and composite application scenarios. Among them, single application scenarios include screen-on standby, audio and video playback, web browsing, word processing, and online meeting scenarios, while composite application scenarios are high-load test scenarios constructed by superimposing multiple application loads in parallel or serially on the basis of single application scenarios.

[0015] The beneficial effects of this invention are as follows: It has achieved full automation of power consumption testing, improving testing efficiency; By configuring the environment, we can ensure the consistency of test conditions and guarantee the comparability of test results. Automated data collection and analysis reduce human error and improve data accuracy; A clearly defined method for calculating power consumption metrics (including a baseline definition for optimization magnitude) ensures that test results analysis is scientific and objective. A robust anomaly detection and handling mechanism ensures the stability and reliability of long-term batch automated testing. It supports flexible test scenario configuration and is easy to extend with new test cases; Automatically generates detailed test reports, facilitating performance analysis and optimization decisions; By introducing a declarative configuration file architecture, "code as configuration" for test scenarios is achieved, significantly reducing the technical threshold for creating and maintaining test cases and improving the reusability and management efficiency of test assets. Detailed Implementation

[0016] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0017] Example 1 This embodiment is a specific implementation method for an automated power consumption testing method based on the Kylin operating system. The specific implementation steps are as follows: S100: Automated Configuration of Test Environment A test environment configuration module is built. This module automatically sets uniform preconditions for the terminal under test running the Kylin Desktop Operating System V10, eliminating the interference of environmental differences on power consumption test results.

[0018] The specific details of the test preconditions and their automated implementation methods are as follows: 1. Set the screen brightness to a preset, uniform, and fixed value: Through the native / sys file system interface of the Kylin operating system, execute the command echo127> / sys / class / backlight / phytium_bl0 / brightness to fix the screen brightness at 127 (the maximum system brightness is 255), ensuring that the brightness is consistent across all test rounds; 2. Set the desktop background to a default, uniform image: Through the GNOME desktop gsettings interface, execute the command `gsettingssetorg.gnome.desktop.backgroundpicture-urifile: / / / usr / share / backgrounds / kylin_default.jpg` to set the desktop background to a system default image. 3. Ensure that the WIFI is connected to the same network and the Bluetooth status is consistent: Execute the command nmclidevicewificonnect "Kylin-Test-Lab"password "Test123456" through the DBus interface of NetworkManager to control the terminal under test to connect to the unified WIFI network with the specified SSID. At the same time, fix the Bluetooth switch status to "on" through the system Bluetooth management interface to ensure that the network and Bluetooth status are completely consistent. 4. Set the system volume to a preset uniform level: Execute the amixersetMaster20% command through the ALSA audio system interface to set the system master volume to a fixed level of 20%; 5. Ensure consistent initialization of system process list: Execute the command pkill -utestuser to shut down all non-essential user processes to ensure that the process running status of the terminal under test is completely consistent before each test starts.

[0019] S200: Test Scenario Library Construction and Management A test scenario library is established, which categorizes test scenarios into single application scenarios and composite application scenarios. Test scenarios in the library are defined and managed through hierarchical structured configuration files, thereby decoupling test logic from the core system code.

[0020] In this step, the hierarchical structured configuration file adopts YAML or JSON format and includes at least four core layers: scenario definition layer, execution sequence layer, monitoring rule layer, and assertion and reporting layer. Testers can complete the definition and loading of new test scenarios by editing the configuration file without modifying the core system code.

[0021] The test scenario library is categorized and contains the following: 1. Single application scenarios: including typical daily user scenarios such as screen-on standby, audio and video playback, web browsing, word processing, and online conferencing, covering the mainstream usage conditions of Kylin operating system terminals; 2. Composite Application Scenarios: These are high-load test scenarios built on top of a single application scenario by superimposing multiple application loads in parallel or serial manner. These include heavy-load scenarios such as screen-on standby and word processing, and are used to evaluate the system's power consumption performance under multi-tasking and high-load conditions.

[0022] S300: Automated Execution of Test Scenarios and Power Consumption Data Acquisition Develop a scenario execution engine that automatically executes test cases for the corresponding test scenario according to the execution sequence defined in the configuration file, and collects power consumption data of the terminal under test in real time at a fixed sampling frequency of 1Hz during the execution process.

[0023] In this step, the scene execution engine includes a device control submodule, a power consumption monitoring submodule, and a timing control submodule. The specific implementation of each submodule is as follows: Device control submodule: Used to control the terminal under test to perform preset test operations. Through the ADB debugging interface and the native API of the Kylin operating system, it performs corresponding automated operations for different test scenarios, including but not limited to: for video playback scenarios, automatically opening the player and playing the preset video file in full screen; for web browsing scenarios, automatically opening the browser and accessing the specified web pages in a preset order; for word processing scenarios, automatically opening the document editor and simulating user text input operations; for online meeting scenarios, automatically opening the meeting application, joining the preset meeting, and enabling the audio function.

[0024] Power consumption monitoring submodule: Used to collect current and voltage data of the terminal under test in real time and calculate power data in real time. Through the standard communication interface of an external high-precision power analyzer, it synchronously collects instantaneous current and instantaneous voltage data of the terminal under test at a fixed sampling frequency, and calculates instantaneous power data in real time based on the formula P=I×V, and simultaneously completes data validity verification.

[0025] Timing control submodule: Used to control the execution duration and interval of test operations. According to the preset parameters in the configuration file, it precisely controls the execution duration of each test step, the interval between adjacent operations, and the start and end times of power consumption data acquisition, ensuring that the timing of all test rounds is completely consistent.

[0026] The implementation code for the scene execution engine is as follows: defscenario_execution(scenario_config): # Load the scenario configuration file and parse the execution sequence execution_steps=scenario_config.get("execution_sequence",[]) monitor_config=scenario_config.get("monitoring_rules",{}) #Initialization timing control and device control timing_controller=TimingController() device_controller=DeviceController() #Execute test steps in sequence forstepinexecution_steps: device_controller.execute_action(step.get("action"),step.get("target"),step.get("args")) timing_controller.wait(step.get("wait_seconds",1)) #Startup power consumption data collection power_monitor = PowerMonitor() power_monitor.start_recording(sampling_rate=monitor_config.get("sampling_rate_hz",1)) #Execute monitoring according to preset duration timing_controller.wait(monitor_config.get("duration",600)) #Stop data collection and return raw power consumption data raw_power_data=power_monitor.stop_recording() returnraw_power_data.

[0027] S400: Power Consumption Data Analysis and Report Generation A data analysis module is built to process the collected power consumption data, automatically calculate preset power consumption indicators, and generate a standardized power consumption test report based on the calculation results.

[0028] In this step, the preset power consumption indicators include average power, average current, and power consumption optimization margin. The specific calculation rules for each indicator are as follows: Average power: The arithmetic mean of all instantaneous power within the test period. The calculation formula is P_avg=Σ(P_i) / n, where P_i is the instantaneous power value collected at the i-th time within the test period, and n is the total number of collections within the test period.

[0029] Average current: The arithmetic mean of all instantaneous currents within the test period. The calculation formula is I_avg=Σ(I_i) / n, where I_i is the instantaneous current value collected at the i-th time within the test period, and n is the total number of collections within the test period.

[0030] Power optimization margin: This is the percentage ratio of the average current difference between the version under test and the baseline version in the same test scenario to the average current of the baseline version. The calculation formula is Improvement=(I_baseline-I_test) / I_baseline×100%, where I_baseline is the average current value of the baseline version in the same test scenario, and I_test is the average current value of the current version under test in the same test scenario.

[0031] After the data analysis module completes the indicator calculation, it automatically calls the preset standardized report template to generate a power consumption test report that includes test environment information, scenario execution details, power consumption indicator data, and version comparison results. It supports exporting result files in PDF, CSV, and JSON formats.

[0032] The implementation code for data analysis and report generation is as follows: import numpyasnp defpower_data_analysis(baseline_data,test_data): #Calculate average power baseline_avg_power=np.mean(baseline_data['power']) test_avg_power=np.mean(test_data['power']) #Calculate average current baseline_avg_current=np.mean(baseline_data['current']) test_avg_current=np.mean(test_data['current']) #Calculate the extent of power consumption optimization improvement_rate=(baseline_avg_current-test_avg_current) / baseline_avg_current 100 #Summary of indicator results analysis_result={ "baseline_avg_power":baseline_avg_power, "baseline_avg_current":baseline_avg_current, "test_avg_power":test_avg_power, "test_avg_current":test_avg_current, "improvement_rate":improvement_rate } #Generate standardized power consumption test report generate_standard_report(analysis_result,template="kylin_power_test_template.html") returnanalysis_result.

[0033] S500: Full-process automation and batch testing Based on the aforementioned test environment configuration module, test scenario library, scenario execution engine, and data analysis module, the entire power consumption testing process is automated, supporting batch testing of multiple test scenarios and comparative analysis of test results from multiple versions.

[0034] In this step, the system can automatically execute multiple test scenarios sequentially according to the preset test task queue without manual intervention; at the same time, it can automatically perform comparative analysis of the test results of the version under test and multiple baseline versions, and generate multi-dimensional comparison reports to provide data support for power consumption optimization of the Kylin operating system.

[0035] Example 2 This embodiment is a specific implementation of an automated power consumption testing system based on the Kylin operating system. Each module achieves instruction transmission and data interaction through a data bus, specifically including an environment configuration module, a scene management module, an execution control module, a data acquisition module, and an analysis report module. The specific implementation of each module is as follows: The environment configuration module automatically sets uniform pre-test conditions for the terminals under test running the Kylin operating system, ensuring that the initial environment is completely consistent across all test rounds. This module includes a brightness setting unit, a network configuration unit, a volume control unit, and a wallpaper setting unit, each responsible for automatically configuring its corresponding parameters. Brightness setting unit: Sets the screen brightness of the terminal under test to a preset uniform fixed value through the / sys file system interface of the Kylin operating system; Network Configuration Unit: Through the NetworkManager's DBus interface, it automatically controls the terminal under test to connect to the specified WIFI network and sets the Bluetooth switch status to a unified preset state; Volume control unit: Sets the system volume of the terminal under test to a preset uniform level via the ALSA audio system interface; Wallpaper setting unit: Sets the desktop background image of the terminal under test to a preset uniform image through the gsettings interface of the GNOME desktop.

[0036] The scenario management module is used to build a test scenario library, classify and manage test scenarios, and define, parse, and load test scenarios through hierarchical structured configuration files. The test scenarios managed by the scenario management module are divided into single application scenarios and composite application scenarios. Single application scenarios: including screen-on standby, audio and video playback, web browsing, word processing, and online conferencing scenarios; Composite application scenario: A high-load test scenario built on top of a single application scenario by superimposing multiple application loads in parallel or serial manner.

[0037] Meanwhile, the scenario management module is responsible for performing syntax validation, parsing, and loading of configuration files, converting YAML or JSON format configuration files into executable test task objects for the system, and then sending them to the execution control module.

[0038] The execution control module, which automatically controls the terminal under test to execute test cases corresponding to the test scenario according to the execution sequence defined in the configuration file, is the core execution unit of the system. The execution control module includes an application control unit, an input simulation unit, a timing management unit, and an exception handling unit. The specific implementation of each unit is as follows: Application control unit: Used to control the startup, operation and shutdown of applications. Through the application startup interface of the Kylin operating system, it realizes the automated management and control of the target application's entire lifecycle. Input simulation unit: used to simulate user clicks, swipes and text input operations, and reproduces the user's real operation behavior through the Linux uinput input subsystem; Timing Management Unit: Used to control the execution sequence of test operations, precisely controlling the execution time of each test step, the execution order, and the interval between adjacent operations; Anomaly Handling Unit: Used to detect anomalies during the testing process and execute corresponding anomaly handling logic. It monitors application status, device connection status, and data acquisition status in real time, and executes graded handling strategies such as retry, recovery, and termination for anomalies of different levels.

[0039] The data acquisition module is used to collect raw power consumption data of the terminal under test in real time at a fixed sampling frequency during test case execution, providing an accurate and reliable data source for subsequent analysis. The data acquisition module includes a current acquisition unit, a voltage acquisition unit, and a power calculation unit. The specific implementation of each unit is as follows: Current acquisition unit: It acquires instantaneous current data of the terminal under test in real time at a fixed sampling frequency through the communication interface of an external power analyzer; Voltage acquisition unit: Synchronized with the current acquisition unit, it acquires the instantaneous voltage data of the terminal under test in real time at the same fixed sampling frequency; Power calculation unit: Based on synchronously acquired instantaneous current and voltage data, it calculates the instantaneous power data of the terminal under test in real time using the formula P=I×V.

[0040] All raw data collected by this module is transmitted to the analysis report module in real time via the data bus.

[0041] The analysis report module processes the collected raw power consumption data, automatically calculates preset power consumption indicators, and generates a standardized power consumption test report based on the calculation results. The analysis report module includes an average power calculation unit, an average current calculation unit, an optimization amplitude analysis unit, and a report generation unit. The specific implementation of each unit is as follows: Average power calculation unit: used to calculate the average power of the terminal under test during the test cycle; Average current calculation unit: used to calculate the average current of the terminal under test during the test cycle; Optimization Amplitude Analysis Unit: Used to calculate the power consumption optimization magnitude of the version under test relative to the baseline version; Report generation unit: Used to generate standardized power consumption test reports based on calculated power consumption indicators and preset templates, supporting export in multiple formats.

[0042] Based on the above five modules, this system automates the entire power consumption testing process and supports batch testing in multiple test scenarios and comparative analysis of test results from multiple versions.

[0043] Example 3 This embodiment is a specific implementation of the test scenario configuration file and exception handling mechanism, which is the core support for achieving flexible expansion of test scenarios and stable system operation.

[0044] 3.1 Detailed Implementation of Test Scenario Configuration File This system uses a hierarchical, structured configuration file in YAML format to define test scenarios, fully covering four core layers: scenario definition layer, execution sequence layer, monitoring rule layer, and assertion and reporting layer. A specific example is shown below: version:"1.0" metadata: Author: "Test Engineer" Description: "Kylin Operating System Online Video Playback Power Consumption Test Scenario" #Scenario Definition Layer: Describes the name, type, and prerequisites of the test scenario. scenario_definition: name: "online_video_playback" type:"single_app" preconditions: brightness: 127 wallpaper:" / usr / share / backgrounds / kylin_default.jpg" wifi_ssid:"Kylin-Test-Lab" volume_level:20 kill_background_apps:true #Execution Sequence Layer: Define test steps, operands, and parameters using an ordered list. execution_sequence: -step:1 action:"launch_app" target:"firefox" args:["https: / / support.kylinos.cn / training / video"] wait_seconds:5 -step:2 action: "simulate_click" target:"fullscreen_button" coordinates:[1900,1060] wait_seconds:2 -step:3 action: "simulate_click" target:"play_button" coordinates:[960,540] wait_seconds:1 #Monitoring Rules Layer: Defines the duration, frequency, and triggering conditions for data collection. monitoring_rules: sampling_rate_hz:1 duration: 600 start_trigger:"step.3.complete" stop_trigger:"duration_reach" #Assertion and Reporting Layer: Defining Results Analysis Metrics and Report Templates assertion and reporting: metrics_to_calculate:["avg_power","avg_current","improvement_rate"] comparison_baseline:"kylin_v10_sp1_baseline" report_template:"kylin_power_test_template.html" output_formats:["pdf","csv","json"] The above configuration file can be automatically parsed and loaded by the scenario management module. Testers only need to modify the contents of the configuration file to complete the creation of new test scenarios without modifying the core system code, thus decoupling the test logic from the core system code.

[0045] 3.2 Specific Implementation of Exception Handling Mechanism The exception handling unit of the execution control module adopts a hierarchical exception handling mechanism, which is implemented as follows: Anomaly detection: After each test step is executed, the application process status, device communication status, power consumption data acquisition status, and test environment configuration status are monitored in real time to determine whether any anomalies have occurred.

[0046] Hierarchical processing: Minor anomalies include single network fluctuations, single application startup failures, and single data collection anomalies. The handling logic is as follows: record the anomaly context information, retry the current operation, and retry a maximum of 3 times. If the retry is successful, continue executing the test process; if the retry fails, upgrade to a serious anomaly. Critical anomalies include application crashes, disconnections of the terminal under test, continuous interruptions in power consumption data collection, and failures to configure the test environment. The handling logic is as follows: immediately stop the current test case, save the on-site logs and system snapshots, perform recovery operations such as forced application shutdown and service restart, and if recovery fails, terminate the current test case, mark it as a test failure, and continue to execute the next test case. Anomaly Reporting: All anomaly information will be aggregated in the analysis report module, and a separate anomaly record section will be generated in the test report, clearly marking the time, scenario, steps and cause of the anomaly, which will facilitate problem tracing and location.

[0047] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. An automated power consumption testing method based on the Kylin operating system, characterized in that, Includes the following steps: S100: Build a test environment configuration module. Through the test environment configuration module, a unified test precondition is automatically set for the terminal under test running the Kylin operating system, eliminating the interference of environmental differences on power consumption test results. S2 00: Establish a test scenario library, classify test scenarios into single application scenarios and composite application scenarios. Test scenarios in the test scenario library are defined and managed through hierarchical structured configuration files to decouple test logic from the core system code; S300: Develop a scenario execution engine. The scenario execution engine automatically executes test cases for the corresponding test scenario according to the execution sequence defined in the configuration file, and collects power consumption data of the terminal under test in real time at a fixed sampling frequency during the execution process. S400: Construct a data analysis module to process the collected power consumption data, automatically calculate preset power consumption indicators, and generate a standardized power consumption test report based on the calculation results; S500: Based on the above modules, the power consumption test process is fully automated, supporting batch testing of multiple test scenarios and comparative analysis of test results from multiple versions.

2. The automated power consumption testing method based on the Kylin operating system according to claim 1, characterized in that, The preconditions for testing in step S100 include: The screen brightness is set to a preset fixed value, the desktop background is set to a preset uniform image, the WIFI is connected to the same specified network and the Bluetooth status remains consistent, the system volume is set to a preset uniform level, and the system process list is initialized in the same state.

3. The automated power consumption testing method based on the Kylin operating system according to claim 1, characterized in that, The scenario execution engine in step S300 includes a device control submodule, a power consumption monitoring submodule, and a timing control submodule. The device control submodule is used to control the terminal under test to perform preset test operations. The power consumption monitoring submodule is used to collect the current and voltage data of the terminal under test in real time and calculate the power data in real time. The timing control submodule is used to control the execution duration and operation interval of the test operations. The scenario execution engine performs corresponding automated operations for different test scenarios.

4. The automated power consumption testing method based on the Kylin operating system according to claim 1, characterized in that, The preset power consumption indicators in step S400 include average power, average current, and power consumption optimization magnitude; wherein, average power is the arithmetic mean of all instantaneous power during the test period, average current is the arithmetic mean of all instantaneous current during the test period, and power consumption optimization magnitude is the percentage ratio of the difference in average current between the test version and the baseline version under the same test scenario to the average current of the baseline version.

5. The automated power consumption testing method based on the Kylin operating system according to claim 1, characterized in that, The hierarchical structured configuration file in step S200 includes a scenario definition layer, an execution sequence layer, a monitoring rule layer, and an assertion and reporting layer. The configuration file adopts YAML or JSON format. The definition and loading of new test scenarios can be completed by editing the configuration file without modifying the core system code.

6. An automated power consumption testing system based on the Kylin operating system, characterized in that, It includes an environment configuration module, a scene management module, an execution control module, a data acquisition module, and an analysis report module; among which, The environment configuration module is used to automatically set uniform pre-test conditions for the terminal under test running the Kylin operating system. The scenario management module is used to build a test scenario library, classify and manage test scenarios, and complete the definition, parsing and loading of test scenarios through a hierarchical structured configuration file; The execution control module is used to automatically control the terminal under test to execute test cases for the corresponding test scenario according to the execution sequence defined in the configuration file. The data acquisition module is used to collect raw power consumption data of the terminal under test in real time at a fixed sampling frequency during the execution of test cases. The analysis report module is used to process the collected raw power consumption data, automatically calculate preset power consumption indicators, and generate standardized power consumption test reports based on the calculation results. The automated power consumption testing system is based on the above modules to automate the entire power consumption testing process, and supports batch testing of multiple test scenarios and comparative analysis of test results from multiple versions.

7. The automated power consumption testing system based on the Kylin operating system according to claim 6, characterized in that, The environment configuration module includes a brightness setting unit, a network configuration unit, a volume control unit, and a wallpaper setting unit, which respectively complete the automated and unified configuration of screen brightness, network and Bluetooth status, system volume, and desktop background.

8. The automated power consumption testing system based on the Kylin operating system according to claim 6, characterized in that, The execution control module includes an application control unit, an input simulation unit, a timing management unit, and an exception handling unit. The application control unit is used to control the startup, operation, and shutdown of the application. The input simulation unit is used to simulate the user's click, swipe, and text input operations. The timing management unit is used to control the execution timing of test operations. The exception handling unit is used to detect abnormal situations during the test process and execute the corresponding exception handling logic.

9. The automated power consumption testing system based on the Kylin operating system according to claim 6, characterized in that, The data acquisition module includes a current acquisition unit, a voltage acquisition unit, and a power calculation unit. The data acquisition module is used to synchronously acquire current and voltage data and calculate power data in real time. The analysis report module includes an average power calculation unit, an average current calculation unit, an optimization amplitude analysis unit, and a report generation unit. The analysis report module is used to complete the calculation of power consumption indicators and generate test reports.

10. The automated power consumption testing system based on the Kylin operating system according to claim 6, characterized in that, The test scenarios managed by the scenario management module are divided into single application scenarios and composite application scenarios. Among them, single application scenarios include screen-on standby, audio and video playback, web browsing, word processing, and online meeting scenarios. Composite application scenarios are high-load test scenarios built on the basis of single application scenarios by superimposing multiple application loads in parallel or serially.