"Project Test Design" for Software Testing"

I have been busy recently, so I have no time to summarize it. Of course, during this busy period, I also found a lot of problems in my work. Today, I am just taking a look at it.

Before that, my opinion on the testing work was that I was familiar with the business and skilled technical skills to complete most of the testing work well. Through the catch-up of this project, I suddenly felt that there were too many irrational ones. After all, there was a lot of uncertainty in testing. In addition, each person's test ideas were different, and it was easy to ignore and omit many test points, in this way, the test coverage is reduced a lot, and there must be a lot of problems when the product is launched at the end, so we still cannot rely on feelings and ideas to do things, because no one will take responsibility for you at the end. So here I also want to talk about some of my ideas about the test design to help and guide my future work.

Generally, at the beginning of a project, the requirement personnel will distribute a bunch of so-called Requirement documents to developers and testers. In this case, the early stage of the test will be involved in the project progress. Of course, at this time, we will have a lot of questions to confirm with the demand, because a bunch of scattered demand documents are enough to explain how they are rashly, but every time a product is delivered, this is the time when developers and testers hate those who need it most. Because their initial needs are unclear, we have to work hard and waste so much time. However, for testing, this process actually plays a crucial role, because only testers will be bored with the demand personnel, at the time of development, I think that as long as the processing is complete, and the test cannot say OK to anyone, or our work will become meaningless. Therefore, testing is a task of in-depth understanding of requirements and correctly guiding development towards the most correct track. It can be seen that it is great!

First, we can abstract the basic functions from the requirement documents and get a document that testers can understand. This way, we can see that we want to test the functions;

Secondly, extract the business process from the requirement document, communicate with the requirement personnel in depth, and draw a business flow chart;

Thirdly, a preliminary test plan, including the test objectives, scope, test content, test process, test methods and test tools, is output based on the above two results, the most important thing is to list the test coverage, such as testing the system platform for the client software, including Windows 7/Vista (32/64 bit), installation and uninstallation testing, and anti-virus software coverage testing; for example, you need to perform browser compatibility tests on Web pages;

Finally, we need to pay attention to the overall consistency of the test ideas, "first normal, then abnormal", to ensure that the functions can be accessed under normal circumstances, and in the case of exceptions, close to possible coverage.

It may be said that the design and review of the test case should be completed, and the final archiving should be completed. However, not all projects will have a lot of time left for the test personnel, this is the difference between product testing and project testing. If you have enough time to design a detailed case and review, it is of course the most complete process. The main purpose of this article is to test the project. It usually takes a very short period of time to complete the software testing process, you need to find a method and process that suits you and your project.