Test process (left picture below) and test phase (or type) (right picture below)
figure 1
Description:
1. The general software testing process described in the left figure above. 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.
2. 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 performed at various stages of software development.
3. Smoke test (also called submission test), a test that verifies and confirms the main business process and main functions of the software before the formal test to ensure that the follow-up test can be carried out normally. Status: Generally, smoke test before the official test is carried out before the new version is submitted
4. 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 the actual situation)
5. The two pictures on the left and the right are integrated into the software development process, resulting in various test models described below
6. Stage (type) breakdown: as shown in the figure below
Collaboration between testing process and development process (example of typical model)
W model as an example
figure 2
Description:
1. System design is also called outline design.
2. Software requirements review, mainly reviewing software requirements specifications, mainly based on product requirements documents
3. System design review, mainly reviewing the system architecture design, etc., mainly based on the system outline design specification
4. 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 cannot be so standardized, and some companies do not even have documents. The more standardized quality management I have seen at present is the quality management of Industrial Bank (the waterfall model seems to be for banking projects). Still more practical)
H model
image 3
Description:
1. There are some improprieties in the V and W models. First of all, as mentioned earlier, they all regard software development as a series of serial activities such as requirements, design, and coding. In fact, although there is a mutual restraint between these activities, most of the time, They can be crossed. Although software development expects to have clear requirements, design and coding stages, practice tells us that strict stage division is just 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.
2. 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, design process and coding process. It 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.
3. In a nutshell, the H model reveals:
1) Software testing not only refers to the execution of tests, but also includes many other activities.
2) 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.
3) Software testing should be prepared and executed as soon as possible.
4) Software testing is carried out at different levels according to the different tested objects. Different levels of testing activities can be carried out in a certain order, but they can also be repeated.
4. Combining the software project development process, different development stages, according to the actual situation, the test process of Figure-1 can be integrated into different development stages. (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 include determining the test purpose, test constraints, test requirements, test risks, test strategies, test resources, test quantitative plans, test progress, test plan workload, and deliverables;
Activities in the test planning phase include:
1. Determine the test purpose, test constraints, test requirements, test strategies, etc.
2. Estimate the test workload and test progress based on historical data, similar project data and estimated number of system test cases.
3. According to the estimated test workload and project plan, estimate test resources (human resources and environmental resources, tools)
4. Perform risk analysis and avoidance based on test workload and test resources.
5. Prepare test plan;
6. Review the test plan
Test design
Analyze test requirements, design test cases, review test cases, and track the execution of test plans.
Activities in the test design phase include:
1. 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.
2. Write test requirements and design test cases.
3. Organize to build a test environment and prepare test data.
4. Review the test case design.
Test execution
Ensure the quality of test objects by means of version control, test environment monitoring, test execution progress control, and change control during the test execution process.
Activities in the test execution phase include:
1. Test-related personnel write and modify test scripts.
2. Test related personnel establish test execution flow and conduct joint debugging.
3. Test related personnel assign test tasks to test executives.
4. Test personnel perform tests according to test cases to ensure that the coverage of test cases meets the requirements of the test plan.
5. Test related personnel record the test results, track the modification status of defects and verify the completed defects.
6. Test related personnel monitor the test environment and organize the collection of quantitative data during the test process.
7. Test related personnel to track and control the progress of test execution
Test summary stage
Analyze and summarize the completed test tasks, and give test conclusions or suggestions.
Activities in the test summary phase include:
1. Test related personnel evaluate test activities.
2. The test personnel analyze the test results.
3. Test related personnel organize and compile test reports.
4. Relevant test personnel conduct test report review.
Detailed test phase
Unit testing activities
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 testing activities include:
1. Write unit test cases;
2. Perform unit testing, self-test and cross-test;
3. Record the unit test results;
4. Evaluate the effectiveness of unit testing activities;
Integration testing activities
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 activities include:
1. Write an integration test plan;
2. Develop integration test cases;
3. Perform integration testing;
4. Regression test on the defect repair version;
5. Record integration test results;
6. Carry out incremental integration module test, repeat steps (2) ~ (5) until the incremental integration ends;
7. Compile an integration test report;
8. Review the integration test report.
Confirm test activity
The confirmation test itself is a 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.
The work of software testing boils 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, and "confirmation" focuses on whether the intended use is satisfied, that is, the real needs of users. We know that software design and coding implementation are based on software requirements specifications. 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 specifications do 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 has been tested. Test whether the software product is what the user wants.
The simplest explanation is:
Verification：Are we building the product right？
(Function verification) Whether the correct product is made according to the requirements
Validation：Are we building the right product?
(Validity Confirmation) Whether the product that the user wants has been made.
In short, the verification is aimed at the software rule requirements specification, whether the software is designed and implemented according to the needs, and the confirmation is aimed at the user, and it is verified whether the software can meet the needs of the user.
Note: Whether to use the 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 verification test specifically for the software subsystem after the integration test, and then perform the 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 testing activities
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 testing activities include:
1. Write system test plan;
2. Develop system test cases;
3. Perform system test;
4. Record the test results;
5. Compile system test reports;
6. Review system test report
User acceptance testing (UAT) activities
Verify that 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 testing (UAT) activities include:
1. Develop UAT test plan;
2. Write UAT test cases;
3. Perform UAT test;
4. Record UAT test results;
5. Compile UAT test report.
6. Review UAT test report.
Written at the end,
if you are interested in python automated testing, web automation, interface automation, mobile terminal automation, interview experience exchange, etc., you can follow the WeChat official account: [Programmer Erhei] to get an interview with a software test engineer data! My learning exchange group: 785128166 There are technical experts in the group to exchange and share~
If the article is of interest to you, please reach out to make a fortune and give me a like. Thank you for your support. Your likes are my motivation for continuous updates.