Software testing work steps details

 

Software testing steps are generally divided into 5 parts according to the development stage: unit testing, integration testing, confirmation testing, system testing, and acceptance testing. Below is a summary of some of the work required at different stages in the hope that it can help everyone.

1. Contents of unit testing: (mainly white box, supplemented by black box)

  Unit testing, also known as module testing, is a testing work that checks the correctness of the smallest unit program module of software design. Unit testing needs to design test cases based on the internal structure of the program. Multiple modules can be unit tested independently in parallel.

1. Module interface test

The data flow through the module under test should be tested

Whether the input parameters when calling the module under test match the number, attributes and order of the formal parameters of the module

When the tested module calls a submodule, check whether the parameters of the input submodule match the formal parameters of the submodule in terms of number, attributes, and order.

Whether the number, attributes and order of parameters output to the standard function are correct.

Whether the definition of global variables is consistent in each module.

When the module performs input/output operations through external devices, check whether the file attributes are correct, whether the open and close statements are correct, whether the specified I/O format description matches the I/O statement; whether the buffer capacity matches the record length, and whether the buffer capacity matches the record length. Whether the file was opened before, whether the file was closed after reading and writing, and whether I/O errors were handled.

2. Local data structure testing

Local data structures are the most common source of errors

Inconsistent data types

Incorrect or inconsistent data description

Using a variable that has not yet been assigned a value or has not yet been initialized

Wrong initial value or wrong default value

3. Path test

Prioritization of operations, common comparisons, and control flow

4. Error handling test

Encounter error conditions and set up appropriate error handling

5. Boundary testing

For example, the number of loops, the maximum or minimum value

2. Unit testing steps:

Use design documents to design test cases;

Create a stub module or driver module for the module under test;

Use the tested module, driver module and stub module to establish a test environment and conduct testing

Driver module: equivalent to the main program of the tested module, it receives test data, transmits these data to the tested module, and finally outputs the actual results.

Stub module: a submodule called instead of the tested module.

3. Integration testing (combination of white box and black box)

  Integration testing is also called assembly testing or joint testing. Based on unit testing, all modules need to be assembled in accordance with the requirements of the outline design specification and detailed design specification.

When connecting various modules, the data passing through the interfaces of each module will be lost.

Whether the function of one module will adversely affect the function of another module

After each sub-function is assembled, can it achieve the expected parent function?

Is there a problem with the global data structure?

Will the errors generated by a single module be amplified cumulatively?

  Integration testing level: Integration testing within subsystems; Integration testing between subsystems; Integration testing between modules.

  

How modules are assembled into systems: one-time assembly and proliferative assembly

1. One-time assembly method (non-proliferative integration)

  First test the modules separately, and then assemble all the modules for testing.

  Disadvantages: It’s not easy for me to locate mistakes when I find them. 

2. Proliferative assembly testing: top-down; bottom-up; hierarchical integration; sandwich integration; grassroots integration; high-frequency integration.

  First perform module testing on each module, and then gradually assemble these modules into a system, which is divided into two methods: top-down proliferation method and bottom-up proliferation method.

(1) Top-down proliferation method (no driver module required)

  The modular ammonium system program structure is assembled from top to bottom with strict control levels.

  First, the main module is used as the module under test and the driving module. All subordinate modules directly under the main module are replaced with stub modules to test the main module. Then adopt the depth-first or breadth-first strategy, replace the stub modules with actual modules, and then replace their directly subordinate modules with stub modules to form a new subsystem with the tested modules. Then perform regression testing.

(2) Bottom-up proliferation method (no driver module required)

  The driver module controls the parallel testing of the lowest-level module.

(3) Mixed proliferation type

Top-down proliferation method:

    Advantages: Ability to detect major control problems early

    Disadvantages: stub modules need to be established, and some additional tests are added. Modules involving algorithms and input and output are generally at the bottom. These bottom-level modules cannot be discovered until the later stages of assembly and testing. Too many regression tests occur once a problem is discovered.

Bottom-up proliferation method:

    Advantages: There is no need to create a stub module. It is much simpler to create a driver module than a stub module. At the same time, modules that involve the input and output of the algorithm must be tested first, and the parts most prone to problems can be solved at an early stage.

    Disadvantages: The program has not existed as an entity until the last module is added to form an entity, and the control aspect can finally be contacted.

3. Sign of completion of integration testing:

  1) Successfully executed all integration tests specified in the test plan

  2) Fixed the found errors

  3) The test results pass the review of a specialized group

  4) Test reports that need to be submitted for integration testing:

  5) Integration test plan, integration test specifications and integration test analysis report

4. Confirmation test (black box)

   The goal of validation testing is to verify that the functionality and performance and other characteristics of the software are consistent with the user's requirements. Validation testing generally includes validity testing and software configuration review. Generally, it is conducted by a third-party testing agency.

1. Conduct validity testing

  Current software validation must pass a series of black box tests. Confirmation testing also requires the development of a test plan and process. The test plan should specify the type of test and the test progress. The test process defines some special test cases to illustrate whether the software is consistent with the requirements.

Whether it is planning or process, emphasis should be placed on whether the software meets all functions and performance specified in the contract, whether the documentation is complete and accurate, human-machine interface and other aspects (such as portability, compatibility, error recovery and maintainability) etc.) whether it satisfies users.

  There are two possibilities for the results of the confirmation test. One is that the functions and performance indicators meet the requirements of the software requirement description and are acceptable to the user;

   The other is that the software does not meet the requirements of the software requirement description and is unacceptable to users. Serious errors and deviations discovered only at this stage of the project are generally difficult to correct within the scheduled construction period. Therefore, it is necessary to negotiate with the user to find a proper solution to the problem.

2. Software configuration review

  Ensure that all components of the software configuration are complete and the quality meets the requirements. The procedures specified in the user manual and operating manual should be followed.

5. System testing System testing in the usual sense includes stress testing (also called strength testing), capacity testing, load testing, performance testing, security testing, fault tolerance testing, etc.

    As part of the computer system, software is integrated with hardware, networks, peripherals, supporting software, data and personnel to test the computer system in actual or simulated environments.

The purpose is to compare with system requirements and find problems.      

   Utilize the program's user documentation or written materials. Design system tests by analyzing target documents and user documents to elucidate test cases.

  Since there is no one method, system testing requires a lot of creativity. In fact, designing good system test cases requires more creativity, wisdom, and experience than designing a system or program.

   To avoid missing anything, all 15 types should be considered when designing test cases.

Capability test, capacity test, strength test, usability test, security test,

Performance testing, storage testing, configuration testing, compatibility/configuration/conversion testing, installation testing,

Reliability testing, recoverability testing, suitability testing, documentation testing, and process testing.

6. Acceptance testing includes: formal acceptance, alpha testing, and beta testing.

  User-oriented testing involves software developers and quality assurance personnel, and users design test cases.

  Rather than testing full coverage of the system, the core business processes are tested.

  Conduct acceptance testing of products according to the contract, Requirements Specification or Acceptance Test Plan.

  For software products that have passed the acceptance test, please refer to the identification method specified in the "Configuration Management Specification" to change the test status. At the same time, the project manager is responsible for preparing the "Acceptance Report".

Finally, I would like to thank everyone who reads my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it directly:

How to obtain documents:

This document should be the most comprehensive and complete preparation warehouse for friends who want to engage in [software testing]. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you!

All of the above can be shared. You only need to search the vx official account: Programmer Hugo to get it for free.

Guess you like

Origin blog.csdn.net/2301_79535544/article/details/133363033