Lecture
This methodology establishes the basic methods, technologies and documents that provide testing and debugging of software modules and software components consisting of several modules. The initial data for testing that needs to be fixed and documented before starting work are:
1) Documentation for the developed software component. This includes the terms of reference and / or specification of requirements for the development of the program, the program description in the form of a printed document, the user's manual, the source text of the program in the form of a printed document, on magnetic other media.
2) Rules for building and describing programs at different levels and languages. Structural construction rules and component interfaces between themselves and the external environment.
3) Specific methods for testing programs: static and dynamic, deterministic and stochastic, etc., are applied depending on specific objects.
4) The criterion for the quality of testing and debugging programs.
5) Reference values and distribution of source data and results, reflecting the requirements of the functions and quality indicators of the program component being created.
6) Tolerances for deviation of results of functioning and quality indicators from reference values.
7) Real testing resources.
Before starting testing specific software modules and components, you need to make a test plan. It should include the following steps:
1. The choice of testing method, corresponding to the main goal.
2. Planning for testing in accordance with the selected method, taking into account resource constraints.
3. Preparation of tasks for testing with indication of monitored parameters, source data and standards.
4. Implement the testing process and get results.
5. Comparison of results with standards.
6. Diagnosis, localization and correction of errors and defects.
7. Assessment of the completeness of testing and the need to use other testing methods.
8. Determining the quality of programs achieved.
The implementation of testing is also performed in several stages:
1) The identity of the source text of the programs presented on the data carrier with the source text presented in the program document is tested.
2) The integration of the statics of the software and information modules included into their components is carried out, while all interfaces between the modules are checked and their inconsistencies are identified with a description of the specification.
3) The analysis of control flows in the program text is made, highlighting the main subroutines, modules, procedures and functions, and the control operators of the computational process are analyzed. For all levels of the hierarchy of the program, flow graphs are built, which are used to highlight the routes of program execution.
4) The analysis of data streams is performed, the correctness of data processing is tested without using the program. The purpose of this stage is to establish the correspondence between the areas of definition of data sets and the routes of their processing in the program.
5) Elimination of inconsistencies between the program and information modules included in the component.
6) Processing of test results and evaluation of quality and correction in statics. Deterministic and stochastic test usage results are compared with reference values.
7) A check is performed on the completeness of test suites. The testing process is considered complete if all sets of test values of the input data were processed, and there were no program failures, stops or results distortion.
The fact that the software component of a given specification meets the formal requirements is considered established if the following results are obtained:
1. The program has the correct structure; 2. Each of the routes ends in a finite number of steps; 3. For each function, there is a non-empty set of routes; 4. no matching routes and data; 5.No unrealized and dead-end routes; 6.program specification meets the requirements of standards and implemented functions; 7. integration of the interaction with the function of the component with other groups of programs is performed, the interaction of the debugged component with other groups of programs is checked, it can be connected to the OS in the form of a boot module; 8. processing the results of debugging, quality assessment and correction of a functioning component in interaction with other components in statics. At this stage, the results of the analysis of the technical assignment, the description of the application of the program with the presented test suites are compared, and conclusions are drawn about the ability of this test suite to fully verify the declared functionality.
7. Documentation of software component test results.
When testing programs, 2 types of documentation are created and tested: 1. Documentation reflecting the state of test objects. 2. Documentation that implements the processes and test results.
Each document must have: assignments, its scope, categories of specialists for which it should be applied, the substantive part in accordance with its purpose.
A system for documenting processes and test results is described in the ANSI / IEEE 829 standard. This standard should be used as a basis for real-world developments. The documentation system covers test planning, test results reports.
At stage 1: the identity of the source text of the programs presented on the data carrier with the source text presented in the program document is tested.
At stage 2: Mfr. integration into the statics of programs and information modules… ..
At the same time, all interfaces of the m / y modules are checked and their inconsistencies with descriptions in the specifications are identified.
At stage 3, an analysis of control flows is performed. The text of the program highlights the basics. subprogram modules; procedures and functions. And analyzed control operators computational process.
For all levels of the hierarchy of the program. flow graphs are built, cat. used to highlight the routes of execution of the program.
At the 4th stage, the analysis of data flows is performed. testing the correctness of the processed data without ipolz. prog. The purpose of this stage is to establish the correspondence of the m / o OO data sets and the routes of their processing in prg.
At the 5th stage, inconsistencies between the m / s prog and information modules included in the component are eliminated.
At the 6th stage, the processing of test results and the quality assessment, and the correctness of the component in statics are performed. Deterministic and stochastic test execution results are compared with reference values.
At stage 7, a test of the completeness of test suites is performed. The testing process is considered complete if all sets of input test values have been processed and there have been no failures, stops or distortion of the results. The fact of compliance programs. components specified in the specification of functional requirements is considered to be installed if the following results are obtained: 1. the program has the correct structure; 2. For each function there is a nonempty set of routes; 3. Each of the routes ends in a finite number of steps; 4. there is no discrepancy between routes and data; 5. there are no unrealized and dead-end routes; 6. software documentation complies with the requirements of the standards and implemented functions.
At the 8th stage, integration of the functional component with other groups of programs is carried out. At the same time, the interaction of the debugged component with other components and with the database model of the whole PS is checked.
At stage 9, connect the components to the operating system OS PC. After the main problems of interaction of components with other groups of programs are eliminated, it can be. connected to the OS as a boot module.
At stage 10. Processing debugging results, quality assessment and correctness of functions. components in conjunction with other components in statics. Compare the results of the analysis of those. tasks, descriptions of the use of the program with repr. test suites and concluded that the ability of this test suite to fully verify the recited funkts. opportunities.
8. Documenting the results of testing prog. component
When testing a program, two types of documentation are created and used: 1. documents that reflect the state of test objects; 2. Doc-ing, characterizing the processes and results of testing.
Each document must have a formulated assignment, its scope, professional category, for the cat. it is intended and by whom it is developed; stages of work on the cat. it must be applied; content part with acc. his appointment. The system for documenting the processes and results of testing is presented in the ANSI / IEEE829 standard. This standard must be used as the basis for real-world development.
The documentation system covers: test planning, spec. tests and test results reports.
Comments
To leave a comment
Software reliability
Terms: Software reliability