CN117891742A - RUCM-based system test case automatic generation method - Google Patents

Abstract

The invention discloses an RUCM-based system test case automatic generation method, which comprises the following steps: s1, re-writing an original demand case modeling RUCM template to obtain an extended RUCM document; s2, generating constraint condition expressions of corresponding entities based on all constraint conditions related in the RUCM document and combining a data model of a tested system; s3, generating a use case test model based on the RUCM flow and the meta model, and extracting and constructing a test scene and path conditions from the use case test model; s4, generating random test data with constraint through a constraint generation algorithm based on the constraint condition expression obtained in the S2; s5, generating test driving function call based on the test scene obtained in the S3, constructing a complete test case, and executing and verifying the test case. The invention provides an RUCM-based system test case automatic generation method, which can automatically generate executable test cases directly from user demand specifications and improve the coverage rate of software testing.

Description

RUCM-based system test case automatic generation method

Technical Field

The invention relates to the technical field of automatic generation of test cases. More particularly, the present invention relates to a safety critical field (such as automotive and aviation fields) applicable to an embedded software system, for automatically generating a test case that matches a user specification and is executable, and in particular, to a method for automatically generating a system test case based on an RUCM.

Background

In the field of software testing automation, the generation of efficient and comprehensive test cases is a key for improving the quality of software. As the complexity of software systems continues to increase, existing automated testing methods have been challenged in terms of high efficiency and comprehensiveness. At present, the design of test cases mainly depends on experience of testers, and the manual design method is low in efficiency, has the problems of uncertainty and blindness, and cannot comprehensively test software in a system. Therefore, researchers propose various inventions for automatically generating test cases so as to reduce test cost and improve test efficiency and quality.

Several methods have been proposed by students at home and abroad for test case generation technology, among which model-based test methods are receiving a great deal of attention because of their high reusability. However, most models are not acquired automatically, but are constructed manually by the tester using the requirement specification, which limits the efficiency of the method. To achieve true automation, some studies attempt to automatically extract models directly from the requirement specification of natural language descriptions and generate test cases, but there are still many problems: the extracted model often needs a large amount of manual correction, the generated test case cannot be executed, manual data supplement is needed, the requirement expression form is limited strongly, and the expandability is poor.

In the prior art, some documents propose corresponding solutions to solve the above-mentioned problems, for example, in an airborne equipment test requirement generating method and an airborne equipment test method, which aims to solve the problems of divergence and misunderstanding existing in the airborne equipment test requirement. The method comprises the steps of determining signal types required by airborne equipment testing, constructing a parameterized sentence pattern template, and expanding the RUCM template to obtain an RUCM4ATE test requirement case template. The method improves the testing efficiency and accuracy, but is mainly limited in the field of airborne equipment testing, and focuses on the generation of testing requirements, rather than the full-automatic generation of testing cases.

In an RUCM-based real-time testing method. The method comprises the steps of carrying out real-time test expansion on the RTCM test template to obtain a real-time test specification template, and converting from a real-time requirement specification to a real-time test specification. The RUCM is adopted as a basis, so that the defects that the existing demand-based test method is incomplete in information, difficult to understand and use, and not aiming at real-time test and the like are overcome, and the method is mainly focused on the specific demand of the real-time test.

In the test data and test case generation method, system and storage medium, the invention is more focused on extracting the data description and the constraint condition of the test data from the functional requirement specification to generate the test data. The method is more focused on the generation and automation of test data than on the overall automated generation of test cases.

In summary, the problems in the current research include the following:

(1) Limitations of model basis: while model-based testing methods are valued for their reusability, most models are not automatically generated. They typically require manual construction by test personnel according to the required specifications, and are therefore limited in efficiency. At the same time, how to ensure the accuracy and coverage rate of the model in the complex software system test is also a challenge.

(2) The automatic extraction model has the following defects: while there are attempts to automatically extract models from the requirements specification to generate test cases, these automatically extracted models often require extensive manual correction. In addition, the existing method only generates abstract test scenes, but cannot automatically generate test data, and data supplementation still needs to be performed manually.

(3) Limitation of user requirements to test cases: a number of methods employ Controlled Natural Language (CNL) to describe user requirements, which impose severe constraints on the form of the requirement expression and affect the scalability of the method. The test cases thus generated are typically non-executable, limited to test step flows, and cannot be combined with existing automated test frameworks to produce executable test case scripts.

Disclosure of Invention

It is an object of the present invention to address at least the above problems and/or disadvantages and to provide at least the advantages described below.

To achieve these objects and other advantages and in accordance with the purpose of the invention, a system test case automatic generation method based on an RUCM is provided, comprising:

S1, re-writing an original demand case modeling RUCM template to obtain an extended RUCM document;

s2, generating constraint condition expressions of corresponding entities based on all constraint conditions related in the RUCM document and combined with a tested system data model;

s3, generating a use case test model based on the RUCM flow and the meta model, and extracting and constructing a test scene and path conditions from the use case test model;

s4, generating random test data with constraint through a constraint generation algorithm based on the constraint condition expression obtained in the S2;

s5, converting the test scene step obtained based on the step S3 into corresponding high-level operation description, and mapping the high-level operation description and the random test data obtained in the step S4 into corresponding test driving function names and input parameters, and constructing a complete test case through the high-level operation description and the test driving function call to execute and verify the test case;

wherein, the content for rewriting the original demand case modeling RUCM template comprises: the method comprises the steps of adding a Constrants module, modifying an expression mode in a conditional statement, modifying an expression mode of a pre-condition and a basic post-condition, marking a first step of a branching stream and expanding keywords in an RUCM.

Preferably, in S1, the Constraints module is configured to describe input data constraint conditions that need to be satisfied by an elementary stream in a current user requirement, and the Constraints module adopts c+id: writing a format of the constraint condition;

The precondition and the basic precondition are Pr+id respectively: preconditions, po+id: writing a basic post-condition format, wherein the post-conditions in other streams are not processed;

adopting the expression mode of C+id to replace the expression mode of a conditional statement pointed by VALIATES THAT in the conventional RUCM, and placing the C+id in a Constraint module for storage;

the first step of the fractional stream is marked with ON CONDITION FAILURE C +id;

The expansion of keywords in an RUCM refers to writing all keywords in the RUCM that are related to the system and user interaction process in the step in uppercase letters.

Preferably, in S2, the preconditions, the basic constraint conditions and the basic post-constraint conditions in the constraint conditions are extracted from the RUCM document;

Wherein the preconditions are extracted from the content in the Preconditions module, the basic Constraints are extracted from the content in the Constraints module, and the basic post-conditions are extracted from the content in the Postconditions module in the elementary stream.

Preferably, in S2, the constraint condition expression is described according to a format of a data object and an operator which are constrained by needs, and a specific constraint condition;

Wherein the specific constraint condition types include: data type related constraints, numeric and size related constraints, format, schema and character type related constraints, selection and dependency related constraints, uniqueness and default related constraints, non-null and default values.

Preferably, in S3, the meta-model is a basic model for converting to a use case test model based on an RUCM structure, and main elements thereof include:

With initial conditions for use case entry UseCaseStart pointing to the first step;

Sequential steps Sequence for pointing to subsequent sequences;

pointing to Condition step conditions of different subsequent steps according to the true and false conditions;

an Internal step International representing operation within the system;

Representing an Input operation for connecting to an Input step Input representing Input data DomainEntity;

include containing other use cases;

a use case outlet Exit for indicating an ending step;

A use case exit Abort for indicating an abnormal end;

an interrupt condition InterruptingCondition for executing a global or limited scope of alternative flows;

Representing the inlet conditions AlternalFlowStart of the alternative flow.

Preferably, in S3, the generating process of the use case test model includes:

s31, identifying and extracting keywords in the RUCM;

s32, based on the case test meta-model, instantiating the steps in the RUCM document into corresponding types of nodes, and displaying the implicit control flow into the test case model so as to convert the RUCM user requirements into a visualized test case model.

Preferably, in S4, the use case test model is traversed by a recursive depth-first algorithm to generate different test scenarios and path conditions involved in each scenario, and the following coverage criteria are followed during the traversal:

criterion one, for each Condition instance not belonging to InterruptingCondition types, first access the true branch and then the false branch to prioritize the basic scene;

a second criterion, when processing non-Condition nodes, continuing to go deep to the next node through node. Next, and continuously searching until no deeper nodes exist;

Thirdly, traversing a scene only once when encountering a RESUME node in one cycle;

And the fourth criterion is that for each traversed conditional step in the current scene, if the next conditional step enters a true branch, directly adding the related constraint number into the constraint array, otherwise, adding an inverse mark in front of the constraint number related to 'ON CONDITION FAILURE C +id' in the first step in the false branch, and then adding the inverse mark into the constraint array.

The invention at least comprises the following beneficial effects:

The invention aims to solve the defects in the generation of the traditional test case method, can automatically generate the executable test case directly from the user demand specification, improves the coverage rate of software test, provides a set of complete automatic flow from demand to test for software test engineering, and has more perfect flow and wider application range compared with other automatic test related inventions, and has the following effects:

1. Manual behavior modeling is avoided, and testing cost is reduced.

2. Test data is automatically generated, and the automation efficiency is improved.

3. The automatic test script is generated, so that the cost of manually writing test cases is reduced.

Additional advantages, objects, and features of the invention will be set forth in part in the description which follows and in part will become apparent to those having ordinary skill in the art upon examination of the following or may be learned from practice of the invention.

Drawings

FIG. 1 is a flow chart of an RUCM-based system test case automatic generation method of the present invention;

FIG. 2 is a diagram of an RUCM-based test case meta-model of the present invention;

FIG. 3 is a diagram of a partial data model constructed by an ATM in accordance with an embodiment of the present invention;

FIG. 4 is a diagram of a test case model generated by a given example of an embodiment of the present invention.

Detailed Description

The present invention is described in further detail below with reference to the drawings to enable those skilled in the art to practice the invention by referring to the description.

The invention relates to a method for automatically generating an executable test case based on user specifications written by RUCM, which has more perfect process and wider application compared with other related inventions which use similar technology to perform automatic test. It should be noted that, in the process from user demand based on the RUCM to test case generation, the technology mainly involved in the present invention includes:

1. Construction of extended RUCM user requirements templates. The RUCM (restricted use case modeling) is a requirement modeling method based on use case modeling, and consists of a use case template and a set of restricted user writing use case specification rules. He can effectively reduce the ambiguity of the requirement specification, and simultaneously, the advantages of easy understanding and easy use of natural language are maintained. And has good scalability. Thus, in order to more normalize the user requirements of the universal spoken expressions, the present invention compiles the user requirements through the RUCM, thereby improving the understandability and accuracy of the user requirements expressions.

2. Constraint expressions are generated for which input data relates. Effect of constraints: (1) Constraints can accurately capture constraints in the user demand input data, thereby providing a correct basis for subsequent test case generation. (2) Constraint conditions provide the necessary information for test input generation based on constraint solving. By generating constraint expressions, preconditions and basic post-conditions of the RUCM are accurately captured, conditions in the conditional step are defined, and a foundation is laid for generating corresponding test input data from a test scene later.

3. Different test scenarios are extracted from the user's needs using a depth-first algorithm. First, information such as the kind, flow, and condition of the step is identified based on the keyword in the RUCM. This provides input for building a case test model. The control flow information of the user needs is then explicitly modeled to the use case test model, and keywords indicate pre/post conditions, alternative flows, types of steps, etc. in the user needs. Finally, traversing the case test model by using a depth-first algorithm to generate different test scenes, wherein the traversal process mainly relates to a path coverage strategy, a conditional/branch coverage strategy and a statement coverage strategy.

4. A constraint solving algorithm is used to generate test input values that satisfy a given scenario. For each use case scenario, extracting the related constraint conditions to form path conditions. And putting the path condition of the current scene as a whole into a constraint solving algorithm to solve, and obtaining an object diagram meeting all constraints. The object diagram gives an example of a model in which the relevant variables are all set to values that make the condition true. From the object graph, those attribute values associated with the path conditions are extracted as test input data for the test scenario.

5. And matching the test driving function in the mapping table into the corresponding high-level step description through character string matching. The high-level operational description is a test step that converts operations in the user's requirements specification, such as actions that the system and participants should perform, into specific ones that can be actually performed in the test environment. The test driver functions are implemented by calling specific software functions in order to simulate the steps in the test environment. And the mapping table is introduced to relate the high-level operation description to the test driver function. The corresponding test driving function is selected according to the high-level operation description through a character string matching algorithm, so that the generated test case can be executed in an actual test environment.

Further, in a specific implementation process, the system test case automatic generation method based on the extended RUCM of the invention comprises the following steps:

S1, writing RUCM: the user requirements of the tested system are written by using the RUCM template expanded by the invention. The extension of the RUCM, except for the conventional basic properties of the RUCM, is an improvement for better analysis and processing of test scenes and generation of test data. The expansion of the invention is mainly characterized in that:

(1) And a new Constraints module is added, and the module is used for describing input data constraint conditions which are required to be met by the elementary streams in the current user demands. According to "c+id: the format of the constraint "is written.

(2) The expressions of Preconditions (preconditions) and Postconditions (postconditions) in the elementary streams are modified. According to "Pr/Po+id: the format of the pre/basic post conditions "is written, and post conditions in other streams are temporarily left untreated.

(3) Modifying the expression in the conditional statement. In the RUCM, sentences with keywords VALIATES THAT are used as conditional sentences, constraint conditions related to the current conditional sentences are directly extracted, and C+id is used for replacing and storing the Constraint conditions in a Constraint module, so that a part of processes for identifying Constraint condition clauses from user demands through NLP technology are reduced.

(4) The first step in the fractional stream is marked with "ON CONDITION FAILURE C +id". In the RUCM step flow, if the conditional step meets the constraint condition, the step flow continues downwards, and if the conditional step does not meet the constraint condition, the step flow enters a branch flow of the line number to be continuously executed. Conventionally, entering the tributary has indicated that the constraints in the elementary stream are not met, but sometimes the constraints of a step in the elementary stream are more than one, the entering the alternative stream needs to indicate which constraint is not met in particular, and the first step in entering the tributary has to be marked with "ON CONDITION FAILURE C +id" in order to unify the template specifications. It is obvious that the subsequent steps are performed without satisfying the constraint condition where "c+id" is located.

(5) Extending keywords in an RUCM where the keywords are used to identify which type of step the step belongs to, a step may describe one of the following activities: one participant sends data to the system; the system validates some of the data; the system replies a result; the system changes its internal state. For readability and subsequent generation of the use case test model by keywords, it is required that all keywords in the steps that relate to the system and user interaction process are written in uppercase letters.

S2, preparing a data model: he is the data that the system under test needs to use during operation, typically provided by an engineer during system development.

S3, generating a constraint expression: constraint expressions for the corresponding entities are generated based on all constraints involved in the RUCM document in combination with the system data model under test, as the generation of the test input data is derived from the description of the input data and the corresponding constraints. After the user provides the extended RUCM document, all constraints related to each user's needs of the RUCM need to be extracted, including pre-conditions, basic constraints, and basic post-conditions. The preconditions are extracted by the content in Preconditions modules, the basic Constraints are extracted by the content in the Constraints modules, and the basic post conditions are extracted by the content in Postconditions modules in the elementary stream. To ensure the accuracy of natural language descriptions, all constraints after extraction need to be converted into canonical constraint expressions for later generation of random test data with constraints from the expressions. The constraint expressions required to be generated by the invention are described according to the format of < lhr, opr, rhs >:

(1) lhs denotes the data object that needs to be constrained and originates from the data model entity of the system.

(2) Opr represents an operator, which contains several major operators "=", "<", ">", and combinations between them.

(3) Rhs represents a specific constraint condition that lhs needs to meet, and according to the constraint type, we normalize the expression form of rhs into the following several types:

1) Data type dependent constraints:

The data type constraint (type (datatype)) specifies the data type of the field, such as string, number, bootan, etc. The type constraint is provided directly through the data model.

2) Numerical and size related constraints:

Numerical range (min-max)) specifying the minimum and maximum ranges of values.

Length (min-max)) by imposing a constraint on the length of the fields of the string, array, etc.

3) Format, schema, and character type related constraints:

A common format limit (format (pattern)) for requiring fields to conform to a particular, predefined format, such as date, phone number, email address, etc.

Regular expression matching regex (pattern) the specific patterns of the string fields are defined using regular expressions. This includes, but is not limited to: character type restrictions (e.g., letter only, number only, letter and number mix). Specific character arrangements and structures. Custom complex formats.

4) Selection and dependency related constraints:

an enumeration type (options)) the field value must be one of the given options.

Dependency constraint: the value of one field depends on the value of the other field.

5) Uniqueness and default-related constraints

Uniqueness constraint (unique) requires that the field value be unique.

6) Non-null and default values:

nonEmpty the field cannot be null.

Default (value) default values for fields.

S4, generating a use case test model: and generating a use case test model according to the RUCM flow and the meta-model. And (3) constructing a use case test model from the RUCM user requirements. Keywords in the RUCM are first identified and extracted. The steps in the RUCM are then instantiated as corresponding types of nodes according to the use case test meta-model (see FIG. 2), and implicit control flows are explicit into the test case model. In this way, the RUCM user requirements translate into a visual test case model.

The use case test meta-model is a base model that is specifically transformed into the use case test model according to the RUCM structure. The main elements include: useCaseStart: use case entry, with initial conditions, points to the first step. Sequence: sequential steps, pointing to a subsequent sequence. Condition: and a conditional step, namely pointing to different subsequent steps according to the true or false condition. International: the internal steps represent operations within the system. Input: an input step, representing an input operation, is connected to DomainEntity representing input data. Include: including other use cases. Exit: and (5) outputting the use case, and normally ending the step. Abort: and (5) a use case outlet and an abnormal ending step. InterruptingCondition: interrupt conditions, execute global or limited scope alternative flows. AlternalFlowStart: replacing the inlet conditions of the stream.

S5, generating a test scene and path conditions: and extracting and constructing the test scene from the use case test model. These scenarios reflect various possible execution paths for the user use case. The test case model graph captures a series of interactions that should be performed during the test. It consists of a limited number of steps. It starts with a UseCaseStart node and ends with an Abort node or an Exit node. The scene is a path in the case test model, the test case model required by the current user is taken as input, and different scenes and path conditions (namely constraint conditions in conditional branching steps) involved in each scene are obtained through a recursion depth-first algorithm. The traversal procedure follows the following coverage criteria:

(1) For each Condition instance that does not belong to the InterruptingCondition type, we first access the true branch and then the false branch to prioritize the basic scenario.

(2) When processing non-Condition nodes, the node continues to go deep to the next node, and continues to search until no more deep nodes exist.

(3) The invention provides that in the traversing process, the node meeting the RESUME traverses only once, that is to say, the special substitution stream with the RESUME node is not entered for the second time, thereby ensuring that each scene triggers the cycle only once for the same condition.

(4) For each traversed conditional step in the current scene, adding the constraint number into the constraint array, directly adding the related constraint number into the constraint array if the conditional step enters a true branch in the next step, and adding the constraint number related to 'ON CONDITION FAILURE C +id' in the first step of the false branch in front of 'I' if the conditional step enters a false branch! "tag" means negation and addition to the constraint array.

S6, generating test data: necessary test data is generated for each test scenario. These data are used to satisfy constraints and provide input when performing the test. And solving the test input data from the constraint expression by using a constraint solving algorithm. And generating test data meeting the scene according to the path conditions extracted from each scene. If the path condition has been determined to be unsatisfiable during the generation of the test input, it returns false and indicates that the current test scenario is also illegitimate to discard; otherwise, it assumes that the path conditions are satisfied and solves for at least one instance that each constraint satisfies.

In the constraint solving process, for most conventional test input data, a faker library can be utilized to generate corresponding test data according to the constraint. The faker library can be used to generate some basic data types and formats, but for situations where a particular format, schema, or value dependent on other variables is required, custom scripts need to be written. The present invention uses formats in expressions to flag the solving of the current constraint data to satisfy and apply the corresponding APIs of faker libraries.

For example, the input data constraint expression involved in the test case process for successful user registration can be expressed as:

1.Regist.username＝format(name())

2.Regist.password＝format(alphaNumeric(8-15))

3.Regist.email＝format(email(gmail.com))

through constraint generation algorithm, the invention can call the API corresponding to faker library according to the expression, and random test data with constraint can be obtained by executing the API function. For example, the three expressions corresponding to the above may call the API to directly obtain the data meeting the condition:

1.faker.person.name()

2.faker.string.alphanumeric({length:{min:8,max:15}})

3.faker.internet.email({provider:"gmail.com"})

faker is a very powerful library that provides a wide range of APIs to generate a variety of random data, including numbers, strings, dates, addresses, etc. There are certain constraints that require custom logic to implement because faker does not provide a direct API to handle these situations. The following are some examples:

(1) Step constraint (value)): e.g., data=step (100), meaning that the data must be a multiple of 100. faker have no straightforward method to generate data that meets this step size constraint. Custom logic is required, for example to generate a random number and then multiply it by a step value.

(2) Complex dependency and association constraints: faker cannot be directly addressed when the value of one data field depends on the values of other fields, especially when such dependencies are conditional or involve complex business logic. This requires custom logic to ensure consistency and correctness of the data. For example: "withdrew al.amountj=user.card.balance", which is a representation with a dependency, the range of withdrawal amounts needs to be smaller than the account balance of the user, and "withdrew al.remainders-withdrew al.amountj which, after withdrawal, should be equal to the account balance of the user minus the withdrawal amount. The APIs of faker libraries do not support formal solutions using dynamic variables directly in the parameters. All relevant rhs variables need to be calculated or determined before invoking faker functions and then passed as parameters.

(3) Highly custom regular expressions: while faker. Js supports basic regular expression generation strings, additional logic may be required to ensure that the generated data is satisfactory for very complex or format-specific regular expressions. The present invention provides for using regex markers to refer to data of complex canonical constraints. For example: the password input when the user registers is required to meet the following conditions: beginning with a capital and lowercase letter, containing at least three formats (capital and lowercase letter, number) and ranging in length from 12 to 16 bits, corresponding constraint expressions: user.passward=regex (/ [0-9a-zA-Z ] {11,15} /). For the constraint of such highly complex data, our custom constraint solving script would need to involve the use of loops and conditional statements, as well as random number generators to jointly implement this complex constraint.

S7, generating a test driving function call: firstly, converting the steps in the test scene into high-level operation description to ensure that the test steps are specific and executable. And generating corresponding test driving function call according to the high-level operation description. The test driver function is capable of implementing or simulating the operation in the test step. It is desirable to provide a mapping table that maps high-level operation descriptions and test inputs to specific driver functions and inputs that the test case should perform. And automatically generating the executable test cases through the mapping table. If the test infrastructure and hardware drivers change over the system lifecycle, only this table needs to be changed.

S8, constructing a complete test case: and combining high-level operation description, test driving function call and test data to construct a complete test case. Four parts (high level operation description, test drive function, input value and expected output) are included.

S9, executing and verifying tests: executing the test cases in a test environment, and verifying whether the results meet expectations.

Examples:

taking a common certain ATM system as an example, the RUCM-based system test case automatic generation method is exemplified.

(1) A withdrawal user demand table as in table 2 is constructed according to the extended RUCM template as in table 1.

TABLE 1

TABLE 2

/>

(2) A partial data model of an ATM as in fig. 3 is provided.

(3) The basic constraint and the basic post-constraint are converted into a specific constraint expression. The main constraints involved in the user requirements of this example are described as follows:

Pr1:the system status is normal.

Pr2:The user has a normal bank card account.

Pr3:The system's maximum withdrawable amount is 10000.

C1:the card status is readable.

C2:the entered pin is equal to the user card pin.

C3:the withdrawal amount is an integer of 100.

C4:the withdrawal amount is less than the user's card balance.

C5:the withdrawal amount is less than the ATM maximum balance.

Po1:The remaining balance is equal to the account balance minus the withdrawal amount.

(4) Converting the above basic constraint and basic post-condition constraint into corresponding constraint expressions according to NLP technology and in combination with a data model for the tested system:

C1:Card.status＝enum(Normal)

C2:Login.pin＝User.card.pin

C3:Withdrawal.amount＝step(100)

C4:Withdrawal.amount<＝User.card.balance

C5:Withdrawal.amount<＝ATM.maximumBalance

Po1:Withdrawal.remainBalance＝User.card.balance-Withdrawal.amount

(5) A test scenario and path conditions are generated. The use case test model according to the user requirements of the RUCM in the example can traverse a plurality of different test scenarios. (the number indicates the txt line number where the step is located, C+id represents the constraint number in the path condition)

For example: scene 1 without any alternative streams:

Scenario:[4,5,6,7,8,9,10,11,12,13,14]

constraints:[C1,C2,C3,C4,C5]

For example: scenario 2 containing backtracking alternate stream:

Scenario:[4,5,6,7,8,9,10,11,28,29,30,10,11,12,13,14]

constraints:[C1,C2,！C3,C3,C4,C5]

An example of test input data solved for scenario one in example 1 is as follows:

Card.status＝"Normal"

Login.pin＝"123456"

Withdrawal.amount＝500

Withdrawal.remainBalance＝4500

(6) High-level operations describe transformations. At this stage, we convert the scene steps in the RUCM into high-level operation descriptions that represent test operations that can be specifically performed in the test tool. For example, the higher-level operations that may be included in the "CASHWITHDRAWAL" use case are described as:

Initialization: set initial state of the system and related components.

Insert card-operation to insert a bank card into an ATM on behalf of a user.

And c, enterPin, namely inputting a password by a user.

SelectService, various services of the ATM are selected by the user.

EnterAmount, user input amount.

Withdraw: ATM processes withdrawal requests.

Printreceptipt: printing the certificate.

EndTransactionuser ends transaction.

(7) The high-level operation description is mapped with the corresponding test driving function. Each high-level operation description is mapped to a specific function to perform a corresponding test step. In this way, the test steps are clearly defined as high-level operation descriptions, and these high-level operation descriptions are directly associated to specific test functions, thereby achieving standardization and automation of the test procedure.

The insert card maps to INSERTCARD (CARDSTATUS) functions.

EnterPin maps to an enterPin (pin) function.

SelectService maps to SELECTSERVICE (SERVICETYPE) functions.

The EnterAmount maps to enterAmount (amount) functions.

Withdraw maps to withdraw (amount) functions.

Printreceip maps to PRINTRECEIP () function.

EndTransection maps to endTransaction () function.

(8) An executable test case is generated. The final test pattern will combine the high-level operation description and the mapping table to form a specific execution step, comprising four parts (high-level operation description, test driving function, input value and expected output). Scenario 1 generates an executable test case script as in table 3:

TABLE 3 Table 3

(8) And sequentially executing the test driving functions in the test environment, and verifying whether the execution result of the functions accords with the expected output result.

The above is merely illustrative of a preferred embodiment, but is not limited thereto. In practicing the present invention, appropriate substitutions and/or modifications may be made according to the needs of the user.

The number of equipment and the scale of processing described herein are intended to simplify the description of the present invention. Applications, modifications and variations of the present invention will be readily apparent to those skilled in the art.

Although embodiments of the invention have been disclosed above, they are not limited to the use listed in the specification and embodiments. It can be applied to various fields suitable for the present invention. Additional modifications will readily occur to those skilled in the art. Therefore, the invention is not to be limited to the specific details and illustrations shown and described herein, without departing from the general concepts defined in the claims and their equivalents.

Claims (7)

1. An automatic system test case generation method based on RUCM is characterized by comprising the following steps:

S1, re-writing an original demand case modeling RUCM template to obtain an extended RUCM document;

S2, generating constraint condition expressions of corresponding entities based on all constraint conditions related in the RUCM document and combining a data model of a tested system;

s3, generating a use case test model based on the RUCM flow and the meta model, and extracting and constructing a test scene and path conditions from the use case test model;

s4, generating random test data with constraint through a constraint generation algorithm based on the constraint condition expression obtained in the S2;

s5, converting the test scene step obtained based on the step S3 into corresponding high-level operation description, and mapping the high-level operation description and the random test data obtained in the step S4 into corresponding test driving function names and input parameters, and constructing a complete test case through the high-level operation description and the test driving function call to execute and verify the test case;

wherein, the content for rewriting the original demand case modeling RUCM template comprises: the method comprises the steps of adding a Constrants module, modifying an expression mode in a conditional statement, modifying an expression mode of a pre-condition and a basic post-condition, marking a first step of a branching stream and expanding keywords in an RUCM.

2. The method for automatically generating system test cases based on RUCM according to claim 1, wherein in S1, the Constraints module is configured to describe input data Constraints that need to be satisfied by an elementary stream in a current user requirement, and the Constraints module adopts c+id: writing a format of the constraint condition;

The precondition and the basic precondition are Pr+id respectively: preconditions, po+id: writing a basic post-condition format, wherein the post-conditions in other streams are not processed;

Replacing a conditional statement pointed by VALIATES THAT in the conventional RUCM by adopting an expression mode of C+id, and placing the conditional statement pointed by C+id in a Constraint module for storage according to the format of the conditional statement pointed by C+id;

the first step of the fractional stream is marked with ON CONDITION FAILURE C +id;

The expansion of keywords in an RUCM refers to writing all keywords in the RUCM that are related to the system and user interaction process in the step in uppercase letters.

3. The automatic generation method of system test cases based on RUCM according to claim 1, wherein in S2, the preconditions, the basic constraint conditions and the basic post-constraint conditions in the constraint conditions are extracted from RUCM document;

Wherein the preconditions are extracted from the content in the Preconditions module, the basic Constraints are extracted from the content in the Constraints module, and the basic post-conditions are extracted from the content in the Postconditions module in the elementary stream.

4. The method for automatically generating system test cases based on RUCM according to claim 3, wherein in S2, the constraint condition expression is described according to the format of data objects and operators to be constrained, and specific constraint conditions;

Wherein the specific constraint condition types include: data type related constraints, numeric and size related constraints, format, schema and character type related constraints, selection and dependency related constraints, uniqueness and default related constraints, non-null and default values.

5. The method for automatically generating system test cases based on the RUCM according to claim 1, wherein in S3, the meta model is a basic model for converting to a case test model based on the RUCM structure, and main elements thereof include:

With initial conditions for use case entry UseCaseStart pointing to the first step;

Sequential steps Sequence for pointing to subsequent sequences;

pointing to Condition step conditions of different subsequent steps according to the true and false conditions;

an Internal step International representing operation within the system;

Representing an Input operation for connecting to an Input step Input representing Input data DomainEntity;

include containing other use cases;

a use case outlet Exit for indicating an ending step;

A use case exit Abort for indicating an abnormal end;

an interrupt condition InterruptingCondition for executing a global or limited scope of alternative flows;

Representing the inlet conditions AlternalFlowStart of the alternative flow.

6. The method for automatically generating system test cases based on the RUCM according to claim 1, wherein in S3, the generating process of the case test model comprises:

s31, identifying and extracting keywords in the RUCM;

s32, based on the case test meta-model, instantiating the steps in the RUCM document into corresponding types of nodes, and displaying the implicit control flow into the test case model so as to convert the RUCM user requirements into a visualized test case model.

7. The method for automatically generating system test cases based on RUCM according to claim 1, wherein in S4, the case test model is traversed by a recursive depth-first algorithm to generate different test scenes and path conditions involved in each scene, and the following coverage criteria are followed in the traversal process:

Criterion one, for each Condition instance not belonging to InterruptingCondition types, first access the true branch and then the false branch to prioritize the elementary stream scenes;

a second criterion, when processing non-Condition nodes, continuing to go deep to the next node through node. Next, and continuously searching until no deeper nodes exist;

Thirdly, traversing a scene only once when encountering a RESUME node in one cycle;

And the fourth criterion is that for each traversed conditional step in the current scene, if the next conditional step enters a true branch, directly adding the related constraint number into the constraint array, otherwise, adding an inverse mark in front of the constraint number related to 'ON CONDITION FAILURE C +id' in the first step in the false branch, and then adding the inverse mark into the constraint array.