Test systems, methods, battery management systems and electric vehicles

Abstract

This application provides a testing system, method, battery management system, and electric vehicle. It relates to the field of battery management system technology. The method involves: determining a corresponding target test case library; matching natural language test cases with the natural language descriptions in the test case library using natural language processing technology to obtain the target signal operations corresponding to the natural language test cases; generating target test cases corresponding to the target signal operations, each target test case possessing execution logic; testing the BMS under test according to the target test cases, obtaining test results, and generating a test report containing the test results. By matching natural language test cases with a pre-generated test case library, target signal operations can be quickly obtained. Target test cases are then generated based on these target signal operations and used to test the BMS under test, avoiding the manual customization and writing of complex test logic, reducing manual operations, and thus improving testing efficiency.

Description

Technical Field

[0001] This application relates to the field of battery management system technology, and in particular to a testing system, method, battery management system and electric vehicle. Background Technology

[0002] As the core controller for safe battery operation, the Battery Management System (BMS) must possess accurate state estimation, intelligent thermal management, and fault diagnosis capabilities. Testing the BMS is a crucial step in research and development, verification, and mass production.

[0003] In related technologies, test schemes for BMS are designed based on human experience and through manual operation.

[0004] However, manually testing the BMS is inefficient. Summary of the Invention

[0005] This application provides a testing system, method, battery management system, and electric vehicle to improve testing efficiency.

[0006] In a first aspect, embodiments of this application provide a testing system for testing a battery management system (BMS) to obtain a test report. The test report is used to evaluate the performance of the BMS. The testing system is configured to perform the following steps: in response to a test request from the BMS under test, determining a corresponding target test case library, wherein the test request includes natural language test cases, and the target test case library stores pre-generated signal operations and their corresponding natural language descriptions; matching the natural language test cases with the natural language descriptions in the test case library using natural language processing technology to obtain the target signal operation corresponding to the natural language test case; generating a target test case corresponding to the target signal operation, wherein the target test case has execution logic; testing the BMS under test according to the target test case, obtaining test results, and generating a test report containing the test results.

[0007] Secondly, embodiments of this application provide a testing method, comprising: responding to a test request from a BMS under test, determining a corresponding target test case library, wherein the test request includes natural language test cases, and the target test case library stores pre-generated signal operations and corresponding natural language descriptions of the signal operations; matching the natural language test cases with the natural language descriptions in the test case library using natural language processing technology to obtain target signal operations corresponding to the natural language test cases; generating target test cases corresponding to the target signal operations, wherein the target test cases have execution logic; testing the BMS under test according to the target test cases, obtaining test results, and generating a test report containing the test results.

[0008] Thirdly, embodiments of this application provide a battery management system, wherein the test result of the battery management system is that the test is passed; the test result of the battery management system is determined after testing the battery management system using the test system described in the first aspect.

[0009] Fourthly, embodiments of this application provide a battery pack, including a housing, a battery pack, and the battery management system described in the third aspect. The battery pack and the battery management system are installed inside the housing. The battery management system is connected to the battery pack and is used to collect the operating parameters of the battery pack and maintain the stable operation of the battery pack.

[0010] Fifthly, embodiments of this application provide an electric vehicle that includes at least the battery pack described in the fourth aspect.

[0011] Sixthly, embodiments of this application provide a testing apparatus, comprising: a determining module, configured to determine a corresponding target test case library in response to a test request from a BMS under test, wherein the test request includes natural language test cases, and the target test case library stores pre-generated signal operations and corresponding natural language descriptions of the signal operations; a matching module, configured to match the natural language test cases with the natural language descriptions in the test case library using natural language processing technology to obtain target signal operations corresponding to the natural language test cases; a generating module, configured to generate target test cases corresponding to the target signal operations, wherein the target test cases have execution logic; and a testing module, configured to test the BMS under test according to the target test cases, obtain test results, and generate a test report containing the test results.

[0012] In a seventh aspect, embodiments of this application provide an electronic device, including: a memory and a processor;

[0013] The memory stores computer-executed instructions;

[0014] The processor executes computer execution instructions stored in the memory, causing the processor to perform the implementation method described in the second aspect above.

[0015] Eighthly, embodiments of this application provide a non-volatile computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the embodiments described in the second aspect above.

[0016] Ninthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the implementation methods described in the second aspect above.

[0017] The testing system, method, battery management system, and electric vehicle provided in this application embodiment can quickly obtain target signal operations by matching natural language test cases with a pre-generated test case library. Target test cases are then generated based on these target signal operations and used to test the BMS under test. This avoids the manual process of customizing and writing complex test logic, reducing manual operations and improving testing efficiency. Attached Figure Description

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

[0019] Figure 1 This is a schematic diagram illustrating an application scenario of a testing method provided in an embodiment of this application;

[0020] Figure 2 A flowchart illustrating a testing method provided in an embodiment of this application;

[0021] Figure 3 A flowchart illustrating another testing method provided in an embodiment of this application;

[0022] Figure 4 A schematic diagram of a test report provided in an embodiment of this application;

[0023] Figure 5 A schematic diagram of the automated testing software provided in an embodiment of this application;

[0024] Figure 6 A schematic diagram illustrating the mapping relationship provided in the embodiments of this application;

[0025] Figure 7 A schematic diagram illustrating test preparation and execution as provided in the embodiments of this application;

[0026] Figure 8 This is a schematic diagram of the structure of a testing device provided in an embodiment of this application;

[0027] Figure 9 This is a schematic diagram of another testing device provided in an embodiment of this application;

[0028] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

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

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0031] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0032] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the display interface provided in the embodiments of this application is merely an example, and the display interface may include more or less content.

[0033] It should be noted that the testing system, method, battery management system, and electric vehicle of this application can be used in the field of battery management system technology, or in any field other than battery management system. The application fields of the testing system, method, battery management system, and electric vehicle of this application are not limited.

[0034] Figure 1 This is a schematic diagram illustrating an application scenario of a testing method provided in an embodiment of this application. The scenario illustrated is as follows: A Battery Management System (BMS) is used to manage the normal operation of a battery. Testing the BMS verifies whether it can accurately manage the battery.

[0035] For example, a BMS has the capabilities of state estimation, intelligent thermal management, and fault diagnosis. Among them, state estimation includes the estimation of State of Health (SOC) and State of Charge (SOC).

[0036] For example, the reliability of the BMS directly determines whether the battery can be managed properly, so testing the BMS is of great significance to ensure that the battery works properly.

[0037] In related technologies, R&D personnel rely on experience to write test cases and test the BMS through these test cases.

[0038] Test cases are standardized test units for BMS (Business Management System). Each test case integrates corresponding signal operations, execution logic, interface acquisition methods, local variable configurations, and data comparison and judgment rules. Test cases can be directly invoked and automatically executed by the test system to complete the entire process of signal delivery, data acquisition, and result judgment for the corresponding functional item.

[0039] However, test cases are logically complex and require a lot of related knowledge to write. Therefore, writing test cases manually consumes a lot of time, resulting in low efficiency of the test BMS.

[0040] The testing method provided in this application is intended to solve the above-mentioned technical problems in related technologies.

[0041] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0042] Figure 2 This is a flowchart illustrating a testing method provided in an embodiment of this application. The method includes the following steps:

[0043] S201. In response to the test request of the BMS under test, determine the corresponding target test case library. The test request includes natural language test cases. The target test case library stores pre-generated signal operations and their corresponding natural language descriptions.

[0044] As an example, the execution entity in this embodiment can be a test system, which is used to test the battery management system (BMS) and obtain a test report. The test results are used to evaluate whether the BMS can function properly.

[0045] For example, the target test case library is a pre-generated library. Test cases are generated directly using the target test case library in the test scenario.

[0046] Specifically, the target test case library stores signal operations that may be used in BMS testing (such as issuing individual unit voltage signals and collecting BMS bus feedback data), and each signal operation is accompanied by an easy-to-understand natural language description explaining the signal operation.

[0047] With the aid of scenario examples, signal operations are the standard action units that the test system performs to send or receive signals to the BMS under test, and they are the basic units that make up test cases. They are used to represent the electrical and communication interaction behaviors between the test system and the BMS under test.

[0048] For example, test requests do not require writing complex test instructions; instead, they can simply describe the requirements in natural language (e.g., "test the accuracy of the BMS's SOC estimation" or "test the BMS's overvoltage protection function"), thereby reducing manual operations.

[0049] S202. Using natural language processing technology, match the natural language test cases with the natural language descriptions in the test case library to obtain the target signal operation corresponding to the natural language test cases.

[0050] For example, natural language processing technology is used to compare and match the natural language test cases input by the testers with the natural language descriptions corresponding to each signal operation in the target test case library.

[0051] The matching process is automated. The testing system will automatically identify the target signal operation, which is the same as or similar to the natural language test case.

[0052] Optionally, natural language processing technology uses a semantic coding model to perform semantic vector matching between natural language test cases and natural language descriptions in the test case library to generate target signal operations.

[0053] Specifically, the semantic encoding model is trained based on multiple samples of natural language information and their corresponding semantic vectors, enabling it to accurately identify key semantics in natural language test cases (e.g., "testing the accuracy of SOC estimation in the BMS"). After matching, the target signal operation is integrated into the pre-stored execution logic in the test case library (including execution prerequisites, execution order, and execution termination conditions), forming a target test case with complete execution logic. For example, if the natural language test case is "simulating fast charging by inserting a fast charging gun," the target signal operation is "setting the CAN signal Charging_Cable_Inserted to 1," and its execution logic includes "collecting BMS feedback data after waiting 100ms." By binding the signal operation with the execution logic, the target test case can directly call automated testing software to complete the test without manually writing complex logic.

[0054] Based on the above implementation methods, the process of manually interpreting requirements and manually searching for corresponding test operations is replaced by automated matching, thereby reducing human intervention and improving testing efficiency.

[0055] S203. Generate the target test case corresponding to the target signal operation. The target test case has execution logic.

[0056] For example, after finding the target signal operation, the system automatically completes the execution logic around this signal operation, assembling it into a runnable target test case.

[0057] For example, the execution logic includes the execution details of the test cases, such as: what to do first, what to do next (e.g., first send a voltage signal, wait 100ms, and then collect feedback data from the BMS under test), what interface to use for data collection (controller area network bus interface, hardwired interface, etc.), how to determine the result (e.g., if the BMS under test triggers protection, it is considered qualified), and which local variables to associate (e.g., variables storing the sent voltage value and the collected results). The execution logic is used to ensure that the target test cases are executed correctly.

[0058] With scenario examples, the process of generating target test cases eliminates the complex work of manually writing test cases, arranging test steps, and configuring decision rules, thereby improving testing efficiency.

[0059] S204. Test the BMS under test according to the target test cases, obtain the test results, and generate a test report containing the test results.

[0060] For example, the test system calls the generated target test cases, automatically interacts with the interface of the BMS under test, and completes signal sending, data collection, and result comparison according to the execution logic to finally obtain the test results (such as test passed, test failed, etc.). The test results, collected data, and comparison details are automatically compiled into a standardized test report.

[0061] Optionally, the testing process is Hardware-in-the-Loop (HIL) testing, a semi-physical real-time simulation testing architecture. The actual BMS under test is connected to the simulation closed-loop circuit, while the remaining components, such as the battery itself, high-voltage circuit, and operating conditions, are simulated and run in real-time using simulation equipment. The virtual simulation part outputs electrical and communication stimuli to the BMS under test in real time, while simultaneously acquiring the BMS's real-time response behavior.

[0062] Optional operating conditions include, but are not limited to, at least one of the following: low-voltage power-on, low-voltage power-off, high-voltage power-on to discharge, high-voltage power-off, simulating plugging in a slow charging gun to enter slow charging, simulating unplugging a slow charging gun to exit slow charging, simulating plugging in a fast charging gun to enter fast charging, simulating unplugging a fast charging gun to exit fast charging, initializing cell voltage = 3V, initializing cell temperature = 25℃, maximum discharge power decreasing to 50% at a certain rate, maximum feedback power decreasing to 50% at a certain rate, maximum discharge power and maximum feedback power decreasing to 50% at a certain rate, maximum discharge power decreasing to 0 at a certain rate, maximum feedback power decreasing to 0 at a certain rate, maximum discharge power and maximum feedback power decreasing to 0 at a certain rate, maximum discharge power immediately decreasing to 0, maximum feedback power immediately decreasing to 0, maximum discharge power and maximum feedback power immediately decreasing to 0, charging request current decreasing to 0, etc.

[0063] The testing method provided in this application, in response to a test request from the BMS under test, determines a corresponding target test case library. The test request includes natural language test cases, and the target test case library stores pre-generated signal operations and their corresponding natural language descriptions. Using natural language processing technology, the natural language test cases are matched with the natural language descriptions in the test case library to obtain the target signal operation corresponding to the natural language test case. Target test cases corresponding to the target signal operation are generated, and these target test cases have execution logic. The BMS under test is then tested according to the target test cases to obtain test results, and a test report containing the test results is generated. This solution, by matching natural language test cases with a pre-generated test case library, can quickly obtain the target signal operation. Based on the target signal operation, target test cases are generated and used to test the BMS under test. This avoids the manual process of customizing and writing complex test logic, reducing manual operations and improving testing efficiency.

[0064] Based on any of the above embodiments, the following, in conjunction with Figure 3 The detailed process of the test is explained.

[0065] Figure 3 This is a flowchart illustrating another testing method provided in an embodiment of this application. Figure 3 As shown, the method includes:

[0066] S301. In response to the test request of the BMS under test, determine the corresponding target test case library. The test request includes natural language test cases. The target test case library stores pre-generated signal operations and their corresponding natural language descriptions.

[0067] One feasible implementation method is to determine the target test case library by: performing keyword matching on natural language test cases based on preset test type keywords to obtain the target test type keywords corresponding to the test request; determining the target test type corresponding to the test request based on the target test type keywords, wherein the target test type is either write test or read test; if the target test type is write test, then determining the pre-configured write test case library as the target test case library; if the target test type is read test, then determining the pre-configured read test case library as the target test case library.

[0068] For example, two types of exclusive keywords are preset for each type of test. For example, keywords for writing tests include: distribute, set, write, configure; keywords for reading tests include: collect, read, obtain, feedback.

[0069] Keyword retrieval and matching are performed on natural language test cases to filter out target test type keywords that clearly define the test type. The corresponding target test type is then determined based on these keywords to avoid test type confusion.

[0070] Similarly, two types of test case libraries are pre-configured: one for writing test case libraries (which store class signal operations and corresponding natural language descriptions) and another for reading test case libraries (which store class signal operations and corresponding natural language descriptions).

[0071] The test case library corresponding to the target test type is identified as the target test case library.

[0072] In this feasible implementation, by using preset test type keyword matching, the core requirements of natural language test cases can be automatically identified quickly without the need for manual interpretation or test type determination, thereby improving the efficiency of pre-test preparation.

[0073] S302. Semantic extraction of natural language test cases is performed through a semantic coding model to obtain the first semantic vector. The semantic coding model is obtained by training the model based on the natural language information of multiple samples and the semantic vectors corresponding to the natural language information of multiple samples respectively.

[0074] The natural language description includes multi-level semantic labels, which include at least one of the following: operating condition type, signal operation type, and test constraints.

[0075] For example, multi-level semantic tags are used to describe signal operations from multiple dimensions.

[0076] For example, the operating condition type corresponds to the BMS test operating condition (e.g., voltage, current, temperature, etc.). The signal operation type corresponds to the specific type of signal operation (e.g., sending a voltage signal, acquiring bus data, etc.). Test constraints are used to represent the boundaries of the test (e.g., voltage tolerance, trigger delay tolerance, test temperature tolerance, etc.).

[0077] Based on the above implementation methods, multi-level semantic tags make natural language descriptions more targeted, avoid matching biases caused by single descriptions, and thus improve the accuracy of testing.

[0078] For example, a semantic encoding model can be pre-trained. This model is trained using a large amount of sample natural language information (such as textual descriptions of various BMS test requirements) and the standard semantic vectors corresponding to these sample natural language information. It can accurately identify the core semantics of natural language.

[0079] For example, the testing system extracts semantics from natural language test cases by using the abstract, non-linear mapping relationship between natural language information and semantic vectors in the semantic coding model, and converts the text description into a first semantic vector that the computer can recognize and calculate.

[0080] S303. Semantic extraction is performed on multi-level semantic tags using a semantic coding model to obtain multiple second semantic vectors.

[0081] For example, similarly, through the mapping relationship in the semantic coding model, the semantics of the multi-level semantic tags corresponding to each signal operation in the test case library are extracted to obtain the second semantic vector corresponding to a set of multi-level semantic tags for each signal operation.

[0082] S304. Calculate the semantic similarity between the first semantic vector and each second semantic vector to obtain multiple semantic similarities.

[0083] For example, the cosine similarity between the first semantic vector and each of the second semantic vectors is calculated. Each cosine similarity represents the degree of association between the first semantic vector and one of the second semantic vectors. A higher cosine similarity indicates that the semantic vectors are closer in space and that the test scenario is more closely matched.

[0084] S305. Based on multiple semantic similarities, determine the target signal operation from the target test case library.

[0085] Optionally, the signal operation corresponding to the highest semantic similarity among multiple semantic similarities can be determined as the target signal operation.

[0086] Based on the above implementation methods, by using a preset similarity threshold for filtering, irrelevant signal operations with low semantic matching are automatically eliminated, reducing the candidate range and the amount of subsequent discrimination calculations, thereby improving testing efficiency.

[0087] One feasible implementation method is to determine the target signal operation by means of the following: if a candidate semantic similarity is included among multiple semantic similarities, then the signal operation corresponding to the candidate semantic similarity is determined as the target signal operation, wherein the candidate semantic similarity is greater than or equal to a preset similarity; if multiple semantic similarities include multiple candidate semantic similarities, then according to a mutual exclusion table, the signal operation that does not have a mutual exclusion relationship among the signal operations corresponding to the multiple candidate semantic similarities is determined as the target signal operation.

[0088] For example, after all semantic similarity calculations are completed, a preset similarity threshold is used for filtering. Semantic similarities that reach or exceed the preset similarity are listed as candidate semantic similarities, and the corresponding signal operations become candidate signal operations.

[0089] The preset similarity is used to determine whether each signal operation meets the preliminary criteria, and further screening is carried out after meeting the preliminary criteria.

[0090] Optionally, a preset similarity can be determined by filtering records based on historical signals.

[0091] Make decisions in two scenarios:

[0092] Scenario 1: There is only one candidate semantic similarity that meets the criteria.

[0093] The signal operation corresponding to the unique candidate semantic similarity is directly selected as the final target signal operation.

[0094] Scenario 2: Multiple candidate semantic similarities that meet the criteria exist simultaneously.

[0095] When multiple candidate semantic similarities meet the threshold requirements, the test system retrieves the mutual exclusion table to check whether there are mutual exclusion constraints between each pair of candidate signal operations. From this, the signal operations that are mutually exclusive, compatible with the operating conditions, and can independently adapt to this test request are selected as the final target signal operations.

[0096] For example, in BMS testing, overvoltage excitation signal operations and undervoltage excitation signal operations are mutually exclusive and cannot be used simultaneously in the same test. Even if the two have high semantic similarity, conflicting items are automatically eliminated through the mutual exclusion table, and only reasonable and usable signal operations are retained.

[0097] Optionally, the mutual exclusion table supports dynamic conflict detection. For example, during test execution, if the BMS state switches from "normal mode" to "protection mode," the mutual exclusion table will dynamically adjust the mutual exclusion relationships of signal operations according to the current BMS state (e.g., "overvoltage stimulus" and "undervoltage stimulus" become non-mutually exclusive items in protection mode). This mechanism ensures the rationality of signal operations and the continuity of the test process by monitoring the BMS state in real time and updating the mutual exclusion table.

[0098] In this feasible implementation, a signal operation mutual exclusion table is introduced to add business logic constraint verification for multiple candidate scenarios. This avoids misselecting signal operations that conflict with operating conditions or are mutually exclusive and cannot be executed in parallel, based solely on high semantic similarity scores. This improves the rationality and business adaptability of the matching results, thereby enhancing the accuracy of the test.

[0099] S306. From the target test case library, determine the target execution logic corresponding to the target signal operation. The target execution logic includes at least one of the following: execution prerequisite, execution order, and execution termination condition.

[0100] For example, the execution prerequisites set the preconditions for the signal operation to begin execution, such as system operating status, interface ready status, and initial parameter configuration requirements;

[0101] The execution order determines the sequential arrangement of signal operations within the entire test process, clarifying the interconnected test steps.

[0102] The criteria for determining the completion of the execution are set as follows: if the signal operation is completed, the test is considered to be completed when the condition is met.

[0103] For example, the target execution logic is retrieved from the target test case library by using the identifier corresponding to the target signal operation.

[0104] S307. Integrate the target signal operation with the target execution logic to obtain the target test cases.

[0105] Optionally, obtain a test case template, which includes general parameters, placeholders for signal operations, and placeholders for execution logic.

[0106] The target signal operation is filled into the placeholder of the signal operation, and the target execution logic is filled into the placeholder of the execution logic, so as to integrate them to obtain the target test case.

[0107] Based on the above implementation method, standardized execution logic is pre-configured for each signal operation, eliminating the need for manual writing of execution logic for each test, thereby improving testing efficiency.

[0108] S308. Test the BMS under test according to the target test cases, obtain the test results, and generate a test report containing the test results.

[0109] Below, in conjunction with Figure 4 Provide an explanation of the test report.

[0110] Figure 4 This is a schematic diagram of a test report provided for an embodiment of this application. For example... Figure 4 As shown, the test report includes tabular test results. Test case names distinguish different test scenarios, signal operations identify specific test actions, response data is the actual BMS feedback data collected, response standard data is the pass / fail threshold, and local variable paths are the signal mapping paths in the simulation model. The test report also includes a pie chart, which visually represents the distribution of test cases under different test states and the total test time. For example, in the test case of low-temperature discharge SOC estimation, the following test records may be included: initializing voltage, initializing temperature, setting discharge current, verifying entry into the discharge state, verifying the SOC estimation result, and disconnecting the high-voltage relay.

[0111] One feasible implementation method involves testing the BMS under test using the following steps: converting the target test cases into executable files that match the automated testing software; using the automated testing software to call the executable files to test the BMS under test; during the testing process, acquiring communication response data output by the BMS under test through its bus interface and acquiring physical signal response data output by the BMS under test through its hardwired interface; and determining the test results based on the communication response data and the physical signal response data.

[0112] For example, the testing system performs operations such as format parsing, logic parsing, and instruction translation on the target test cases, compiling the execution prerequisites, execution order, signal operations, and judgment conditions within the target test cases into executable files that can be recognized and scheduled for execution by automated testing software.

[0113] For example, the automated testing software is instructed to load and call the executable file, and automatically send various stimuli and control commands to the BMS under test according to the preset process sequence and signal interaction rules inside the executable file, so as to perform automated testing.

[0114] For example, two types of data collection are performed in parallel during the test run:

[0115] Through the bus interface, continuously collect communication response data such as Controller Area Network (CAN) communication messages, status messages, operating data, and alarm information sent out by the BMS under test.

[0116] The physical signal response data, such as the level, switch quantity, and analog quantity output by the BMS pins, are acquired through a hard-wired interface.

[0117] The test results are determined by combining communication response data and physical signal response data, taking into account the real feedback from both digital communication links and physical hardware links, resulting in a more comprehensive data collection.

[0118] Below, in conjunction with Figure 5 The automated testing software is explained.

[0119] Figure 5 This is a schematic diagram of the automated testing software provided in an embodiment of this application. Figure 5 As shown, the automated testing software provides an interface for automatically generating test case files and executable files. Users can configure the test case library file path, test case file path, and target test case file path through the interface to trigger the generation of the target test case file; further, they can configure the executable file path and project file path, and generate an executable file adapted to the automated testing platform through executable file generation or one-click generation functions. The software also provides functional modules such as generating target test cases, generating executable files, automatically executing tests, and filtering data records, enabling automated execution from test case preparation and executable file generation to automated test execution and data collection.

[0120] For example, automated test software communicates with the hardware interface through a local variable mapping table. This ensures that signal operations can be directly mapped to the hardware interface. This adaptation method binds predefined signal paths to local variables, avoiding signal loss or parsing errors caused by incompatible interface protocols.

[0121] In this feasible implementation, communication response data and physical signal response data are simultaneously collected through the bus interface and the hardwire interface, covering multiple dimensions, avoiding information loss caused by single-dimensional data collection, and improving the completeness of the test.

[0122] One feasible implementation method involves determining the test result as follows: determining standard communication response data and standard physical signal response data from a target test case library; obtaining a first data deviation by comparing the communication response data and the standard communication response data; obtaining a second data deviation by comparing the physical signal response data and the standard physical signal response data; determining the test result as passed if the first data deviation is less than or equal to a preset first deviation and the second data deviation is less than or equal to a preset second deviation; and determining the test result as failed if the first data deviation is greater than a preset first deviation and / or the second data deviation is greater than a preset second deviation.

[0123] For example, communication response standard data and physical signal response standard data are quantitative baselines for determining whether a test meets the standards.

[0124] For example, standard data is pre-bound to signal operations in the target test case library to ensure consistent judgment criteria.

[0125] For example, after collecting the response data, the testing system automatically retrieves the corresponding standard response data from the target test case library based on the target signal operation or the unique identifier corresponding to the target signal operation, ensuring that the standard response data is completely matched with the test scenario and signal operation.

[0126] For example, the testing system automatically compares the collected communication response data with the retrieved standard communication response data parameter by parameter and time sequence, and obtains the deviation value between the two through quantitative calculation, namely the first data deviation.

[0127] Similarly, the testing system automatically compares the physical signal response data and calculates the second data deviation.

[0128] For example, the first preset deviation and the second preset deviation are preset as thresholds for judging the test results.

[0129] For example, if the first data deviation is less than or equal to the preset first deviation and the second data deviation is less than or equal to the preset second deviation (e.g., 0.1V ≤ 0.2V), it means that the communication response and physical signal response of the BMS both meet the preset standards, and the test result is determined to be a pass.

[0130] If the first data deviation is greater than the preset first deviation, and / or the second data deviation is greater than the preset second deviation, that is, if one of them fails to meet the standard, or if neither of them meets the standard, it means that the BMS response does not meet the preset standard, and the test result is determined to be a test failure.

[0131] In this feasible implementation, the target test case library pre-stores the corresponding response standard data, saving the workload of manually searching and entering standard data, thereby improving testing efficiency.

[0132] One feasible implementation method involves the following steps in generating a test case library: obtaining multiple sample test cases and multiple sample execution logics corresponding to multiple sample BMSs; determining the mapping relationship between the multiple sample test cases and multiple sample execution logics; generating a mapping relationship data table based on the multiple sample test cases, multiple sample execution logics, and the mapping relationship; and adding a natural language description corresponding to each sample test case to the mapping relationship data table to obtain the test case library.

[0133] For example, multiple sample BMSs of different models and specifications can be obtained in batches from the historical test data table to cover common BMS test scenarios, ensuring the comprehensiveness and representativeness of the samples, and collecting multiple sample test cases and multiple sample execution logics corresponding to these sample BMSs.

[0134] Below, we provide an example of the obtained sample data, using Table 1 as an example:

[0135] Table 1

[0136]

[0137] The simulation model path is the data storage path of the overall model of the simulation project corresponding to the sample BMS. The data storage path includes local variables, and the meaning of the local variables is explained by the signal value description in natural language, so as to quickly perform matching of natural language processing technology.

[0138] Referring to Table 1, local variables are bridging variables that are directly mapped to signal operations. Since the simulation model path is relatively long (for example, it could be Targets\Controller\Simulation Models\Models\BMS_HIL_VinFast_CloseModel\Parameters\I_O\PowerControl\PowerShutDown\Value), signal operations can be efficiently represented by shorter local variables.

[0139] It should be noted that Table 1 can contain either write-type or read-type data.

[0140] For example, multiple sample test cases and multiple sample execution logics have been verified.

[0141] Optionally, the sample data can be standardized and cleaned to remove invalid, duplicate, or conflicting samples.

[0142] For example, a mapping relationship is obtained by matching multiple sample test cases and multiple sample execution logics one-to-one. The mapping relationship clearly defines which set of sample execution logic each sample test case uniquely corresponds to.

[0143] Below, in conjunction with Figure 6 Explain the mapping relationship.

[0144] Figure 6 This is a schematic diagram illustrating the mapping relationship provided in an embodiment of this application. For example... Figure 6 As shown, the mapping relationship between sample test cases, sample execution logic, and natural language descriptions is suggested. Sample test cases can be extracted from the path "Simulation Model Name / Signal Interaction Model Name / Test Case Name". Sample execution logic can be extracted from the path "Execution Message Name / Execution Channel Name / Execution Message Details". Natural language descriptions include, for example, sending an event-type abort command to the BMS and annotating it for inclusion in the test.

[0145] The simulation model name identifies the overall model of the simulation project corresponding to the sample BMS. The signal interaction model name identifies the sub-model within the overall model that is specifically used for signal input and output. The test case name identifies the specific test behavior, i.e., the test case. The execution message name represents the message frame name of the communication message carrying the sample's execution logic. The execution channel name identifies the signal transmission channel during the execution of the sample test cases. The execution message details represent specific information about the sample's execution logic, such as signal transmission direction, triggering method, and signal transmission period.

[0146] For example, based on multiple sample test cases, multiple sample execution logics, and the determined mapping relationships, the test system automatically organizes and generates a mapping relationship data table. The mapping relationship data table is the core skeleton of the test case library, recording the basic information of each sample test case, the corresponding sample execution logic, and the mapping relationship between the two.

[0147] For example, by adding corresponding natural language descriptions to the mapping relationship data table, the final test case library can be obtained.

[0148] Below, we provide an example of the test case library based on Table 2:

[0149] Table 2

[0150]

[0151] Wherein, BMS_FD1 represents the message name, (242) represents the message number, Sts is the preset state, and BMS_SOC represents the standard value of the state of charge.

[0152] In the process of generating the test case library, a mapping relationship data table is first constructed by mapping the sample test cases to the sample execution logic.

[0153] Specifically, for each sample test case, its corresponding sample execution logic is extracted, and a mapping relationship is established through one-to-one matching. For example, the sample execution logic corresponding to the sample test case "sets the CAN signal Charging_Cable_Inserted to 1" is "triggers the fast charging mode start event". The mapping relationship data table records the correspondence between sample test cases and sample execution logic, ensuring the uniqueness of test cases and execution logic.

[0154] Furthermore, natural language descriptions are added to the mapping relationship data table to enable natural language matching of test cases. These descriptions explain the meaning of signal operations (e.g., "setting the low-voltage enable signal to 1 indicates power-on"), providing a matching basis for subsequent natural language processing techniques. For example, the natural language description for the signal operation "setting the CAN signal Battery_Ready to 1" is "simulating low-voltage power-on condition." By binding natural language descriptions to signal operations, the test case library can support rapid matching of natural language test cases and the generation of target signal operations.

[0155] In this feasible implementation, a test case library is generated based on sample data from multiple sample BMSs. The samples are comprehensive and representative, ensuring that the resources in the library can be adapted to the testing needs of different models and scenarios of BMS. This allows for matching and hitting of test scenarios, reducing manual operations and improving testing efficiency.

[0156] One feasible implementation method is to generate a mapping relationship data table by: dividing multiple sample test cases into write-type sample test cases and read-type sample test cases according to the data flow and data interaction objects in multiple sample test cases; generating a write-type mapping relationship data table based on the write-type sample test cases, their corresponding sample execution logic, and mapping relationships; and generating a read-type mapping relationship data table based on the read-type sample test cases, their corresponding sample execution logic, and mapping relationships.

[0157] For example, based on the data flow and data interaction objects, all sample test cases are categorized by type:

[0158] The data flow of write-type sample test cases is that the test platform sends stimuli, instructions, configuration parameters, and operating condition signals to the BMS, and the settings and operating conditions are written from the outside to the inside of the BMS, corresponding to write-type signal operations;

[0159] The data flow of read-type sample test cases is from BMS to external acquisition and reading of status data, operating parameters, fault information, and physical level signals, corresponding to read-type signal operations.

[0160] After classification, separate tables are created for each test case. Write-type test cases, along with their corresponding execution logic and pre-defined mapping relationships, are collected and organized separately to generate a write-type mapping relationship data table. The read-type mapping relationship data table is created similarly.

[0161] Below, in conjunction with Figure 7 The test preparation and execution are explained.

[0162] Figure 7 This is a schematic diagram illustrating the test preparation and execution provided in an embodiment of this application. Figure 7 As shown, during the test preparation phase, sample data is retrieved in batches from the historical test data table and summarized into a write-type data table and a read-type data table, respectively. A write test case library is generated based on the write-type data table, and a read test case library is generated based on the read-type data table.

[0163] During the test execution phase, natural language test cases that match the natural language descriptions in the test case library are obtained. This involves staff writing natural language test cases based on the keywords or constraints used in the natural language descriptions in the test case library to improve matching accuracy. The natural language test cases are then matched against the target test case library to generate target test cases. These target test cases are then automatically converted into executable files using automated testing software. The executable files are then automatically executed by the automated testing software to perform the tests. A test report is generated based on the test results.

[0164] During the construction of the test case library, a data table is divided into write-type and read-type mapping relationships based on data flow. The data flow for write-type test cases involves the test platform sending signals or configuration parameters to the BMS (such as setting CAN signals or simulating operating conditions), while the data flow for read-type test cases involves collecting status data or physical signals from the BMS (such as reading CAN bus feedback data or hardwired interface levels). For example, for the "simulating fast charging gun insertion" scenario, write-type test cases simulate fast charging gun insertion by setting the CAN signal Charging_Cable_Inserted to 1, while read-type test cases verify whether fast charging mode is activated by collecting the Charging_Mode status feedback from the BMS. By dividing the data flow, the test case library can support independent management of write-type and read-type test scenarios, improving the clarity of test logic and execution efficiency.

[0165] In this feasible implementation, sample test cases are categorized according to data flow and interaction objects, and physical table storage is implemented for write and read test businesses. This avoids the two types of test data from being mixed together, which can cause retrieval confusion and thus improve the reliability of the test.

[0166] This application provides a battery management system, and the test result of the battery management system is that the test is passed; the test result of the battery management system is determined after testing the battery management system by a test system.

[0167] Based on the above implementation method, by matching natural language test cases with a pre-generated test case library, the target signal operation can be quickly obtained. Based on the target signal operation, target test cases are generated and tested on the BMS under test. This avoids the work of manually customizing and writing complex test logic one by one, which can reduce manual operation and thus improve testing efficiency.

[0168] This application provides a battery pack, including a housing, a battery pack, and a battery management system. The battery pack and the battery management system are installed inside the housing. The battery management system is connected to the battery pack and is used to collect the operating parameters of the battery pack and maintain the stable operation of the battery pack.

[0169] Based on the above implementation method, by matching natural language test cases with a pre-generated test case library, the target signal operation can be quickly obtained. Based on the target signal operation, target test cases are generated and tested on the BMS under test. This avoids the work of manually customizing and writing complex test logic one by one, which can reduce manual operation and thus improve testing efficiency.

[0170] This application provides an electric vehicle that includes at least the aforementioned battery pack.

[0171] Based on the above implementation method, by matching natural language test cases with a pre-generated test case library, the target signal operation can be quickly obtained. Based on the target signal operation, target test cases are generated and tested on the BMS under test. This avoids the work of manually customizing and writing complex test logic one by one, which can reduce manual operation and thus improve testing efficiency.

[0172] Figure 8 This is a schematic diagram of a testing device provided in an embodiment of this application. Figure 8 As shown, the testing device 80 may include: a determination module 81, a matching module 82, a generation module 83, and a testing module 84.

[0173] The determination module 81 is used to determine the corresponding target test case library in response to the test request of the BMS under test. The test request includes natural language test cases, and the target test case library stores pre-generated signal operations and their corresponding natural language descriptions.

[0174] The matching module 82 is used to match natural language test cases with natural language descriptions in the test case library using natural language processing technology to obtain the target signal operation corresponding to the natural language test cases.

[0175] The generation module 83 is used to generate target test cases corresponding to the target signal operation. The target test cases have execution logic.

[0176] Test module 84 is used to test the BMS under test according to the target test cases, obtain test results, and generate a test report containing the test results.

[0177] Optionally, module 81 can be executed. Figure 2 S201 in the embodiment.

[0178] Optionally, the matching module 82 can be executed. Figure 2 S202 in the embodiment.

[0179] Optionally, the generation module 83 can be executed. Figure 2 S203 in the embodiment.

[0180] Optionally, test module 84 can be executed. Figure 2 S204 in the embodiment.

[0181] It should be noted that the testing device shown in the embodiments of this application can execute the technical solutions shown in the above method embodiments, and its implementation principle and beneficial effects are similar, so they will not be described again here.

[0182] Based on the above implementation method, by matching natural language test cases with a pre-generated test case library, the target signal operation can be quickly obtained. Based on the target signal operation, target test cases are generated and tested on the BMS under test. This avoids the work of manually customizing and writing complex test logic one by one, which can reduce manual operation and thus improve testing efficiency.

[0183] In one possible implementation, the determining module 81 is specifically used for:

[0184] Based on the preset test type keywords, keyword matching is performed on the natural language test cases to obtain the target test type keywords corresponding to the test request;

[0185] The target test type is determined based on the target test type keyword. The target test type is either a write test or a read test.

[0186] If the target test type is write test, then the pre-configured write test case library will be determined as the target test case library;

[0187] If the target test type is read test, then the pre-configured read test case library will be selected as the target test case library.

[0188] In one possible implementation, the natural language description includes multi-level semantic tags, which include at least one of the following: operating condition type, signal operation type, and test constraints; the matching module 82 is specifically used for:

[0189] The semantics of natural language test cases are extracted by a semantic coding model to obtain the first semantic vector. The semantic coding model is trained based on the natural language information of multiple samples and the semantic vectors corresponding to the natural language information of multiple samples.

[0190] Semantic extraction is performed on multi-level semantic tags using a semantic encoding model to obtain multiple second semantic vectors;

[0191] Calculate the semantic similarity between the first semantic vector and each of the second semantic vectors to obtain multiple semantic similarities;

[0192] The target signal operation is determined from the target test case library based on multiple semantic similarities.

[0193] In one possible implementation, the target test case library includes a table of mutual exclusion relationships between signal operations; the matching module 82 is specifically used for:

[0194] If a candidate semantic similarity is included among multiple semantic similarities, then the signal operation corresponding to the candidate semantic similarity is determined as the target signal operation, and the candidate semantic similarity is greater than or equal to the preset similarity.

[0195] If multiple semantic similarities include multiple candidate semantic similarities, then based on the mutual exclusion table, the signal operation that does not have a mutual exclusion relationship among the signal operations corresponding to the multiple candidate semantic similarities is determined as the target signal operation.

[0196] In one possible implementation, the generation module 83 is specifically used for:

[0197] From the target test case library, determine the target execution logic corresponding to the target signal operation. The target execution logic includes at least one of the following: execution prerequisites, execution order, and execution termination conditions.

[0198] By integrating the target signal operations with the target execution logic, the target test cases are obtained.

[0199] In one possible implementation, test module 84 is specifically used for:

[0200] Convert the target test cases into executable files that match the automated testing software;

[0201] The BMS under test is tested by calling the executable file through automated testing software.

[0202] During the test, communication response data output by the BMS under test is collected through the bus interface of the BMS under test, and physical signal response data output by the BMS under test is collected through the hardwire interface of the BMS under test.

[0203] The test results are determined based on the communication response data and the physical signal response data.

[0204] In one possible implementation, test module 84 is specifically used for:

[0205] Determine the standard data for communication response and physical signal response from the target test case library;

[0206] The testing module is also specifically used to obtain the first data deviation by comparing the communication response data with the standard communication response data;

[0207] The testing module is also used to obtain the second data deviation by comparing the physical signal response data with the physical signal response standard data;

[0208] The testing module is also specifically used to determine the test result as passed when the first data deviation is less than or equal to a preset first deviation and the second data deviation is less than or equal to a preset second deviation.

[0209] The testing module is also specifically used to determine the test result as a failure when the first data deviation is greater than a preset first deviation and / or the second data deviation is greater than a preset second deviation.

[0210] Figure 9 This is a schematic diagram of another testing device provided in an embodiment of this application. Figure 8 Based on the illustrated embodiments, as Figure 9 As shown, the test apparatus 80 also includes a construction module 85.

[0211] Module 85 is used for:

[0212] Obtain multiple sample test cases and execution logic corresponding to multiple sample BMS;

[0213] Determine the mapping relationship between multiple sample test cases and multiple sample execution logic;

[0214] Generate a mapping relationship data table based on multiple sample test cases, multiple sample execution logic, and mapping relationships;

[0215] Add a natural language description for each sample test case to the mapping relationship data table to obtain the test case library.

[0216] In one possible implementation, the construction module 85 is specifically used for:

[0217] Based on the data flow and data interaction objects in multiple sample test cases, the multiple sample test cases are divided into write-type sample test cases and read-type sample test cases;

[0218] Based on the write-type sample test cases and the corresponding sample execution logic and mapping relationship, a write-type mapping relationship data table is generated;

[0219] Based on the read-type sample test cases, the corresponding sample execution logic, and the mapping relationship, a read-type mapping relationship data table is generated.

[0220] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 10 As shown, the electronic device includes:

[0221] The electronic device includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, memory 292, and communication interface 293 can communicate with each other via the bus 294. The communication interface 293 can be used for information transmission. The processor 291 can invoke logical instructions stored in the memory 292 to execute the methods of the above embodiments.

[0222] Furthermore, the logic instructions in the aforementioned memory 292 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0223] The memory 292, as a non-volatile computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, that is, it implements the methods in the above-described method embodiments.

[0224] The memory 292 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 292 may include high-speed random access memory and may also include non-volatile memory.

[0225] Based on the above implementation method, by matching natural language test cases with a pre-generated test case library, the target signal operation can be quickly obtained. Based on the target signal operation, target test cases are generated and tested on the BMS under test. This avoids the work of manually customizing and writing complex test logic one by one, which can reduce manual operation and thus improve testing efficiency.

[0226] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in the foregoing embodiments.

[0227] Based on the above implementation method, by matching natural language test cases with a pre-generated test case library, the target signal operation can be quickly obtained. Based on the target signal operation, target test cases are generated and tested on the BMS under test. This avoids the work of manually customizing and writing complex test logic one by one, which can reduce manual operation and thus improve testing efficiency.

[0228] This application provides a computer program product, including a computer program that, when executed by a processor, implements the method as described in the foregoing embodiments.

[0229] Based on the above implementation method, by matching natural language test cases with a pre-generated test case library, the target signal operation can be quickly obtained. Based on the target signal operation, target test cases are generated and tested on the BMS under test. This avoids the work of manually customizing and writing complex test logic one by one, which can reduce manual operation and thus improve testing efficiency.

[0230] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0231] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps; they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages, which do not necessarily complete at the same time but can be executed at different times. The execution order of these sub-steps or stages is also not necessarily sequential but can be alternated or carried out in turn with other steps or at least some of the sub-steps or stages of other steps.

[0232] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0233] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0234] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. The processor can be any suitable hardware processor, such as CPU, GPU, FPGA, DSP, and ASIC. The storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0235] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0236] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0237] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0238] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A testing system, characterized in that, The testing system is used to test the battery management system (BMS) and obtain a test report. The test report is used to evaluate the performance of the BMS. The testing system is configured to perform the following steps: In response to a test request from the BMS under test, a corresponding target test case library is determined. The test request includes natural language test cases, and the target test case library stores pre-generated signal operations and their corresponding natural language descriptions. By using natural language processing technology, the natural language test cases are matched with the natural language descriptions in the test case library to obtain the target signal operation corresponding to the natural language test cases; Generate target test cases corresponding to the target signal operation, wherein the target test cases have execution logic; The BMS under test is tested according to the target test cases, the test results are obtained, and a test report containing the test results is generated.

2. The system according to claim 1, characterized in that, The step of determining the corresponding target test case library specifically includes: Based on preset test type keywords, keyword matching is performed on the natural language test cases to obtain the target test type keywords corresponding to the test request; The target test type is determined based on the target test type keyword, where the target test type is either a write test or a read test. If the target test type is write test, then the pre-configured write test case library will be determined as the target test case library; If the target test type is a read test, then the pre-configured read test case library will be determined as the target test case library.

3. The system according to claim 1, characterized in that, The natural language description includes multi-level semantic tags, which include at least one of the following: operating condition type, signal operation type, and test constraint conditions; The step of matching the natural language test cases with the natural language descriptions in the test case library using natural language processing technology to obtain the target signal operation steps corresponding to the natural language test cases specifically includes: The semantics of the natural language test cases are extracted by a semantic coding model to obtain a first semantic vector. The semantic coding model is obtained by training a model based on the natural language information of multiple samples and the semantic vectors corresponding to the natural language information of the multiple samples. The semantic encoding model is used to extract the semantic meaning of the multi-level semantic tags to obtain multiple second semantic vectors. Calculate the semantic similarity between the first semantic vector and each second semantic vector to obtain multiple semantic similarities; The target signal operation is determined from the target test case library based on the multiple semantic similarities.

4. The system according to claim 3, characterized in that, The target test case library includes a table of mutual exclusion relationships between signal operations; the step of determining the target signal operation steps from the target test case library based on the multiple semantic similarities specifically includes: If the plurality of semantic similarities includes a candidate semantic similarity, then the signal operation corresponding to the candidate semantic similarity is determined as the target signal operation, and the candidate semantic similarity is greater than or equal to a preset similarity; If the plurality of semantic similarities includes a plurality of candidate semantic similarities, then according to the mutual exclusion table, the signal operation that does not have a mutual exclusion relationship among the signal operations corresponding to the plurality of candidate semantic similarities is determined as the target signal operation.

5. The system according to claim 1, characterized in that, The step of generating the target test case corresponding to the target signal operation specifically includes: From the target test case library, determine the target execution logic corresponding to the target signal operation. The target execution logic includes at least one of the following: execution prerequisite, execution order, and execution termination condition. The target signal operation is integrated with the target execution logic to obtain the target test case.

6. The system according to claim 1, characterized in that, The step of testing the BMS under test according to the target test cases and obtaining test results specifically includes: The target test cases are converted into executable files that match the automated testing software; The BMS under test is tested by calling the executable file through the automated testing software. During the test, the communication response data output by the BMS under test is collected through the bus interface of the BMS under test, and the physical signal response data output by the BMS under test is collected through the hardwire interface of the BMS under test. The test results are determined based on the communication response data and the physical signal response data.

7. The system according to claim 6, characterized in that, The step of determining the test result based on the communication response data and the physical signal response data specifically includes: Determine the communication response standard data and physical signal response standard data from the target test case library; The first data deviation is obtained by comparing the communication response data with the standard communication response data; The second data deviation is obtained by comparing the physical signal response data with the physical signal response standard data; If the first data deviation is less than or equal to a preset first deviation, and the second data deviation is less than or equal to a preset second deviation, the test result is determined to be a pass. If the first data deviation is greater than the preset first deviation, and / or the second data deviation is greater than the preset second deviation, the test result is determined to be a test failure.

8. The system according to any one of claims 1-7, characterized in that, The testing system is also configured to perform the following steps: Obtain multiple sample test cases and execution logic corresponding to multiple sample BMS; Determine the mapping relationship between the plurality of sample test cases and the plurality of sample execution logic; Based on the multiple sample test cases, the multiple sample execution logic, and the mapping relationship, a mapping relationship data table is generated; Add a natural language description corresponding to each sample test case to the mapping relationship data table to obtain the test case library.

9. The system according to claim 8, characterized in that, The step of generating a mapping relationship data table based on the multiple sample test cases, the multiple sample execution logic, and the mapping relationship specifically includes: Based on the data flow and data interaction objects in the multiple sample test cases, the multiple sample test cases are divided into write-type sample test cases and read-type sample test cases; Based on the write-type sample test cases, the sample execution logic corresponding to the write-type sample test cases, and the mapping relationship, a write-type mapping relationship data table is generated; Based on the read-type sample test cases, the sample execution logic corresponding to the read-type sample test cases, and the mapping relationship, a read-type mapping relationship data table is generated.

10. A testing method, characterized in that, include: In response to a test request from the BMS under test, a corresponding target test case library is determined. The test request includes natural language test cases, and the target test case library stores pre-generated signal operations and their corresponding natural language descriptions. By using natural language processing technology, the natural language test cases are matched with the natural language descriptions in the test case library to obtain the target signal operation corresponding to the natural language test cases; Generate target test cases corresponding to the target signal operation, wherein the target test cases have execution logic; The BMS under test is tested according to the target test cases, the test results are obtained, and a test report containing the test results is generated.

11. A battery management system, characterized in that, The battery management system passed the test. The test results of the battery management system are determined by testing the battery management system using the test system described in any one of claims 1-9.

12. A battery pack, characterized in that, The device includes a housing, a battery pack, and the battery management system as described in claim 10. The battery pack and the battery management system are installed inside the housing. The battery management system is connected to the battery pack and is used to collect the operating parameters of the battery pack and maintain the stable operation of the battery pack.

13. An electric vehicle, characterized in that, It includes at least the battery pack as described in claim 12.

Images