The basics of software testing

Software testing is a critical effort to identify flaws in the software. For the time being, don't delve into why software testing, and software testing benefits. Only some of the basic test methods in software testing are introduced. According to whether the code program is divided into black box test and white box test , according to whether to run the software can be divided into static testing and dynamic testing .

　　black Box testing: also known as functional testing or behavioral testing, just consider each function, do not need to consider the entire software internal structure and code.

　　White Box testing: access code to assist in testing by checking the code for clues.

　　Static testing: The test software does not run the part, just check and audit.

　　Dynamic Testing: use and run the software for testing.

1. Static black box test: Check the product manual and find out the problem before the software is written.

• Advanced review of product manuals or software requirements reports:

(1) Review from a designer's perspective to identify fundamental issues or omissions

(2) Review from the perspective of the customer (user), because the definition of software quality is to meet the needs of customers

(3) Research the existing standards and norms, can be the company's customary terminology and conventions, industry requirements, GUI, safety standards, check whether the standards are correct, missing, and whether the standards and norms are inconsistent

(4) Review and test similar software to check its size, complexity, testability, quality and reliability, security

• Perform low-level testing of product manuals or software requirements reports:

A good product specification or Demand report: Must be complete, accurate, accurate (unambiguous, clear), consistent, appropriate, reasonable, code-independent, Testability

2. Dynamic black box test: Test without knowing how the software works

Two basic methods: passing Sex test and failure test

Select test Case: equivalence class Division : The software has similar input, similar output, similar operation of the sub-group. An equivalence class or equivalence class partition refers to a set of test cases that test the same target or expose the same software defect.

Goal of equivalence class partitioning: Reduce the set of possible test cases to a small scope that is controllable and still sufficient to test the software.

　　(1) test data

　　Passing Sex test:

A) boundary conditions: the boundary condition at which the software runs at the planned operating boundary. The test boundary consists of testing valid data near the boundary, testing the last possible valid data, and testing the invalid data just above the boundary.

b) Sub-boundary condition: Typical sub-boundary condition: power of 2, ASCII table

c) Test default, blank, NULL, 0 value, and no such data

　　Test of failure:

D) Testing for illegal, erroneous, incorrect, and spam data

　　(2) Test status

Software Status: The condition or mode in which the software is currently located.

State test: The state of the test program and its transformation.

Step: 1) Establish the state transition diagram

2) Reduce the number of States to be tested and their conversions

A. Access to each state at least once

B. The most infrequently used branch between test states

C. Testing all error states and their return values

D. Testing for random State transitions

E. Testing appears to be the most common and common state transitions

　　　　 Pass the sexual state test : Review the software, describe the status, try various legal possibilities, confirm the status and its transformation is normal.

　　　　 Failure State Testing : Race conditions, repetition (check for memory leaks), compression (running in less than ideal condition: small memory, low disk space ...) Limit the requirements of the software as much as possible) and overburden (providing the conditions for its play).

3. Static White-Box testing: The process of identifying software defects in a structured and carefully scrutinized software design, architecture, and code without executing software

(1) Coding standards and Specifications: reliability, readability/maintainability, portability

(2) General Code Review Checklist:

A. Buffer overflow with Data reference error

B. Data declaration error <-incorrectly declares and uses variables and constants

C. Calculation errors

D. Comparing error <-boundary condition problems

E. Control process errors <-loops and other control structures do not work as expected and are indirectly caused by calculation or comparison errors

F. Subroutine parameter error <-subroutine incorrectly passes data

G. Input/Output error

H. Other inspection--coded, portable, compatible

4. Dynamic White Box testing: structured testing, checking code and observing health, using the information found in code functions and implementations to determine what needs to be tested, what is not, and how to conduct testing, including the following:

(1) Direct testing of underlying function procedures, subroutines and libraries (API)

(2) Complete program from the top-level test software, according to the understanding of software operations to adjust test cases

(3) Gain access to read variables and status information from the software, determine if the test matches the expected results, and force the software to run in a way that normal testing is difficult to achieve

(4) Estimating the amount and code of code hit when executing the test, adjusting the test, removing the redundant test cases, and supplementing the missing use cases

Dynamic white box testing differs from debugging in that it includes the process of dealing with software defects and viewing code, but their goals are different: The goal of the test is to find software defects; The goal of debugging is to fix the defects.

Test methods: Segmented test (unit test and integration test), data overlay, code overlay

　　Data coverage:

Data flow overlay to fully track a batch of data in the software.

Secondary boundary: Similar to dynamic black box testing.

Equations and equations: In a division-like operation, consider the case of a divisor of 0.

Error enforcement: Forces all error messages in the software to be displayed.

　　Code Coverage: test the state of the program and the process of the program, try to enter and exit each module, execute each line of code, enter the software every logical and decision branch

Code overrides include: Program statements and code line overrides, branch overrides (such as the If branch and Else branch in a judgment statement), conditional overrides (a condition may contain several sub-conditions, covering each sub-condition and their combination).

Software testing is to use and run the software before the user, to find out the defects in the software as early as possible. It is impossible for us to fully test the software, only to make the probability of the software still having bugs as small as possible after testing a limited use case. The above is only a little fur, software testing coverage of a wide range of knowledge, need to learn a lot!!

The basics of software testing