Talk Test this thing _ test

About software testing this thing, played for four years, still haven't figured out its temper.

It is said that software testing is to find more defects, others say, software testing is to ensure the quality of products. All right, one is from the point of view of duty, one is from the point of view of control.

Software testing, in fact, is a validation process, software testers do their best to toss a set of software to see if it meets customer requirements of the standard, whether it can withstand toss, to evaluate the quality of the product good or bad. That's not it. ：-）

The conventional software testing theory follows the V&V process in the V model, which is validation and verification. Validation is the validation of customer requirements, such as acceptance testing and beta testing, which are commonly referred to. Verification refers to every validation activity in the software process, including the review and testing of key products at each stage of the customer's requirements.

According to the V model concept, we divide the software process into the key phases of customer requirement, requirement specification, outline design, detailed design, coding and system testing. Each stage will have relevant review and test, therefore, to customer demand as the main basis of the test, we call it acceptance testing, focusing on user needs verification, usually by the customer to do, the requirements of the main basis for the test, called system testing, focusing on the product comprehensive capability verification, Usually done by a professional tester; The test based on the outline design is called the Integration test, which focuses on the validation of the interfaces at all levels, usually performed by the coder and the tester, and the test based on the detailed design becomes the unit test, focusing on verifying the minimum level of code. Typically implemented by a coder. To see such a rule, it is easy to clear that each test phase, the object to be tested is different, and the corresponding basis once the review has passed, you can proceed with the preparation of the test.

The test phase executes in the opposite order, relative to each of the previous critical phases. The encoding phase can only perform unit tests, and only unit tests pass to allow integration between units and cells, testing the interface between them, which is called integration testing. When all the modules of the software have been completed and the integration test is passed, the system testing phase can be entered. At this time, testers are gearing up, eager to find bugs and not stop.

However, in the end of each test phase of how the test work is carried out. Such a process, we call the test management process. Each test phase will include the test plan, test design, test implementation of these three parts, some people will be divided into more detailed, such as the acquisition of test requirements, test implementation, build test environment.

The test plan does not simply write a schedule, it is when the corresponding document as the basis of the test is fixed (usually called baseline) to start doing, the main purpose is to tell your team members, what you want to do (clear test purposes). What to do (clear test subjects and test requirements). What to do (develop a test strategy). What to use to do (determine the test resource). When to do (schedule test progress). Need to pay attention to what to control (estimate test risk, use evasive means).

The test design is done after the test plan has passed the review, and the main product is the test case, which is to upgrade your test strategy to a detailed step, validate the test object you identified, and what the desired outcome should be. When the test is executed, people will find that the actual result is not the same as expected, and then judge it as a defect. The auxiliary test design product also includes the test environment construction, the test script, the test use data and so on. About the test script, is to measure the development cost and the expected income, can not assume that the use of automated testing is the test master, this is a very serious misunderstanding. The goal of the test script is to improve your test efficiency, how to design or rely on a person's Test level, if the one-sided pursuit of programming skills, this is considered to be a test skills, then you do not have to do the test, to do development. More test scripts are used during unit tests and integration tests because they are highly reusable, and are executed almost every day in the coding process. In the system testing phase, because the test focus is different, the test script reuse rate is far from the first two stages of the effect, naturally more prudent. You know, a conventional 80/20 rule that describes the fact that 80% of the bugs are manually tested, and that only 20% of the bugs are obtained using automated tests. You spend two months to do a set of test scripts, but only need to perform four or five times, found a few defects, after all, many of the verification points in the test is not implemented by the program. Then, if you use a two-month manual test, the results will be vastly different. Which way would you choose?

Test execution can only be done after the required code has been implemented. Take the document to do the design, but not in the real environment to carry out, it becomes an armchair Zhao Kuo. Therefore, you can say that test design is the most important, I have no objection, but, test execution is the most critical. Only this time, you can understand the quality of the software, how many problems, how to repair. At this point, we often say that the test phase (unit test step, integration test phase, System testing phase). In the testing phase, the defect management becomes the most important, and the tracking and control of defects becomes the most direct and effective means to make up the software defect and control the product quality.

The documentation is generated at every stage of the test: test plans, test cases, test reports, and these three documents become the most basic resources. The key to a document is not how it is written, but whether it can express your intentions clearly and let all the people understand that the work you do is visible and controllable, and there will be no big deviations. Therefore, writing a document is not a simple task to complete, it is integrated into all your thoughts, your skills, your level of communication, is to stand at a certain height to complete. Even if you're an expert at catching bugs, you don't write a document and don't express your ideas clearly, which at least means you're not a good tester.

I definitely disagree with a test novice to write what test plan, test case. It would be nice if he could write the test report and the flaw description clearly. Imagine, who is not a natural document master, is bound to be thoroughly tempered, the accumulation of increasingly. First learn to test, you can find a lot of defects from the test, know how the test should be a process, and then start the document cultivation.

I don't think a tester will be able to write good stuff based on user requirements/Requirements Specification/Profile design/module design as soon as they start writing test plans/use cases. After all, at home, most of the technical documents are not very clearance. Therefore, I think to practice writing, it is necessary to start from a more familiar with the already formed software. At this point you don't have to imagine what a software should be, but start working on a real software, recording your actions and your results, and turning it into your test case. The test plan is needless to say, it is natural to be familiar with the software, you know how to test it on the basis of completion.

After such a forging, you will understand how to present your ideas, in the new project, according to the analysis or design documents, you only have to consider what it is specifically implemented, and then according to your test ideas, your writing experience, to complete a high quality test document.

Any theory has its meaning, and any development model has its own reason for survival. The same is true for tests. Theoretically, the design of the test will not begin until the document on which it is based has passed the review, but how can you make sure that the document will work for you by then?

When we from a chaos to the beginning of a formal testing process, we may not have the experience to learn, only with the guidance of our theory, step by step groping forward. So, in the actual process, how do we go about the revolution in the software process?

......

This article is reproduced from the 51Testing Software test Network, view the full text: http://www.51testing.com/html/21/n-243521.html