【Abstract] Where does software testing start and end? Which links should be taken and what matters should be paid attention to during each link. This article will elaborate on relevant issues based on my actual work experience. Since each link can be discussed as a topic, due to the length and time constraints, this article has not thoroughly analyzed the relevant issues, let's only make a macro introduction.
Key words: test process, requirement analysis, test cases, test plan, and defect management
I. Overview
Generally, software testing starts from the establishment of the project and involves the following steps:
Requirement Analysis → test plan → test design → test environment setup → test execution → test records → defect management → software evaluation →RTM.
Before explaining the relevant issues, we should clarify the division of labor. In general, requirement analysis, test case writing, test environment setup, and test execution belong to the work scope of testing developers, testing execution and defect submission belong to the work scope of ordinary testers. The testing director is responsible for tracking, implementing and managing all aspects of the test.
Note:
1The above process does not cover all the software testing processes. For example, some test plan reviews, case reviews, and test training can be implemented based on the actual situation. After the software is officially released, some subsequent maintenance tests are required when some serious problems occur.
2. The above steps are not independent and unrelated. The actual work is ever-changing. Some links are intertwined and overlapping. For example, you can build a test environment while writing test cases, of course, you may also need to re-analyze the requirements due to unclear requirements. This is the same as that proposed by our country to build a socialist country with Chinese characteristics. It is because the national conditions are different. Therefore, you must analyze and solve specific problems during the actual test.
Ii. Test Procedure
Requirement Analysis
Requirement Analysis (Requirment Analyzing) It should be said that it is an important part of software testing. How much the tester's understanding of this part will directly affect the subsequent development of relevant testing work.
Some people may think that testing requirement analysis is irrelevant. Demand analysis is not only important, but also crucial!
Generally, requirement analysis includes software function requirement analysis, test environment requirement analysis, and test resource requirement analysis.
The most basic requirement analysis is software functional requirements. To test a software, you must first know what functions the software can implement and how it is implemented. For exampleSmartphoneIncludingVoIP,Wi-FiAndBluetooth. Then we should know how the software implements these functions. In order to implement these functions, we need to test the equipment and how to set up the corresponding test environment. Otherwise, the test will be impossible!
Now that we have talked about demand analysis, what can we do based on? You can't imagine it out of thin air.
Generally speaking, the basis for testing requirement analysis includes software requirement documents, software specifications, and design documents of developers. I believe that companies that manage certain specifications have these documents in the software development process.
Test Plan
Test Plan (Test Plan) Is generally compiled by the test leader.
The test plan is developed based on the project development plan and test requirement analysis results. The test plan generally includes the following aspects:
1.Test background
- A.Introduction to software projects;
- B.Project Personnel (such as the software and hardware project owner) and corresponding contact information.
2.Test basis
- A.Software Requirement documents;
- B.Software specifications;
- C.Software design documents;
- D.Others, such as reference products.
3.Test Resources
- A.Test Device requirements;
- B.Testing personnel requirements;
- C.Test environment requirements;
- D.Others.
4.Test Policy
- A.Adopt testing methods;
- B.Test environments;
- C.Which test tools are used to test management tools;
- D.Train testers.
5.Test schedule
- A.Test Requirement Analysis;
- B.Write test cases;
- C.Test implementation. test phases (such as unit test, integration test, system test phase, alpha and beta test phase) are divided according to the project plan ), priorities and resources for each stage.
6.Others.
The test plan also includes the date and author of the test plan. The more detailed the plan is, the better.
The plan cannot keep up with the changes. A plan can do well. When it is actually implemented, it will often find it difficult to follow the original plan. For example, the lack of resources and staff flow during software development may affect the testing. Therefore, this requires the test owner to be able to control the situation from a macro perspective. In the face of changes, it is best to be able to cope with the freedom and chaos.
Test Design
The test design mainly includes test case writing and test scenario design.
A good test case provides good guidance for testing and can discover many software problems. For details about how to write test cases, see the previous article "also talk about test cases.
The design of the test scenario is mainly about the test environment.
Test Environment setup
Different software products have different requirements for the test environment. For exampleC/SAndB/SFor architecture-related software productsWindowsSeries,UNIX,LinuxEven AppleOSAnd so on. These test environments are required. For some embedded software, such as mobile phone software, if we want to test the power consumption of function modules and the standby time of mobile phones, we may need to set up a corresponding current testing environment. Of course, there are requirements for environments such as mobile phone networks in the test.
The testing environment is very important. A testing environment that meets the requirements can help us accurately detect software problems and make correct judgments.
To test a software, we may use many different test environments based on different requirements. Some test environments can be built, while some environments cannot be built or the construction cost is high. In any case, our goal is to test software problems and ensure software quality. To solve the test environment problems, take the most economical approach based on the actual situation of specific products and developers.
Test execution
The test execution process can be divided into the following phases:
Unit Test → integration test → system test → factory test, and regression test is performed at each stage.
From the test perspective, test execution involves a problem of quantity and degree. That is, the test scope and degree. For example, what do I need to test for a version? To what extent should we test each aspect?
From the management point of view, we should consider how to divide labor and how to use resources reasonably for testing when there are limited or even insufficient personnel within a limited period of time. Consider the following:
1.What should we do when the testing is not in place and perfunctory?
2.How can we improve the test efficiency?
3.Based on different versions, is it only for verification testing, smoke testing, or comprehensive system testing?
4.What should I do if I encounter unexpected random problems during the test?
5.What should I do when there are many new problems in the version? Test stop standard?
6.......
In short, there will be a lot of complicated problems during the test execution process. Let's talk about the specific problem! This article does not elaborate too much.
Test records
Defect records generally consist of two aspects: who submits the records and the description of the defects.
Generally, some companies may assess the quality of the submitted defects to ensure the accuracy of the submitted defects.
The description of the defect should include at least the following:
| Serial number |
Title |
Preset conditions |
Procedure |
Expected results |
Actual results |
Note |
Severity |
Probability |
Version |
Tester |
Test Date |
The above is a descriptionBugThe content that is often described, of course, in the actual submissionBugCan be supplemented according to the actual situation, such as the attachment,LogFiles.
In addition, a test report should be prepared based on the test results after the software version is tested.
Defect management
In defect management, many companies adopt defect management tools. Common defect management tools include:Test director,Bugfree.
IsBugFrom proposalCloseSome processes, suchKeep no action \ keep specAnd other status processes are not included. Here, only demonstration instructions are provided.
Note: Software defects andBugThe two are slightly different in meaning. This document is collectively referred to as a defect.
Software Evaluation
The evaluation here refers to the evaluation of the software to be sent to the customer when it is confirmed that the software has no major problems or few problems after another round of tests, to determine whether it can be released to the customer or to the market.
A software evaluation team is generally composed of project owners, marketing personnel, department managers, and other third-party personnel designated by the customer.
Test Summary
Each version has a test summary for each version, and each stage has a test summary for each stage.RTMIn general, we need to review and summarize the entire project to see what are the shortcomings and what experiences can be used for reference in future testing. The test summary has no strict format or word limit. It should be said that the test summary is still very important.
Test and Maintenance
Due to test incompleteness, when the software is formalReleaseIn the use process, the customer will inevitably encounter some problems, some or even serious problems, which need to modify the relevant problems, after the modification, the software needs to be tested, evaluated, and released again.
This article is transferred from workshop!