Lithium battery bms cloud platform firmware upgrade push function test and execution method

Abstract

The application discloses a lithium battery BMS cloud platform firmware upgrade pushing function test and execution method, comprising the following steps: S1, dividing test cases into six dimensions, selecting key parameter combinations from each dimension based on an orthogonal experiment design method, and generating a basic test case set; S2, supplementing boundary cases through boundary value analysis to finally form a complete test set; S3, constructing a test environment, checking the test environment, and initializing test data; S4, test case scheduling, and distributing test tasks by using a load balancing algorithm; S5, controlling the test process through a script, automatically triggering an upgrade instruction, simulating an abnormal scenario, and recording execution results; and S6, identifying abnormal data through big data analysis technology, and generating a test report of each dimension. The application adopts a combination of automatic execution and manual verification, realizes comprehensive testing of the BMS cloud platform firmware upgrade pushing function, and significantly reduces the safety risk of lithium batteries caused by firmware upgrade pushing problems.

Description

Technical Field

[0001] This invention belongs to the field of battery management system testing technology, specifically relating to a testing and execution method for the firmware upgrade push function of a lithium battery BMS cloud platform. Background Technology

[0002] With the development of lithium battery technology, the BMS (Battery Management System), as the "brain" of the lithium battery, has seen its functions continuously enriched. Remote firmware upgrades via cloud platforms have become the mainstream solution in the industry. Currently, the mainstream BMS cloud platform firmware upgrade push process includes: cloud platform generates upgrade instructions → encrypted and packaged firmware → pushes it to the terminal BMS via 4G / 5G / Wi-Fi networks → terminal receives and verifies → executes the upgrade → feedback of upgrade results. Existing testing methods mainly focus on: 1. Functional testing: verifying whether the basic upgrade process is smooth; 2. Compatibility testing: verifying compatibility for a few mainstream BMS models; 3. Simple stress testing: simulating a scenario where a small number of terminals are upgraded simultaneously. According to industry reports, the global electric vehicle BMS cloud platform market reached $8.7 billion in 2024, with an annual growth rate of 23.5%, and the user coverage rate of remote firmware upgrade functionality reached 92%.

[0003] The existing testing methods have the following shortcomings: 1. Incomplete test coverage: They only cover 5-8 network environments, while there are more than 20 complex network scenarios in actual applications, resulting in an upgrade failure rate of 8.7% due to network problems in actual applications.

[0004] 2. Lack of consideration for battery status: Test cases were not designed in conjunction with parameters such as battery SOC (State of Charge) and temperature. In actual applications, upgrade interruptions due to low battery accounted for 15.3%.

[0005] 3. Low testing efficiency: Traditional methods require 72 hours to simulate testing 1,000 terminals, and the rate of manual intervention is as high as 35%.

[0006] 4. Insufficient coverage of abnormal scenarios: Only 3-5 abnormal scenarios are included in the test, while more than 30 abnormal scenarios may occur in actual operation, resulting in an unknown failure rate of 6.2%.

[0007] 5. Lack of a quantitative evaluation system: The reliability of the upgrade push function cannot be accurately quantified, and the reliability of the test results is only 68%. Summary of the Invention

[0008] The purpose of this invention is to provide a testing and execution method for the firmware upgrade push function of a lithium battery BMS cloud platform. By constructing a multi-dimensional test model and designing a test case set covering different network environments, hardware configurations, and battery states, and by adopting a combination of automated execution and manual verification, a comprehensive test of the firmware upgrade push function of the BMS cloud platform can be achieved, which significantly reduces the safety risks of lithium batteries caused by firmware upgrade push problems.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a method for testing and executing firmware upgrade push function of a lithium battery BMS cloud platform, comprising the following steps: S1. Divide the test cases into 6 dimensions, and based on the orthogonal experimental design method, select key parameter combinations from each dimension to generate a basic test case set; S2. Boundary test cases are supplemented through boundary value analysis, ultimately forming a complete test set; S3. Build the test environment, check the test environment, and initialize the test data; S4. Test case scheduling: A load balancing algorithm is used to allocate test tasks. S5. Control the test process through scripts, automatically trigger upgrade commands, simulate abnormal scenarios, and record execution results; S6. Identify abnormal data through big data analytics and generate test reports for various dimensions; S7. Automatically trigger the reproduction process for failed test cases, and locate the root cause of the failure by combining device logs and monitoring data.

[0010] Preferably, the six dimensions specifically include: network environment dimension, hardware configuration dimension, battery status dimension, firmware characteristics dimension, concurrency scale dimension, and abnormal scenario dimension.

[0011] Preferably, the construction of the test environment includes building a comprehensive test platform, deploying hybrid test nodes, and configuring a monitoring and analysis system.

[0012] Preferably, the comprehensive testing platform includes an integrated hardware simulator, a network simulator, and a battery status simulator, which can accurately simulate the operating characteristics of different hardware models, complex network environments, and various battery status parameters. The deployment of hybrid test nodes includes 100 physical test terminals (covering 18 mainstream BMS hardware models) and 10,000 virtual test nodes (deployed based on Docker container technology, supporting dynamic expansion) to meet the testing needs of different concurrency scales. Configure a monitoring and analysis system: Deploy real-time monitoring tools that can collect 38 key indicators such as upgrade success rate, upgrade time, network bandwidth usage, battery status changes, and device operation logs, and support real-time data visualization and historical backtracking.

[0013] Preferably, the load balancing algorithm allocates test tasks by matching test cases according to the node load capacity and test case resource requirements. High resource requirement test cases (such as 100,000 concurrent tests) are preferentially allocated to physical terminals or high-configuration virtual nodes, while low resource requirement test cases (such as single network scenario tests) are evenly allocated to the remaining nodes.

[0014] Preferably, the load balancing algorithm is as follows: A weighted round-robin / resource-aware hybrid algorithm is adopted, which combines node resource capabilities (weighting) with real-time load status (awareness) to achieve balanced distribution of test tasks and avoid overload or idleness of a single node. Node weight reflects the node's resource carrying capacity, calculated based on three core resources: CPU, memory, and network bandwidth. Node weight calculation : ; In the formula: Let be the weight of the i-th node (value range 0-1). This represents the number of CPU cores in the i-th node (8 cores for physical terminals and 4 cores for virtual nodes by default). This represents the maximum number of CPU cores across all nodes (8 in this case). Set the maximum memory capacity for all nodes (32GB by default for physical terminals and 16GB by default for virtual nodes). This represents the maximum memory capacity across all nodes (32GB in this case). This represents the maximum network bandwidth for the i-th node (100Mbps by default for physical terminals and 50Mbps by default for virtual nodes). This represents the maximum network bandwidth among all nodes (100Mbps in this case). This is the CPU weighting coefficient. For memory weighting coefficients, These are the network weight coefficients; Calculate the real-time load factor of the node based on real-time resource utilization. .

[0015] Preferably, the real-time load factor of the node The calculation formula is as follows: ; In the formula: This is the real-time load coefficient of the i-th node (the value ranges from 0 to 1, and the closer it is to 1, the busier it is). Let be the real-time CPU utilization of the i-th node (e.g., 0.6 if it is 60%). Let be the real-time memory utilization of the i-th node. Let be the real-time network bandwidth utilization of the i-th node.

[0016] Preferably, the assignment of test tasks: the task assignment priority is determined by both weight and real-time load; ; in: Assign priority to the task of the i-th node (the value ranges from 0 to 1, with higher values ​​indicating higher priority). This represents the node idle coefficient (the lower the load, the larger the idle coefficient).

[0017] Compared with the prior art, the beneficial effects of the present invention are: 1. Improved comprehensive test coverage: The number of test dimensions has been expanded from the traditional 3 to 6, the scenario coverage has been increased by 300%, and the defect detection rate has been increased by 68.3%.

[0018] 2. Significantly improved testing efficiency: The testing time for 10,000 terminals was reduced from 72 hours to 18 hours, an efficiency improvement of 75%; the rate of manual intervention was reduced from 35% to 8%.

[0019] 3. Enhanced risk control capabilities: Through testing in 42 abnormal scenarios, the incidence of unknown failures was reduced from 6.2% to 1.1%, significantly reducing the safety risks of lithium batteries.

[0020] 4. Quantitative evaluation system: Establish a scientific evaluation index system to increase the reliability of test results from 68% to 95%.

[0021] 5. Significant economic benefits: According to actual application data, the user complaint rate decreased by 83% after adopting this method.

[0022] 6. High versatility: Applicable to different types and manufacturers of lithium battery BMS cloud platforms, with compatibility exceeding 98%. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the overall process structure of this method; Figure 2 Design a dimensional relationship diagram for the test cases in this method; Figure 3 This is a flowchart of the automatic test execution process in this method. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Please see Figures 1-3 This invention provides a technical solution: a method for testing and executing firmware upgrade push function of a lithium battery BMS cloud platform, comprising the following steps: Test case design: Step 1: Divide the test cases into 6 dimensions; Network environment dimension: Includes 23 network scenarios, covering different signal strengths of 4G / 5G (-110dBm to -50dBm), Wi-Fi interference (2.4G / 5G frequency band conflict), network switching (4G→5G→Wi-Fi), network disconnection and reconnection, latency jitter (10ms-500ms), etc. Hardware configuration: Covers 18 mainstream BMS hardware models (including products from mainstream manufacturers such as CATL, BYD, and Sunwoda) and 32 hardware parameter combinations (such as processor model, storage capacity, and communication module type). Battery status dimension: covering SOC (0-100%, step 5%), temperature (-20℃ to 60℃, step 5℃), health status (SOH 60%-100%, step 10%), and also including key scenarios such as charge and discharge status (resting, charging, discharging); Firmware feature dimensions: including firmware size (1MB-50MB, divided into 5 ranges), version span (spanning 1-5 versions), and functional modules (separate upgrade scenarios for core control modules, communication modules, security modules, etc.). Concurrency scale dimension: 9 tiers from 10, 100, 1000, 5000, 10000, 30000, 50000, 80000 to 100000 terminals, covering all scenarios from small-scale testing to large-scale deployment; Abnormal Scenarios: 42 abnormal scenarios are designed, including network-related (network outage, weak network, network hijacking), power-related (sudden power outage, voltage fluctuation), data-related (firmware package tampering, checksum error), device-related (device offline, restart, hardware failure), and battery-related (low battery, extreme temperature, SOH degradation), etc.

[0026] Based on orthogonal experimental design, key parameter combinations are selected from various dimensions to generate a basic test case set: Key parameters were selected from six dimensions and combined to generate 1200 basic test cases, ensuring even coverage of parameters across all dimensions.

[0027] Step 2: Supplement boundary test cases through boundary value analysis to finally form a complete test suite: Then, 800 boundary test cases (such as SOC=0%, temperature=-20℃, firmware size 50MB, 100,000 concurrent devices, etc.) are added through boundary value analysis, finally forming a complete test set containing 2,000 test cases, which ensures comprehensive coverage and avoids redundancy. Test execution steps: Step 3: Build the test environment; Building a test environment includes building a comprehensive test platform, deploying hybrid test nodes, and configuring a monitoring and analysis system.

[0028] The comprehensive testing platform includes an integrated hardware simulator, network simulator, and battery status simulator, which can accurately simulate the operating characteristics of different hardware models, complex network environments, and various battery status parameters. Deploy hybrid test nodes: including 100 physical test terminals (covering 18 mainstream BMS hardware models) and 10,000 virtual test nodes (deployed based on Docker container technology, supporting dynamic expansion) to meet the testing needs of different concurrency scales; Configure a monitoring and analysis system: Deploy real-time monitoring tools that can collect 38 key indicators such as upgrade success rate, upgrade time, network bandwidth usage, battery status changes, and device operation logs, and support real-time data visualization and historical backtracking; Perform test environment checks and test data initialization; Unify BMS baseline version: Flash the BMS firmware version of all test terminals (physical + virtual) to the same baseline version (e.g., V3.0) to ensure consistency of initial state.

[0029] Device identification configuration: Assign a unique device ID and communication address to each terminal, enter it into the cloud platform device management list, and complete device registration and authentication.

[0030] Security parameter initialization: Configure firmware encryption key (AES-256 algorithm) and checksum (SHA-256) generation rules, and synchronize them to the cloud platform and terminal.

[0031] Calibrate battery simulator parameters: Set initial SOC to 50% (standard reference value), temperature to 25℃ (normal temperature environment), and SOH to 90% (healthy state) to ensure that the initial parameters of all terminal batteries are consistent.

[0032] Enter battery characteristic parameters: Import basic data such as charge and discharge curves and safety thresholds (e.g., overcharge voltage 4.2V, over-discharge voltage 2.5V) of different types of lithium batteries.

[0033] Step 4: Test case scheduling, using a load balancing algorithm to allocate test tasks; Total number of test tasks: 2000 test cases. Specific execution time estimates for each test case (5-10 minutes / case for basic test cases, 10-15 minutes / case for boundary test cases) and resource requirements (CPU / memory / network bandwidth).

[0034] Collect node resource status: Real-time acquisition of the current load (CPU utilization, memory usage, network usage) of 100 physical terminals + 10,000 virtual nodes, and marking available nodes (load ≤ 70%) and busy nodes (load > 70%). Load balancing algorithm for allocating test tasks: Test cases are allocated according to the principle of matching node load capacity with test case resource requirements. High resource requirement test cases (such as 100,000 concurrent tests) are prioritized to be allocated to physical terminals or high-configuration virtual nodes, while low resource requirement test cases (such as single network scenario tests) are evenly allocated to the remaining nodes. Establish a task queue: sort unassigned test cases by priority, dynamically monitor node status, and when the node load drops below the threshold, extract the next test case from the queue for execution to avoid node idleness; The specific load balancing algorithm is as follows: A weighted round-robin / resource-aware hybrid algorithm is adopted, which combines node resource capabilities (weighting) with real-time load status (awareness) to achieve balanced distribution of test tasks and avoid overload or idleness of a single node. Node weight reflects the node's resource carrying capacity, calculated based on three core resources: CPU, memory, and network bandwidth. Node weight calculation : ; In the formula: Let be the weight of the i-th node (value range 0-1). This represents the number of CPU cores in the i-th node (8 cores for physical terminals and 4 cores for virtual nodes by default). This represents the maximum number of CPU cores across all nodes (8 in this case). Set the maximum memory capacity for all nodes (32GB by default for physical terminals and 16GB by default for virtual nodes). This represents the maximum memory capacity across all nodes (32GB in this case). This represents the maximum network bandwidth for the i-th node (100Mbps by default for physical terminals and 50Mbps by default for virtual nodes). This represents the maximum network bandwidth among all nodes (100Mbps in this case). This is the CPU weighting coefficient. For memory weighting coefficients, These are the network weight coefficients; Calculate the real-time load factor of the node based on real-time resource utilization. .

[0035] Node real-time load factor The calculation formula is as follows: ; In the formula: This is the real-time load coefficient of the i-th node (the value ranges from 0 to 1, and the closer it is to 1, the busier it is). Let be the real-time CPU utilization of the i-th node (e.g., 0.6 if it is 60%). Let be the real-time memory utilization of the i-th node. Let be the real-time network bandwidth utilization of the i-th node.

[0036] Assigning test tasks: Task assignment priority is determined by both weight and real-time load; ; in: Assign priority to the task of the i-th node (the value ranges from 0 to 1, with higher values ​​indicating higher priority). This represents the node idle coefficient (the lower the load, the larger the idle coefficient). according to Sort all nodes in descending order and assign test tasks to the nodes with the highest priority. The maximum number of tasks that can be assigned to each node Calculation formula: ; In the formula: This represents the total number of test tasks (2000 in this case). This is the load redundancy factor (valued at 0.8 to avoid nodes operating at full load).

[0037] Step 5: Control the test process through scripts to automatically trigger upgrade commands, simulate abnormal scenarios, and record execution results; Script triggering: The test scheduling center sends an automated script execution instruction to the target node. The script includes test case parameters (such as network scenario, battery status, firmware version, etc.), execution steps, and expected results.

[0038] Process control: 90% automation use cases (1800): No human intervention throughout the process. The script automatically controls the terminal to receive upgrade instructions, simulate target scenarios (such as network switching, low battery), execute upgrade operations, and record real-time data.

[0039] 10% Manually Assisted Test Cases (200): For complex scenarios such as hardware failure simulation and extreme environment combinations, testers assist in triggering the scenario (such as manually disconnecting the power to the physical terminal), and the script synchronously records the execution results.

[0040] Progress monitoring: Real-time statistics on test case execution progress (executed / not executed / failed / successful). When a node fails to execute, the test case is automatically added to the retry queue. If it still fails after 2 retries, it is marked as "to be reproduced".

[0041] Key metrics collected (38 core metrics), as shown in Table 1: Data analysis logic Data cleaning: Remove outlier data (such as sudden changes in indicators caused by network interruption) and supplement missing data (by interpolation based on historical trends).

[0042] Dimensional analysis: The data is split into 6 test dimensions, and the performance of indicators under each dimension is analyzed (such as the upgrade success rate in different network scenarios).

[0043] Defect identification: Compare the actual results with the expected results. When the indicator does not reach the threshold (e.g., upgrade success rate < 95%), it is marked as a defect and classified according to severity (critical defect / general defect).

[0044] Step 6: Identify abnormal data using big data analytics and generate test reports for each dimension; Data analysis logic Data cleaning: Remove outlier data (such as sudden changes in indicators caused by network interruption) and supplement missing data (by interpolation based on historical trends).

[0045] Dimensional analysis: The data is split into 6 test dimensions, and the performance of indicators under each dimension is analyzed (such as the upgrade success rate in different network scenarios).

[0046] Defect identification: Compare the actual results with the expected results. When the indicator does not reach the threshold (e.g., upgrade success rate < 95%), it is marked as a defect and classified according to severity (critical defect / general defect).

[0047] Step 7: Automatically trigger the reproduction process for failed test cases, and locate the root cause of the failure by combining device logs and monitoring data.

[0048] Evaluation system: Metrics Design: Define 5 primary metrics (functional completeness, compatibility, performance efficiency, security, and reliability) and 23 secondary metrics (such as upgrade success rate, cross-version adaptation rate, concurrent processing capability, data encryption strength, and anomaly recovery rate). Scoring Method: A weighted scoring method is used, assigning weights based on the importance of each indicator (security 30%, reliability 25%, functional integrity 20%, performance efficiency 15%, compatibility 10%), and calculating a comprehensive score (0-100 points). A score of 85 or above is excellent, 70-84 is acceptable, and below 70 is unacceptable. - Report Output: The test report includes the comprehensive score, details of each indicator dimension, a defect list (including severity and root cause analysis), optimization suggestions, etc., providing data support for product iteration.

[0049] Taking the firmware upgrade push function test of a certain electric vehicle BMS cloud platform V3.2 as an example, the implementation process of the present invention is described in detail: Test objective: To verify the functionality, compatibility, security, and reliability of this firmware upgrade push function in different scenarios, and to ensure that it meets mass production delivery standards; Test environment configuration: Network simulator: 23 network scenarios are configured, focusing on simulating typical electric vehicle scenarios such as weak network on highways, signal interference in densely populated urban areas, and no signal in underground parking garages; Hardware equipment: 15 mainstream BMS controllers are deployed (including all hardware models adapted to this vehicle model), covering different production batches and hardware versions; Battery simulator: SOC is set from 0% to 100% (in 5% increments) and temperature is set from -20℃ to 60℃ (in 5℃ increments) to simulate battery parameters under different conditions such as vehicle driving, stationary, and charging; Concurrency scale: Concurrency tests are planned at three levels: 100 units, 1000 units, and 10000 units, covering daily after-sales upgrades and large-scale batch upgrade scenarios.

[0050] Execution process: - Generate 2000 test cases according to the design method of this invention, and sort them by priority (security class → functional class → performance class → compatibility class → exception class); start automated testing, with a total test duration of 18 hours (75% shorter than the traditional method of 72 hours), an automation execution rate of 92%, and only 8% of the hardware failure simulation scenarios require manual assistance; monitor 38 key indicators in real time, and record the execution results of each test case and device logs.

[0051] Test Results: Defect Detection: 12 critical defects were found (such as the inability to recover after an upgrade interruption under extreme temperatures, and upgrade timeouts for some terminals when there were 10,000 concurrent users), and 35 general defects were found (such as abnormal upgrade progress display for some older hardware models); Performance Improvement: After optimization based on the defect reports by the R&D team, and subsequent testing and verification, the upgrade success rate increased from 91.3% to 99.7%, and the recovery rate for abnormal scenarios reached 100%; Security Verification: All security test cases passed, and no security risks such as firmware tampering, data leakage, or battery overcharging / over-discharging were found; Compatibility: All 15 BMS controllers were adapted normally, achieving 100% compatibility and meeting the upgrade requirements of all configuration versions of this vehicle model.

[0052] In summary, this application has the following effects: Significantly improved test coverage: Through 6 core dimensions and 2,000 test cases, scenario coverage is increased by 300% compared to traditional methods, defect detection rate is increased by 68.3%, effectively solving the problem of "missed tests" in traditional testing.

[0053] Testing efficiency has been greatly improved: the testing time for 10,000 terminals has been reduced from 72 hours to 18 hours, an efficiency increase of 75%, and the rate of manual intervention has been reduced from 35% to 8%, significantly reducing testing costs and time.

[0054] Enhanced risk control capabilities: Through comprehensive testing of 42 abnormal scenarios, the incidence of unknown failures has been reduced from 6.2% to 1.1%, eliminating lithium battery safety risks caused by upgrade issues and ensuring the safety of terminal devices and users.

[0055] Establish a scientific and quantitative evaluation system: The design of 5 primary indicators and 23 secondary indicators increases the reliability of test results from 68% to 95%, providing accurate data support for product quality decisions.

[0056] Significant economic benefits: After adopting this method, the maintenance cost of a single firmware upgrade push was reduced by 625,000 yuan (reducing manual troubleshooting, after-sales repair and fault compensation costs), the user complaint rate decreased by 83%, and the brand reputation was improved.

[0057] 6. High versatility and scalability: Applicable to different types and manufacturers of lithium battery BMS cloud platforms, with compatibility of over 98%. Test dimensions and test cases can be flexibly adjusted according to application scenarios to meet personalized testing needs.

[0058] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A testing and execution method for firmware upgrade push function of lithium battery BMS cloud platform, characterized in that, Includes the following steps: S1. Divide the test cases into 6 dimensions, and based on the orthogonal experimental design method, select key parameter combinations from each dimension to generate a basic test case set; S2. Boundary test cases are supplemented through boundary value analysis, ultimately forming a complete test set; S3. Build the test environment, check the test environment, and initialize the test data; S4. Test case scheduling: A load balancing algorithm is used to allocate test tasks. S5. Control the test process through scripts, automatically trigger upgrade commands, simulate abnormal scenarios, and record execution results; S6. Identify abnormal data through big data analytics and generate test reports for various dimensions; S7. Automatically trigger the reproduction process for failed test cases, and locate the root cause of the failure by combining device logs and monitoring data.

2. The method for testing and executing firmware upgrade push function of lithium battery BMS cloud platform according to claim 1, characterized in that, The six dimensions specifically include: network environment dimension, hardware configuration dimension, battery status dimension, firmware characteristics dimension, concurrency scale dimension, and abnormal scenario dimension.

3. The method for testing and executing firmware upgrade push function of lithium battery BMS cloud platform according to claim 1, characterized in that, The construction of the test environment includes building a comprehensive test platform, deploying hybrid test nodes, and configuring a monitoring and analysis system.

4. The method for testing and executing firmware upgrade push function of lithium battery BMS cloud platform according to claim 3, characterized in that, The comprehensive testing platform includes an integrated hardware simulator, a network simulator, and a battery status simulator, which can accurately simulate the operating characteristics of different hardware models, complex network environments, and various battery status parameters. The deployment of hybrid test nodes includes 100 physical test terminals and 10,000 virtual test nodes to meet testing needs at different concurrency levels. Configure a monitoring and analysis system: Deploy real-time monitoring tools to collect key indicators such as upgrade success rate, upgrade time, network bandwidth usage, battery status changes, and device operation logs, and support real-time data visualization and historical backtracking.

5. The method for testing and executing firmware upgrade push function of lithium battery BMS cloud platform according to claim 1, characterized in that, The load balancing algorithm allocates test tasks by matching test cases according to the node load capacity and test case resource requirements. It prioritizes allocating test cases with high resource requirements to physical terminals or high-configuration virtual nodes, and evenly distributes test cases with low resource requirements to the remaining nodes.

6. The method for testing and executing firmware upgrade push function of lithium battery BMS cloud platform according to claim 1 or 5, characterized in that, The specific load balancing algorithm is as follows: Employing a weighted round-robin / resource-aware hybrid algorithm: Node weight calculation : ； In the formula: Let be the weight of the i-th node. Let be the number of CPU cores in the i-th node. The maximum number of CPU cores across all nodes. This represents the maximum memory capacity across all nodes. This represents the maximum memory capacity across all nodes. This represents the maximum network bandwidth for the i-th node. The maximum network bandwidth among all nodes. This is the CPU weighting coefficient. For memory weighting coefficients, These are the network weight coefficients; Calculate the real-time load factor of the node based on real-time resource utilization. .

7. The method for testing and executing firmware upgrade push function of lithium battery BMS cloud platform according to claim 6, characterized in that, The node's real-time load factor The calculation formula is as follows: ； In the formula: Let be the real-time load coefficient of the i-th node. Let be the real-time CPU utilization of the i-th node. Let be the real-time memory utilization of the i-th node. Let be the real-time network bandwidth utilization of the i-th node.

8. The method for testing and executing firmware upgrade push function of lithium battery BMS cloud platform according to claim 5, characterized in that, The allocation of test tasks: the priority of task allocation is determined by both weight and real-time load; ； in: Assign a priority to the task of the i-th node. This represents the node idle coefficient.

Images