WO2023103640A1

WO2023103640A1 - Method and apparatus for generating test case, and electronic device and storage medium

Info

Publication number: WO2023103640A1
Application number: PCT/CN2022/128119
Authority: WO
Inventors: 陈惠娟
Original assignee: 中兴通讯股份有限公司
Priority date: 2021-12-08
Filing date: 2022-10-28
Publication date: 2023-06-15
Also published as: CN116302902A

Abstract

Disclosed in the present application are a method and apparatus for generating a test case, and an electronic device and a storage medium. The method comprises: acquiring standardized input and output data of each software entity of a product to be tested, and then using the standardized input and output data as product standard data; determining characteristics of said product according to functions of said product and values of the functions of said product to a user, wherein the characteristics represent the functions and values of the product; and for each characteristic, acquiring each sub-function for realizing the characteristic, and respectively generating a test case for each sub-function, wherein both the sub-function and the test case of the sub-function are described by the product standard data.

Description

Test case generation method, device, electronic device and storage medium

related application

This application claims the priority of the Chinese patent application with application number 202111493037.9 filed on December 08, 2021, the entire contents of which are incorporated in this application by reference.

technical field

The embodiments of the present application relate to the field of software testing, and in particular to a method, device, electronic device and storage medium for generating test cases.

Background technique

With the continuous development and evolution of communication technology, the complexity and quality requirements of current software systems are continuously increasing, especially for large-scale wireless communication system software, this change is more obvious. In this context, as an important means of discovering software faults and evaluating and improving software quality, testing itself has become more and more important in terms of quality and efficiency. Test design is an important part of the test work. The test plan and test cases output in this link determine the direction and content of test execution. The completeness and redundancy of test plans and test cases directly determine the quality and efficiency of test work.

In the field of testing, there is a general consensus on what test cases test: the content that test cases need to cover needs to come from at least two aspects: requirement specification and code implementation. If the test cases only focus on the software code, identify test points and design use cases based on the code, it is difficult to find behaviors that have been specified but not implemented by the software, and 100% code test coverage cannot guarantee the usability of the software. On the contrary, if the test cases only focus on the requirement specifications, identify test points and design use cases based on the requirements, it is difficult to find behaviors that are not specified in the requirements but implemented by the software (for example, Trojan horse virus), and there may be serious redundancy among test cases.

In traditional testing, the completeness and redundancy of test cases are generally measured by statistical code coverage after the test cases are executed, and then corrected by updating the test cases. Common code coverage includes: line coverage, branch coverage, condition coverage, path coverage, etc. However, this method can only judge the completeness and redundancy of test cases from the perspective of code, and cannot measure the completeness and redundancy of test cases from the perspective of requirements specification, especially for large-scale wireless communication systems, which have a large number of industry protocols specification, this measure is less effective, which in turn leads to less validity of the final generated test cases.

Contents of the invention

The main purpose of the embodiment of the present application is to propose a test case generation method, device, electronic equipment and storage medium, aiming to measure the completeness and redundancy of the test case from the two perspectives of code implementation and requirement specification, Improve the effectiveness of test cases.

In order to achieve the above purpose, the embodiment of the present application provides a method for generating test cases, including: obtaining the standardized input and output data of each software entity of the product to be tested as product standard data; Value, to determine the characteristics of the product to be tested, the characteristics represent the product function and value; for each characteristic, obtain the sub-functions used to realize the characteristics, and generate test cases for each sub-function; among them, the sub-functions and sub-functions Test cases are described by product standard data.

In order to achieve the above purpose, the embodiment of the present application also proposes a test case generation device, including: an acquisition module for acquiring standardized input and output data of each software entity of the product to be tested as product standard data; a determination module for According to the function of the product to be tested and the value of the function to the user, determine the characteristics of the product to be tested, and the characteristics represent the product function and value; the generation module is used to obtain the sub-functions used to realize the characteristics for each characteristic, and for each characteristic Test cases are generated for each sub-function; among them, the sub-functions and the test cases of sub-functions are described by product standard data.

To achieve the above purpose, an embodiment of the present application also proposes an electronic device, the device includes: at least one processor; and a memory connected to the at least one processor in communication; wherein, the memory stores information that can be executed by the at least one processor. Instructions, the instructions are executed by at least one processor, so that the at least one processor can execute the method for generating test cases as described above.

To achieve the above purpose, the embodiment of the present application also proposes a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the method for generating test cases as described above is implemented.

The test case generation method provided by the embodiment of the present application, before generating the test case, according to the standardized input and output data of each software entity of the product to be tested, a product standard data set is generated, and when the test case is generated, according to the function of the product to be tested and the value of the function to the user, determine all the features contained in the product to be tested, and then determine the sub-functions that need to be used when each feature is realized, use the pre-generated product standard data to describe each sub-function, and provide automatic Can generate test cases described by product standard data. The test case is generated by the product standard data generated according to the standardized input and output data of each software entity of the product under test, so that the generated test case and the function of the product under test are mapped and linked; Generate multiple features of the product to be tested, and obtain the sub-functions needed for each feature, and generate test cases for the sub-functions, so that the completeness of the test cases' coverage of the expected content of the requirements can be measured, and then it can be realized from the code and the requirements. Standardize two angles to measure the completeness and redundancy of test cases, and improve the effectiveness of the final generated test cases.

Description of drawings

One or more embodiments are exemplified by pictures in the accompanying drawings, and these exemplifications are not intended to limit the embodiments.

Fig. 1 is the generation method flowchart of the test case in the embodiment of the present application;

Fig. 2 is a schematic diagram of the product standard data generation process in the embodiment of the present application;

FIG. 3 is a schematic diagram of timing interaction of DRX characteristics in an embodiment of the present application;

Fig. 4 is a schematic diagram of the sub-function splitting of the characteristics in the embodiment of the present application;

5 is a schematic structural diagram of a test case generation device in another embodiment of the present application;

Fig. 6 is a schematic structural diagram of an electronic device in another embodiment of the present application.

Detailed ways

It can be seen from the background technology that the traditional test methods and test case generation methods can only judge the completeness and redundancy of test cases from the perspective of code, and cannot measure the completeness and redundancy of test cases from the perspective of requirements specifications. The generated test cases and measurement The method is less effective. Therefore, how to establish test cases that can measure completeness and redundancy from the perspective of code and requirement specification is an urgent problem that needs to be solved.

In order to solve the above problems, the embodiment of the present application provides a method for generating test cases, including: obtaining the standardized input and output data of each software entity of the product to be tested as product standard data; The value of each feature of the product to be tested is determined, and the feature represents the function and value of the product; for each feature, each sub-function used to implement the feature is obtained, and test cases are generated for each sub-function; among them, sub-functions and sub-functions All test cases are described by product standard data.

In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below with reference to the accompanying drawings. However, those of ordinary skill in the art can understand that in each embodiment of the application, many technical details are provided for readers to better understand the application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical solutions claimed in this application can also be realized. The division of the following embodiments is for the convenience of description, and should not constitute any limitation to the specific implementation of the present application, and the embodiments can be combined and referred to each other on the premise of no contradiction.

The implementation details of the method for generating test cases recorded in this application will be described in detail below in conjunction with specific embodiments. The following content is only the implementation details provided for easy understanding, and is not necessary for implementing this solution.

The first aspect of the embodiment of the present application provides a method for generating test cases. Refer to FIG. 1 for the specific flow of the method for generating test cases. In some embodiments, the method for generating test cases is applied to a terminal device with analysis capabilities. Such as computers, tablets, mobile phones and other electronic devices, this embodiment takes the application in computers as an example for illustration, and the method for generating test cases includes at least but not limited to the following steps:

Step 101, acquire standardized input and output data of each software entity of the product to be tested as product standard data.

Specifically, when the computer generates the test cases of the product to be tested, it first obtains the software entities contained in the product to be tested, and then uses the standardized input and output data of each software entity of the product to be tested as the product standard data describing the test case.

In one example, the computer obtains standardized input and output data of each software entity of the product to be tested as product standard data, including: decomposing the implementation architecture of the product to be tested as a software entity; Input and output data, the standardized input and output data of each software entity is extracted from the software product version package; wherein, each software entity obtained after decomposition includes one of the following or any combination thereof: system, subsystem, module, and submodule. Specifically, when the computer acquires product standard data, it needs to obtain the overall structure and level of the realization function of the product under test, and decompose the realization structure of the product under test into structured and hierarchical software entities to obtain software entities of various granularities. . By decomposing software entities according to the product architecture, and obtaining product standard data according to the input and output data of each software entity interacting with the outside world, the product standard data can support the requirements of generating test cases for each sub-function, and it is convenient to meet the demand expectations through the generated test cases. Content coverage completeness is measured.

For example, the specific flow diagram of computer-generated product standard data can be referred to Figure 2. First, according to the overall structure of the product to be tested, the product to be tested is split into several subsystems. For example, if the product to be tested is a communication product, it can be split into Configuration management, control plane, user plane, wireless scheduling, platform and other subsystems. Then each subsystem is further split to obtain several modules of each subsystem (for example, the control plane subsystem in a communication product is further split into modules such as cell management, physical resource allocation, process management, etc.), and the communication product to be tested is obtained Software entities at different granularities. For each software entity, because it has to interact with the peripheral environment, there must be rules such as protocols, interfaces, and constraints for interacting with the peripheral environment. The computer sorts out the content and rules of the interaction between each software entity and the peripheral environment. According to the sorted out rules, The standardized input and output data of each software entity is extracted from the software product version package as product standard data.

Further, the computer extracts the standardized input and output data of each software entity from the software product version package, including: extracting the standardized input and output data of each software entity from the software product version package according to the category of the input and output data interacting with the outside; Wherein, the categories include one or any combination of the following: configuration parameters, key indicators, abnormal alarms, protocol cells, and software interfaces. Specifically, when the computer extracts the standardized input and output data of each software entity, it classifies the product standard data that needs to be extracted, which can be divided into configuration parameters, key indicators, and abnormal alarms according to the purpose and implementation management methods in software products. , protocol cells, software interfaces and other categories. For each type of standardized data, extract its extraction rules from the software product version package, sort out its value range, value rules, default values, units, and its attributes such as the measured object according to specific rules, and then sort out according to specific rules Automatically extract and store the standardized data and their attributes to form a standardized input and output data collection of the requirements specification expectations of each software entity.

For example, for communication system products, the main product standard data that can be extracted include: configuration parameters, protocol cells, software interfaces, test logs, counters, key indicators, alarms, etc. For each type of product standard data, the respective data attributes are sorted out, and the storage format of each type of data is determined in combination with the attributes. For example, the data attributes of key indicators include: indicator number, indicator name, measurement type, indicator meaning, calculation formula, unit, etc. For each type of product standard data and its attributes, extract rules that are automatically extracted from version packages and code bases. Complete the automatic extraction of these standardized data and their attributes in the version data package according to specific rules, and then complete the storage according to the storage address of this type of data, forming a standard input and output data set of the expected content of the requirements specification of the communication system under test.

Step 102, according to the function of the product under test and the value of the function to the user, determine the characteristics of the product under test.

Specifically, after the computer generates product standard data based on the standardized input and output data of each software entity, the functions provided by the product to be tested and the value of these functions to users are tested respectively, and then the functions are evaluated according to the specific functions and their value to users. Classify and split out a series of characteristics of the product to be tested, where the characteristics represent product functions and values.

For example, the typical characteristics of a communication system include: providing uplink power control services to achieve the effect of ensuring demodulation, reducing interference and saving power; providing DRX (discontinuous reception) configuration services to achieve a balance between service delay and terminal power saving effect . After dismantling the characteristics of the product to be tested, the computer can also clarify the effect of each characteristic, and the implementation plan of each characteristic uses the dismantled system, subsystem, module, submodule, and products that interact with them Standard data to describe, and then determine the product standard data involved in each characteristic.

It is worth mentioning that, in the case of new requirements for the product under test, according to the effect of the new requirements, the modification content of the requirements is divided into one or several characteristics that have been determined, and can be extracted if necessary. New features, so as to ensure that the functions and values of software products are described through the feature system. Revise the software entity and product standard data of the affected features according to the changes of new requirements. At the same time, the required product standard data collection can also be maintained according to the granularity of the requirement. For example, a new requirement requires adjusting DRX (Discontinuous Reception) configuration parameters for power-insensitive terminals, and this requirement can be divided into the feature "providing DRX (Discontinuous Reception) configuration services to achieve a balance between service delay and terminal power saving effect." ", revise the product standard data involved in this characteristic according to the change of this requirement.

Step 103, for each feature, obtain each sub-function for realizing the feature, and generate test cases for each sub-function.

Specifically, after the computer divides the characteristics of the product to be tested, according to the functions and values of the characteristics, it analyzes the functions that need to be completed by each software entity that has been split, and splits the sub-functions of the characteristics step by step. The sub-functions build a systematic test framework for the product to be tested, and design test cases for each sub-function in the test framework, where each sub-function of the product to be tested and the test cases for each sub-function are described by product standard data . By generating test cases for the sub-functions of the features, the completeness of the test cases' coverage of the expected content of the requirements can be measured, and then the completeness and redundancy of the test cases can be measured from the perspectives of code implementation and requirement specification.

For example, if the product to be tested is a communication system product, when generating test cases, the computer draws the timing interaction diagrams of the subsystems and modules involved for each feature, and combines the drawn timing interaction diagrams to split each A subfunction of a feature. Through these characteristics and their sub-functions, a systematic test framework of the communication system under test is constructed. Design test cases for each sub-function in the test architecture, and the input and output of each sub-function and its use cases are described by the above-mentioned product standard data. For example, the sequence interaction diagram of the feature "provide DRX (discontinuous reception) configuration service to achieve a balance between service delay and terminal power saving effect" (referred to as feature DRX) is shown in Figure 3 . Based on the drawn timing interaction diagram, the computer splits the sub-functions of this feature step by step according to the order of the software carrying entity from the system —> multi-subsystem —> single subsystem —> single module, and the schematic diagram of the sub-function splitting of each feature As shown in Figure 4, the feature is split into the most granular sub-function level. These sub-functions make up the test architecture for this feature. Use cases are designed for each sub-function, and the input and output of each sub-function and its use cases are described by product standard data. All features and their sub-functions constitute the systematic test framework of the communication system under test, and the use cases of all sub-functions form the systematic test case set of the communication system under test.

It is worth mentioning that if the computer finds that the extracted product standard data is insufficient during the design process of feature sub-functions and use cases, it can further dismantle the physical software of the product to be tested, and based on the standardized input and output of the newly added physical software Data, adding specific product standard data; if it is found that the functions of some subsystems/modules cannot be decomposed into the extracted feature set, the function and value of the product to be tested can be further expanded to obtain new specific features.

In another example, after the computer generates the test cases for each sub-function, it also includes: testing the test completeness of the product to be tested according to the product standard data, and/or, the redundancy of the generated test cases according to the product standard data Test the degree; supplement the test cases according to the test results of the completeness, and/or integrate the test cases according to the test results of the redundancy. After the computer generates initial test cases for each sub-function based on the product standard data, it can check the test completeness of the product to be tested based on the product standard data according to the preset order, or directly in the process of continuous integration of product requirements and continuous design of use cases During the process, the latest standardized data set of each version is automatically extracted, compared with the standardized data and its attributes covered by the current version of the use case, the test completeness of the product to be tested is tested, and the test case is tested if the test completeness is insufficient. Replenish. While testing the completeness of the test, the computer can also check the redundancy between the generated test cases according to the product standard data, and integrate the redundant test cases. Based on product standard data, during the test case generation process, the test completeness and test case redundancy are detected, so that the test case architecture and test cases can be improved and optimized in the design process, and the test case can be improved. Use-case refinement optimizes efficiency.

In another example, the detection of the test completeness of the product to be tested by the computer based on the product standard data includes one of the following or any combination thereof: according to the quantity of product standard data covered by sub-functions and the quantity of all product standard data, the test framework Detect the completeness of the test case; according to the quantity of product standard data covered by the test case and the quantity of all product standard data, test the completeness of the test case; according to the quantity of product standard data covered by the sub-function of the feature and all The quantity of product standard data is used to detect the completeness of the characteristic test framework; according to the quantity of product standard data covered by the characteristic test cases and the quantity of all product standard data involved in the characteristic, the completeness of the characteristic test cases is detected; according to the product The quantity of product standard data that has been covered by the sub-functions of the requirements and the quantity of all product standard data involved in the product requirements are used to test the completeness of the requirements test architecture; The quantity of all product standard data involved is used to test the completeness of the requirement test cases. Test the structure of various dimensions and the completeness of use cases directly based on product standard data, and realize the test completeness inspection from multiple perspectives.

Specifically, when the computer checks the completeness of the test during the test case design process or after the initial test case design is completed, the completeness of the test can be measured from multiple angles by the following calculation method, according to the product standard data The total amount is used to detect the completeness of the test architecture and test case set: completeness of the test architecture = product standard data quantity covered by sub-functions / total product standard data quantity; test case completeness = product standard data covered by use cases Quantity/quantity of all product standard data. Test the completeness of the feature test architecture and feature test cases based on the quantity of all product standard data designed for a single feature: The completeness of the feature test architecture = the quantity of product standard data covered by the sub-functions of the feature/all the features involved Product standard data quantity; feature test case completeness = product standard data quantity covered by use cases of this feature / total product standard data quantity involved in this feature. Test the completeness of the test structure and test cases of a single requirement based on the quantity of all product standard data involved in a single requirement: completeness of the requirement test structure = the quantity of product standard data covered by the sub-functions of the requirement / the data involved in the requirement Quantity of all product standard data; completeness of requirement test case = quantity of product standard data covered by use cases of the requirement/quantity of all product standard data involved in the requirement.

It is worth mentioning that after the computer checks the completeness of the test, it can also supplement sub-functions or test cases if the completeness of the test does not meet the requirements. For example, for each data of various product standard data such as configuration parameters, protocol cells, software interfaces, counters, key indicators, and alarms of the communication system to be tested, count the number of sub-functions and use cases that refer to the data as input/output in sequence , when the overall test structure or test case completeness is low, refine the product standard data that has not been covered, and determine the characteristics of the product standard data that have not been referenced according to the feature splitting scheme, and perform sub-function splitting for this feature Sub-functions and supplements, and supplementary test cases for supplementary sub-functions, to complete the test coverage of product standard data that is currently not covered.

In another example, the computer detects the redundancy of the generated test cases according to the product standard data, including: detecting the similarity between the sub-functions according to the carrying entity of the sub-function and the product standard data; judging that the similarity is greater than There is redundancy in the test cases of sub-functions with preset thresholds. Specifically, when the computer detects the redundancy of a test case, it directly characterizes the redundancy based on the functional similarity between the sub-functions corresponding to the test case, and through the carrying entity of the sub-function and its product standard data, Calculate the similarity between different sub-functions according to the similarity calculation algorithm between sub-functions, identify the sub-functions whose similarity is higher than the preset threshold, and then determine the existence of test cases between multiple sub-functions whose similarity is higher than the preset threshold Redundancy, and de-redundancy for the integration of sub-functions and use cases above the preset threshold, reducing the redundancy of test cases. According to the carrying entity of the sub-function and the product standard data, the similarity of the sub-function is checked, and the test cases that are likely to be relatively redundant are obtained by identifying similar sub-functions, and then the test cases are integrated to reduce the redundancy of the test cases.

When the computer calculates the similarity between sub-functions, it can calculate the similarity between sub-function M1 and sub-function M2 according to the following similarity algorithm: S=S_Input+S_Output+S_Bearer; wherein, S_Input represents the input similarity, and S_Output represents the output Similarity, S_Bearer means bearer entity similarity. The input similarity, output similarity, and bearer entity similarity can be calculated by the following formulas:

S_Input＝(M1_Input∩M2_Input)÷(M1_Input∪M2_Input);

S_Output＝(M1_Output∩M2_Output)÷(M1_Output∪M2_Output);

S_Bearer＝(M1Bearer∩M2Bearer)÷(M1Bearer∪M2Bearer);

Among them, M1_Input and M2_Input represent the input product standard data sets of sub-functions M1 and M2 respectively, M1_Output and M2_Output represent the output product standard data sets of sub-functions M1 and M2 respectively, and M1_Bearer and M2_Bearer represent the software bearing entities of sub-functions M1 and M2 respectively gather.

In another example, after the computer generates test cases for each sub-function, it also includes: identifying the cross-influence between sub-functions according to the relationship between the product standard data of different sub-functions; Example. Specifically, for each sub-function in the test architecture, the mutual cross-influence can be identified based on the relationship between their corresponding product standard data. After creation, the poor impact between sub-functions can be detected, and supplementary test cases are used to cover the intersections of sub-functions that are currently not covered to improve the completeness of test cases.

When the computer performs sub-function interaction impact detection, the typical interaction impacts detected are as follows:

M1_Output∩M2_Input≠Φ, indicating that part of the input of the sub-function M2 is determined by M1, after the change of the sub-function M1 needs to be revised synchronously to cover its impact on the sub-function M2; M1_Input_Resource∩M2_Input_Resource≠Φ, where M1_Input_Resource and M2_Input_Resource represent the sub-function M1 , resource product standard input of M2, this formula indicates that sub-function M1 and sub-function M2 share some resources, when one of the sub-functions increases or decreases the occupancy of the corresponding resources, it is necessary to revise the use case synchronously to cover its use for the other sub-function The influence of functions; M1_Output∩M2_Output≠Φ, which indicates that the standard output of some products is jointly determined by sub-function M1 and sub-function M2. It is necessary to analyze the interaction between the operation timing and operation ratio of this part of output M1 and M2, and design use cases cover.

It is worth mentioning that when the computer performs sub-function interaction impact detection, other interaction impact algorithms can also be added according to different software product features. This embodiment does not limit the interaction impact algorithms used.

In another example, after the computer generates test cases for each sub-function, the computer further includes: supplementing the test cases according to the changed product standard data when the product standard data changes. Specifically, after the computer generates test cases, it needs to maintain the test case set. The product under test may change in requirements and expectations in different versions, which will cause data increase or decrease in various product standard data and data Attribute changes. In order to ensure that the test cases can support new requirements, the redundancy of the test cases is as low as possible. The computer extracts the current product standard data in the software version package or code library according to the pre-extraction rules, and extracts a new one each time. After the standard data of each product is compared with the historically stored data, it is identified which attributes of which data have changed, and then according to the data increase or decrease in various product standard data and the change of data attributes, for the identified change points, Trigger revision of test architecture and use cases. By updating and supplementing or deleting test cases according to changes in product standard data, it is possible to ensure accurate testing of new functions and at the same time ensure that the redundancy of test cases is as low as possible.

Another aspect of the embodiment of the present application relates to a device for generating test cases, referring to FIG. 5 , including:

An acquisition module 501, configured to acquire standardized input and output data of each software entity of the product to be tested as product standard data;

A determining module 502, configured to determine each characteristic of the product to be tested according to the function of the product to be tested and the value of the function to the user, where the characteristic represents the function and value of the product;

The generating module 503 is used to obtain each sub-function for realizing the feature for each feature, and generate test cases for each sub-function;

Among them, sub-functions and test cases of sub-functions are described by product standard data.

It is not difficult to find that this embodiment is an apparatus embodiment corresponding to the method embodiment, and this embodiment can be implemented in cooperation with the method embodiment. The relevant technical details mentioned in the method embodiments are still valid in this embodiment, and will not be repeated here in order to reduce repetition. Correspondingly, the related technical details mentioned in this embodiment can also be applied in the method embodiment.

It is worth mentioning that all the modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, or a part of a physical unit, or multiple physical units. Combination of units. In addition, in order to highlight the innovative part of the present invention, units that are not closely related to solving the technical problem proposed by the present invention are not introduced in this embodiment, but this does not mean that there are no other units in this embodiment.

Another aspect of the embodiment of the present application also provides an electronic device. Referring to FIG. 6 , it includes: at least one processor 601; Instructions executed by at least one processor 601, the instructions are executed by at least one processor 601, so that at least one processor 601 can execute the method for generating test cases described in any one of the above method embodiments.

Wherein, the memory 602 and the processor 601 are connected by a bus, and the bus may include any number of interconnected buses and bridges, and the bus connects one or more processors 601 and various circuits of the memory 602 together. The bus may also connect together various other circuits such as peripherals, voltage regulators, and power management circuits, all of which are well known in the art and therefore will not be further described herein. The bus interface provides an interface between the bus and the transceivers. A transceiver may be a single element or multiple elements, such as multiple receivers and transmitters, providing means for communicating with various other devices over a transmission medium. The data processed by the processor 601 is transmitted on the wireless medium through the antenna, and further, the antenna also receives the data and transmits the data to the processor 601 .

Processor 601 is responsible for managing the bus and general processing, and may also provide various functions including timing, peripheral interface, voltage regulation, power management, and other control functions. And the memory 602 may be used to store data used by the processor 601 when performing operations.

Another aspect of the embodiments of the present application also provides a computer-readable storage medium storing a computer program. The above method embodiments are implemented when the computer program is executed by the processor.

That is, those skilled in the art can understand that all or part of the steps in the method of the above-mentioned embodiments can be completed by instructing related hardware through a program, the program is stored in a storage medium, and includes several instructions to make a device ( It may be a single-chip microcomputer, a chip, etc.) or a processor (processor) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disc, etc., which can store program codes. .

Those of ordinary skill in the art can understand that the above-mentioned embodiments are specific embodiments for realizing the present application, and in practical applications, various changes can be made to it in form and details without departing from the spirit and spirit of the present application. scope.

Claims

A method for generating test cases, comprising:

Obtain standardized input and output data of each software entity of the product to be tested as product standard data (101);

According to the function of the product to be tested and the value of the function to the user, determine the characteristics of the product to be tested, and the characteristics represent the function and value of the product (102);

For each feature, obtain the sub-functions used to realize the feature, and generate test cases for each of the sub-functions (103);

Wherein, the sub-functions and the test cases of the sub-functions are described by the product standard data.
The method for generating a test case according to claim 1, wherein said acquisition of standardized input and output data of each software entity of the product under test as product standard data (101) includes:

Decomposing the implementation architecture of the product under test into software entities;

Extract the standardized input and output data of each software entity from the software product version package according to the input and output data of each software entity interacting with the outside obtained after decomposing;

Wherein, each software entity obtained after the decomposition includes one of the following or any combination thereof: a system, a subsystem, a module, and a submodule.
The method for generating test cases according to claim 2, wherein said extracting the standardized input and output data of each software entity from the software product version package comprises:

Extracting the standardized input and output data of each software entity from the software product version package according to the category of the input and output data interacting with the outside;

Wherein, the categories include one of the following or any combination thereof: configuration parameters, key indicators, abnormal alarms, protocol cells, and software interfaces.
The method for generating test cases according to any one of claims 1 to 3, wherein, after generating test cases (103) for each of the sub-functions, further comprising:

Detecting the test completeness of the product to be tested according to the product standard data, and/or detecting the redundancy of the generated test cases according to the product standard data;

The test cases are supplemented according to the detection results of the completeness, and/or the test cases are integrated according to the detection results of the redundancy.
The method for generating test cases according to claim 4, wherein the detection of the test completeness of the product under test according to the product standard data includes one of the following or any combination thereof:

According to the quantity of product standard data covered by sub-functions and the quantity of all product standard data, the completeness of the test framework is tested;

Test the completeness of the test case according to the quantity of product standard data covered by the test case and the quantity of all product standard data;

Detect the completeness of the characteristic test framework according to the quantity of product standard data covered by the sub-function of the characteristic and the quantity of all product standard data involved in the characteristic;

According to the quantity of product standard data covered by the test cases of the characteristics and the quantity of all product standard data involved in the characteristics, the completeness of the characteristic test cases is tested;

According to the quantity of product standard data covered by the sub-functions of the product requirements and the quantity of all product standard data involved in the product requirements, the completeness of the requirements testing framework is tested;

According to the quantity of product standard data covered by the test cases of the product requirements and the quantity of all product standard data involved in the product requirements, the completeness of the requirement test cases is tested.
The method for generating a test case according to claim 4, wherein the detecting the redundancy of the generated test case according to the product standard data includes:

According to the bearer entity of the sub-function and the product standard data, the similarity between the sub-functions is detected;

It is determined that there is redundancy in the test cases of the sub-functions whose similarity is greater than the preset threshold.
The method for generating test cases according to any one of claims 1 to 3, wherein, after said generating test cases (103) for each of said sub-functions, further comprising:

According to the relationship between product standard data of different sub-functions, identify cross-effects between sub-functions;

The test cases are supplemented based on the identified cross-effects.
The method for generating test cases according to any one of claims 1 to 3, wherein, after said generating test cases (103) for each of said sub-functions, further comprising:

In the case that the product standard data is changed, the test cases are supplemented according to the changed product standard data.
A device for generating test cases, comprising:

An acquisition module (501), configured to acquire standardized input and output data of each software entity of the product to be tested as product standard data;

A determining module (502), configured to determine each characteristic of the product under test according to the function of the product under test and the value of the function to the user, the characteristics representing the function and value of the product;

A generating module (503), configured to obtain each sub-function for realizing the feature for each feature, and generate test cases for each of the sub-functions;

Wherein, the sub-functions and the test cases of the sub-functions are described by the product standard data.
An electronic device comprising:

at least one processor (601); and,

A memory (602) communicatively connected to the at least one processor (601); wherein,

The memory (602) stores instructions executable by the at least one processor (601), the instructions are executed by the at least one processor (601), so that the at least one processor (601) can Executing the method for generating test cases as described in any one of claims 1 to 8.
A computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the method for generating test cases according to any one of claims 1 to 8 is realized.