Abstract
Master's Qualification Work
"Test Cases Generation Based on Object-Oriented Models"

      Introduction


      An important task in the development and implementation of software it is testing. It usually takes from 30 to 50 percent of the time that was spent on the creation of products. In this regard, is it appropriate to develop a system that will simplify the testing process that will positively affect both the quality of products, and at the time of production.


      Topical issue


Every day comes a lot of software products, which often fail for the desired level of testing. The development of this system will simplify the process of testing and shorten it’s time.


      Aims of development


      The purpose of master's work is the creation of an automated system for test case generation based on object-oriented model.

      The main objectives of the system is:

    1) optimization of a set of tests;
    2) reduce the period of testing;
    3) increasing the coverage of the system.

      The general formulation of the problem


      Software development process consists of 5 stages: nomination of requirements analysis, design, development, testing [1].


      Producing quality software is the main task of developers. But in addition to the design, a lot of time and money spent on verification of manufactured product. The process of testing software to assess the quality of the software product, to assess its readiness for implementation. At present testing methods do not reveal all the possible "failure" when considering large scale information systems and give a definite answer about the correctness of the software [1]. But mostly on the quality of verification will depend on how good and popular is the product.


      By testing is not quite a big model, you can check almost all embodiments of a system. But if the system is large, the number of tests and the execution time can be a serious problem for developers and testers. In this regard, there is the problem of optimizing test sets. For this purpose, criteria for test coverage. Criteria for test coverage is a certain set of conditions, following which we can say that the system was successfully tested. At the moment it is believed that a good percentage of coverage of   60 – 70% [2].


      Here are the most common criteria for test coverage:

  • Statement coverage – in a test set T, each state will be performed at least once;
  • Branch coverage – in a test set T, each operator of branching should be executed for both values true and for the value false;
  • Conditional coverage – each condition in the column must be satisfied as to the true and for false;
  • Path coverage – in a test set T, each transition must be performed at least once. [2]

      Today, the issue of testing, namely, its automation, attracted considerable attention. It creates special programs for testing products that use the program code or the model of the system. But, as the bulk of products designed to work precisely with the program code. Due to the fact that there is a huge number of programming languages and design principles of program code, test-based software package is a difficult task doable. Order that would make the testing process is universal, should be used for constructing tests of object-oriented model of the system. We can distinguish three main reasons why you should use the model of the project:

    1) Traditional software testing includes only a statistical review of the code, which is not enough to test the dynamic behavior of the system;
    2) use of code to test the system is complex and time consuming task;
    3) model helps to better understand the system and find the data for testing after viewing the model than the same job with the code.

      Generation of test case, based on object-oriented models, can be initiated at the earliest stages of creating the software and allows you to simultaneously write and test the product.


      The most universal method of testing is considered the last option – the formation of tests based on object-oriented models. To build an object-oriented models most often used language UML. Interaction diagram, class diagram, state diagram can consider the dynamics of interaction of objects in the system and arising from this branch and an alternative flow of events.


      There are 3 types of testing:

    1) black box testing;
    2) white box testing;
    3) gray box testing.

      The basis of testing object-oriented models is the so-called gray box, this kind of testing, when the developer tests is not available through the code, but the algorithm process and all possible conditions that may affect the outcome of the program.


      When considering testing on the basis of object-oriented models Test Case is a set of constants, the values of variables that lead the system into one of the states. For that to understand whether the system is working correctly, compared to test oracle – the expected result of the system after testing and actual result – a result of which the tester receives after testing. Based on the analysis of the results conclusions are drawn as to whether the test passes.


      Presentation of models


      Any model of the system or program can be viewed as a function of Figure 2 – Presentation of models , where S is a set of possible input values and R is a set of possible outcomes. More formally, S is a set of vectors Figure 3 – Input, ), so that Figure 4 – Îinput variables where Dxi is the domain of input variables xi.

      The control flow graph model of P is a directed graph G = (N, E, s, e) which consists of a set of nodes N and a set of edges Figure 5 – Set of edges are connected with nodes. In each box there are two special node s input node and output node e [3].


      Each node can be considered as the base unit, which is interpreted as a sequence of instructions. Performing the block can be understood as performing a sequence of instructions in this block. An edge between two nodes n and m, corresponds to a possible transition from n to m. Each edge represents a predicate with the condition. The predicate can be without conditions – an empty predicate whose value is always true.


      Path p = (p1, p2 ... pqp) – a sequence of nodes, where pqp is the last node path. Running the model P c input parameters xi means that the scenario with the input parameters xi leads to a passage on the path p. The path is called feasible if there exists xi S crosses the path, otherwise it is called is not feasible.

      Figure 1 shows a scheme for generating test data proposed by Beiser.

Figure 1 – Scheme for Test Case Generation

Figure 1 – Scheme for Test Case Generation
(Animation:volum – 23.7 Kb; size – 462õ446; numbers of shots – 4; delay between 500 ms;
numbers of loops – infinity)


      Based on the allegations Beizer, were created to describe the sequence diagrams presented below [2].


      Each figure represents a record of the form D = (A, T, F, C, a1, af), where:

  • A={a1,a2…am} ) is a set of state diagrams ;
  • T={t1,t2…tn} is a set of transition diagrams;
  • Ñ={ñ1,ñ2…cn} is a set of boundary conditions, ñi corresponds to ti. Ñon is displaying the values ti, Ñon(ti)= ñi;
  • Figure 7 – Stream of links between actions and transitions ) is a stream of links between actions and transitions;
  • a1 start node, af terminal node.

      In order to generate Test Cases we need to compare the performance of programs with dynamic performance of the chart [2].


      The method of formation Test Case

      The method of formation Test Case. There are many different algorithms to build tests on the system model. And often, the procedure consists of three basic steps:

    1) formation of the system and putting restrictions and conditions;
    2) interpretation of the model as a graph;
    3) preparation of test sequences (test case.

      Consider these steps more

       Formation of the system and putting restrictions and conditions

       Order that would begin the process of compiling Test Cases must first create a model project. For the development of the project will use UML. The emergence of OCL (Object Constraint Language) has made it possible to impose additional conditions to the UML model. The conditions asked by OCL, make it possible to sequence diagrams and activity, as advanced scenarios of system behavior.


      Interpreting the model as a graph

      Often the formation of test sequences using structured composite graph (Structured Composite Graph). This is to ensure that would systematically investigate the flow control model. Information that is stored in the diagram is transformed, and stored in a structured composite graph. Alternately, all state diagrams are investigated and placed on a graph. To automate the process of building test sequences representation diagram in the form of a graph is very convenient. The model should contain information and requirements for the possible values of variables and to input data, which lead to a change in the state of the system.


      Preparation of Test Case

      The aim is to generate a set of input data xi model P and the path u, that would set xi led to the movement on a script u. There are three class methods for generating test sequences: the generation of random test data, goal-oriented test data generation, path-oriented test data generation.


      Generating random test data

      This method is the easiest to compile test data. It can be used for any type of data. But this method has a small probability of error, and so, as a small test coverage. The data are generated, can not meet certain conditions of the model.


      Goal-oriented test data generation

      ÝThis method is much more efficient random generation. A place to generate data that allow to consider the model from beginning to end, the method generates a set of data that will cross a given unspecific path.


      One of the methods using this technique, a Chain approach. The method of the chain is looking for value for the branch predicates on the basis of imposed conditions. This problem is solved to identify the chain of nodes that must be done that would reach the selected node. This chain is built iteratively in the process of implementation.


      Path-oriented test data generation

      This method is the most efficient of these. It does not provide a choice of ways of a certain set of possible paths, but gives the opportunity to choose one particular path. That this method is somewhat similar to the targeted generation. Use dedicated paths leads to more coverage of the model. On the other hand more difficult to find test data.


      Figure 1 shows a scheme for generating data using the road. An important component of the scheme is precisely the choice of route (Path selector). Selects a set of paths, which will meet the selected criteria for coverage.


       At this moment project is not finished.


      Literature

      1. Journal of Object Technology 2008// A Novel Approach to Generate Test Cases from UML Activity Diagrams.

      2. Journal of Object Technology 2008// Automatic Test Data Synthesis using UML Sequence Diagrams [Electronic resours] Access mode to article: http://www.jot.fm/issues/issue_2010_03/article2.pdf

      3. A survey on automatic test data generation. In Proceedings of the Second Conference on Computer Science and Engineering in Linkoping, pages 21-28.ECSEL, October 1999.

      4. B. Beizer. Software Testing Techniques. Van Nostrand Reinhold, 2nd edition, 1990.

      5. K. Chang, W. Carlisle, J. Cross II, and D. Brown. A heuristic approach for test case generation. In Proceedings of the 1991 ACM Computer Science Conference, pages 174{180. ACM, 1991.

      6. W. H. Deason, D. Brown, K. Chang, and J. H. Cross II. A rule-based software test data generator. IEEE Transactions on Knowledge and Data Engineering, 3(1):108{117, March 1991.

      7. R. A. DeMillo and A. J. O utt. Constraint-based automatic test data generation. IEEE Transactions on Software Engineering, 17(9):900{910, September 1991.

      8. R. Ferguson and B. Korel. The chaining approach for software test data generation. IEEE Transactions on Software Engineering, 5(1):63{86, January 1996.

      9. R. Ferguson and B. Korel. Generating test data for distributed software using the chaining approach. Information and Software Technology, 38(1):343{353, January 1996.

      10. N. Gupta, A. P. Mathur, and M. L. So a. Automated test data generation using an iterative relaxation method. In Proceedings of the ACM SIGSOFT sixth international symposium on Foundations of software engineering, pages 231{244, November 1998.

      11. B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870{879, August 1990.