Test type・Unit tests, integration test and system test
- 1. The name of the test along the development phase
- 2. Unit test is a comprehensive test for a single module
- 3. The integration test is a test of the cooperation function of multiple modules.
- 4. System test is a test to find the condition that the software does not work
- 5. Test management using a test plan is important for system testing
- 6. The result of the system test is the discovery of latent bugs and the absence of bugs.
- 7. The actual system test is in the death march
The name of the test along the development phase
To hear most often in the name of the test, unit testing , integration testing , system testing and so on development phase of the software is the name given along. It 's the name of a test that is often used in waterfall models and V-shaped models .
The name of this test is common and easy to use, but be aware that the definition may differ slightly from organization to organization . You can reduce mistakes by checking the definition of the test, paying attention to items such as the time of the test , the person in charge, the purpose , the method of the test , and the method of using the test results .
I will write here with reference to the definition used by Father Gutara, but please read it thinking that this is not the correct answer and there is such a definition.
Unit test is a comprehensive test for a single module
Unit tests are done immediately after coding. The test is performed by the coder itself , and the purpose of the test is to confirm that the source code works according to the detailed design . In the detailed design of software, with functions and functions as the smallest unit, (1) functions to be provided, (2) processing and output for inputs, (3) errors to be detected and processing for those errors, and (4) processing policies for unexpected errors are specifically determined. I will continue. In coding, the contents of these detailed designs will be written down in the actual source code.
Therefore, in the unit test, the contents decided in the detailed design are described in the source code, and we will check that the code works as decided in the detailed design one by one.
The unit test method can be roughly divided into two. The first is to give various inputs and internal states to modules and functions, and confirm that the results and error return values are output as designed. It is also called a gray box test because it is a test method to check whether the output as designed can be obtained for the input after knowing the contents of the source code .
The second method is the same as the first method up to giving various inputs and internal states to modules and functions, but step by step whether the source code is executed as designed for them. It is a method of chasing line by line . It is also called a white-box test because it is a test method that confirms that the source code is executed as designed after knowing the contents of the source code .
A test that confirms the execution of source code step by step is also called a path test . It means a test that confirms the path where the code is executed. When using a path test, the coverage rate of the path test , which is whether all the paths of the written code have been confirmed, is often used as the goal of test execution. The ideal coverage rate is 100% when all paths are tested, but depending on the test conditions and the scale of the software, it is difficult to achieve 100% coverage rate, so we may aim for a coverage rate of 80%. When using coverage rate, it is necessary to pay attention to the definition of coverage rate, whether it is instruction coverage, branch coverage, or condition coverage, so it is recommended that you also read the articles on equivalence partitioning, boundary value analysis, and path coverage. To do.
Unit tests are often carried out in unison with the initial debugging immediately after code creation , and tests are often carried out by the coder itself, so bugs found in the tests will be debugged by the coder as they are. If the person who found the bug and the person who fixed the code are the same, there is no problem even if there is no separate record of the bug reproduction conditions and the reproduction procedure, so it is often the case that the normal bug management is not performed for the bug found in the unit test . Since the purpose of bug management is to improve the quality of software by efficient debugging, it is quite convincing to think that there is no problem even if bug management is not performed in unit tests where bug detection is directly linked to debugging work. ..
The integration test is a test of the cooperation function of multiple modules.
The integration test is a test that is performed after the unit test, but it may be included in the system test when the development scale is small. To carry out the test, the coder itself in the design department if there is also the case of bond tester There is also a case of. This is different depending on the scale of the project.
The purpose of the integration test is to confirm the cooperative operation between multiple functions . Since the unit test confirms the operation of each module, here the function realized by the cooperation of the operations between multiple modules. However, confirm that it works according to the basic design. The basic integration test is a black-box test in which various inputs of normal, abnormal, and quasi-normal systems are given and whether the inputs operate as designed.
The method of testing also varies depending on the development project. However, in order to confirm the cooperation of operations between modules while taking the black box test method of giving various inputs and observing the operation, it is often difficult to perform the test only with the interface originally possessed by the software. Therefore, in the case of integration testing, it is often the case that a test application or test suit for the purpose of conducting the test is created separately from the original software and tested using these. In addition, sometimes a stub dedicated to the test is created to generate various errors on purpose, and the test of the quasi-normal system or the abnormal system is advanced. Of course, there are cases where integration testing is carried out using various interfaces that the software originally has.
If the unit test has sufficiently confirmed the operation of the function alone, the integration test can concentrate on checking the cooperation function between modules . When multiple modules are linked, a mechanism is created to link multiple modules using some kind of inter-module interface , such as via shared memory, message communication, or remote calling. The bond Est, focusing on these intermodule interface, through the interface normal information if it has been exchanged, the error information designed if is exchanged, not in the design abnormal condition occurs in If so, we will test the cooperation function separately.
In the integration test to check the embedded system linkage function, it is important to check the timeout processing from the viewpoint of checking the reliability and robustness of the system, so do not forget this test. When linking functions, even if the function is inside the same computer or on another computer, the linked partner does not always operate correctly. Time-out processing is built in as a mechanism to prevent your processing from hanging up when the other party to cooperate with is for some reason, for example, a bug or an abnormality in the operating environment, and it cannot operate correctly . One of the major purposes of integration testing is to ensure that this timeout process works properly.
In the integration test, the test is performed by multiple designers / implementers separately, or by a specialized integration tester, depending on the development organization. However, since the coder itself often does not test, it is necessary to manage the bugs found in the test correctly . Therefore, it is common to record information in some bug tracking system for bugs found in integration tests, and manage such things as reproduction and subsequent bug fixes.
Discussion
New Comments
No comments yet. Be the first one!