The art of software testing Reading Notes (2)

Chapter 2 psychology and economics of testing

Psychology

The main reason for a poor program test is that most programmers start with an incorrect definition. They may say:

"Testing is a process to prove there is no error ."
Or
"The purpose of the test is to demonstrate that the program has implemented the correct functions ."
Or
"Testing is a process of building confidence that the program can be correctly executed ."

These definitions are put before the horse.

When you test a program, you want to add value to it, that is, to improve quality and reliability. Improving Reliability means identifying and removing errors. Therefore, do not test to prove that the program is correct, but try to identify as many errors as possible.

Therefore, a better definition for testing should be:

"Testing is the process of executing a program with the purpose of looking for errors ."

Testing is a process of destruction or even abuse. (In fact, most people tend to build rather than destroy it. Although I once heard a teacher say that human nature is destructive, it is like a child in kindergarten. When he builds blocks very high, he is not so happy to put them down. It seems that if you choose to test this line, you have to create a "bad boy", haha)

A good test case is a case that is likely to discover no errors.
A successful test case is a case where no error is found.

It is like seeing a doctor. You don't want a doctor to tell you that you are healthy, but you want a doctor to tell you what went wrong.

Economics

Black box testing means that even programs like triangle types cannot exhaust all possible input, not to mention compilers, operating systems, and databases.
White-box testing may allow statement coverage, condition coverage, or even path coverage, but it still determines that the program meets the requirements and cannot test the missing path, data-related errors cannot be tested.
It is impossible to perform a exhaustive test. Therefore, we need to consider the economics in the test and how to identify as many errors as possible with limited test cases.

Ten Principles for testing

1 defining the expected output or result is a necessary component of the test case.
2. A programmer should avoid testing his own program.
3. A working group should not test their own programs.
4. Thoroughly check the results of each test.
5. In addition to valid input, the test case must contain invalid input.
6. Check whether the program has not completed the function that should be completed is only half of the project, and the other half is to check whether the program has done what should not be done.
7. Avoid one-time test cases unless the program is actually one-time.
8. Do not perform a test on the assumption that no errors will be detected by default.
9 The possibility of more errors in a program is proportional to the number of errors found in the program.
10 testing is a very challenging task of creativity and intelligence.