Software module testing strategies

When testing software modules, 2 debug strategies are used: 1. from the structure; 2. from the data.
The first strategy is based on the structure of the module, built on the program text in the form of a directed graph. The graph highlights and organizes the routes of program execution and the conditions under which they can be implemented. These conditions are used for the preparation of test kits, each of which must be realized along the route taken as a standard in preparing the test. Deviations from using the test from the originally selected route is an error. It can be localized either in the primary structure of the PM, or in the implementation of a specific route with this test at the entrance. After eliminating the errors, the inconsistencies of the used and selected routes for each of them check the data processing process and identify errors as a result of their conversion. Debugging ends with full coverage of the graph of the program with tested routes or full use of resources allocated for debugging. This strategy has advantages when testing logic programs with a small amount of computation.
In the second strategy, specific test values ​​are taken as a basis, which are prepared by analyzing variables and predicates in the program text. With each test, the program is executed along a specific route that is being registered. As debugging progresses, verified operators are noted and the fullness of test coverage of all components in test routes is assessed. The accumulation of implemented routes allows you to reproduce the full structure of the program and control the degree of verification of each component. With such a strategy, it is difficult to assess the degree of verification of the main use routes of the program, without using a structural graph constructed from the original test. This strategy has + with a relatively simple program structure and the predominance of computing operators in it.
On each route, attention is focused on the computational part of the program. At the same time, there is a risk of missing a combination of predicates defining untested routes; it follows from this that it is almost always advisable to use two strategies together.
Programs with a complex logical structure and a small computational part are better tested first by 1 strategy, and for routes with computational operators use data flow analysis.
Programs that have a simple structure and contain a large amount of computation first use 2 strategies, and end with debugging 1 strategy each.
Ascending and descending testing
For upstream testing, the software modules of the lower hierarchical modules are first verified. The modules that call them are connected in series. In these modules, debugging the same begins with the simplest structures and information processing routes. In this case, the debugging methods used and the types of errors detected are consistently complicated.
The main difficulties with such a strategy are to continuously update and increase the number of test cases as the components of a higher level are connected. At the same time, the testing of components of the lower levels deepens, which leads to an increase in their quality.
For downstream testing, debugging begins with computation process organization programs. At first, the control core of the complex of programs and programs for solving functional tasks located at the highest hierarchical levels is tested. Components of lower levels are connected in series. This strategy is effective if there is a set of proven software modules. The advantage of this strategy is the preservation and consistent development of test source data as components are connected.
Stages and tasks of testing software components
The most typical are the tasks of testing the following objects:
1. Formalized specification of requirements for software and information modules, for groups of programs and software systems.
2. Program modules are programmed and prepared for debugging at the source level of programs and at the level of object program codes.
3. Groups of software modules (components) that solve small complete functional tasks.
1. The main purpose of testing the specification is to verify the completeness and mutual conformity of the functions prescribed by the program and information components of different levels. In addition, the correspondence of descriptions of information on the input and output interactions of program modules in the database is checked. Such testing is advisable to carry out a top-down method, starting with the specification of a component or group of programs.
Testing the consistency of interfaces in the specifications of software components is used to detect errors in the descriptions of variables and control transfers in the interaction of modules and program groups. According to the block diagram of the program complex, a list of successively called modules is established and verification of the call descriptions in the program specifications is correct. For each input, the variable is composed of its name and description of the specification of this module, descriptions of operations of those models where this variable is used.
2. The main task of testing and debugging the functions of software modules is to verify the correctness of the incoming information processed by the modules and is obtained on the output data in accordance with the functions presented in the specifications. The correctness of the structure of the modules and the applied structural components must be verified. Verification subject to information processing routes in each module and the correctness of their implementation, depending on the source data. The completeness of the test is determined by the degree of coverage of possible routes of the program. Testing of calculations and data conversion by software modules is used to detect errors in the computational part of the program. The benchmarks are the results of preliminary calculations on files embedded in the modules. Testing of software modules should be carried out on ordered data sets, taking into account the degree of their influence on the output results. From this point of view, there are 2 types of data processing:
1. the ability to completely change the scope of the results;
2. modifying results within a certain limited domain.
The first type of processing corresponds to the initial data at critical points and at the boundaries of the regions of change of variables. With such critical values, the route of the program execution may change, therefore the greatest changes in the results are possible, therefore testing of data processing must first of all be aimed at checking the execution of programs with the values ​​of variables affecting the choice of route and the logic of the program's operation.
The second type of processing corresponds to data on a bounded (unlimited) domain of definition, which can be divided into some sets of contiguous regions. Changing the data inside such an area does not affect the program execution route. To test the functioning of the program, it is sufficient to use only a few values ​​inside and near the borders of the area when testing.
Testing the completeness of the functions performed by the modules is intended to identify errors in the development of the program with respect to the functions specified by the program specification. Testing is subject to the implementation of all functions defined by the specification, and the characteristics of the intermodular interface. When checking the correctness of the functions, the results are used that precede the testing of the structure and calculation in the modules. To test the unsupervised function, special tests are created. In order to cover all possible variants of the initial data including. abnormal with various distortions.
3. Testing of software components is intended to verify the correctness of the solution of rather large autonomous functional tasks. At this stage, the validity of the checking and information links between the groups of modules is checked, as well as the correctness of the calculated functions during the processing of information in the group of programs.
Testing the structure of a group of programs is used to detect errors of conformity with the actual structure of the group and its specification. Checks the correctness of calling program modules (PM) and control returns when they interact in the group being debugged. The technology of testing the structure of groups of programs is similar to the technology of testing PM.
Testing the intermodule interface in a group of programs is designed to detect errors of information communication between the modules in the group. Links are also checked through global data prepared and used by other functional groups of programs when interacting with the group being debugged. Each variable (array) should be checked for the identity of the descriptions in the texts of the programs of interaction between the modules, as well as for compliance with the original program specifications. Testing of data streams is performed mainly at the level of interaction between the PM. All implemented information interfaces of the components in the group and with the external environment. mapped to specifications.
Testing on the implementation of restrictions on the use of memory and the permissible duration of the CIP-I group of programs is designed to detect errors in the use of real computer resources by the developed functional group of programs. The most difficult is to test the use of computer performance resources in real time.
Testing the completeness of solving a functional task by a group of programs serves to complete the group of programs and to detect errors remaining after previous types of testing. Testing is performed in accordance with the specification of requirements for a group of programs. Of particular importance are tests for testing programs at specific points of the values ​​of the original parameters and combinations under critical conditions in the data. Testing is completed by registering the results obtained and issued the test protocol.
Testing of the completeness and correctness of the documentation is intended to detect errors of compliance of the implementation of the program with all the design and operational documentation accompanying it. Most of the previous testing of software components is done using incompletely formalized design and operational documentation. That allows you to partially verify its correctness. This group of tests is final and is intended to record the quality of official documentation on software components. All test cases accompanying the instruction manual should be checked most fully in the documentation, in addition, verification of the documentation compliance with the standards and design of the program should be carried out.