Test process explained in detail
Internet company's R & D team structure:
Test process:
1. Demand analysis stage
It is usually based on the needs of the tested product as the prototype for analysis and transformation. The test requirements are mainly collected through the following channels:
- Various documents related to the software to be tested . Such as software requirements specifications, Use
cases, interface design, project meetings or meeting minutes with requirements information and other technical documents when communicating with customers. (Requirement documents are generally written by product managers, and demand analysis books are written by tests) - Communicate with customers or system analysts.
- Business background information. Such as the knowledge of the software business area to be tested.
- Formal and informal training .
- other. If the old system is used as a prototype and the software is designed or improved in a new architectural manner, the original functions and features of the old system have become the most effective way to collect test requirements.
Extract function points from big to small: subdivide into tree structure
2. Test design stage
Test plan, plan and strategy can be written together in the test plan
5W+1H：
For the selected project, process or operation, the reasons (Why), objects (What), location (Where), time (When), personnel (Who), method (what Law How) and other six aspects to raise questions and think.
1. What—
What products does the company produce? What spare parts are produced in the workshop? Why should we produce this product? Can you produce something else? What should I produce? For example: If this product does not make money, is it better to change to a higher profit?
2. Where-Where
is production done? Why did you have to work in this place? Is it okay to change places? Where should I do it? This should be considered when choosing a workplace.
3. Time and procedure (When)-When,
for example, when was this procedure or part done? Why do you want to do it at this time? Can you do it at other times? Is it possible to bring the post-process to the front? When should it be done?
4. Person-Who is responsible
? Who is doing this? Why should he do it? If he is irresponsible and has a strong temper, can he change himself? Sometimes changing one person will improve the whole production.
5. Why-
why use this technical parameter? Why can't there be changes? Why can't it be used? Why does it turn red? Why do you want to make this shape? Why use machines instead of manpower? Why do you have to do it?
6. How (how)
means how is the process, for example, how do we do it? Why use this method to do it? Is there any other way to do it? What should I do? Sometimes when the method is changed, the whole situation will change.
Reference:
https://blog.csdn.net/u011090984/article/details/90724494
https://blog.csdn.net/zimingzim/article/details/81709142
Test Case: needs analysis prior to the conversion according to the instructions, with a look at how much demand is coverage of
the general idea of writing:
black box + white box use cases (supplement) = complete test use cases (priority)
overall strategy to prepare:
For the preparation of test cases, the four commonly used methods are basically enough, equivalent class, boundary value, orthogonal experiment method, error inference method, supplemented by the scene test method, demand / design conversion method, exploratory test , Can cope with the testing of most products. Individual products also need to be refined and expanded at a certain point, and need to be discussed.
Comprehensive design strategies using various writing methods;
1) In any case, the boundary value analysis method must be used. Experience has shown that the test cases designed by this method have the strongest ability to find program errors.
2) When necessary, supplement some test cases with equivalence class division methods, paying special attention to the situation of invalid equivalence classes.
3) If the function description of the program contains a combination of input conditions, the causality diagram method (or decision table method, orthogonal test method) can be used from the beginning.
4) Additional test cases are added by the method of error guessing, mainly using test experience.
5) Check the logic coverage of the designed test cases against the program logic. If the required coverage standards are not met, sufficient test cases should be added; refer to the white box use cases.
6) Study and think about the application scenarios of the program and add test cases in different scenarios; user scenario testing must be paid attention to, and a large part of program errors are caused by the difference between the test scenario and the user's real scenario.
7) After having a deeper understanding of the business and procedures, you can give full play to divergent thinking and exploratory ideas; everyone should not misunderstand that exploratory testing is aimless testing. In fact, exploratory testing has very detailed testing guidelines.
After the test, review it and see what the test looks like:
3. Test execution phase
During the test execution phase, see the comparison between the expected results and the actual results. If there is a bug, submit it, and then do a regression test on version two
4. Test summary stage
The statistics of bugs include the number, status, and rank of bugs, how many bugs have been submitted by various developers, and how many bugs are under the name of each developer. So write a summary based on these to see which development bugs are few and which test picks are few. The reason is that the development does not understand the requirements well? Lazy testing? Ability to develop code? The test is relatively new to the beginning? So as to make statistical analysis
