Unit testing are small modules (procedures, classes, etc.). When testing a relatively small unit size of 100-1000 lines have the possibility to check, if not all, then, at least, many branches of logic in the implementation, different paths in the graph depending on the data, the boundary values. In accordance with these criteria are based test coverage (covered by all the operators, all of the logical branches, all the boundary points, etc.).
Checking the correctness of all modules, unfortunately, does not guarantee the correctness of the system modules. The literature is sometimes considered “classical” model irregular organization of testing the system modules, often referred to by the “great leap”. The essence of the method is to first test the each module separately, then combine them into a system and test the system entirely. For large systems, this is unrealistic. With this approach will be spent very much time to localize errors, and the quality of software testing remains low. Alternative to the “great leap” – integration software testing when the system is constructed in phases, groups of modules are added gradually.
Dissemination of component technologies spawned the term “component software testing” as a special case of integration software testing.
Fully implemented the software system being tested. At this stage, the tester are not interested in the correctness of the implementation of certain procedures and methods, and the entire program as a whole, as it sees the end user. The basis for the tests serve as general requirements for the program, including not only the correctness of the implementation of functions, but also productivity, response time, fault tolerance, attacks, user error, etc. For system and component software testing using specific types of test coverage criteria (eg, whether covered all typical scenarios, all scenarios with emergency situations, the pairwise composition scenarios, etc.).
After graduating excursion into methodology, let us return to the issue of what software testing tools are currently being used and how they correspond to new ideas about the place of software testing during software development.
At the moment, to the greatest extent automate the following stages: performance tests, collect the data, analysis of test coverage (for unit software testing are usually collected information on the covered operators and covered with branches of logic), tracking the processing status of requests for correction of errors.
Overview of test tools will be carried out in reverse order – from a modular system software testing.
Widespread application software testing tools with a graphical user interface. They are often called tools for functional software testing. If the level of responsibility of the application is not large, so software testing can be limited, such software testing is the most cheaply.
In this form of software testing is widely used tools record-playback (record / playback); of the most well-known products include Rational Robot (company IBM / Rational), WinRunner (Mercury Interactive), QARun (Compuware). Along with this there are some tools for text-based terminal interface, for example, QAHiperstation company Compuware.
For system load software testing Web-based applications and other distributed systems, widely used tool LoadRunner from Mercury Interactive; it is not aimed at the generation of sophisticated test scripts, but provides a wealth of material for performance analysis, finding the bottlenecks affecting the performance of a distributed system.
Estimated overall scheme of using record-playback tool is as follows:
The resulting script can be run repeatedly, making it necessary for small change.
When writing the script can make stops in order to specify which system responses in a particular situation should be viewed as correct, any variation of the user input is possible, etc. In the presence of such variations the next time you play the test instrument itself will choose one of the identified alternatives. If you do not match the expected response of the system response will be fixed bug.
However, the possibility of this type of software testing is limited:
The next class of tools – tools to test the components. An example is Test Architect (IBM / Rational). These tools help to organize the software testing of applications built on one of the component technologies (eg, EJB). Provides a set of templates for creating various components of the test program, in particular, tests for modules, scripts, caps.
Does the tool demand advanced test development? In general, yes: to create a test sufficiently describe interfaces of components. But there are weaknesses, which, however, are inherent to most other instruments. Thus, the test script to write manually. In addition, there is no single set of criteria for test coverage and communication of these criteria to functional system requirements.
The last of the classes discussed here of tools – tools to test the modules. An example is the Test RealTime (IBM / Rational), designed to test the modules on C + +. An important component of this tool is a verification mechanism “statements» (assertion). With the help of statements we can formulate the requirements for input and output data functions / methods of classes in the form of logical conditions in a similar form can specify the invariant requirements for data objects. This is a significant step forward compared with the Test Architect. The device enables the allegations in a systematic way to represent functional requirements and based on those requirements to build the criteria for test coverage (though, Test RealTime support for automated coverage analysis does not provide).
In principle, this tool can be used for advanced development of tests, but it remains unfulfilled is the same generation function properly test stimuli – this work must be done manually. There is no technical and methodological support for reuse of tests and results.
The solution of these problems offers a new generation of tools that follow the approach of software testing based on the model (model based software testing) or on the basis of specifications (specification based software testing).