Software testing common sense

The history of software development and use has left us with many lessons learned from the huge financial and material losses caused by software defects. These lessons have forced us test engineers to take strong detections to detect undetected hidden software defects.

The ultimate goal of production software is to meet customer needs. We use customer requirements as a criterion for judging software quality. We believe that the specific meaning of Software Bug includes the following factors:

• Software does not meet the functionality and performance required by customers;

• Software exceeds customer requirements;

• Software has errors that cannot be tolerated by customers;

• Software Use does not meet the customer's habits and work environment.

Considering the design and other factors, we can also think that software defects can also include software design that does not meet the specifications, failing to achieve the best conditions (funds, scope, etc.). Unfortunately, many of us are more inclined to think of software defects as runtime problems, and that software testing is limited to after the program is submitted.

In the current domestic environment, we can hardly see complete and accurate customer demand specifications, and the needs of our customers are changing from time to time. It is impossible to pursue perfect tests. Therefore, as an excellent tester, the pursuit of the perfection of software quality is certainly our aim, but to clarify the gap between the reality and the ideal of software testing, learn to choose and give in software testing, there is no harm to software testing. .

The following are some common sense of software testing. The understanding and application of these common senses will help us better grasp the scale of software testing when testing software.

• Testing is incomplete (test is not complete)

Obviously, due to incompleteness of software requirements, combination of software logic paths, large amount of input data, and diversity of results Other factors, even an extremely simple program, to exhaust all logical paths, all input data and verify all results is a very difficult thing. Let's take a simple example, such as finding the greatest common divisor of two integers. Its input information is two positive integers. But if we test the number of the entire positive integer field, from the infiniteness of its number, we can prove that such a test will not work in real life, even if we can exhaust the program one day, I am afraid We and our children and grandchildren have long been old. For this reason, as a software test, we generally use the equivalent class and boundary value analysis to conduct actual software testing. Finding the minimum use case set becomes a necessary way for us to streamline the test complexity.

• Testing is immune (software defect immunity)

Software defects are as terrible as “immunity” as viruses, and the more tests the tester uses, the more immune they are. The stronger it is, the more difficult it is to find more software defects. We can make this conclusion from the mathematical probability theory. Assuming that there are 500 software defects in a 50000 line program and the software errors are evenly distributed, a software defect can be found every 100 lines. We assume that the tester spends some time looking for software defects in X hours /100 lines. Based on this calculation, when the software has 500 defects, it takes X hours to find a software defect. When there are only 5 errors in the software, we need 100X hours for each software defect. Practice has proved that the actual test process is more demanding than the above assumptions, so we must replace different test methods and test data. This example also shows that a single method in software testing cannot efficiently and completely address all software defects, so software testing should be tested in as many ways as possible.

• Testing is “generic concept” (full test)

I have always opposed software testing only after the program is completed. If the stage after the programming phase is simply called software testing, the amplification effect of the defects in the demand phase and the design phase will increase. This is very detrimental to the quality of the software. Defects in demand and design flaws are also software defects, remembering that "software defects have fertility". Software testing should span the entire software development process. Requirements verification (self-test) and design verification (self-test) can also be counted as one of software tests (recommended as: demand test and design test). Software testing should be a generic concept that covers the entire software lifecycle to ensure that each phase of the cycle is forbidden. At the same time, the test itself needs to have a third party to evaluate (information system audit and software engineering supervision), that is, the test itself should also be tested to ensure the reliability and efficiency of the test itself. Otherwise, it is not correct and it is difficult to serve people.

It is also necessary to point out that software testing is a necessary and not sufficient condition for improving the quality of software products. Software testing is the most direct and quickest means to improve product quality, but it is by no means a fundamental means.

• 80-20 Principles

80% of software defects often live in 20% of the software space. This principle tells us that if you want to make software testing effective, remember to visit its high-risk multiple "locations". There is a much greater likelihood of finding software defects there. This principle is of great significance for software testers to improve test efficiency and defect discovery rate. Clever testers will quickly find more defects based on this principle, while stupid testers are still searching aimlessly.

80-20 Another aspect of the principle is that we can find and avoid 80% of software defects in the system analysis, system design, system implementation stage, and test work. After that, system testing can help We identified 80% of the remaining defects, and the last 5% of software defects may only be revealed after the system has been delivered for a wide range of long-term use. Because software testing can only guarantee to detect as many software defects as possible, there is no guarantee that all software defects will be discovered.

80-20 Principles can also be reflected in the automation aspects of software testing. It has been proven that 80% of software defects can be discovered by manual testing, and 20% of software defects can be discovered by automated testing. Because of the crossover between the two, there are still about 5% of software defects that need to be discovered and corrected in other ways.

• Testing for Benefits

Why do we implement software testing to improve the quality and efficiency of the project and ultimately to improve the overall effectiveness of the project. For this reason, we can easily find out the degree we should master in implementing software testing. Software testing should find a balance between software testing costs and software quality benefits. This balance point is the degree we should follow when implementing software testing. Unilateral pursuits will inevitably damage the value and significance of software testing. In general, in software testing, we should try to keep the software testing simple, do not over-complicate the software testing, in the words of physicist Einstein: Keep it simple but not too simple.

• The inevitability of defects

In software testing, not all software defects can be fixed due to the wrong correlation. Although some software defects can be repaired, we will inevitably introduce new software defects during the repair process. Many software defects are contradictory, and the disappearance of a contradiction will inevitably lead to another contradiction. For example, when we solve the deficiencies of generality, we often bring defects in execution efficiency. Moreover, in the process of repairing defects, we often suffer from limitations in time and cost, so we cannot effectively and completely repair all software defects. Therefore, assessing the importance of software defects, the scope of influence, choosing a compromise solution or considering software defects from non-software factors (such as improving hardware performance) is a fact that we must face in the face of software defects.

• Software testing must have expected results

Tests with no expected results are unreasonable. Software defects are derived from comparisons. This is just as there is no standard to measure. If we don't know or we can't be sure of the expected results, we can't understand the correctness of the test. It is easy for people to feel like a blind person. Many testers often judge the occurrence of software defects by their own feelings. The result is often judged by plausible things as correct results, so misdetection often occurs.

• The meaning of software testing - Post-mortem analysis

The purpose of software testing is simply to find defects so simple? If it is "yes", I can guarantee that similar software defects will occur in the next software test of the new project. The old saying goes well, "People who don't know history will inevitably repeat the same mistakes." Without a careful analysis of the software test results, we can't understand the causes and countermeasures of the defects. As a result, we have to spend a lot of manpower and resources to find software defects again. Unfortunately, most test teams are not aware of this at present, and there is a lack of test results analysis in the test report.

Conclusion:

Software testing is a process that requires "consciousness". As a tester, he is calm and holds the scale, and fundamentally responds to software testing with a correct understanding. I hope this article It is helpful for readers to understand software testing.