Dmytro Zinoviev
Faculty: | Computer Sciences and Technologies |
Department: | Automated Control Systems |
Speciality: | Information Control Systems and Technologies |
Theme of Master's Work: | Test Cases Generation Based on Object-Oriented Models |
Scientific Supervisor: | Associate Professor Anastas Fonotov |
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:
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:
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:
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:
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 , 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 , ), so that 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 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
(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:
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:
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. Outt. 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. Soa. 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.