Software Test Reading notes

[Mei] Ron Paton, Zhou, Yiu Jing. Software testing [M]. Beijing: Mechanical Industry Press, 2002.

This book is an entry-level reader of software testing, and the writing style of the book is easy to understand, and the scope of knowledge is broad. The content of the book is divided into six parts, each of which describes one aspect of software testing knowledge. By reading the book I understand the software testing and software defects of the relevant knowledge, a general understanding of the emergence of software defects and how to deal with defects in the test and management.

1 Software Testing Overview

The authors described several notorious software error cases, including the Patriot Missile defense system (which caused the tracking system to lose accuracy due to a small system clock error accumulated over a period of dozens of hours), the millennium bug (resulting in a 2000-year date error due to a compressed program storage space), etc. This paper introduces the concept of software defect, and gives the strict definition of software defect, which satisfies the software problem of 5 rules listed in the Book (6th page of book text). From the analysis of the causes of software defects and the cost analysis of repairing software defects, the paper puts forward the method of software testing for discovering software defects in two angles, and emphasizes the importance of testing from the beginning of software development process.

Figure 1.1 Why software defects occur

Figure 1.2 Fixing the cost of software defects

After understanding what the software flaw is, how it is produced in general, and the purpose and importance of software testing, the authors then further elaborate on the role of software testing in software development from the software development process, and analyze how several development models can be easily implemented and perform test tasks at very early cost. Ruled out the stick pattern (almost no test process), the flow mode (test only at the last, the cost of a large risk), etc., that the spiral mode is more suitable for software testing. The main emphasis here is on the importance of software testing and how to incorporate testing into the software development process.

Then, the author introduces the principles of software testing and related terms and definitions, in fact, to further let the reader understand the essence of software testing, so that readers will be more aware of the use of software testing to solve their own problems, and which problems are software testing can not be solved. The following principles are listed in the book:

1) Fully testing the program is not possible (all possible test cases cannot be tested all)

2) Software testing is risky behavior (no test all cases, need to find optimal test volume)

3) test cannot show latent software defect (full test program is not possible)

4) The more software defects found, the more software defects

5) Pesticides Strange Things (you have to keep writing different new test procedures)

6) Not all software defects can be repaired (risk)

7) Difficult to clarify software defects (the definition of software defects rules)

8) Continuous change of product specification (requirement)

9) Software Testers are not welcome in the product group (do the work of checking and fault)

10) Software testing is a disciplined technical professional

2 Test Basics

This part first introduces the basic concepts of black box, white box, static and dynamic test, then mainly describes four kinds of software testing techniques: static black box test, dynamic black box test, static white box test, dynamic white box test.

The main difference between a black box test and a white-box test is whether the software tester can access the program's code and check the code to assist the test. The main difference between static and dynamic testing is whether the software is run and used.

The author describes in detail the static black box test, which is the test product specification, and explains how the test is conducted (including whether the review manual reflects the objective requirements and whether the specification itself is complete or correct).

Through the dynamic black-box test, the author introduces the concept of test and failure testing and the subtle relationship between them (the test proves that the software is usually healthy), and describes in detail several common techniques for dynamic black-box testing: Equivalence partitioning, boundary testing, state testing, It also points out the rules that should be followed in applying these techniques.

Static White-box testing, which examines the design and code, verifies that the logic of the design and code is correct, and conforms to standards and norms. Dynamic White-Box testing not only looks at the code, but also includes direct test and control software, which intersects with the concept of debugging, where the author points out the difference: The goal of dynamic white-box testing is to look for software defects, and the goal of debugging is to fix them. The author introduces the process of dynamic white-box testing (unit and integration test) and the test rules from two angles of data range (data flow, sub-boundary, formula and equation, error enforcement) and code range (statement and Code line overlay, branch coverage, conditional override).

Figure 1.3 Unit Test and integration test

3 Using Test technology

This part mainly includes using the test technology to carry out some test analysis, such as compatibility test, foreign language test and so on, the part is only skimming.

4 Strengthening testing

This part mainly includes automatic testing and testing tools and smelly bombing and beat test two aspects of content, its purpose is to let the tester learn to weigh which way to make the test more effective, such as: the use of technology, increased manpower, brute Force manual test, the part is only skimming.

5 Using the test document

This section explains how to use test documents to plan and organize test tasks, correctly document discovered software defects, and ensure that software defects are repaired.

In this section I look at the problem of reporting software defects more carefully, the other content only skim. It mainly clarifies the circumstances under which a software defect can be repaired and does not fix some software defects (there is not enough time, the risk of repair is too great, it is not worth repairing, etc.), why it is necessary to report software defects as soon as possible (the more likely the discovery time will be repaired), how to effectively describe (short, single, Obvious and reproduction) and effective reporting (no evaluation at the time of reporting, follow-up of repair process Supplement report) software defects, priority of software defects (immediate fix, must fix before product release, if time permitting should be repaired, etc.) and the concept of severity (System crashes, operational errors, minor issues, etc.) and the lifecycle of software defects.

Figure 1.4 Life cycle of software defects

6 Software Testing Outlook

This part includes the software quality evaluation and the software Tester Professional guidance two aspects content, to this part only skim.

Software Test Reading notes