Test case generation method, device, equipment, vehicle, medium and product

Abstract

The present disclosure relates to the technical field of vehicle testing, and particularly relates to a test case generation method and device, equipment, vehicle, medium and product. The method comprises: obtaining a test requirement document of a test case to be generated, the test case to be generated being used for testing a target test function of a vehicle; determining a test development strategy corresponding to the target test function, the test development strategy being used for indicating at least one test case design method corresponding to the test case to be generated, a coverage dimension of the test development strategy being determined based on a risk score of the target test function, the risk score being used for representing a risk level of the target test function under a target evaluation dimension; determining a plurality of first test points of the test case to be generated according to the test development strategy and the test requirement document; and generating a plurality of target test cases corresponding to the test requirement document based on the plurality of first test points. The present application can solve the problem that the generated test case causes insufficient testing of part of the functions and waste of test resources.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle testing technology, and in particular to a method, apparatus, equipment, vehicle, medium, and product for generating test cases. Background Technology

[0002] In the field of vehicle functional testing, test case writing is a key step in ensuring system security and functional integrity. Its quality and efficiency directly determine the effectiveness of vehicle testing, and thus affect the development cycle and market competitiveness of vehicle products.

[0003] In related technologies, test requirements documents are typically input directly into the model, and all functions use a unified test standard to output test cases. However, since different test functions have different test requirements, some test functions need to be tested in all dimensions, while others only need to be tested in key dimensions. Test cases generated by using a unified test standard for all functions will lead to insufficient test coverage for some functions and excessive test coverage for others, resulting in inadequate testing of some functions, redundant and wasteful test resources, and low overall test efficiency. Summary of the Invention

[0004] To address the aforementioned technical problems, this disclosure provides a method, apparatus, equipment, vehicle, medium, and product for generating test cases, thereby resolving issues such as insufficient testing of certain functions, redundant and wasted testing resources, and low overall testing efficiency.

[0005] Firstly, this disclosure provides a method for generating test cases, the method comprising: obtaining a test requirement document for generating test cases, the test cases being used to test a target test function of a vehicle; determining a test development strategy corresponding to the target test function, the test development strategy being used to indicate at least one test case design method corresponding to the test cases being generated, the coverage dimension of the test development strategy being determined based on a risk score of the target test function, the risk score being used to characterize the risk level of the target test function under the target evaluation dimension; determining multiple first test points for the test cases being generated based on the test development strategy and the test requirement document; and generating multiple target test cases corresponding to the test requirement document based on the multiple first test points.

[0006] In one optional implementation, determining the test development strategy corresponding to the target test function includes: obtaining at least one functional indicator corresponding to the target test function, wherein the at least one functional indicator includes one or more of customer perceived frequency, usage frequency, complexity indicator, security correlation indicator, and quality indicator; determining a risk score for the target test function based on each functional indicator and the weight value corresponding to each functional indicator; and determining a test development strategy based on the risk score and a first mapping relationship, wherein the first mapping relationship is the mapping relationship between the risk score and the test development strategy.

[0007] In one optional implementation, based on the test development strategy and test requirements document, multiple first test points for generating test cases are determined, including: determining the test requirement category of the test cases to be generated as the target requirement category based on the test requirements document; and determining multiple first test points for generating test cases based on the test development strategy and the target requirement category.

[0008] In one optional implementation, based on the test requirement document, determining the test requirement category of the test cases to be generated as the target requirement category includes: parsing the test requirement document to obtain feature information and multiple keywords, wherein the feature information is used to indicate the characteristics of the test requirement corresponding to the target test function; detecting whether the multiple keywords include at least one preset keyword, wherein the preset keyword is a keyword that matches the target requirement category; if the multiple keywords include at least one preset keyword, determining whether the feature information matches the category definition corresponding to the target requirement category; if the feature information matches the category definition corresponding to the target requirement category, then the target requirement category is determined as the test requirement category of the test cases to be generated.

[0009] In one optional implementation, multiple first test points for generating test cases are determined based on the test development strategy and the target requirement category. This includes: determining multiple target prompts corresponding to the test cases to be generated based on the target requirement category and the test requirement document. The target prompts are used to indicate one or more of the generation conditions, test dimensions, and output formats of the test points to be generated. The multiple target prompts, the test point generation strategy, and the test development strategy are input into a first model, and multiple first test points are output. The test point generation strategy matches the target requirement category.

[0010] In one optional implementation, based on the target requirement category and the test requirement document, multiple target prompt words corresponding to the test cases to be generated are determined, including: determining multiple initial prompt words based on the target requirement category and a second mapping relationship, wherein the second mapping relationship is the mapping relationship between the target requirement category and the multiple initial prompt words; and expanding and enhancing the multiple initial prompt words based on the test requirement document to obtain multiple target prompt words.

[0011] In an optional implementation, the method further includes: if the target test function is a change function, obtaining the historical test requirement document and multiple historical test cases corresponding to the target test function, each historical test case being generated based on a historical test point; comparing the test requirement document and the historical test requirement document to determine the requirement analysis result, the requirement analysis result being used to indicate the change requirement of the target test function; analyzing and processing each historical test case to obtain the writing strategy for each historical test case; inputting the test requirement document, the requirement analysis result, each historical test case and the corresponding writing strategy into a first model, outputting multiple second test points carrying change type labels, the change type labels being used to indicate the change type of each second test point; and generating multiple target test cases corresponding to the test requirement document based on the multiple second test points.

[0012] In one optional implementation, generating target test cases corresponding to the test requirement document based on multiple second test points includes: obtaining at least one historical test case associated with the target test point, where the target test point is one of multiple second test points; if the change type label carried by the target test point is a modification type label, then modifying at least one historical test case based on the target test point to determine at least one target test case associated with the target test point; or, if the change type label carried by the target test point is a deletion type label, then deleting at least one historical test case associated with the target test point; or, if the change type label carried by the target test point is a same type label, then determining at least one historical test case associated with the target test point as at least one target test case associated with the target test point.

[0013] In an optional implementation, the method further includes: after generating multiple target test cases, inputting the multiple target test cases into a second model and outputting review results of the multiple target test cases, wherein the second model has the function of reviewing each target test case; if the review results indicate that the multiple target test cases meet the test requirements document, then outputting the multiple target test cases to the client; if the review results indicate that there is at least one abnormal test case, then updating the first model based on the review results to obtain an updated target model, wherein the target model is used to generate a first test point or a second test point.

[0014] Secondly, the present invention provides a test case generation apparatus, comprising: an acquisition module for acquiring a test requirement document for which test cases to be generated are to be used to test a target test function of a vehicle; a processing module for determining a test development strategy corresponding to the target test function, the test development strategy indicating at least one test case design method corresponding to the test cases to be generated, the coverage dimension of the test development strategy being determined based on a risk score of the target test function, the risk score being used to characterize the risk level of the target test function under the target evaluation dimension; determining multiple first test points for the test cases to be generated based on the test development strategy and the test requirement document; and a generation module for generating multiple target test cases corresponding to the test requirement document based on the multiple first test points.

[0015] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the test case generation method of the first aspect or any corresponding embodiment described above.

[0016] Fourthly, the present invention provides a vehicle including the aforementioned electronic device, thereby executing a method for generating test cases for the first aspect or any corresponding embodiment thereof.

[0017] Fifthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the test case generation method of the first aspect or any corresponding embodiment thereof.

[0018] In a sixth aspect, the present invention provides a computer program product, including computer instructions for causing a computer to execute a method for generating test cases according to the first aspect or any corresponding embodiment thereof.

[0019] The technical solution provided in this disclosure has the following advantages compared with the prior art: The test case generation method provided in this embodiment can obtain the test requirement document of the test cases to be generated; determine the test development strategy corresponding to the target test function; determine multiple first test points of the test cases to be generated based on the test development strategy and the test requirement document; and generate multiple target test cases corresponding to the test requirement document based on the multiple first test points.

[0020] Since the test development strategy is determined based on the risk score of the target test function, and the risk score matches the risk level of the target test function under the target assessment dimension, meaning the coverage dimension of the test development strategy matches the risk level of the target test function, test points can be precisely broken down from the requirements document and test cases can be generated based on the test development strategy that matches the target test function. This not only allows for the reasonable allocation of test resources according to the risk level of the test function, increasing the depth and breadth of test coverage for high-risk test functions to ensure the sufficiency of high-risk function testing, but also standardizes the test case generation process, improves the completeness and effectiveness of vehicle function test cases, reduces the risk of missing tests in vehicle function testing, optimizes overall test quality and development efficiency, improves the testing efficiency of test cases, and avoids redundant and wasteful test resources. Attached Figure Description

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

[0022] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a topology diagram of a test case generation system provided according to an embodiment of this application; Figure 2 This is a flowchart illustrating a method for generating test cases according to an embodiment of this application; Figure 3 This is a flowchart illustrating another method for generating test cases according to an embodiment of this application; Figure 4 This is a flowchart illustrating another method for generating test cases according to an embodiment of this application; Figure 5 This is a flowchart illustrating the method for reviewing test cases according to an embodiment of this application; Figure 6 This is a flowchart illustrating a method for generating another test case according to an embodiment of this application; Figure 7 This is a structural block diagram of the test case generation device provided in the embodiments of this application; Figure 8 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0024] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0025] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0026] The embodiments of this application are applied to the scenario of generating test cases for vehicle function testing.

[0027] In related technologies, test requirements documents are typically input directly into the model, and all functions use a unified testing standard to output test cases. However, since different test functions have different test requirements, some test functions need to be tested in all dimensions, while others only need to be tested in key dimensions. Test cases generated using a unified testing standard for all functions can lead to insufficient test coverage for some functions and excessive test coverage for others, resulting in redundant and wasted test resources and low overall test efficiency.

[0028] In addition, test cases can be manually written, but this method is inefficient, prone to omissions, and difficult to reuse. Furthermore, test cases can be generated through recording and playback, keyword-driven methods, and model-driven methods. These methods suffer from poor adaptability, high maintenance costs, and an inability to understand semantic requirements. Methods for generating test cases based on test requirement documents and large language models (Artificial Intelligence, AI) suffer from shallow semantic understanding, fragmented generation results, and a lack of domain knowledge accumulation. For example, they cannot accurately identify functional boundaries, interaction sequences, and safety constraints in vehicle requirements; there are many repetitive test cases, incomplete coverage, and a lack of structured organization; historical testing experience is not effectively reused, and each generation starts "from scratch." Although retrieval-enhanced generation technology introduces a historical test case library, it still relies on passive retrieval, lacks active reasoning and strategy guidance, and struggles to handle complex vehicle scenarios (such as multi-sensor fusion and fault injection). It cannot accurately interpret test requirement documents and cannot generate test cases based on the actual requirements of the function under test, resulting in poor accuracy of the generated test cases.

[0029] To address the aforementioned technical problems, embodiments of this application provide a method for generating test cases. The method includes: obtaining a test requirement document for which test cases to be generated are used to test the target test functions of a vehicle; determining a test development strategy corresponding to the target test functions, wherein the test development strategy indicates at least one test case design method corresponding to the test cases to be generated, and the coverage dimension of the test development strategy is determined based on a risk score of the target test functions, the risk score characterizing the risk level of the target test functions under the target evaluation dimension; determining multiple first test points for the test cases to be generated based on the test development strategy and the test requirement document; and generating multiple target test cases corresponding to the test requirement document based on the multiple first test points. This method can generate test cases that match the risk level of the target test functions, increasing the depth and breadth of test coverage for high-risk test functions, and performing routine testing on low-risk test functions, thereby improving the testing efficiency of test cases and avoiding redundant waste of test resources.

[0030] The following is based on Figure 1 Taking the test case generation system shown as an example, the method provided in the embodiments of this application will be described.

[0031] like Figure 1 As shown, Figure 1 This is a topology diagram of a test case generation system provided according to an embodiment of this application. Figure 1 In the test case generation system 100, there are test case generation device 101 and client 102.

[0032] The test case generation device 101 can be any device with communication and computing functions. For example, the test case generation device 101 can be a server, cloud server, virtual machine, etc.

[0033] Client 102 can be any device with communication and display functions. Client 102 can be used to display the test cases output by the test case generation device 101.

[0034] Figure 1 The test case generation system illustrated is for illustrative purposes only and is not intended to limit the technical solutions of this application. Those skilled in the art should understand that, in specific implementations, the test case generation system may include more devices, without limitation.

[0035] This embodiment provides a method for generating test cases, which can be used in the aforementioned test case generation apparatus. Figure 2 This is a flowchart illustrating a test case generation method according to an embodiment of this application; as shown below. Figure 2 As shown, the process includes the following steps: S201, Obtain the test requirement document for generating test cases.

[0036] The test cases to be generated are used to test the target test functions of the vehicle. The target test functions can be newly added test functions or update test functions that update existing test functions.

[0037] In this embodiment of the application, the test requirement document may include the function name of the target test function to be tested, the test requirement document version, vehicle requirements, hardware interface requirements, software protocol requirements, normal working condition requirements, boundary condition requirements, abnormal working condition requirements, timing interaction requirements, state switching logic requirements, vehicle power-on status, gear, vehicle speed, environmental conditions, device connection, software version, criteria for determining whether the function passes or fails, performance indicators, response latency, fault tolerance, fault handling requirements, etc.

[0038] For example, in response to a user's upload operation on the client, the uploaded document corresponding to the upload operation is retrieved.

[0039] S202, Determine the test development strategy corresponding to the target test function.

[0040] The test development strategy specifies at least one test case design method corresponding to the test cases to be generated. The coverage dimension of the test development strategy is determined based on the risk score of the target test function, which characterizes the risk level of the target test function under the target evaluation dimension. Test development strategies may include requirement coverage strategies, decision coverage strategies, equivalence class partitioning strategies, boundary value analysis strategies, flowchart analysis strategies, state transition strategies, error guessing strategies, multi-defect combination strategies, independent stress testing strategies, and non-functional testing strategies.

[0041] For example, based on the target test function, a risk score for the target test function is determined; based on the target risk score, a test development strategy corresponding to the target test function is determined.

[0042] Understandably, determining the test development strategy corresponding to the target test function is suitable when the target test function is a newly added test function.

[0043] S203, based on the test development strategy and test requirements document, identify multiple first test points for generating test cases.

[0044] A test point is the smallest independently verifiable test unit extracted from the requirements document. A test point is used to verify a sub-function of the target test function.

[0045] For example, using the first model, multiple first test points for generating test cases are determined based on the test development strategy and test requirements document.

[0046] S204 generates multiple target test cases corresponding to the test requirement document based on multiple first test points.

[0047] Among them, multiple target test cases are used to test the target test functions.

[0048] For example, based on multiple first test points, multiple target test cases corresponding to the test requirement document are generated.

[0049] based on Figure 2 The method can obtain the test requirement document for generating test cases; determine the test development strategy corresponding to the target test function; determine multiple first test points for generating test cases based on the test development strategy and the test requirement document; and generate multiple target test cases corresponding to the test requirement document based on the multiple first test points.

[0050] Since the test development strategy is determined based on the risk score of the target test function, and the risk score matches the risk level of the target test function under the target assessment dimension, meaning the coverage dimension of the test development strategy matches the risk level of the target test function, test points can be precisely broken down from the requirements document and test cases can be generated based on the test development strategy that matches the target test function. This not only allows for the reasonable allocation of test resources according to the risk level of the test function, increasing the depth and breadth of test coverage for high-risk test functions to ensure the sufficiency of high-risk function testing, but also standardizes the test case generation process, improves the completeness and effectiveness of vehicle function test cases, reduces the risk of missing tests in vehicle function testing, optimizes overall test quality and development efficiency, improves the testing efficiency of test cases, and avoids redundant and wasteful test resources.

[0051] In an alternative example, based on the foregoing embodiments, as described above, Figure 3 This is a flowchart illustrating another test case generation method provided in an embodiment of this application. The method determines the test development strategy corresponding to the target test function, as shown in the following steps. See details below. Figure 3 As shown, it includes: S301, Obtain at least one functional indicator corresponding to the target test function.

[0052] Among them, at least one functional indicator includes one or more of the following: customer perceived frequency, usage frequency, complexity indicator, security-related indicator, and quality indicator.

[0053] The customer perception frequency indicates how frequently end customers can perceive anomalies in the target test function. The customer perception frequency can include a first perception frequency, a second perception frequency, a third perception frequency, and a fourth perception frequency. The first perception frequency indicates that end customers do not perceive any anomalies; the second perception frequency indicates that a few attentive end customers can perceive them; the third perception frequency indicates that most end customers can perceive them; and the fourth perception frequency indicates that all end customers can perceive them.

[0054] In this embodiment, usage frequency is used to indicate how frequently an end user uses the target testing function. Usage frequency includes a first usage frequency, a second usage frequency, a third usage frequency, and a fourth usage frequency. The first usage frequency indicates that the end user uses it very infrequently; the second usage frequency indicates that the end user uses it occasionally; the third usage frequency indicates that the end user uses it frequently; and the fourth usage frequency indicates that the end user uses it every time.

[0055] In this embodiment, the complexity index is used to indicate the complexity of the target test function. The complexity index includes a first complexity index, a second complexity index, a third complexity index, and a fourth complexity index. The first complexity index indicates that the target test function is centralized and simple; the second complexity index indicates that the target test function is distributed and simple; the third complexity index indicates that the target test function is centralized and simple; and the fourth complexity index indicates that the target test function is distributed and complex.

[0056] In this embodiment, the safety correlation index is used to indicate the degree of correlation between the target test function and vehicle safety performance. The safety correlation index may include a first correlation index, a second correlation index, a third correlation index, a fourth correlation index, and a fifth correlation index. The first correlation index indicates that the target test function is not related to vehicle safety performance; the second correlation index indicates that the correlation between the target test function and vehicle safety performance is related to driving safety (causing minimal harm to occupants); the third correlation index indicates that the correlation between the target test function and vehicle safety performance is not related to driving safety (e.g., anti-theft function); the fourth correlation index indicates that the correlation between the target test function and vehicle safety performance is related to driving safety (causing mild to moderate harm to occupants, but not fatal); and the fifth correlation index indicates that the correlation between the target test function and vehicle safety performance is related to driving safety (causing serious harm to occupants, potentially fatal).

[0057] In this embodiment, quality indicators are used to indicate the technological maturity and product quality of the target test function. Quality indicators may include a first quality indicator, a second quality indicator, a third quality indicator, and a fourth quality indicator. The first quality indicator indicates that the technological maturity of the target test function is mature and the product quality is good (supplier product quality is good); the second quality indicator indicates that the technological maturity of the target test function is mature and the product quality is poor (supplier product quality is poor); the third quality indicator indicates that the technological maturity of the target test function is immature and the product quality is good (supplier product quality is good); the fourth quality indicator indicates that the technological maturity of the target test function is immature and the product quality is poor (supplier product quality is poor).

[0058] For example, based on vehicle after-sales data, at least one functional indicator corresponding to the target test function of the vehicle is obtained. It is understood that the after-sales data may include at least one functional indicator corresponding to at least one target test function.

[0059] S302, determine the risk score of the target test function based on each functional indicator and the corresponding weight value of each functional indicator.

[0060] The weight value for each functional indicator can be set according to actual needs and is not restricted. For example, the weight value for the security correlation indicator can be set to twice the weight values ​​for other functional indicators. Other functional indicators can be customer perception frequency, usage frequency, complexity indicators, or quality indicators.

[0061] In one example, based on each functional indicator and a preset mapping table, the evaluation score corresponding to each functional indicator is determined; the product between the evaluation score corresponding to each functional indicator and its corresponding weight value is calculated to obtain the contribution value corresponding to each functional indicator; the sum of each contribution value is calculated to obtain the risk score of the target test function.

[0062] The preset mapping table is shown in Table 1 below:

[0063] Table 1 S303, determine the test development strategy based on the risk score and the first mapping relationship.

[0064] The first mapping relationship is the mapping relationship between risk score and test development strategy.

[0065] Specifically, when the risk score is between 4 and 9, the test development strategy is determined to be the requirements coverage strategy (Analysis of requirements) based on the risk score and the first mapping relationship.

[0066] When the risk score is between 10 and 14, the test development strategy is determined based on the risk score and the first mapping relationship as a decision coverage strategy (e.g., cause-effect graph coverage strategy and decision table coverage strategy) or an equivalence class partitioning strategy.

[0067] When the risk score is between 15 and 19, the test development strategy is determined based on the risk score and the first mapping relationship as the boundary value analysis strategy, flow diagram analysis strategy, state transition strategy, and error guessing strategy.

[0068] When the risk score is between 20 and 24, the test development strategy is determined based on the risk score and the first mapping relationship as a multi-defect combination strategy (orthogonal experimental design), an individual stress test strategy, or a non-functional test strategy (e.g., performance test strategy, user usability strategy).

[0069] Understandably, a comprehensive approach is taken, considering multiple functional indicators such as customer perception, usage frequency, functional architecture complexity, security relevance, and technical quality. Based on the weights of each indicator, a risk score is determined for the target test function, leading to a test development strategy that matches the risk score. This allows for precise quantification of vehicle function risk levels, enabling the application test design method with the highest applicability based on risk level. High-risk functions employ in-depth testing strategies for enhanced verification, while low-risk functions have streamlined testing processes. This approach not only rationally allocates test resources, avoids redundant and missed tests, and effectively controls potential defects in vehicle functions, but also standardizes test judgment logic, significantly improving the scientific nature of test case design and the overall quality of vehicle testing.

[0070] In an alternative example, based on the foregoing embodiments, as described above, Figure 4 This is a flowchart illustrating another test case generation method provided in an embodiment of this application; based on the test development strategy and test requirements document, multiple first test points for generating test cases are determined, as follows: (See details in the attached document). Figure 4 As shown, it includes: S401, Based on the test requirements document, determine the test requirement category of the test cases to be generated as the target requirement category.

[0071] The test requirements categories include combination type, process type, parameter type, status type, and data type.

[0072] In some optional implementations, the test requirement document is parsed to obtain feature information and multiple keywords; it is detected whether the multiple keywords include at least one preset keyword; if the multiple keywords include at least one preset keyword, it is determined whether the feature information matches the category definition corresponding to the target requirement category; if the feature information matches the category definition corresponding to the target requirement category, the target requirement category is determined as the test requirement category for generating test cases.

[0073] The preset keywords are those that match the target requirement category. Feature information is used to indicate the characteristics of the test requirements corresponding to the target test function.

[0074] Specifically, when the target requirement category is a combination type, the preset keywords are "combination", "factor", "state table", "scenario coverage" or "exhaustive search"; the feature information is used to indicate that the test requirement has many factors, many states, and many combinations.

[0075] When the target requirement category is process, the preset keywords are "process", "step", "trigger", "exception handling" or "flow"; the feature information is used to indicate scenarios where the test requirement has many steps, sequential dependencies, and multiple roles triggering it.

[0076] When the target requirement category is parameter-based, the default keywords are "rule", "condition", "value combination", "if-then", or "constraint"; the feature information is used to indicate that the test requirement includes multiple parameters or rule combinations and is a non-process requirement.

[0077] When the target requirement category is a state, the preset keywords are "state", "switch", "trigger event", "activation" or "exit"; the feature information is used to indicate scenarios in the test requirements where the same object has multiple states and there are event-driven state transitions.

[0078] When the target requirement category is data, the default keywords are "value range", "field", "unit", "format" or "validation"; the feature information is used to indicate that the test requirement includes multiple independent data items, no combination logic, and only range constraints on the data items.

[0079] It should be noted that combined requirement categories have higher priority than other requirement categories. Specifically, after obtaining feature information and multiple keywords, the process first determines whether the target requirement category is a combined category; if it is not a combined category, it determines whether it is a process category based on feature information and multiple keywords; if it is not a process category, it determines whether it is a parameter category based on feature information and multiple keywords; if it is not a parameter category, it determines whether it is a status category based on feature information and multiple keywords; if it is not a status category, it determines whether it is a data category based on feature information and multiple keywords; if it is not a data category, it is determined that there is a conflict or ambiguity between the feature information and multiple keywords, so the keywords are backtracked, the most prominent keyword is re-selected for matching, and the test requirement category to be generated for test cases is re-determined.

[0080] Understandably, determining the requirement category through keyword retrieval and requirement feature comparison, and then quickly and accurately classifying requirements into five categories—combination, process, parameter, status, and data—based on the priority rules of requirement categories, allows for a more accurate understanding of the test requirements document compared to directly inputting the test requirement document into the model. This also facilitates subsequent strategy generation based on matching corresponding test points according to the category, adapting test cases to different requirement characteristics, ensuring that the test direction aligns with actual business needs, and effectively improving the rationality of test case design and overall test quality.

[0081] S402, based on the test development strategy and target requirement category, determine multiple first test points for generating test cases.

[0082] In some optional implementations, multiple target prompts corresponding to the test cases to be generated are determined based on the target requirement category and the test requirement document; the multiple target prompts, the test point generation strategy, and the test development strategy are input into the first model, and multiple first test points are output.

[0083] The target prompts are used to indicate one or more of the generation conditions, test dimensions, and output formats of the test points to be generated. Understandably, the target prompts are used to standardize the generation conditions, test dimensions, and output formats of test points, solving the problems of fragmented thinking, missing dimensions, and inconsistent formats in traditional manual test point generation, thus achieving standardized and structured test point generation.

[0084] In this embodiment of the application, the test point generation strategy is matched with the target requirement category.

[0085] Specifically, when the target requirement category is process-based, the test point generation strategy is as follows: take the complete business process as the smallest design unit, design test points based on the main process, branch processes, and abnormal processes as a whole, without breaking down individual operations; adopt the layered coverage principle to achieve full coverage for simple processes, and adopt a simplified coverage strategy of main process plus key supplementary processes for complex processes; at the same time, distinguish between user roles and vehicle models, and design exclusive test points independently for different user roles and different vehicle models.

[0086] When the target requirement category is parameter-based, the test point generation strategy is as follows: Functional parameters are used as the core of the test; all parameters and their corresponding values ​​are extracted from the test requirements, and each business rule is set as a separate test point; a combination of decision tables, equivalence class partitioning, and boundary value analysis is used to systematically cover various parameter combinations and prevent omissions in test scenarios; business rules are standardized and solidified into a standardized sentence structure of "When [A = first value] and [B = second value], execute operation X" to ensure clear and consistent test logic.

[0087] When the target requirement category is data-related, the test point generation strategy is as follows: Focus on explicitly defined data fields such as numerical values, dates, and enumerations within the requirement, and extract test points based on the data item's value range; divide each data item into valid and invalid equivalence classes, and extract boundary values ​​such as minimum, maximum, and critical points to generate high-coverage test points; sort out the mutual exclusion and conditional triggering dependencies between data, build a data constraint matrix, and avoid invalid and conflicting data combinations; uniformly transform the requirement rule according to the standard template "when [A = preset value], execute operation Y" to ensure that the test points are executable and verifiable; finally, optimize the generated test points by deduplication and merging, and output a concise and non-redundant test set.

[0088] When the target requirement category is composite, the test point generation strategy is as follows: Focus on the key input factors and corresponding state sets in the test requirements, using the factor-state structure as the basis for test modeling; clarify and define the logical constraints such as mutual exclusion, dependency, and default values ​​between each factor, as the basis for combination selection; adopt a layer-by-layer orthogonal design approach, generate candidate combinations through Cartesian product, and then intelligently prune according to orthogonality principles and constraints to reduce the number of test cases; output a test matrix containing factor-state tables, constraint descriptions, and orthogonal logs in a standardized structure to ensure that the test process is traceable and the solution is reusable; minimize the number of test cases while meeting high composite coverage, balancing test completeness and test execution efficiency.

[0089] When the target requirement category is state-based, the test point generation strategy is as follows: Focus on the requirement content and extract all business states, with the business state model as the core; follow the unified modeling language state diagram modeling standard, systematically sort out and extract all observable business states and state transition trigger conditions, ensuring no omissions or duplications in state sorting; number and name all state transition relationships sequentially from T1 to Tn, and list all trigger events corresponding to each state transition completely; atomically decompose each independent trigger event and branch condition, and use them as independent test points to ensure full coverage of state transition paths; define test points in a structured manner, using the state transition number as the test point name and the original requirement trigger conditions and guard logic as the test point description, ensuring that the test points are executable and traceable.

[0090] Understandably, test points are generated based on specific prompts, generation strategies, and development strategies that match the requirement categories, standardizing generation conditions, test dimensions, and output formats. For five different requirement categories, corresponding design logic is matched, and multiple primary test points are determined to fit the characteristics of various business scenarios, avoiding the problems of scattered thinking, inconsistent formats, and missing dimensions in manual test point generation. This ensures complete test scenario coverage, reduces redundant and invalid content, and achieves standardized and structured test point generation, effectively improving output quality and design efficiency.

[0091] In one example, multiple initial prompt words are determined based on the target requirement category and the second mapping relationship; based on the test requirement document, the multiple initial prompt words are expanded and enhanced to obtain multiple target prompt words; the multiple target prompt words are concatenated and combined with the test requirement document to obtain a query instruction; the query instruction, test point generation strategy and test development strategy are input into the first model to output multiple first test points.

[0092] The second mapping relationship is the mapping relationship between the target demand category and multiple initial prompt words.

[0093] In this embodiment of the application, the first model can be a large language model. The first model is deployed in the test case generation device.

[0094] For example, based on the target requirement category and the second mapping relationship, multiple initial prompt words corresponding to the target requirement category are determined; based on the test requirement document, the meta-reasoning capability of the first model is used to expand, refine and professionally revise the basic prompt words to obtain multiple target prompt words.

[0095] Understandably, by relying on the meta-reasoning of the large language model to refine, correct, and standardize the original initial prompts, eliminating ambiguity, redundancy, and vague content, and by combining them with the professional scenarios of vehicle testing, we can proactively supplement essential dimensions for professional testing such as boundary value analysis, state transitions, process branches, abnormal scenarios, user roles, vehicle model differences, and parameter combination constraints. This addresses the shortcomings of the initial prompts and outputs professionally optimized prompts that are logically rigorous, comprehensive in dimensions, precise in instructions, and in line with testing business specifications. This allows the prompts to accurately drive high-quality and standardized completion of tasks such as test point extraction and test case generation, completely solving the problems of vague instructions, incomplete coverage, insufficient professionalism, and inconsistent output quality of the basic prompts.

[0096] In an optional example, based on the foregoing embodiments, as described above, the methods for generating test cases when the target test function is a newly added function are all applicable. The following describes the method for generating test cases when the target test function is a changed function.

[0097] In some optional implementations, when the target test function is a changed function, the following steps are taken: First, obtain the historical test requirement document and multiple historical test cases corresponding to the target test function; second, compare the test requirement document and the historical test requirement document to determine the requirements analysis results; third, analyze and process each historical test case to obtain the writing strategy for each historical test case; fourth, input the test requirement document, requirements analysis results, each historical test case, and the corresponding writing strategy into the first model, and output multiple second test points carrying change type labels; fifth, based on the multiple second test points, generate multiple target test cases corresponding to the test requirement document.

[0098] Each historical test case is generated based on a historical test point. The requirements analysis results are used to indicate the change requirements for the target test function.

[0099] In this embodiment, the change type label is used to indicate the change type of each second test point. The change type labels include modification type labels, deletion type labels, identical type labels, and new type labels. A modification type label indicates that the test cases for a sub-function within the original test function are modified; a deletion type label indicates that the test cases for a sub-function within the original test function are deleted; an identical type label indicates that a test case identical to the original test function is generated. A new type label indicates that a test case for a sub-function is added to the original test function.

[0100] Understandably, by retrieving historical test requirements documents and comparing multiple historical test cases to identify requirement changes, and combining this with the historical test case writing approach, test points with change identifiers are generated. This can accurately distinguish between four types of change scenarios: additions, modifications, retentions, and deletions, fully reusing effective historical test cases, reducing repetitive design work, ensuring full test coverage of functional changes, and improving iterative testing efficiency and test case matching accuracy.

[0101] In some optional implementations, at least one historical test case associated with the target test point is obtained; if the change type label carried by the target test point is a modification type label, then based on the target test point, at least one historical test case is modified to determine at least one target test case associated with the target test point; or, if the change type label carried by the target test point is a deletion type label, then at least one historical test case associated with the target test point is deleted; or, if the change type label carried by the target test point is a same type label, then at least one historical test case associated with the target test point is determined as at least one target test case associated with the target test point.

[0102] The target test point is one of multiple second test points.

[0103] It should be noted that when the type label is changed to the "new" type label, it means that a test case for a sub-function needs to be added to the existing test function. The method for generating the test case is the same as... Figure 2 The method for generating test cases is similar and will not be elaborated here.

[0104] Understandably, for functional change scenarios, historical requirements and test cases are retrieved, compared and analyzed to clarify the changed content, and test points with categorized tags are generated based on past test case writing strategies. Differentiated handling of test cases based on different change types (modification, deletion, retention, addition) allows for precise matching of requirement changes to adjust test content, reuse of effective historical test cases, avoidance of repetitive writing work, and ensures complete test coverage of the changed parts. This effectively reduces test case iteration time and improves version iteration testing efficiency and test case adaptation accuracy.

[0105] Furthermore, after generating multiple target test cases, the multiple target test cases are input into the second model, and the review results of the multiple target test cases are output. If the review results indicate that the multiple target test cases meet the test requirements document, the multiple target test cases are output to the client. If the review results indicate that there is at least one abnormal test case, the first model is updated based on the review results to obtain the updated target model.

[0106] The target model is used to generate the first test point or the second test point.

[0107] In this embodiment of the application, the second model has the function of reviewing each target test case.

[0108] Understandably, by assigning two independent models to the roles of "generating test cases" and "reviewing test cases" respectively, the cognitive biases or blind spots of a single model can be avoided. The independent review model will examine the generated results from different perspectives (such as requirement coverage, logical completeness, and compliance), effectively compensating for the omissions of the generation model; and filtering out low-quality test cases with logical contradictions, incomplete coverage, or non-compliance in advance, thus preventing them from entering the subsequent execution stage and causing waste.

[0109] like Figure 5 As shown, Figure 5 This is a flowchart illustrating the method for reviewing test cases according to embodiments of this application; Figure 5 In addition, the test case generation device can also perform: S501, Input test requirements document.

[0110] S502 uses the first model to generate multiple target test cases.

[0111] S503 utilizes the second model and manual review to obtain the review results.

[0112] S504, whether the inspection and review results are satisfactory.

[0113] S505: If the review result is passed, the generated test cases will be output.

[0114] S506 If the review result is not passed, the first model is instructed to reflect on and optimize the test cases to obtain optimized test cases, and S503 is re-executed, with the number of re-loops being less than or equal to 5.

[0115] Optionally, after obtaining the optimized test cases, optimization strategy suggestions can be output and stored in the review decision memory pool for subsequent review of the test cases.

[0116] Understandably, adopting a dual review model combining models and manual review ensures that test points and test cases fully cover all business requirements. The first model can trigger test case updates synchronously when requirements change, and automatically initiate iterative corrections if the review fails. At the same time, it can accumulate learning in practice, absorb the experience of industry experts, and continuously optimize to achieve steady improvement in performance and capabilities.

[0117] like Figure 6 As shown, Figure 6 This is a flowchart illustrating a method for generating another test case according to an embodiment of this application; Figure 6 In this context, the test case generation device can perform the following steps: S601, Obtain the test requirement document for generating test cases.

[0118] S602, Check if the target testing function is a new function.

[0119] S603 If it is a new feature, determine the test development strategy corresponding to the target test feature; based on the test development strategy and test requirements document, determine multiple first test points.

[0120] S604 If it is not a new function (i.e. an updated function), then obtain the historical test requirement document and multiple historical test cases corresponding to the target test function; based on the test requirement document, the historical test requirement document and multiple historical test cases, determine multiple second test points.

[0121] S605 generates multiple target test cases based on multiple first test points or multiple second test points.

[0122] This embodiment also provides a test case generation apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0123] This embodiment provides a test case generation device, such as... Figure 7 As shown, Figure 7 This is a structural block diagram of a test case generation device provided according to an embodiment of this application; including: The acquisition module 701 is used to acquire the test requirement document of the test cases to be generated, which are used to test the target test functions of the vehicle. Processing module 702 is used to determine the test development strategy corresponding to the target test function. The test development strategy is used to indicate at least one test case design method corresponding to the test cases to be generated. The coverage dimension of the test development strategy is determined based on the risk score of the target test function. The risk score is used to characterize the risk level of the target test function under the target evaluation dimension. According to the test development strategy and the test requirement document, multiple first test points of the test cases to be generated are determined. The generation module 703 is used to generate multiple target test cases corresponding to the test requirement document based on multiple first test points.

[0124] In some optional implementations, the processing module 702 is specifically used to obtain at least one functional indicator corresponding to the target test function, the at least one functional indicator including one or more of customer perceived frequency, usage frequency, complexity indicator, security correlation indicator, and quality indicator; determine the risk score of the target test function based on each functional indicator and the weight value corresponding to each functional indicator; and determine the test development strategy based on the risk score and a first mapping relationship, the first mapping relationship being the mapping relationship between the risk score and the test development strategy.

[0125] In some optional implementations, the processing module 702 is specifically used to determine, based on the test requirement document, the test requirement category of the test cases to be generated as the target requirement category; and to determine multiple first test points of the test cases to be generated according to the test development strategy and the target requirement category.

[0126] In some optional implementations, the processing module 702 is specifically used to parse the test requirement document to obtain feature information and multiple keywords. The feature information is used to indicate the characteristics of the test requirement corresponding to the target test function. The processing module 702 is used to detect whether the multiple keywords include at least one preset keyword, where the preset keyword is a keyword that matches the target requirement category. If the multiple keywords include at least one preset keyword, the processing module 702 is used to determine whether the feature information matches the category definition corresponding to the target requirement category. If the feature information matches the category definition corresponding to the target requirement category, the target requirement category is determined as the test requirement category for generating test cases.

[0127] In some optional implementations, the processing module 702 is specifically used to determine multiple target prompt words corresponding to the test cases to be generated based on the target requirement category and the test requirement document. The target prompt words are used to indicate one or more of the generation conditions, test dimensions, and output formats of the test points to be generated. The multiple target prompt words, test point generation strategy, and test development strategy are input into the first model, and multiple first test points are output. The test point generation strategy is matched with the target requirement category.

[0128] In some optional implementations, the processing module 702 is specifically used to determine multiple initial prompt words based on the target requirement category and the second mapping relationship, wherein the second mapping relationship is the mapping relationship between the target requirement category and the multiple initial prompt words; and to perform expansion and enhancement processing on the multiple initial prompt words based on the test requirement document to obtain multiple target prompt words.

[0129] In some optional implementations, the acquisition module 701 is further configured to, if the target test function is a change function, acquire the historical test requirement document and multiple historical test cases corresponding to the target test function, each historical test case being generated based on a historical test point; the processing module 702 is further configured to compare the test requirement document and the historical test requirement document to determine the requirement analysis result, the requirement analysis result being used to indicate the change requirement of the target test function; analyze and process each historical test case to obtain the writing strategy for each historical test case; input the test requirement document, the requirement analysis result, each historical test case and the corresponding writing strategy into the first model, and output multiple second test points carrying change type labels, the change type labels being used to indicate the change type of each second test point; the generation module 703 is configured to generate multiple target test cases corresponding to the test requirement document based on the multiple second test points.

[0130] In some optional implementations, the generation module 703 is specifically used to obtain at least one historical test case associated with the target test point, where the target test point is one of a plurality of second test points; if the change type label carried by the target test point is a modification type label, then based on the target test point, at least one historical test case is modified to determine at least one target test case associated with the target test point; or, if the change type label carried by the target test point is a deletion type label, then at least one historical test case associated with the target test point is deleted; or, if the change type label carried by the target test point is a same type label, then at least one historical test case associated with the target test point is determined as at least one target test case associated with the target test point.

[0131] In some optional implementations, the processing module 702 is further configured to, after generating multiple target test cases, input the multiple target test cases into a second model and output review results of the multiple target test cases, wherein the second model has the function of reviewing each target test case; if the review results indicate that the multiple target test cases meet the test requirements document, then the multiple target test cases are output to the client; if the review results indicate that there is at least one abnormal test case, then the first model is updated based on the review results to obtain an updated target model, wherein the target model is used to generate a first test point or a second test point.

[0132] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0133] In this embodiment, the test case generation device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0134] This invention also provides an electronic device having the above-described features. Figure 7 The device for generating test cases shown.

[0135] Please see Figure 8 , Figure 8 This is a schematic diagram of the hardware structure of the electronic device according to an embodiment of this application, such as... Figure 8 As shown, the electronic device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise as required. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 8 Take a processor 10 as an example.

[0136] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0137] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0138] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0139] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0140] The electronic device also includes a communication interface 30 for communicating with other devices or communication networks.

[0141] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0142] This invention provides a computer program product, which includes computer instructions for causing a computer to execute the method of any embodiment of this invention.

[0143] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0144] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for generating test cases, characterized by, The method includes: Obtain the test requirements document for generating test cases, which are used to test the target test functions of the vehicle; A test development strategy is determined for the target test function. The test development strategy is used to indicate at least one test case design method for the test cases to be generated. The coverage dimension of the test development strategy is determined based on the risk score of the target test function. The risk score is used to characterize the risk level of the target test function under the target evaluation dimension. Based on the test development strategy and the test requirements document, determine multiple first test points for the test cases to be generated; Based on multiple first test points, generate multiple target test cases corresponding to the test requirement document.

2. The method of claim 1, wherein, The determination of the test development strategy corresponding to the target test function includes: Obtain at least one functional indicator corresponding to the target test function, wherein the at least one functional indicator includes one or more of the following: customer perceived frequency, usage frequency, complexity indicator, security correlation indicator, and quality indicator; The risk score of the target test function is determined based on each of the functional indicators and the weight value corresponding to each of the functional indicators; The test development strategy is determined based on the risk score and the first mapping relationship, wherein the first mapping relationship is the mapping relationship between the risk score and the test development strategy.

3. The method of claim 1, wherein, The step of determining multiple first test points for generating test cases based on the test development strategy and the test requirements document includes: Based on the test requirement document, the test requirement category of the test cases to be generated is determined as the target requirement category; Based on the test development strategy and the target requirement category, determine multiple first test points for the test cases to be generated.

4. The method of claim 3, wherein, The step of determining the test requirement category of the test cases to be generated as the target requirement category based on the test requirement document includes: The test requirement document is parsed to obtain feature information and multiple keywords. The feature information is used to indicate the features of the test requirement corresponding to the target test function. Detect whether the multiple keywords include at least one preset keyword, where the preset keyword is a keyword that matches the target demand category; If multiple keywords are detected to include at least one of the preset keywords, it is determined whether the feature information matches the category definition corresponding to the target demand category; If the feature information matches the category definition corresponding to the target requirement category, then the target requirement category is determined as the test requirement category of the test case to be generated.

5. The method of claim 3, wherein, The step of determining multiple first test points for the test cases to be generated based on the test development strategy and the target requirement category includes: Based on the target requirement category and the test requirement document, determine multiple target prompt words corresponding to the test cases to be generated. The target prompt words are used to indicate one or more of the generation conditions, test dimensions, and output formats of the test points to be generated. The first model is input with multiple target prompts, test point generation strategies, and test development strategies, and multiple first test points are output, wherein the test point generation strategies are matched with the target requirement categories.

6. The method according to claim 5, characterized in that, The step involves determining multiple target prompts corresponding to the test cases to be generated based on the target requirement category and the test requirement document, including: Based on the target demand category and the second mapping relationship, multiple initial prompt words are determined, where the second mapping relationship is the mapping relationship between the target demand category and the multiple initial prompt words. Based on the aforementioned test requirements document, multiple initial prompt words are expanded and enhanced to obtain multiple target prompt words.

7. The method according to claim 6, characterized in that, The method further includes: If the target test function is a changed function, then obtain the historical test requirement document and multiple historical test cases corresponding to the target test function, and each historical test case is generated based on a historical test point; Compare the test requirement document with the historical test requirement document to determine the requirements analysis results, which are used to indicate the change requirements for the target test function; Each of the historical test cases is analyzed and processed to obtain the writing strategy for each of the historical test cases; The test requirement document, the requirement analysis results, each historical test case and the corresponding writing strategy are input into the first model, and multiple second test points carrying change type labels are output. The change type labels are used to indicate the change type of each second test point. Based on multiple second test points, multiple target test cases corresponding to the test requirement document are generated.

8. The method according to claim 7, characterized in that, The step of generating target test cases corresponding to the test requirement document based on multiple second test points includes: Obtain at least one historical test case associated with the target test point, wherein the target test point is one of a plurality of second test points; If the change type label carried by the target test point is a modification type label, then based on the target test point, at least one of the historical test cases is modified, and at least one target test case associated with the target test point is determined. Alternatively, if the change type label carried by the target test point is a deletion type label, then at least one historical test case associated with the target test point is deleted. Alternatively, if the change type label carried by the target test point is of the same type, then at least one historical test case associated with the target test point is determined as at least one target test case associated with the target test point.

9. The method according to any one of claims 5-8, characterized in that, The method further includes: After generating multiple target test cases, the multiple target test cases are input into the second model, and the review results of the multiple target test cases are output. The second model has the function of reviewing each target test case. If the review results indicate that multiple target test cases meet the test requirement document, then multiple target test cases are output to the client; If the review result indicates that there is at least one abnormal test case, the first model is updated based on the review result to obtain an updated target model, which is used to generate the first test point or the second test point.

10. A test case generation apparatus, characterized in that, The test case generation device includes: The acquisition module is used to acquire the test requirement document of the test cases to be generated, which is used to test the target test functions of the vehicle. The processing module is used to determine the test development strategy corresponding to the target test function. The test development strategy is used to indicate at least one test case design method corresponding to the test cases to be generated. The coverage dimension of the test development strategy is determined based on the risk score of the target test function. The risk score is used to characterize the risk level of the target test function under the target evaluation dimension. According to the test development strategy and the test requirement document, multiple first test points of the test cases to be generated are determined. The generation module is used to generate multiple target test cases corresponding to the test requirement document based on multiple first test points.

11. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory storing computer instructions, and the processor executing the computer instructions to perform the test case generation method of any one of claims 1 to 9.

12. A vehicle, characterized in that, Including the electronic device as described in claim 11.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to execute the test case generation method according to any one of claims 1 to 9.

14. A computer program product, characterized in that, It includes computer instructions for causing a computer to execute the method for generating test cases according to any one of claims 1 to 9.

Images