BUG location analysis method

As a tester, what you come into contact with the most are bugs. How can you show the professionalism of a tester? Being able to accurately locate and analyze bugs must be a plus for you.

If something is done somewhere and the result is inconsistent with the expected result, then this is a bug. Everyone can find bugs. How can we give developers more information on this basis to improve the efficiency of all parties? Here are some methods commonly used by testers at work.

1. Packet capture analysis method

By capturing packets, you can see the input and output parameters, etc. By comparing the developed technical solutions, you can determine whether it is a front-end or back-end problem. This method should be familiar to everyone, so I won’t introduce it too much.

2. Amplification of current phenomena

When you find a bug, don't rush to submit it. Remove another layer of conditions based on the current situation to see if it will happen, or verify whether a similar scenario will happen on this basis (if there is a new problem, see if the editor can fix it) There are also problems). It is necessary to amplify the current phenomenon to prevent developers from incomplete modifications.

3. Reduce the current phenomenon

If you find a bug, it may be under certain specific conditions, then you must find all these conditions to provide more information for developers to reproduce the problem (they will not keep looking for you because they cannot reproduce the problem)

4. Analogy

When you find a bug, based on experience, you can basically guess a reason. Then you need to verify whether it is the reason you guessed. You can use analogies. For example, you can change the subject to see if it will happen. If it happens, Then look for their common points, and if they do not happen, look for their differences, and so on, gradually narrow the scope to locate the problem. After basically locating the problem, follow this step and try again to determine the cause.

5. Error cause analysis method

If errors are reported in similar scenarios, check to see if the errors are caused by the same cause to avoid submitting multiple duplicate bugs. For example, interfaces in similar scenarios will report data anomalies/system busy prompts. Then go to the error logs to see if the error types are the same, which can avoid repeating bugs or missing bugs.

6. Handling occasional problems

Most problems that seem to occur by chance actually have necessary steps, so when it cannot be reproduced, try to recall the operation you just performed, boldly guess the cause and verify it. If it is really impossible to reproduce, you can write down this problem and follow the group The internal staff will synchronize and everyone will pay attention to it. When it appears again one day, compare the scenes that appear to find the reason. .

Finally: The following is the supporting learning materials. For those who are doing [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you!

Software testing interview applet

A software test question bank that has been used by millions of people! ! ! Who is who knows! ! ! The most comprehensive interview test mini program on the Internet, you can use your mobile phone to answer questions, take the subway, bus, and roll it up!

Covers the following interview question sections:

1. Basic theory of software testing, 2. web, app, interface function testing, 3. network, 4. database, 5. linux

6. Web, app, interface automation, 7. Performance testing, 8. Programming basics, 9. HR interview questions, 10. Open test questions, 11. Security testing, 12. Computer basics

  How to obtain the full set of information: Click on the small card below to get it yourself

Guess you like

Origin blog.csdn.net/weixin_57794111/article/details/132830867