Unit test, integration test, System test summary

One, Unit test

Unit testing is the minimum unit of software design----------the test of correctness test. The goal is to discover possible errors within each program module.

Unit testing is also a basic responsibility of programmers, and programmers must maintain a conscientious attitude to the code they write, which is one of the basic professional qualities of a programmer. At the same time, unit testing capability is also a basic ability of programmers, which directly affects the productivity of programmers and the quality of software.

In the process of coding the Unit test, the cost is minimal, but the return is particularly generous. Consider testing problems during coding, and you'll get better code, because at this point you know what the code should do best. If you don't, you'll have to wait until a module crashes, and then you may have forgotten how the code works. Even under strong working pressure, you have to re-figure it out again, and it will take a lot of time. Further, such corrections are often less thorough and potentially more fragile, because the understanding you call back may not be so complete.

Normally qualified code should have the following properties: Correctness, clarity, standardization, consistency, efficiency, etc. (sorted by priority).

1. Correctness means that the code logic must be correct and capable of achieving the expected functionality.

2. Clarity means that the code must be concise and understandable, with no ambiguity as to the accuracy of the annotations.

3. Normative means that code must conform to the common norms defined by the enterprise or department, including naming rules, code styles, and so on.

4. Consistency refers to the code must be named (such as: the same function of variables as far as possible to use the same identifier), style is consistent.

5. Efficiency refers to the code not only to meet the above properties, but also to minimize the execution time of the code.

Method of unit Testing:

After the code is written, the unit test work is divided into two steps: manual static Check and dynamic execution tracking.

Manual static check is the first step of the test, this phase of the work is to ensure the logic of the Code algorithm correctness (as far as possible through manual detection of Code logic errors), clarity, standardization, consistency, algorithm efficiency. And as much as possible to find errors found in the program.

The second step is to find errors by designing test cases and executing the program to be tested to track comparisons between actual and expected results. Experience has shown that the use of manual static inspection can effectively detect 30% to 70% of logical design and coding errors. However, there are still a large number of hidden errors in the code can not be seen through visual inspection, must be carefully analyzed through the tracking debugging to be able to capture. Therefore, the dynamic tracking and debugging method has also become the focus and difficulty of unit testing.

Second, integration testing

　Integration testing refers to the joint testing of individual components of an application system to determine whether they can work together without conflict. A part can be a block of code, a standalone application, a client on a network, or a server-side program. This type of testing is especially relevant to client servers and distributed systems. Before the general integration test, the unit test needs to be completed.

Integration testing is a logical extension of unit testing. Its simplest form is: Two tested units are assembled into one component, and the interfaces between them are tested. In this sense, a component refers to an integrated aggregation of multiple cells. In a real-world scenario, many units are assembled into components that are then assembled into a larger part of the program. The method is to test the combination of fragments and eventually extend the process to test your module with the other group's modules. Finally, all modules that make up the process are tested together. In addition, if a program consists of multiple processes, you should test them in pairs instead of testing all the processes at the same time.

Integration testing identifies problems when combining units. By using a test plan that requires testing each cell before the composition unit and ensuring the viability of each unit, it is possible to know that any errors found in the composition of the unit are likely to be related to the interface between the cells. This approach reduces the number of possible scenarios to a simpler level of analysis.

Methods of integration testing:

From bottom up integration

This strategy can be applied to almost any system. This strategy starts with a low-level, inter-dependent module that can be used to test these modules with drivers. This strategy can be used to build up the system gradually, or to set up subsystems in parallel, then set into a complete system. This integration can begin early in the development process. Of course, if the project plan in the module submission is also a bottom-up approach, then the use of this method can be detected early interface problems, and these interface problems are relatively easy to isolate, so the cost of the solution is low. The main drawback is the need to use many drivers to execute this strategy, and because the tests need to be iterative, it is also a time-consuming strategy.

Integrated from top to bottom

This strategy is guided by the control structure of the system. The control structure is developed in order from the top down, which also provides the ability to start from the upper control module and to integrate the module from top to bottom. For each new level, the relevant modules at the same level are integrated and tested. A module role that does not yet exist can be implemented with a placeholder. One drawback of adopting this integration strategy is that if the requirements change, the changes affect the underlying modules, which will also cause the upper modules to change. This can lead to the need to re-start the integration and test process (partially). Another disadvantage is the large number of placeholders that must be used to test each integration step. If integration testing begins early in the upper module, even if the placeholder is used to replace the main part of the system. The overall overview of the system and how it works can still be observed.

Third, System testing

System testing is a confirmed software, computer hardware, peripherals, networks and other elements together to carry out a variety of information system assembly testing and validation testing, its purpose is to compare with the needs of the system, found that the development of the system and user needs inconsistent or contradictory places, thereby proposing a more complete program. Its task is to check out the errors in the program as thoroughly as possible, improve the reliability of the software system, and the purpose is to test the system "How did it go?" "。 This stage can be divided into three steps: module testing, testing each module for errors, assembly testing, testing the interface between modules is correct, confirm the test, test the entire software system to meet the requirements of user function and performance. The end of the phase should deliver a test report explaining the selection of test data, test cases, and whether the test results meet the expected results. After the test finds the problem, it is debugged to find out the cause and location of the error and correct it. is a black box class test based on the overall requirements specification of the system, which should cover all the components of the system. System testing is a test of the entire product system to verify that the system satisfies the definition of the requirements specification and to identify areas that do not conform to or contradict the requirements specification.
The object of system testing is not only the software of the product system that needs to be tested, but also the hardware that the software depends on, the peripherals even include some data, some supporting software and its interface. Therefore, the software in the system must be combined with a variety of dependent resources to test the system in its actual operating environment.

How to test the system:

1. Recovery test

Recovery testing primarily checks the system for fault tolerance. Can you fix the error within a specified time interval and restart the system when the system is faulted. Recovery testing the first thing to do is to force the system to fail, and then verify that the system recovers as quickly as possible. The correctness of mechanisms such as re-initialization (reinitialization), Checkpoint (checkpointing mechanisms), data recovery, and restart (restart) are required for automatic recovery For human-assisted recovery systems, the average repair time needs to be estimated to determine whether it is within acceptable range.

2. Safety Test

The safety test checks the system's ability to prevent intrusion. During the security test, the testers disguised as illegal intruders and tried to break through the line of defense by various means. For example, ① tries to intercept or decipher the password, ② specially custom-made software to destroy the system protection mechanism, ③ deliberately cause system failure, attempt to take advantage of the recovery of the machine illegally enter, ④ try to browse non-confidential data, deduce the required information, and so on. Theoretically, as long as there is enough time and resources, there is no system to enter. Therefore, the criterion of system security design is to make the cost of illegal intrusion exceed the value of protected information. At this time the illegal intruders are unprofitable.

3. Strength test

The strength test examines the ability of the program to withstand abnormal conditions. Strength testing always forces the system to run under an abnormal resource configuration. For example, ① a test case that runs 10 interrupts per second when the normal frequency of interrupts is one to two per second, and ② quantitatively increases the data input rate to check the reflection capability of the input sub function; ③ Run test cases that require maximum storage space (or other resources) ④ run a test case that could cause a virtual-memory operating system crash or severe disk data jitter, and so on.

4. Performance test

For those real-time and embedded systems, even if the software part meets the functional requirements, it may not be able to meet the performance requirements, although from the unit test, each test step contains a performance test, the lead survey that only when the system is truly integrated, in the real environment can be comprehensive, Reliably test run performance system performance tests are done to accomplish this task. Performance testing, sometimes combined with strength testing, often requires support from other hardware and software.

Unit test, integration test, System test summary