Writing requirements is a two-way process. In this paper we use to classify Functional Requirements (FR) and Non Functional Requirements (NFR) statements from Software Requirements Specification (SRS) documents. This is systematically transformed into state charts considering all relevant information. The current paper outlines how test cases can be automatically generated from these state charts. The application of the states yields the different test cases as solutions to a planning problem. The test cases can be used for automated or manual software testing on system level. And also the paper presents a method for reduction of test suite by using mining methods thereby facilitating the mining and knowledge extraction from test cases.
The systematic production of high-quality software, which meets its specification, is still a major problem. Although formal specification methods have been around for a long time, only a few safety-critical domains justify the enormous effort of their application. The state of the practice, which relies on testing to force the quality into the product at the end of the development process, is also unsatisfactory. The need for effective test automation adds to this problem, because the creation and maintenance of the test ware is a source of inconsistency itself and is becoming a task of comparable complexity as the construction of the code.
Data mining algorithms can be applied at different levels of abstraction and help the user discover more meaningful patterns. Data mining will create patterns from the existing database. Using well-established data mining techniques, practitioners and researchers can explore the potential of this valuable data in order to manage their project and to produce higher quality software systems that are delivered on time and within budget.
In the current paper, we provide the Software Requirements Specification to the classifier system. For classifying we use Weka. From NFR we derive the state machine. State machines specify the behaviour of a system/subsystem. The scope of our method is the generation of test sequences supplemented by constraints on the test data, as far as these can be derived from the information presenting the state machine.
The method given in [3] can be used to create test cases from state machine diagrams which is as follows:
There are three main steps in test case generation, in the first step a predicate is selected on a transition from a UML state machine diagram. In the next step, the selected predicate is transformed into a predicate function. In the third step, test data are generated corresponding to the transformed predicate function. The generated test data are stored for use with an automatic tester. Once the test data corresponding to a particular predicate are determined, the steps are repeated by selecting the next predicate on the state machine diagram. The process is repeated until all Predicates on the state machine diagram have been considered.
For selecting a predicate, a traversal of the state diagram is performed using depth first (DFS) traversal or breadth first (BFS) traversal to see that every transition is considered for predicate selection. DFS traversal is used here. During traversal, conditional predicates on each of the transitions are looked. Corresponding to each conditional predicate, test data are generated.
The test data are generated for each predicate corresponding to the true or false values of the conditional predicate satisfying the prefix path condition.
Let I0 consists of all variables that affect a predicate q in the path P of a state machine diagram, then two points named ON and OFF for a given border satisfying the boundary-testing criterion are created. The relational expressions of the predicates are transformed into a function F called predicate function. If the predicate q is of the form (E1 op E2), where E1 and E2 are arithmetic Expressions and op is a relational operator; then F = (E1 -E2) or (E2 -E1) depending on whichever is positive for the data I0. Next, the input data I0 is modified such that the function F decreases and finally turns negative. When F turns negative, it corresponds to the alternation of the outcome of the Predicate. Hence, as a result of the predicate transformation, the point at which the outcome of a predicate q changes, corresponds to the problem of minimization of the corresponding function F. This minimization is achieved through repeated modification of the input data values.
The basic search Procedure we use for finding the minimum of a predicate function F is the alternating variable method. This method is based on minimizing F with respect to each input variable in turn. An initial set of inputs can be randomly generated by instantiating the data variables. Each input data variable xi is increased/ decreased in steps of Sxi, while keeping all other data variables unchanged. Here, Sxi refers to a unit step of the variable xi. The exact value of unit step can be defined conveniently. For example, unit step of 1 is normally used for integer values. Unit step can easily be defined for many other types of data such as float, double, array, and pointer and so on.
However, the method may not work when the variable assumes only a discrete set of values. Each predicate in a path can be considered to be a constraint. A path will not be traversed for some input data value, if the corresponding constraint is not satisfied. If a path P is not traversed for some data value, then we say that a constraint violation has taken place for that data value. We compute the value of F when each input datum is modified by Sxi. If the function F decreases for the modified data, and Constrai
This content is AI-processed based on open access ArXiv data.
