Function requirement and test case mapping method and device, equipment and storage medium
By automatically matching test requirement identifiers with functional requirement identifiers, the problem of inefficient correspondence between functional requirements and test cases in autonomous vehicles is solved, efficient and accurate test case mapping is achieved, and coverage of each functional requirement is ensured.
Patent Information
- Application Number
- CN202510895204.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-30
- Publication Date
- 2025-10-14
AI Technical Summary
In existing technologies, the correspondence between the functional requirements of autonomous vehicles and test cases relies on manual operations, which is inefficient and prone to errors, and cannot ensure that each functional requirement has a corresponding test case.
Provided is a method and device for mapping functional requirements to test cases. By receiving batch uploaded test cases, code scripts are used to automatically match test requirement identifiers with functional requirement identifiers, and mandatory fields set by the system are shielded to achieve automatic correspondence between test cases and FRDs.
It achieves efficient and automatic correspondence between functional requirements and test cases, improves processing efficiency, avoids omissions in requirement coverage, ensures that each functional requirement has a corresponding test case, and reduces the time and errors of manual operations.
Smart Images
Figure CN120780602A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of autonomous vehicles, and in particular to a method and device for mapping functional requirements to test cases, a device, and a storage medium. BACKGROUND
[0002] In the development of autonomous vehicles, testing and verification is a very important step. Through testing, it can be verified whether the functions planned for the development of the autonomous driving system have been implemented, and whether the performance meets the requirements of the functional requirements document (FRD).
[0003] Among them, the FRD is a systematic document that defines the system functions, performance and acceptance criteria in the product development process. In particular, in the development of complex systems such as autonomous driving, the FRD is the core bridge connecting function design and testing and verification. In other words, the test cases and functional requirements are one by one corresponding, which plays an important role in the testing of autonomous driving systems.
[0004] In related technologies, the correspondence between test cases and functional requirements relies on manual operation. However, manual operation is not only time-consuming and laborious, but also inefficient and prone to errors, such as missing requirement coverage, which cannot ensure that each functional requirement in the FRD has a corresponding test case. SUMMARY
[0005] The embodiments of the present application provide a method and device for mapping functional requirements to test cases, a device, and a storage medium. The technical solution is as follows:
[0006] On the one hand, a method for mapping functional requirements to test cases is provided, which comprises:
[0007] Under a preset condition, a batch of uploaded test cases are received; wherein the test cases are used to test and verify the autonomous driving functions; the preset condition refers to the mandatory fields set by the system when the test cases are shielded; each test case received includes a test requirement identifier; different test cases correspond to different test requirement identifiers;
[0008] For each test case received, the test requirement identifier included in the test case is obtained, and a functional requirement identifier matching process is performed to obtain a functional requirement identifier matched with the test requirement identifier; wherein the functional requirement identifier is used to identify the functional requirement item in the FRD;
[0009] If the functional requirement identifier is included in the FRD, the correspondence between the functional requirement identifier and the test case is recorded.
[0010] In some embodiments, the batch uploaded test cases are written based on a general test case template; wherein the general test case template comprises a field for filling in the test requirement identifier.
[0011] In other embodiments, the execution of the function requirement identifier matching process to obtain the function requirement identifier matched with the test requirement identifier comprises:
[0012] According to a preset encoding conversion rule, converting the test requirement identifier from an initial encoding format to a target encoding format, and taking the obtained encoding result as the function requirement identifier matched with the test requirement identifier.
[0013] Wherein, the test requirement identifier corresponding to each received test case adopts the initial encoding format; and the function requirement identifier included in the FRD adopts the target encoding format.
[0014] In other embodiments, each received test case further comprises a function requirement identifier.
[0015] The obtaining of the test requirement identifier included in the test case comprises:
[0016] The obtaining of the test requirement identifier and the function requirement identifier included in the test case comprises:
[0017] The recording of the correspondence between the function requirement identifier and the test case comprises:
[0018] If the obtained function requirement identifier is included in the FRD, and the matched function requirement identifier is consistent with the obtained function requirement identifier, the correspondence between the function requirement identifier and the test case is recorded.
[0019] In other embodiments, the method further comprises:
[0020] If the obtained function requirement identifier is included in the FRD, but the matched function requirement identifier is inconsistent with the obtained function requirement identifier, an alarm prompt is outputted; or,
[0021] If the matched function requirement identifier is consistent with the obtained function requirement identifier, but the obtained function requirement identifier is not included in the FRD, an alarm prompt is outputted.
[0022] Wherein, the alarm prompt is used to prompt to modify the test case or synchronize the latest version of the FRD.
[0023] In other embodiments, the method further comprises:
[0024] output a requirement coverage report, the requirement coverage report including at least a total requirement number, a covered requirement number, and a requirement coverage rate;
[0025] The total requirement number refers to a total number of functional requirements included in the FRD. The covered requirement number refers to a number of functional requirements that have been associated with at least one test case. The requirement coverage rate is a ratio of the covered requirement number to the total requirement number.
[0026] In some embodiments, the requirement coverage report includes:
[0027] In the requirement coverage report, an un-covered requirement is highlighted, the un-covered requirement referring to a functional requirement in the FRD that has not been associated with a test case.
[0028] In another aspect, a functional requirement and test case mapping device is provided, the device including:
[0029] A receiving module configured to receive batch-uploaded test cases under a preset condition, the test cases being used to test and verify an automatic driving function, the preset condition referring to a mandatory field set by the system when the test case is shielded from being uploaded, each of the received test cases including a test requirement identifier, and different test cases corresponding to different test requirement identifiers.
[0030] An executing module configured to, for each of the received test cases, obtain a test requirement identifier included in the test case, and perform a functional requirement identifier matching process to obtain a functional requirement identifier matched with the test requirement identifier, the functional requirement identifier being used to identify a functional requirement item in an FRD.
[0031] A mapping module configured to, if the FRD includes the functional requirement identifier, record a correspondence between the functional requirement identifier and the test case.
[0032] In some embodiments, the batch-uploaded test cases are written based on a general test case template, the general test case template including a field used to fill in the test requirement identifier.
[0033] In another aspect, the executing module is configured to:
[0034] convert the test requirement identifier from an initial encoding format to a target encoding format according to a preset encoding conversion rule, and obtain an encoding result as the functional requirement identifier matched with the test requirement identifier.
[0035] The test requirement identifier in each received test case corresponds to the initial encoding format, and the functional requirement identifier included in the FRD corresponds to the target encoding format.
[0036] In some other embodiments, each received test case further includes a functional requirement identifier.
[0037] The execution module is configured to acquire the test requirement identifier and the functional requirement identifier included in the test case.
[0038] The execution module is configured to record the correspondence between the functional requirement identifier and the test case if the acquired functional requirement identifier is included in the FRD and the matched functional requirement identifier is consistent with the acquired functional requirement identifier.
[0039] In some other embodiments, the apparatus further includes:
[0040] The first output module is configured to output an alarm prompt if the acquired functional requirement identifier is included in the FRD but the matched functional requirement identifier is inconsistent with the acquired functional requirement identifier, or if the matched functional requirement identifier is consistent with the acquired functional requirement identifier but the acquired functional requirement identifier is not included in the FRD.
[0041] The alarm prompt is used to prompt modification of the test case or synchronization of the latest version of the FRD.
[0042] In some other embodiments, the apparatus further includes:
[0043] The second output module is configured to output a requirement coverage report, and the requirement coverage report at least includes total requirement number, covered requirement number, and requirement coverage rate.
[0044] The total requirement number refers to the total number of functional requirements included in the FRD, the covered requirement number refers to the number of functional requirements associated with at least one test case, and the requirement coverage rate is the ratio of the covered requirement number to the total requirement number.
[0045] In some other embodiments, the second output module is configured to:
[0046] The un-covered requirements in the requirement coverage report are highlighted, and the un-covered requirements refer to the functional requirements in the FRD that are not associated with test cases.
[0047] In another aspect, a computer device is provided, which includes a processor and a memory, the memory having stored therein at least one program code, the at least one program code being loaded and executed by the processor to implement the mapping method of functional requirements and test cases as described above.
[0048] In another aspect, a computer readable storage medium is provided, which has stored therein at least one program code, the at least one program code being loaded and executed by a processor to implement the mapping method of functional requirements and test cases as described above.
[0049] In another aspect, a computer program product or computer program is provided, which includes computer program code stored in a computer readable storage medium, the computer program code being read by a processor of a computer device from the computer readable storage medium, the processor executing the computer program code to cause the computer device to perform the mapping method of functional requirements and test cases as described above.
[0050] The embodiments of the present application realize automatic correspondence between functional requirements and test cases, without relying on manual operation. In detail, the scheme shields the mandatory fields set by the system when uploading test cases, so that batch uploading of test cases can be realized. For the batch uploaded test cases, after obtaining the test requirement number included in each test case, the scheme can automatically perform the requirement ID matching process, i.e., complete the correspondence between the test requirement number and the requirement ID, and automatically record the correspondence between the requirement ID and the test case. This automatic correspondence method not only saves time and effort and is efficient, but also does not have the problem of missing requirement coverage, and can ensure that each functional requirement in the FRD has a corresponding test case. BRIEF DESCRIPTION OF DRAWINGS
[0051] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.
[0052] Figure 1 is a structural schematic diagram of a test case coverage system based on FRD provided by the embodiments of the present application;
[0053] Figure 2 is a complete link schematic diagram for correspondence between test cases and requirement IDs provided by the embodiments of the present application;
[0054] Figure 3 is a mapping method flowchart of functional requirements and test cases provided by the embodiments of the present application;
[0055] Figure 4 is a structural schematic diagram of a functional requirement and test case mapping device provided by an embodiment of the present application;
[0056] Figure 5 is a structural schematic diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION
[0057] In order to make the purpose, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.
[0058] The terms "first", "second", and the like are used herein to distinguish between elements having substantially the same functions and the same types, and it should be understood that there is no logical or time sequence dependency between "first", "second", and "n", and the number and execution order are not limited. It should also be understood that although the following description uses the terms first, second, and the like to describe various elements, these elements should not be limited by the terms.
[0059] These terms are only used to distinguish one element from another. For example, without departing from the scope of various examples, a first element can be referred to as a second element, and similarly, a second element can also be referred to as a first element. The first element and the second element can both be elements, and in some cases, can be separate and distinct elements.
[0060] Among them, at least one refers to one or more, for example, at least one element can be one element, two elements, three elements, etc. any integer greater than or equal to one element. And multiple refers to two or more, for example, multiple elements can be two elements, three elements, etc. any integer greater than or equal to two elements.
[0061] In this paper, "and / or" means that there can be three relationships, for example, A and / or B, which can mean: A exists alone, A and B exist together, and B exists alone. The character " / " generally represents an "or" relationship between the objects before and after it.
[0062] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data for analysis, stored data, displayed data, etc.) and signals involved in the present application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards in relevant regions.
[0063] As described in the background, the correspondence between the test cases and the functional requirements at present relies on manual operation. The complete operation link is: test case starts uploading → manual filling of the required fields for each test case → test case completes uploading. Among them, "manual filling of the required fields for each test case" means that the tester needs to manually fill in the required fields (such as the requirement ID field) set by the test management system when uploading the test case.
[0064] However, manually completing the correspondence between the test cases and the functional requirements in the FRD has defects such as low efficiency and easy to make mistakes. For example, the tester needs to manually enter the test cases into the system one by one, which is very time-consuming. In addition, as the complexity of the requirements of the FRD increases (such as the automatic driving system needs to cover thousands of functions), manual operation cannot meet the large-scale testing requirements. For another example, manual operation may also miss some test cases corresponding to the functional requirements, and it is difficult to quickly verify whether each functional requirement has a corresponding test case coverage. In addition, manual input is prone to errors (such as inputting the requirement ID incorrectly), which will cause the test to be out of sync with the requirements.
[0065] In view of the above problems, the embodiment of the present application provides a test case coverage system based on FRD, which can automatically complete the quick correspondence between the functional requirements and the test cases. The following will be described in detail through the following implementation manner.
[0066] Figure 1 It is a structure schematic diagram of a test case coverage system based on FRD provided by the embodiment of the present application. Referring to Figure 1 The test case coverage system includes: an FRD storage module 11, a test case uploading module 12, and a code script 13 in the code cabin.
[0067] Among them, the FRD management system is used to manage the creation, approval, version control, etc. of the functional requirement specification, and the test case coverage system is used to automatically correspond the test case and the functional requirement, and to count the coverage of the test case to the functional requirement. Generally, the FRD management system and the test case coverage system are independent systems, and the data synchronization is completed through the data interaction interface. For example, the test case coverage system obtains the requirement list from the FRD management system through the data interaction interface, and stores it in the FRD storage module 11.
[0068] In addition, the tester can realize batch uploading of test cases through the test case uploading module 11. Among them, the uploaded test cases are written based on the general test case template. And the general test case template adds a key field for filling in "test requirement number". In addition, the function of the code script 13 will be described later.
[0069] Figure 2is a complete link diagram provided by the embodiment of the application for testing the correspondence between the test case and the requirement ID. Referring to Figure 2 The link includes the following steps:
[0070] A key field for filling in the "test requirement number" is added in the general test case template, which is a mandatory field set by the system when uploading the test case, and is a mandatory field for batch uploading the test case, and a code script is executed (reading, corresponding, and connecting), and the test case is matched with the functional requirement specification in the FRD.
[0071] The mandatory field set by the system when uploading the test case (here, all mandatory fields) is shielded, so as to remove the step of manually filling in the mandatory field, and a basic condition for batch uploading the test case is realized.
[0072] In addition, the general test case template is used for writing the test case. The general test case template can include fields for filling in the function, test category, test scene description, or pass index. In addition, the general test case template further includes a key field for filling in the "test requirement number". After batch uploading the test case, the test requirement number is a prerequisite for matching the test case with the functional requirement in the FRD.
[0073] Finally, another prerequisite for matching the test case with the functional requirement in the FRD is the coding and corresponding of the test requirement number. In the embodiment of the application, a code script written by the user is added in the code cabin, the key field "test requirement number" in the test case is automatically read, coded, and matched with the functional requirement in the FRD, so as to efficiently complete the correspondence between the functional requirement and the test case after batch uploading the test case, and the processing efficiency is improved.
[0074] For example, for the original operation link, 500 test cases are taken as an example, and the requirement ID is manually matched for each test case. On average, it takes 2 minutes to match each test case, so it takes 1000 minutes to complete the matching of 500 test cases. However, by using the operation link shown in Figure 2 , the 500 test cases can be batch uploaded in 1 minute, and the automatic correspondence between the test case and the requirement ID can be completed in 1 minute. The efficiency is improved by 99.8%. And it can ensure that the test case and the functional requirement are 100% matched, and avoid the coverage omission problem existing in manual matching.
[0075] The automatic correspondence process between the requirement ID and the test case will be introduced below in combination with Figure 1 and Figure 2 .
[0076] Figure 3is a flowchart of a method for mapping a functional requirement and a test case according to an embodiment of the present application. The execution subject of the method is a computer device, such as a test case coverage system based on FRD installed on the computer device. Referring to Figure 3 The method flow includes the following steps:
[0077] 301. Under a preset condition, the computer device receives batch uploaded test cases; wherein the test cases are used to test and verify the autonomous driving function; the preset condition refers to the mandatory fields set by the system when the test cases are shielded from uploading; each test case received includes a test requirement identifier.
[0078] The first point to be explained is that the test requirement identifier is also referred to as the test requirement number in this article, and the functional requirement identifier is also referred to as the functional requirement ID or simply the requirement ID. The requirement ID is used to identify the functional requirement item in the FRD. The FRD is a systematic document that defines the system function, performance and acceptance criteria in the product development process, especially in the development of complex systems such as autonomous driving, the FRD is the core bridge connecting functional design and test verification.
[0079] Exemplarily, in the field of autonomous driving, the FRD usually contains the following contents:
[0080] Functional module definition: clearly define the functional modules of the autonomous driving system (such as perception, decision, control, etc.), and refine to sub-functions (such as obstacle detection, path planning, vehicle dynamics control).
[0081] Functional requirement description: such as defining each function in the form of requirement ID + specific behavior.
[0082] Performance index: quantifying the functional requirements, such as response time, accuracy, robustness, etc.
[0083] Acceptance criteria: define the conditions for the function to pass the test.
[0084] Non-functional requirements: such as system safety, real-time performance, etc.
[0085] Those skilled in the art can know that in addition to the above contents, the FRD can also include more contents, which are not limited in the present application.
[0086] In the embodiments of the present application, the prerequisite for being able to realize batch uploading of test cases is that the mandatory fields set by the system when the test cases are shielded from uploading. After removing this manual operation step, a basic condition is created for realizing batch uploading of test cases, so that the test cases can be batch uploaded without the need for manual processing and filling work related to the mandatory fields.
[0087] In addition, the test cases uploaded in batches are written based on a general test case template. The general test case template includes a field for filling in a test requirement identifier. The purpose of adding this field is to align the test case with the functional requirement in the FRD through the test requirement identifier after the test case is uploaded in batches. That is, the test case and the functional requirement can be associated through the test requirement identifier.
[0088] Of course, in addition to the test requirement identifier, the general test case template can also include fields for filling in functions, test categories, test scene descriptions, or pass indexes, and the present application does not limit this.
[0089] The second point to be explained is that different test cases correspond to different test requirement identifiers. One requirement ID can correspond to multiple test requirement IDs. This is because one functional requirement can be decomposed into multiple sub-functional requirements, and a test case needs to be designed for each sub-functional requirement.
[0090] 302 For each received test case, the computer device obtains the test requirement identifier included in the test case, and performs a functional requirement identifier matching process to obtain a functional requirement identifier matched with the test requirement identifier included in the test case.
[0091] In the embodiment of the present application, the test case coverage system reads the test requirement identifier included in each test case by executing the code script in the code cabin, and automatically performs the requirement ID matching process. In other words, this code script has the function of automatically reading the test requirement number in the test case, then encoding the read test requirement number, and automatically matching the requirement number in the FRD, thereby forming a one-to-one logical relationship.
[0092] As an example, performing the functional requirement identifier matching process to obtain the functional requirement identifier matched with the test requirement identifier includes, but is not limited to, using the following encoding rule conversion matching:
[0093] According to the preset encoding conversion rule, the test requirement identifier is converted from the initial encoding format to the target encoding format, and the obtained encoding result is taken as the functional requirement identifier matched with the test requirement identifier.
[0094] Among them, the test requirement identifier corresponding to each received test case adopts the initial encoding format; the functional requirement identifier included in the FRD adopts the target encoding format.
[0095] That is, the encoding conversion rule is defined in the code script, and since the test requirement identifier is encoded based on the first encoding rule and has the initial encoding format, the test requirement identifier can be converted into the same encoding format as the function requirement identifier, i.e., the target encoding format, based on the encoding conversion rule. The function requirement identifier has the target encoding format after being encoded based on the second encoding rule. The first encoding rule and the second encoding rule are different encoding rules.
[0096] 303. If the matched function requirement identifier is included in the FRD, a correspondence between the matched function requirement identifier and the test case is recorded.
[0097] In the embodiment of the present application, after the requirement ID is matched, validity verification is further needed, i.e., whether the matched requirement ID exists in the FRD is verified. If the matched requirement ID exists in the FRD, a correspondence between the matched requirement ID and the test case is recorded, and thus the matching between the test case and the requirement ID is completed. The above steps 302-303 are executed for each uploaded test case, and thus the automatic correspondence between the batch-uploaded test cases and the requirement IDs in the FRD is completed.
[0098] It should be noted that if the matching between the test requirement identifier and the requirement ID adopts the encoding rule conversion matching, the batch-uploaded test cases can include the requirement ID or can not include the requirement ID, which is not limited in the present application. In the case that the test case includes both the test requirement identifier and the requirement ID, the automatic correspondence between the test case and the requirement ID is usually still needed, and the reason is as follows: the logic relationship between the read test requirement number and the requirement ID is verified to be correct through the execution of the automatic correspondence process, in other words, whether the test requirement number corresponds to the correct requirement ID is verified through the automatic correspondence.
[0099] Suppose that each received test case further includes a requirement ID, and the "obtaining the test requirement identifier included in the test case" in step 302 refers to obtaining the test requirement identifier and the requirement ID included in the test case. In this case, if the requirement ID obtained in the test case is included in the FRD, and the requirement ID matched through step 302 is consistent with the requirement ID obtained in the test case, a correspondence between this requirement ID and the test case can be recorded.
[0100] In addition, if the requirement ID obtained in the test case is included in the FRD, but the requirement ID matched through step 302 is not consistent with the requirement ID, the test case coverage system outputs an alarm prompt. Or, if the matched requirement ID is consistent with the obtained requirement ID, but the requirement ID is not included in the FRD, the test case coverage system also outputs an alarm prompt.
[0101] The outputted alarm prompt is used to prompt to modify the test case or synchronize the latest version of the FRD. Because the above-mentioned situation may be that the requirement ID or the test requirement identifier is filled in error when the test case is manually written, or the requirement change of the FRD is not synchronized to the FRD storage module.
[0102] As an example, the test case coverage system also outputs a requirement coverage report. The requirement coverage report at least includes total requirement number, covered requirement number and requirement coverage rate. The total requirement number refers to the total number of functional requirements included in the FRD; the covered requirement number refers to the number of functional requirements associated with at least one test case; and the requirement coverage rate is the ratio of the covered requirement number to the total requirement number.
[0103] In addition, in order to facilitate the test personnel to check the uncovered requirements and perfect the coverage state, the test case coverage system can highlight the uncovered requirements in the requirement coverage report. The uncovered requirements refer to the functional requirements in the FRD that are not associated with the test cases.
[0104] In summary, the embodiment of the application realizes the automatic correspondence between the functional requirements and the test cases without relying on manual operation. In detail, the scheme shields the mandatory fields set by the system when uploading the test cases, so that batch uploading of the test cases can be realized. For the batch uploaded test cases, after the test requirement number included in each test case is obtained, the requirement ID matching process can be automatically executed, that is, the correspondence between the test requirement number and the requirement ID is completed, and the correspondence between the requirement ID and the test case is automatically recorded. This automatic correspondence method not only saves time and effort and is efficient, but also does not have the problem of missing requirement coverage, and can ensure that each functional requirement in the FRD has a corresponding test case.
[0105] In addition, the automatic correspondence is helpful for more accurate data analysis and report generation. By accurately corresponding the test cases and the requirement IDs, the coverage of each functional requirement, the test results and other information can be clearly understood. For example, a detailed report about which requirements have passed the test and which requirements still have problems can be quickly generated, helping the test personnel to timely find risks and problems and make reasonable decisions.
[0106] Figure 4 FIG. 1 is a structural schematic diagram of a functional requirement and test case mapping device provided by an embodiment of the application. Referring to FIG. 1, Figure 4 The device includes:
[0107] The receiving module 401 is configured to receive the batch uploaded test cases under a preset condition; wherein the test cases are used for testing and verifying the automatic driving function; the preset condition refers to the mandatory fields set by the system when the test cases are shielded and uploaded; each received test case includes a test requirement identifier; different test cases correspond to different test requirement identifiers;
[0108] The executing module 402 is configured to, for each received test case, acquire the test requirement identifier included in the test case, and perform a function requirement identifier matching process to obtain a function requirement identifier matched with the test requirement identifier; wherein the function requirement identifier is used for identifying the function requirement item in the FRD;
[0109] The mapping module 403 is configured to, if the function requirement identifier is included in the FRD, record the correspondence between the function requirement identifier and the test case.
[0110] The embodiment of the application realizes the automatic correspondence between the function requirement and the test case without relying on manual operation. In detail, the scheme shields the mandatory fields set by the system when the test cases are uploaded, so that the batch uploading of the test cases can be realized. For the batch uploaded test cases, after acquiring the test requirement number included in each test case, the scheme can automatically perform the requirement ID matching process, that is, complete the correspondence between the test requirement number and the requirement ID, and automatically record the correspondence between the requirement ID and the test case. This automatic correspondence method not only saves time and effort and is efficient, but also does not have the problem of missing requirement coverage, and can ensure that each function requirement in the FRD has a corresponding test case.
[0111] In some embodiments, the batch uploaded test cases are written based on a general test case template; wherein the general test case template includes a field for filling in the test requirement identifier.
[0112] In other embodiments, the executing module is configured to:
[0113] According to a preset encoding conversion rule, convert the test requirement identifier from an initial encoding format to a target encoding format, and take the obtained encoding result as the function requirement identifier matched with the test requirement identifier;
[0114] In the embodiment, the test requirement identifier corresponding to each received test case adopts the initial encoding format; and the function requirement identifier included in the FRD adopts the target encoding format.
[0115] In other embodiments, each received test case further includes a function requirement identifier;
[0116] The execution module is configured to acquire the test requirement identifier and the function requirement identifier included in the test case;
[0117] The execution module is configured to record a corresponding relationship between the function requirement identifier and the test case if the acquired function requirement identifier is included in the FRD and the matched function requirement identifier is consistent with the acquired function requirement identifier.
[0118] In some other embodiments, the apparatus further comprises:
[0119] The first output module is configured to output an alarm prompt if the acquired function requirement identifier is included in the FRD but the matched function requirement identifier is not consistent with the acquired function requirement identifier, or if the matched function requirement identifier is consistent with the acquired function requirement identifier but the acquired function requirement identifier is not included in the FRD.
[0120] The alarm prompt is used to prompt modification of the test case or synchronization of the latest version of the FRD.
[0121] In some other embodiments, the apparatus further comprises:
[0122] The second output module is configured to output a requirement coverage report, wherein the requirement coverage report at least includes total requirement number, covered requirement number, and requirement coverage rate.
[0123] The total requirement number refers to the total number of function requirements included in the FRD, the covered requirement number refers to the number of function requirements associated with at least one test case, and the requirement coverage rate is the ratio of the covered requirement number to the total requirement number.
[0124] In some other embodiments, the second output module is configured to:
[0125] The requirement coverage report highlights an uncovered requirement, which refers to a function requirement in the FRD that is not associated with a test case.
[0126] All the optional technical solutions described above can be combined to form optional embodiments of the present application, which will not be described again.
[0127] It should be noted that the mapping device for the functional requirement and the test case provided in the above embodiment only takes the division of the above functional modules as an example when mapping the functional requirement and the test case. In actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the mapping device for the functional requirement and the test case provided in the above embodiment and the mapping method for the functional requirement and the test case belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.
[0128] Figure 5 Fig. 1 is a structural schematic diagram of a computer device 500 provided by an embodiment of the present application.
[0129] Generally, the computer device 500 includes a processor 501 and a memory 502.
[0130] The processor 501 includes one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 501 is implemented in at least one hardware form of a DSP (Digital Signal Processing), an FPGA (Field-Programmable Gate Array), and a PLA (Programmable Logic Array). Alternatively, the processor 501 includes a main processor and a coprocessor. The main processor is a processor for processing data in a wake-up state, also known as a CPU (Central Processing Unit). The coprocessor is a low-power processor for processing data in a standby state.
[0131] In a possible implementation, the processor 501 is integrated with a GPU (Graphics Processing Unit) that is responsible for rendering and drawing the content required to be displayed by the display screen.
[0132] In a possible implementation, the processor 501 further includes an AI (Artificial Intelligence) processor that is used for processing machine learning-related computing operations.
[0133] The memory 502 includes one or more computer-readable storage media that are non-transitory. The memory 502 further includes a high-speed random access memory and a non-volatile memory such as one or more disk storage devices, flash storage devices.
[0134] In a possible implementation, the non-transitory computer-readable storage medium in the memory 502 is configured to store at least one program code for being executed by the processor 501 to implement the mapping method of the functional requirements and the test cases provided in the embodiments of the present application.
[0135] In a possible implementation, the computer device 500 further includes a peripheral device interface 503 and at least one peripheral device. The processor 501, the memory 502, and the peripheral device interface 503 are connected through a bus or a signal line. Each peripheral device is connected to the peripheral device interface 503 through a bus, a signal line, or a circuit board. The peripheral devices include a display screen 504 and a power supply 505.
[0136] The peripheral device interface 503 is configured to connect at least one peripheral device related to I / O (Input / Output) to the processor 501 and the memory 502. In a possible implementation, the processor 501, the memory 502, and the peripheral device interface 503 are integrated on the same chip or circuit board. In another possible implementation, any one or two of the processor 501, the memory 502, and the peripheral device interface 503 are implemented on a separate chip or circuit board, which is not limited in the present application.
[0137] The display screen 504 is configured to display a UI (User Interface). The UI includes graphics, text, icons, video, and any combination thereof. The display screen 504 is made of materials such as LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), and the like.
[0138] The power supply 505 is configured to supply power to each component in the computer device 500. The power supply 505 is an alternating current, a direct current, a disposable battery, or a rechargeable battery. In the case where the power supply 505 includes a rechargeable battery, the rechargeable battery is a wired charging battery or a wireless charging battery. The wired charging battery is a battery charged through a wired line, and the wireless charging battery is a battery charged through a wireless coil. The rechargeable battery is also configured to support fast charging technology.
[0139] Those skilled in the art can understand that, Figure 5 The structure shown in the figures does not constitute a limitation on the computer device 500, and can include more or fewer components than those shown in the figures, or combine certain components, or adopt a different arrangement of components.
[0140] In the example embodiment, a computer readable storage medium, such as a memory including program code executable by a processor in a computer device to perform the mapping method of functional requirements and test cases, is also provided. For example, the computer readable storage medium can be a Read-Only Memory (ROM), a Random Access Memory (RAM), a Compact Disc Read-Only Memory (CD-ROM), a magnetic tape, a floppy disk, an optical data storage device, etc.
[0141] In the example embodiment, a computer program product or computer program including computer program code stored in a computer readable storage medium is also provided, the computer program code being readable by a processor in a computer device from the computer readable storage medium, the processor executing the computer program code to cause the computer device to perform the mapping method of functional requirements and test cases.
[0142] Those of ordinary skill in the art can understand that all or part of the steps of the above-mentioned embodiments can be completed by hardware, or by a program instructing relevant hardware, and the program can be stored in a computer readable storage medium, such as a Read-Only Memory (ROM), a magnetic disk or an optical disk, etc.
[0143] The above description is merely optional embodiments of the present application and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims
1. A method for mapping functional requirements to test cases, characterized in that: The method comprises: Receive batches of uploaded test cases under preset conditions; wherein the test cases are used to test and verify the autonomous driving function; the preset conditions refer to the blocking of mandatory fields set by the system when uploading test cases; each received test case includes a test requirement identifier; different test cases correspond to different test requirement identifiers; For each test case received, obtain the test requirement identifier included in the test case, and perform a functional requirement identifier matching process to obtain a functional requirement identifier that matches the test requirement identifier; wherein the functional requirement identifier is used to identify the functional requirement item in the functional requirement document (FRD); If the FRD includes the functional requirement identifier, the corresponding relationship between the functional requirement identifier and the test case is recorded.
2. The method according to claim 1, characterized in that The test cases uploaded in batches are written based on a general test case template; The general test case template includes a field for filling in the test requirement identifier.
3. The method according to claim 1, characterized in that The performing of the function requirement identifier matching process to obtain a function requirement identifier that matches the test requirement identifier includes: According to a preset encoding conversion rule, the test requirement identifier is converted from an initial encoding format to a target encoding format, and the obtained encoding result is used as a functional requirement identifier that matches the test requirement identifier; The test requirement identifier corresponding to each received test case adopts the initial coding format; and the function requirement identifier included in the FRD adopts the target coding format.
4. The method according to claim 1, wherein Each test case received also includes a functional requirement identifier; The obtaining of the test requirement identifier included in the test case includes: Obtaining the test requirement identifier and the functional requirement identifier included in the test case; The recording of the correspondence between the functional requirement identifier and the test case includes: If the FRD includes the acquired functional requirement identifier, and the matched functional requirement identifier is consistent with the acquired functional requirement identifier, the corresponding relationship between the functional requirement identifier and the test case is recorded.
5. The method according to claim 4, characterized in that The method further comprises: If the FRD includes the acquired functional requirement identifier, but the matched functional requirement identifier is inconsistent with the acquired functional requirement identifier, output an alarm prompt; or, If the matched functional requirement identifier is consistent with the obtained functional requirement identifier, but the obtained functional requirement identifier is not included in the FRD, an alarm prompt is output; The warning prompt is used to prompt modification of the test case or synchronization of the latest version of the FRD.
6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Output a demand coverage report, wherein the demand coverage report includes at least the total number of demands, the number of covered demands, and the demand coverage rate; Among them, the total number of requirements refers to the total number of functional requirements included in the FRD; the covered requirement data refers to the number of functional requirements associated with at least one test case; and the requirement coverage rate is the ratio of the number of covered requirements to the total number of requirements.
7. The method according to claim 6, characterized in that The output requirements coverage report includes: Uncovered requirements are highlighted in the requirement coverage report, where the uncovered requirements refer to functional requirements that are not associated with test cases in the FRD.
8. A mapping device for functional requirements and test cases, characterized in that: The device comprises: a receiving module configured to receive batch uploaded test cases under preset conditions; wherein the test cases are used to test and verify the autonomous driving function; the preset conditions refer to the blocking of required fields set by the system when uploading test cases; each received test case includes a test requirement identifier; different test cases correspond to different test requirement identifiers; an execution module configured to, for each received test case, obtain a test requirement identifier included in the test case and perform a functional requirement identifier matching process to obtain a functional requirement identifier that matches the test requirement identifier; wherein the functional requirement identifier is used to identify a functional requirement item in a functional requirement document (FRD); The mapping module is configured to record the corresponding relationship between the functional requirement identifier and the test case if the FRD includes the functional requirement identifier.
9. A computer device, characterized in that: The device includes a processor and a memory, wherein at least one program code is stored in the memory, and the at least one program code is loaded and executed by the processor to implement the mapping method between functional requirements and test cases as claimed in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that The storage medium stores at least one program code, and the at least one program code is loaded and executed by a processor to implement the method for mapping functional requirements and test cases according to any one of claims 1 to 7.