Automatic regression test method and system for battery test software step file

Abstract

The invention provides an automatic regression test method and system for process step files of battery test software. The method comprises the following steps: establishing a golden sample library containing a process step file set passing historical verification and corresponding standard output time sequence data; starting to-be-tested software and loading a virtual battery simulation engine, wherein the virtual battery simulation engine is configured to simulate battery response characteristics and respond to a hardware control instruction of the to-be-tested software; obtaining a to-be-tested step file associated with the to-be-tested software, loading the to-be-tested step file in batches, driving the virtual battery simulation engine to execute a test, and collecting actual measurement output time sequence data; and comparing the actual measurement output time sequence data corresponding to the part, contained in the gold sample library, in the to-be-tested work step file with standard output time sequence data to judge a regression test result and output a report. According to the method, the automatic regression test of the battery test software working step file which runs at an ultra-real-time speed and automatically performs high-precision data comparison is realized.

Description

An automated regression testing method and system for battery testing software process files. Technical Field

[0001] This invention belongs to the field of software testing technology, specifically relating to an automated regression testing method and system for battery testing software process files. Background Technology

[0002] With the rapid development of the new energy industry, the functions of battery testing equipment are becoming increasingly complex, and the frequency of updates and iterations of its supporting host computer software (battery testing software) is also increasing. In order to ensure the stability and compatibility of the software after the upgrade, regression testing must be carried out before releasing a new version of the software. This involves verifying whether the new version of the software can correctly parse and execute a large number of historical process files (such as test scripts in .csv, .xml, or .sda format) and ensuring that the output control logic is consistent with the historical versions.

[0003] Currently, the industry mainly adopts the method of "manual loading + physical / simple tooling testing" for regression testing of process files for battery testing software. That is, the tester manually loads the historical process files one by one into the software under test, connects a real battery or resistive load to run it, and observes the voltage, current and temperature curves during the operation.

[0004] However, the aforementioned existing technologies have the following significant drawbacks: First, the testing efficiency is extremely low. On the one hand, manually loading and configuring thousands of process step files is extremely time-consuming; on the other hand, when testing with real batteries or ordinary loads, the testing process is limited by the passage of physical time (i.e., 1:1 real-time operation), making it impossible to speed up. For example, a charge-discharge process step that lasts for 10 hours must also take 10 hours to actually test. This results in a single full regression test often taking 48-72 hours, severely slowing down the software release schedule.

[0005] Second, result judgment relies on subjective experience, which carries the risk of missed tests and misjudgments. Current result verification mainly depends on testers visually comparing waveform curves between old and new versions. Faced with massive amounts of time-series data, manual comparison is unlikely to detect minute logical degradations or numerical drifts, and is prone to misjudgments due to fatigue. In addition, test results usually cannot automatically generate standardized comparison reports, making it difficult to meet the data traceability requirements of quality management systems such as IATF 16949.

[0006] Third, limited test coverage poses safety risks. When using real batteries for regression testing, it is often difficult to execute test cases that trigger extreme conditions such as over-temperature protection and over-voltage emergency stop for safety reasons. This makes it difficult to discover logical defects in the software when handling abnormal conditions during the regression phase, resulting in hidden bug risks. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of the aforementioned background technology and provide an automated regression testing method and system for battery testing software process files, enabling automated regression testing of battery testing software process files that runs at ultra-real-time speed and automatically performs high-precision data comparison.

[0008] The technical solution adopted in this invention is: an automated regression testing method for battery testing software step files, comprising the following steps: establishing a gold sample library containing a set of historically verified step files and corresponding standard output timing data, wherein the standard output timing data includes at least voltage, current, temperature, step status code, and cumulative charge / discharge data; starting the software under test and loading a virtual battery simulation engine, wherein the virtual battery simulation engine is configured to simulate battery response characteristics and respond to hardware control commands of the software under test; acquiring the step files to be tested associated with the software under test and loading them in batches, driving the virtual battery simulation engine to execute tests, and collecting measured output timing data; comparing the measured output timing data corresponding to the portion of the step files to be tested contained in the gold sample library with the standard output timing data to determine the regression test results and output a report.

[0009] In the above technical solution, the comparison step adopts a hierarchical dual verification strategy: first, the root mean square error or Euclidean distance between the measured output time series data and the standard output time series data is calculated. If it is less than the first preset threshold, it is determined to pass; if it fails, the optimal matching path distance between the two is calculated using the dynamic time warping algorithm. If it is less than the second preset threshold, it is determined to pass; otherwise, it is determined to be a regression failure.

[0010] In the above technical solution, the virtual battery simulation engine adopts an adaptive variable step size integration strategy: when a steady-state control command is received and the battery state has not reached the cutoff condition, a first simulation time step is adopted, wherein the steady-state control command includes at least constant current, constant voltage, constant power, constant resistance, and static command; when the battery state is detected to have reached the cutoff threshold or safety protection threshold, it automatically switches to a second simulation time step that is smaller than the first simulation time step; the strategy enables the virtual test time compression ratio to reach a preset super real-time ratio.

[0011] In the above technical solution, the method further includes an automatic learning step for new steps: when the acquired test step file contains a new step file that does not exist in the gold sample library, a preset standard reference battery model is automatically called; the virtual battery simulation engine is driven to execute the new step file, and the generated output timing data is marked as standard output timing data and stored in the gold sample library to update the sample library.

[0012] In the above technical solution, the virtual battery simulation engine includes an electrothermal coupling model: it is configured to calculate the internal temperature change of the virtual battery in real time based on the current command and internal resistance parameters; the method also includes verifying whether the software under test triggers the protection logic defined in the process file when it receives temperature data exceeding the preset safety value.

[0013] In the above technical solution, the method further includes an anomaly localization step: when regression is determined to fail, based on the backtracking path matrix of the dynamic time warping algorithm, the timestamp at which the measured output time series data and the standard output time series data begin to deviate in shape is identified; the timestamp is mapped to the specific instruction line number of the step file, and the line number and the corresponding control parameters are marked in the report.

[0014] This invention provides an automated regression testing system for battery testing software step files, used to implement the methods described in the above technical solution, comprising: a sample management module for storing and maintaining the gold sample library; a virtualization driving module for simulating the communication protocol of battery testing equipment, receiving step instructions and feeding back simulation data to the software under test; a simulation calculation core for building the virtual battery simulation engine to calculate the battery response at ultra-real-time speed according to the step instructions; an intelligent comparison module configured to perform comparison and judgment between the measured output timing data and the standard output timing data; and a main control scheduling module for obtaining the list of step files to be tested, allocating concurrent simulation tasks, and outputting a report based on the judgment results.

[0015] In the above technical solution, the simulation calculation core is configured with a fault injection interface: used to forcibly send preset abnormal state data to the software under test based on a preset time point, battery state threshold, or pseudo-random triggering logic based on a preset seed during the test; the abnormal state data includes at least voltage jump, temperature over-limit, communication packet loss, or auxiliary channel fault signal.

[0016] In the above technical solution, the intelligent comparison module also includes a data resampling unit: used to perform interpolation processing on the non-uniform time series data generated by variable step size simulation before performing the comparison, so as to unify the data dimension.

[0017] The present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in the above technical solution.

[0018] The beneficial effects of this invention are as follows: The automated regression testing method and system for battery testing software provided by this invention, by constructing a golden sample library containing historical verification data and using a virtual battery simulation engine to replace traditional physical batteries for testing, achieves complete automation and digitization of the testing process. Compared with the existing technology that relies on manual loading of steps and visual comparison of curves, this invention shortens the execution time of regression testing from tens of hours to minutes, greatly improving the iteration efficiency of software releases. Simultaneously, due to the adoption of virtual simulation technology, the testing process is no longer limited by the charge / discharge rate (C-rate) and safety risks of the physical battery, eliminating the potential for battery fires or equipment damage due to operational errors, and achieving full step coverage under zero-risk conditions. Furthermore, a rigorous logical closed loop is achieved by introducing a multi-dimensional data comparison mechanism. The system not only compares conventional voltage, current, and temperature curves but also forcibly verifies the step status code and cumulative charge / discharge amount (Ah / Wh). This improvement effectively avoids hidden bugs such as curves appearing to overlap but internal state transition errors or drift in integral algorithm accuracy, ensuring the software's dual correctness in both underlying control logic and numerical calculation accuracy.

[0019] Furthermore, addressing the common challenges of false alarms and missed alarms in time-series data comparison, this invention innovatively employs a hierarchical dual verification strategy. First, a rigid verification is performed using the root mean square error (RMSE) or Euclidean distance, which has low computational cost and high sensitivity, quickly filtering out the vast majority of normal or seriously erroneous steps. For minor deviations, a second-level flexible verification is performed using the Dynamic Time Warping (DTW) algorithm. This mechanism effectively overcomes spurious discrepancies caused by slight asynchrony between the simulation clock and the standard clock, ensuring rigorous capture of logic degradation while avoiding misjudgments due to minor timing phase shifts, achieving a balance between strictness and fault tolerance.

[0020] Furthermore, to achieve ultra-real-time testing speed while ensuring simulation accuracy, the virtual battery simulation engine of this invention adopts an adaptive variable step-size integration strategy. The system can intelligently identify steady-state control commands such as constant current, constant voltage, constant power, constant resistance, and static conditions, and use large step sizes for ultra-fast simulation; while for transient changes such as pulses and ramps, it automatically switches to high-precision small step sizes. Combined with the data resampling unit in the intelligent comparison module, the problem of inconsistent data dimensions caused by variable step sizes is solved. This design enables the virtual testing time compression ratio to reach more than 100 times (i.e., 100:1) of physical real-time testing without sacrificing the verification accuracy of key control logic at the charging and discharging ends.

[0021] Furthermore, this invention addresses the pain point of high maintenance costs in traditional automated testing. Through a new automatic learning mechanism for work steps, when a new work step file not covered by the gold standard sample library appears in the system, the system can automatically call the standard reference model for pre-running and automatically mark and incorporate the generated data into the library. This mechanism enables the testing system to have self-updating and evolution capabilities, eliminating the need for testers to manually enter standard data for new test cases, significantly reducing long-term maintenance labor costs, and ensuring that the sample library always remains synchronized with software version iterations.

[0022] Furthermore, this invention not only focuses on conventional charging and discharging functions, but also deeply verifies the software's protection logic and anomaly handling capabilities by introducing an electrothermal coupling model and fault injection functionality. During testing, the system can forcibly inject voltage jumps, communication packet loss, or auxiliary channel faults based on preset time points, battery state thresholds, or even random logic. This allows the code in the software under test concerning over-temperature protection, emergency stop logic, and fault tolerance mechanisms to be fully verified, filling the blind spots of extreme operating conditions that cannot be covered in traditional physical testing due to safety concerns, and eliminating hidden bug risks.

[0023] Furthermore, to address the difficulty developers face in troubleshooting test failures, this invention utilizes the backtracking path matrix of the DTW algorithm to accurately identify the timestamp when the measured curve begins to deviate from the standard curve, directly mapping it to the specific instruction line number in the process step file. In the regression test report, the system highlights the specific code line and its parameters that caused the anomaly, allowing developers to directly pinpoint the root cause without analyzing massive amounts of data from scratch. This reduces communication and repair costs between development and testing by more than 50%. Attached Figure Description

[0024] Figure 1 is a schematic diagram of the method flow of the present invention. Detailed Implementation

[0025] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments to facilitate a clear understanding of the present invention, but these descriptions do not constitute a limitation on the present invention.

[0026] Example 1, as shown in Figure 1, provides an automated regression testing method for battery testing software step files, comprising the following steps: Construction of a gold sample library: Obtaining a set of step files that have passed verification in historical versions of the battery testing software, and standard output timing data generated by each step file under preset test conditions, establishing a gold sample library containing step file indexes and their corresponding standard output timing data; Initialization of a virtual execution environment: Starting the battery testing software version under test and loading a virtual battery simulation engine, wherein the virtual battery simulation engine is configured with a mathematical model for simulating the response characteristics of a real battery and is configured to accept and respond to hardware control commands sent by the software under test; Automated concurrent execution: Scanning... The storage path of the process step files associated with the software under test is used to obtain a list of process step files to be tested. Files from the list are then imported in batches into the software under test for parsing and loading, driving the virtual battery simulation engine to execute the test process and collecting the measured output timing data generated by the software under test during execution in real time. For difference verification and result output: for process step files in the list that exist in the gold sample library, the measured output timing data is compared with the corresponding standard output timing data in the gold sample library. Based on the comparison results, it is determined whether the parsing and control logic of the software under test for the process step files has degraded, and a regression test report is generated and output.

[0027] This embodiment of the method elaborates on the automated regression testing process described in the claims, covering the entire process from sample library establishment to final report generation (steps S1 to S5), specifically including: S1: Establishing a Golden Sample Library for Work Step Files The primary task of regression testing is to build a reliable benchmark database, namely the golden sample library. This library serves as the benchmark for the entire test and includes all verified work step files from historical versions and their corresponding standard output data as golden samples. This step first selects a set of work step files that have been physically verified or have been running without bugs for a long time from historical software versions. For each work step file added to the library, the system records in detail the standard output data generated when running under a stable version, covering multi-dimensional time-series information such as timestamps, voltage, current, temperature, work step status codes (used to verify the software's judgment of work step jump logic), and cumulative charge and discharge data (used to verify the accuracy of the capacity integration algorithm), and the sampling rate must be guaranteed to be above 10Hz to capture transient characteristics.

[0028] To address the issue of sample library lag, this step also incorporates an adaptive learning mechanism: when a new work step file that has not yet been added to the test list is detected, the system will not simply report an error, but will automatically call the standard virtual battery model and safely perform a complete charge-discharge simulation at a preset low rate of 0.05C. The generated data without anomalies will be marked as new gold samples and automatically stored in the library, thereby enabling the sample library to automatically expand and evolve with business development.

[0029] S2: Full Traversal and Intelligent Loading. During the test startup phase, the main control module automatically scans the storage directory of all process files under the software version under test to obtain a complete list of files. To improve processing efficiency, the system calculates the MD5 or SHA256 digital fingerprint for each file and compares it with records in the gold sample library. This process can quickly classify massive amounts of files into "existing files" (with existing baselines) and "incremental files" (requiring the triggering of S1 self-learning). Subsequently, the system dynamically allocates thread pools based on hardware resources (number of CPU cores and memory size), loading process files in batches into the memory waiting queue to ensure that subsequent simulation tasks can run at maximum concurrency, achieving 100% test coverage without blind spots.

[0030] During this loading phase, preprocessing logic is executed synchronously: an "instruction-time index mapping table" is built for each work step file. This table records the physical line number, instruction semantics, and expected simulation start time of each test instruction, laying the data foundation for accurate anomaly localization in the subsequent S5 steps.

[0031] S3: Virtual Battery Automated Execution and Fault Injection. This step is the core execution stage of the test. The system starts no fewer than 1024 concurrent threads, each thread independently instantiating a virtual battery object to respond to the step instructions. This embodiment supports parsing of all types of instructions. The hardware control instructions include at least one of the following: constant current (CC), constant voltage (CV), constant power (CP), constant resistance (CR), pulse (Pulse), ramp current (Ramp), and rest (Rest) instructions.

[0032] Based on the second-order RC equivalent circuit and electrothermal coupling model, the virtual engine can not only simulate the voltage rebound and temperature change of the battery in the constant current, constant voltage and resting stages at a speed 100 times faster than physical time (i.e. compression ratio ≥100:1), but also perform high-order fault injection tests during the simulation process.

[0033] Specifically, the system is equipped with a fault injection interface, which can artificially introduce abnormal state data at specific moments during simulation. For example, it can force the virtual battery temperature to 60°C to simulate overheating, or generate communication packet loss and voltage jump signals. This mechanism aims to verify whether the software under test can immediately cut off the current or trigger an alarm according to the expected safety strategy (such as OTP over-temperature protection), thus simultaneously verifying the functional safety logic during regression testing. The voltage, current, and triggered protection status of all channels are collected in real time during the simulation process, forming measured output timing data.

[0034] The fault injection interface supports flexible triggering logic, including: (1) triggering based on a preset time point: for example, setting a voltage jump to occur when the simulation runs to the 1000th second; (2) triggering based on a battery state threshold: for example, automatically sending a simulated over-temperature signal when the virtual battery SOC is detected to be > 95%; (3) pseudo-random triggering based on a preset seed: used to simulate occasional communication packet loss or interference.

[0035] To meet the reproducibility requirements of regression testing, the system employs a pseudo-random number generator (PRNG) and loads a fixed random number seed at the start of each test. This ensures that the timing and type sequence of "random" faults are completely consistent across different test runs, thereby guaranteeing the comparability of the measured data with the gold standard database. This mechanism aims to comprehensively verify the functional safety logic of the software under test (such as OTP protection and disconnection protection) while ensuring the determinism of the testing process.

[0036] S4: After data resampling and hierarchical dual comparison simulation, the system adopts a coarse-to-fine hierarchical dual verification strategy to determine the test results, thus solving the problem of high misjudgment rate in traditional comparison methods. Because the simulation in S3 used an adaptive variable step-size integration strategy (i.e., a small step size in the voltage fluctuation region and a larger step size in the stable region), the output is non-uniform time series data, and direct comparison would lead to dimensionality mismatch. Therefore, this step first uses linear interpolation or spline interpolation algorithms to map the measured non-uniform data and the golden sample data onto the same time axis, achieving data dimensionality standardization.

[0037] This embodiment performs rigorous multi-dimensional data comparison: in addition to conventional voltage, current, and temperature, it also includes the step status code and cumulative charge / discharge amount (Ah / Wh) in the comparison range to enhance the rigor of the judgment.

[0038] This embodiment performs hierarchical dual verification: the first level of verification adopts rigid mathematical comparison. First, the measured data and the gold sample are aligned on the time axis, and the root mean square error (RMSE) or Euclidean distance between the two is calculated. If the error is less than the first preset threshold (preferred range 0.0001 to 0.001, corresponding to a deviation of about 0.5mV), the test case is directly determined to pass. This can quickly filter out the vast majority of completely normal test cases and save computing power.

[0039] If the first-level verification fails, the system will not hastily declare failure, but will automatically trigger the second-level flexible verification—Dynamic Time Warping (DTW). The DTW algorithm, by constructing a cumulative distance matrix and searching for the optimal matching path, can effectively identify and tolerate minor time drifts or phase stretching caused by software version updates. To prevent excessive path distortion and improve computational speed, the algorithm introduces a Sakoe-Chiba global constraint window with a width of approximately 5% of the sequence length. As long as the normalized similarity distance calculated by DTW is less than a second preset threshold (preferred range 0.001–0.01), the system will still determine it as passed, thus accurately distinguishing between benign version differences and malicious logical errors.

[0040] S5: The final step in the report generation and anomaly tracing process is the summarization and visualization of results. Based on the judgment results of S4, the system automatically generates a test report that meets the requirements of the IATF 16949 quality system, which includes a test overview, pass rate statistics, and a detailed list of failed test cases.

[0041] For anomalous use cases deemed as regression failures, this step goes beyond simply reporting errors; it also possesses powerful anomaly localization capabilities. Using the backtracking path matrix generated by the DTW algorithm in S4, the exact timestamp at which the measured curve and the gold sample begin to deviate in shape can be calculated, and this timestamp can be mapped back to the specific instruction line number in the process step file.

[0042] For abnormal use cases judged as "regression failure", this step uses the instruction-time index mapping table built in the S2 stage to achieve line-level anomaly location. The specific process is as follows: (1) During the running phase, the simulation engine records the absolute simulation timestamp (Tick) triggered by each instruction in real time; (2) During the backtracking phase, when the DTW determines a deviation, the backtracking path matrix is ​​used to accurately identify the time point when the measured data and the standard data begin to deviate in shape. (3) Reverse lookup location, based on The system performs a reverse search in the index table to pinpoint the specific instruction line number that caused the anomaly. This mechanism enables automated cross-dimensional location of the problem, from "waveform deviation" to "code line number." The final report not only displays a screenshot of the failure but also directly marks "the bug originates from line N of file X (e.g., the constant voltage stage)." Technically, this can reduce the cost of manual troubleshooting by more than 50%.

[0043] The virtual battery simulation engine in this embodiment is built based on the industry-standard equivalent circuit model (ECM) technology, aiming to provide a stable, fast, and repeatable standard test object for regression testing. This part of the design fully leverages the advantages of existing technologies and has been specifically optimized for the "ultra-real-time regression testing" requirements of this invention.

[0044] To maximize computational speed while ensuring simulation accuracy, this invention employs a second-order RC equivalent circuit model. This model utilizes a combination of electronic components such as resistors and capacitors to simulate the physical characteristics of an actual battery: the ohmic internal resistance simulates the instantaneous voltage drop of the battery; while two sets of parallel RC networks simulate the electrochemical polarization and concentration polarization effects (i.e., the transient voltage rebound phenomenon) during the charging and discharging process. This model structure is a common standard in the field of battery simulation, accurately reproducing the voltage response characteristics of key steps such as constant current charging, constant voltage cutoff, and static rebound, fully meeting the logic accuracy requirements of verification and testing software.

[0045] Given that battery performance is significantly affected by temperature, and that testing software typically includes extensive logic verification related to "over-temperature protection" or "temperature rise rate protection," the virtual engine of this invention incorporates an electrothermal coupling model. During simulation, the engine calculates the Joule heat generated by current flowing through the internal resistance in real time and dynamically updates the internal temperature of the virtual battery by combining the ambient temperature and heat dissipation coefficient. The calculated real-time temperature, in turn, corrects the battery's internal resistance and open-circuit voltage parameters (e.g., simulating the characteristics of increased internal resistance at low temperatures and increased capacity activity at high temperatures). This mechanism allows the testing software to trigger corresponding safety protection logic (such as OTP) as it would with a real battery when receiving temperature data from the virtual battery, thereby verifying whether the software's safety control functions are normal under extreme operating conditions.

[0046] To achieve "ultra-real-time scaling" (i.e., simulation speed much faster than physical time, e.g., 100:1), this embodiment employs an adaptive variable-step-size integration algorithm. The core of this strategy lies in dynamically adjusting the sampling step size by real-time monitoring of the voltage change rate (dV / dt): Acceleration during the stationary period: when a voltage change rate (dV / dt) is detected... When the current is less than the preset threshold (such as during the middle of constant current charging or after a long period of rest), the system determines that the battery state is stable and automatically expands the calculation step size to the second level or even the minute level, thereby skipping a large number of redundant calculations at once.

[0047] Encryption during periods of rapid change: Once detected If the threshold is exceeded (such as during a pulse instant, a step switching, or when the voltage is close to the cutoff value), the algorithm immediately reduces the step size to the millisecond level.

[0048] This strategy ensures that the accuracy of critical control inflection points is not lost during sudden voltage changes, while maximizing the saving of computing power during the stable phase, thereby enabling regression verification of thousands of hours of physical testing within tens of minutes.

[0049] This strategy ensures extremely high simulation resolution at the moment of voltage change (i.e. the moment when software bugs are most likely to occur), while maximizing computational savings during the stable phase, thereby enabling regression verification of thousands of hours of physical testing within tens of minutes.

[0050] In a typical enterprise-level software iteration scenario, the battery testing system was upgraded from the old version B5.1.1.0 to the new version B5.1.2.2. The testing team faced the challenge of verifying 5604 historical process step files, while also covering 12 newly submitted process step files containing complex pulse sequences from the R&D department. After the test started, the system first quickly completed a fingerprint scan of all process step files, automatically identified the 12 new files, and triggered a self-learning mechanism. It then used a virtual battery to generate new benchmark data at a 0.05C rate, expanding the sample library to 5616 files.

[0051] Subsequently, the system mobilized hardware resources to launch 1024 concurrent threads for ultra-real-time simulation. The entire execution process took only 27 minutes, an efficiency improvement of approximately 160 times compared to the 72 hours required for traditional manual testing. During the data comparison phase, the intelligent comparison module performed initial screening using RMSE and subsequent DTW verification, ultimately outputting a 99.93% pass rate report and accurately intercepting four failed test cases. Three of these test cases were marked as critical errors due to RMSE errors exceeding 0.001 and DTW failure, while one test case, although passing RMSE, failed during the DTW phase. The system report not only listed the failures but also used a backtracking algorithm to directly locate lines 128 and 5003 of the process step file and extracted waveform difference diagrams. Developers confirmed that this was due to a timing deviation caused by a change in the parsing logic of the "dormant process step" in the new version. Based on the location information, the developers completed the code fix that same day, and triggered regression testing again that evening. The system output a fully green report 24 minutes later, ensuring the successful release of the software the following day.

[0052] Example 2 This example provides an automated regression testing system for battery testing software step files, designed to meet the high-concurrency testing requirements of industrial applications. The system is based on a modular microservice architecture, with each module working collaboratively to achieve the automated process described in the claims. It includes: a sample management module for storing and maintaining the gold standard sample library; managing all historically validated step file sets and their corresponding standard output time-series data (voltage, current, and temperature curves). A built-in version control mechanism enables rapid retrieval of benchmark data based on the digital fingerprint (Hash) of the step files, and supports the classification, labeling, and metadata management of newly added samples.

[0053] The virtualization driver module simulates the communication protocol of battery testing equipment, receives step instructions, and feeds back simulation data to the software under test (DUT). This module acts as a bridge between the DUT and the virtual environment. It receives hardware control commands from the DUT (such as "Open Channel 1" and "Set Constant Current 5A") and translates them into signals recognizable by the simulation kernel. Simultaneously, it packages the voltage, current, and other data calculated by the simulation kernel into messages conforming to the device protocol and feeds them back to the DUT. This makes the DUT believe it is connected to a real physical test cabinet, thus enabling black-box testing without modifying the DUT code.

[0054] The core of the simulation calculation includes a built-in virtual battery simulation engine for calculating battery response at ultra-real-time speed based on step instructions. It employs a second-order RC equivalent circuit model coupled with an electrothermal model to simulate the battery's polarization rebound and temperature rise characteristics. This core is specifically configured with a fault injection interface to send preset abnormal state data to the software under test during testing. This interface supports deterministic and pseudo-random triggering modes. In pseudo-random triggering mode, by locking the random number seed, it ensures that the abnormal signal sequences such as voltage jumps and communication packet losses generated in each regression test remain consistent, thereby supporting automated comparison. These abnormal data include at least: voltage jumps: simulating instantaneous voltage drops / pulses caused by poor contact or short circuits within the cell; temperature over-limit: forcibly outputting temperature data exceeding a safety threshold (e.g., 60°C) to verify the OTP protection logic; communication packet loss: simulating unstable states of the RS485 / CAN bus; and auxiliary channel faults: simulating disconnection signals in the auxiliary voltage / temperature acquisition channel.

[0055] The intelligent comparison module is configured to compare and determine the measured output time-series data with the standard output time-series data. Internally, it includes a data resampling unit specifically for processing variable-step-size simulation data. Because the simulation core employs an adaptive step-size strategy (smaller step size during drastic changes, larger step size during stable periods), the output data is non-uniformly distributed along the time axis. This unit uses linear or spline interpolation algorithms to uniformly map the measured data to a sampling frequency consistent with the gold sample, thus unifying the data dimension and clearing obstacles for subsequent comparisons. It integrates a dual verification algorithm combining root mean square error (RMSE) and dynamic time warping (DTW).

[0056] The main control scheduling module is used to obtain a list of test step files, allocate concurrent simulation tasks, and output reports based on the judgment results; it dynamically manages the thread pool, supporting parallel simulation with more than 1024 channels. It identifies newly added test step files, schedules the simulation core to generate new benchmark data, and notifies the sample management module to add it to the database.

[0057] Example 3: The present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in Example 1.

[0058] Embodiments of this application may be provided as methods, systems, or computer program products.

[0059] The specific embodiments of the present invention are described in conjunction with flowcharts and / or block diagrams of computer program products, including descriptions of software runtime carriers or hardware configurations. This application may take the form of hardware embodiments, completely software embodiments, or embodiments combining software and hardware aspects.

[0060] This application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0061] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0062] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0063] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0064] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

[0065] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

Claims

1. An automated regression testing method for battery testing software process files, characterized in that, Includes the following steps: Establish a gold sample library containing a set of historically verified process step files and corresponding standard output timing data. The standard output timing data includes at least voltage, current, temperature, process step status code, and cumulative charge / discharge data. Start the software under test and load the virtual battery simulation engine. The virtual battery simulation engine is configured to simulate battery response characteristics and respond to the hardware control commands of the software under test. Obtain the process step files associated with the software under test and load them in batches. Drive the virtual battery simulation engine to execute the test and collect the measured output timing data. The measured output time series data corresponding to the portion of the gold sample library contained in the test step file are compared with the standard output time series data to determine the regression test results and output a report.

2. The method according to claim 1, characterized in that, The comparison step adopts a hierarchical dual verification strategy: first, the root mean square error or Euclidean distance between the measured output time series data and the standard output time series data is calculated, and if it is less than the first preset threshold, it is determined to pass. If the regression fails, the optimal matching path distance between the two is calculated using the dynamic time warping algorithm. If the distance is less than the second preset threshold, the regression is considered successful; otherwise, it is considered a regression failure.

3. The method according to claim 1, characterized in that, The virtual battery simulation engine adopts an adaptive variable step size integration strategy: when a steady-state control command is received and the battery state has not reached the cutoff condition, a first simulation time step is adopted. The steady-state control command includes at least constant current, constant voltage, constant power, constant resistance, and static command. When the battery state is detected to have reached a set threshold, it automatically switches to a second simulation time step that is smaller than the first simulation time step. Through this strategy, the time compression ratio of the virtual test reaches a preset super real-time ratio.

4. The method according to claim 1, characterized in that, The method further includes an automatic learning step for new steps: when the acquired test step file contains a new step file that does not exist in the gold sample library, a preset standard reference battery model is automatically called; the virtual battery simulation engine is driven to execute the new step file, and the generated output timing data is marked as standard output timing data and stored in the gold sample library to update the sample library.

5. The method according to claim 1, characterized in that, The virtual battery simulation engine includes an electrothermal coupling model, which is configured to calculate the internal temperature change of the virtual battery in real time based on current commands and internal resistance parameters. The method also includes verifying whether the software under test triggers the protection logic defined in the process step file when it receives temperature data exceeding a preset safety value.

6. The method according to claim 2, characterized in that, The method further includes an anomaly localization step: when regression is determined to fail, based on the backtracking path matrix of the dynamic time warping algorithm, the timestamp at which the measured output time series data and the standard output time series data begin to deviate in shape is identified; the timestamp is mapped to the specific instruction line number of the step file, and the line number and the corresponding control parameters are marked in the report.

7. An automated regression testing system for battery testing software process files, used to implement the method according to any one of claims 1 to 6, characterized in that, include: Sample Management Module: Used to store and maintain the gold sample library; Virtualization Driver Module: Used to simulate the communication protocol of battery testing equipment, receive step instructions and feed back simulation data to the software under test; Simulation Calculation Core: Built-in virtual battery simulation engine, used to calculate battery response at ultra-real-time speed according to step instructions; Intelligent Comparison Module: Configured to perform comparison and judgment between the measured output timing data and the standard output timing data; Main control scheduling module: used to obtain the list of test step files, allocate concurrent simulation tasks, and output reports based on the judgment results.

8. The system according to claim 7, characterized in that, The simulation calculation core is configured with a fault injection interface: used to forcibly send preset abnormal state data to the software under test during the test based on a preset time point, battery state threshold, or pseudo-random triggering logic based on a preset seed. The abnormal status data includes at least voltage jumps, temperature exceeding limits, communication packet loss, or auxiliary channel fault signals.

9. The system according to claim 7, characterized in that, The intelligent comparison module also includes a data resampling unit: used to perform interpolation processing on the non-uniform time series data generated by variable step size simulation before performing the comparison, so as to unify the data dimension.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 6.

Images