[Software Testing] Software Testing Fundamentals from Scratch (02): Testing Process

Preface

The series of learning software testing from scratch will be divided into three stages

Basic chapter,
transition chapter,
automated testing chapter

The basic part (01) talked about the classification of bugs, so that everyone has a simple understanding of the working objects of software testing. This basic part (02) will take you to understand the testing process in detail, that isHow to find bugs better

text

Graphical description of the test process (the following left picture) and the test phase (or type) (the following right picture)

The general software testing process described above on the left. The figure on the right describes the specific test activity stages. According to different test stages, it can be divided into unit test, integration test, confirmation test, system test, acceptance test, regression test, smoke test and other test types.
Regression testing means that after modifying the old code, re-testing to confirm the repair of the defect, and the modification does not introduce new errors or cause errors in other codes. Multiple regression tests are conducted at various stages of software development.
Smoke test (also called submission test) is a test that verifies and confirms the main business process and main functions of the software before the formal test to ensure that subsequent tests can be performed normally. Status: Generally, smoke test before the official test is carried out before the new version is submitted
Each test activity stage on the right can be carried out according to the test process on the left, document review, test plan, test design, test execution, test summary, etc. (The test process can be appropriately tailored according to actual conditions)
The two pictures on the left and the right are integrated into the software development process, resulting in various test models described below
Stage (type) breakdown: as shown in the figure below.
Test process and development process collaboration (a typical model is an example)

W model as an example

Emphasize

System design is also called outline design.
Software requirements review, mainly reviewing software requirements specifications, the main basis is product requirements documents
System design review, mainly reviewing system architecture design, etc., mainly based on the system outline design specification
Detailed design review, mainly to review the detailed design, such as whether the interface design is reasonable, mainly based on the detailed design specification

ps: The reality is that ordinary companies and ordinary projects can’t be so standardized.
Some companies don’t even have documentation. The more standardized ones I’ve seen so far are the quality management of banks (the waterfall model seems to be relatively good for banking projects. Useful)

H model

Insert picture description here

Description:

Both V and W models have some improprieties. As mentioned earlier, they all regard software development as a series of serial activities such as requirements, design, and coding, but in fact, although these activities have a mutually restrictive relationship.
But in most of the time, they can be carried out crosswise. Although software development expects clear requirements, design and coding stages, practice tells us that strict stage division is only an ideal situation.
Let me ask, how many software projects were designed after having clear requirements?
Therefore, there is no strict order relationship between the corresponding tests. At the same time, there are also repeated triggers, iterations and increments in the tests between each level.
Secondly, the V and W models do not reflect the integrity of the test process well.
In order to solve the above problems, the H model is proposed. It completely separates the test activities, forming a completely independent process, and clearly reflects the test preparation activities and test execution activities.
The H model diagram only demonstrates a test "microcycle" at a certain level in the entire life cycle.
The other processes in the figure can be any development processes.
For example, the design process and coding process can also be other non-development processes, or even the testing process itself. In other words, as long as the test conditions are mature and the test preparation activities are completed, the test execution activities can (or need) be carried out.
In a nutshell, the H model reveals:

Software testing not only refers to the execution of tests, but also includes many other activities.
Software testing is an independent process that runs through the entire life cycle of the product and is carried out concurrently with other processes. When a certain test time point is ready, the software test moves from the test preparation stage to the test execution stage.
Software testing should be prepared and executed as soon as possible.
Software testing is carried out at different levels according to the tested objects. Different levels of testing activities can be carried out in a certain order, but they can also be repeated

Combining the software project development process, different development stages, the test process of Figure-1 can be integrated into different development stages according to the actual situation (the test process can be appropriately tailored according to the actual situation).
For example, in the requirements analysis stage, you can use the "document review" process to conduct business requirements document review and software requirements specification review, and also include "test plan" and "test design" to plan and design system testing.
In the system design stage, it can be included in the "document review" process to review the system architecture design specification and outline design specification

Detailed test process

Test Plan

The main tasks of the test planning stage includeDetermine the test purpose, test constraints, test requirements, test risks, test strategies, test resources, test quantitative plans, test progress, test plan workload, deliverables

Test planning stage

Determine the test purpose, test constraints, test requirements, test strategies, etc.
Based on historical data, similar project data and estimated number of system test cases, estimate the test workload and test progress.
According to the estimated test workload and project plan, estimate test resources (human resources and environmental resources, tools)
Perform risk analysis and avoidance based on test workload and test resources.
Prepare test plan;
Review test plan

Test design

definition:Analyze test requirements, design test cases, review test cases and track the execution of test plans。

Test design phase

Test-related personnel participate in the software requirements development process, analyze software test requirements, participate in software requirements review, and ensure the testability of software requirements.
Write test requirements and design test cases.
Organize to build a test environment and prepare test data.
Review the test case design.

Test execution

definition:Through the version control, test environment monitoring, test execution progress control and change control in the test execution process, the quality of the test object is ensured.

Test execution phase

Test related personnel write and modify test scripts.
Test related personnel establish test execution flow and conduct joint debugging.
Test related personnel assign test tasks to test executives.
Testing personnel perform tests according to test cases to ensure that the coverage of test cases meets the requirements of the test plan.
Testing personnel record the test results, track the modification status of defects and verify the completed defects.
Testing personnel monitor the testing environment and organize the collection of quantitative data during the testing process.
Test related personnel to track and control test execution progress

Test summary

definition:Analyze and summarize the completed test tasks, and give test conclusions or suggestions.

Test summary stage

Test related personnel evaluate test activities.
Test related personnel analyze the test results.
Test related personnel organize the preparation of test reports.
Test related personnel conduct test report review.

Detailed test phase

unit test

definition:Developers are mainly responsible for self-testing and cross-testing the written code to check whether the code implements module functions, whether it complies with coding specifications, and whether there are obvious logic errors.

unit test

Write unit test cases;
Perform unit testing, self-test and cross-test;
Record unit test results;
Evaluate the effectiveness of unit testing activities;

Integration Testing

definition:The modules that have passed the unit test are gradually assembled into a complete program with good consistency, the integration test implementation strategy is formulated, the implementation steps of the integration test are determined, the integration test cases are designed, and the modules are added one by one for testing.

Integration Testing

Write integration test plan;
Develop integration test cases;
Perform integration testing;
Regression test on defect repair version;
Record integration test results;
Carry out incremental integration module test, repeat steps (2) ~ (5) until the incremental integration ends;
Write integration test report;
Review integration test report

Confirmation test

definition:Confirmation test itself belongs to system test, but sometimes it emphasizes its importance and comes out separately. Confirmation test Confirmation test, also known as validity test, aims to show future users that the system can work as scheduled.

Confirmation test

The work of software testing comes down to two Vs, Verification and Validation.

Verification translates as verification. In ISO9000, the strict definition of "verification" is: verification is the recognition that the specified requirements have been met through inspection and the provision of objective evidence.

Validation translates to confirmation. In ISO9000, the strict definition of "confirmation" is: confirmation is the recognition that some requirements for a specific intended use have been met through inspection and the provision of objective evidence.

From the definition, it can be seen that "verification" focuses on whether the requirements are met, that is, the requirements specification
"confirmation" focuses on whether the intended use is met, that is, the real needs of users.
We know that software design and coding implementation are based on software requirements specifications Instructions. For software testing, the purpose of unit testing, integration testing, and system testing is to verify whether the software meets the requirements and specifications of the software, so they can all be attributed to the verification process.
However, the requirements specification does not represent the real needs of users, and the design based on requirements often deviates from the requirements. Therefore, the resulting software products need to be confirmed and tested after the system tests.
Confirm whether the test software product is what the user wants.

The simplest explanation is:

Verification：Are we building the product right？

(Functional Verification)Whether the correct product is made according to the demand

Validation：Are we building the right product?

(Validity confirmation)Whether to make the product that the user wants

All in all, the verification is aimed at the software rule requirements specification, whether the software is designed and implemented according to the requirements, the confirmation is aimed at the user, and the verification is whether the software can meet the user's needs.

Note : Whether to use confirmation test depends on the size of the system under test. If the system under test is a relatively large-scale system, including software, hardware, etc., it is necessary to conduct a confirmation test specifically for the software subsystem after the integration test, and then perform a system test for the entire system; if the entire system is composed of software, There is no need to perform a special confirmation test, and the system test can be performed directly after the integration test.

System test

definition:Verify that the various function points in the requirements specification are complete and correctly implemented, and at the same time test the system's installation, deployment, adaptability, information security, interface and other non-functional requirements.

System test

Write system test plan;
Develop system test cases;
Perform system testing;
Record test results;
Write system test report;
Review system test report

User Acceptance Test (UAT)

Definition: Verify whether the business functions in the requirements specification are met, and pay attention to non-functional requirements such as system interface and response time.

User Acceptance Test (UAT)

Develop UAT test plan;
Write UAT test cases;
Perform UAT test;
Record UAT test results;
Compile UAT test report.
Review UAT test report

Afterword

There is no absolute description above, specific analysis of specific circumstances

Although the testing industry has entered the eyes of many Internet companies, it is still sluggish. Many companies do not follow the standard process. Moreover, each company is different, with different projects, different resources, different development models, and different processes. Naturally
, the purpose of this series is not only to let everyone know the knowledge, but to understand the general idea. After understanding the idea of the test, you can appropriately tailor it according to the actual situation. There must be some, even if it is Agile testing
The above summary is mainly to help novices get started, so that novices have a general impression

Finally, if you want to communicate and learn, you can come to my big family to chat, click and enter the secret code: CSDN
has a large gift package for sending it.
Insert picture description here