Click on the "blue word" above to follow us easily
Tomorrow is New Year's Eve. Many people have returned to their hometowns and ate the meals cooked by their mothers. This should be the happiest moment. I also use the few hours left to work a year ago to share the defect location (2) with everyone. I hope everyone can support, and I wish you all a happy new year in 2022, happiness and health! ! !
Past classics:
Defect location | The test found a bug, but do you need to analyze and locate the bug? (one)
I think BUG analysis, reasoning and positioning are very interesting. It is very similar to solving a case. According to various evidence information provided by users, analyze and reason, gradually try to restore the scene, and finally restore the scene of the crime. This is the most glorious moment and the most glorious moment. It is also worthy of the respect and admiration of others, so BUG positioning is very important in our daily work, and it is also the most important technical means for test engineers.
The efficiency and accuracy of BUG positioning has a lot to do with its experience accumulation. It takes a lot of time for ordinary newcomers to reproduce BUGs, but people with rich experience have experienced more types of BUGs. Seeing the appearance of BUGs, you can It is very efficient to roughly identify the cause of the BUG at a glance, and then try to reproduce it based on the identification results. If the identification is wrong, try a second identification. First of all, when we generally receive a bug, we can roughly classify whether it is a front-end problem or a back-end problem, whether it is a data problem or a business logic problem, whether it is a system compatibility problem or a network environment problem, etc. according to the situation, so that we can reason and reproduce it at a deeper level. Randomly and illogically reproducing BUG is not only inefficient but also difficult to reproduce the problem.
If the user provides a large amount of information (pictures, videos, environment, version number, device information, network environment, location, etc. where the bug occurred), try to reproduce the test environment directly according to the user's operation steps. If it can be reproduced, it means that we This bug does exist in the business; if it cannot be reproduced, try the same software version with the user, and if it can be reproduced, it may be related to the reproducible version of the software; if it cannot be reproduced, it can be reproduced with the user in the same environment , indicating that it may be related to the reproduction environment; if it cannot be reproduced, consider using the same software version, the same device information, the same software progress data, and the same network environment as the user. , The network environment may be related; if it cannot be reproduced, try to log in to the user account information to reproduce, if it can be reproduced, it may be related to the user account data; if it still cannot be reproduced, we need further analysis and reasoning.
Analyze the time period and scope of the BUG occurrence. If it happened to a large number of users in the last 1-2 days, it may be caused by the recent small version, small version business or some logic changes; if it happened to individual users in the last 1-2 days, It may be caused by some operating logic after a small version was recently launched; if it is an occasional phenomenon that cannot be reproduced by individual users, it may be related to user account data, network environment, software version, device compatibility, etc.
Analyze the user account data, check the user's registration time, and judge whether it is compatible with the old account data, causing problems; check the user's operation behavior, and judge the problems caused by the user's abnormal operation; compare with the normal user data to judge whether it is Problems caused by bad data.
If you see interface 500, must it be a backend bug? This should not necessarily be true. It does appear that there is an error in the backend, but it is not necessarily caused by a BUG in the backend. It may also be caused by an error in passing parameters or an exception in the frontend, or it may be an error or abnormal data returned by interface A to the frontend. , causing the front-end to take wrong or abnormal parameters to make an error in the request of interface B; it may also be that the front-end H5 passed the wrong or abnormal parameters to the App, causing the App to get wrong parameters and request the interface to make an error. It is all possible, so The occurrence of BUG requires further analysis, location and confirmation, and conclusions cannot be drawn blindly.
Example reasoning analysis:
Recently, I played Douyin’s annual red envelope activity again, and happened to encounter a few bugs. I will analyze and reason for you on the spot.
Question 1: Withdrawal, click Withdraw Now, and the withdrawal fails with an error message, please try again
Steps for problem occurrence: After the withdrawal is successful, return to the withdrawal page, click withdraw immediately again, and an error will be reported
When we see this problem at a glance, we can judge that it should be an error reported by the backend. It is most likely not a device compatibility problem, nor a network environment problem, because the network environment in the picture is full, and we can see the withdrawal amount It is not selected, so guess whether the amount is not selected, resulting in an error in the App passing parameters, and the backend reports an error, and then capture the packet and reproduce it according to the speculation. This is the problem caused by insufficient interface testing.
Question 2: Return the goods, match with the logistics delivery person, cancel the return, select the reason for the cancellation as other, click confirm, the error task_fulfillment_pickup_cancel 503 failed to cancel the logistics
This problem seems to be an error reported by the backend. From the error message, it can be seen that the cancellation of logistics failed. Normal cancellation of logistics cannot fail. After all, it is a big Douyin factory. It is speculated that the backend may have handled the exception or the frontend. An abnormal parameter is passed. If an abnormal parameter is passed, an error will be reported if the normal cancellation is made. It is speculated again that the error may be caused by repeated cancellations. The logistics has been canceled successfully. Cancel again, and the cancellation fails with an error. This kind of problem occurs. It has verified the state test method I mentioned before, and it is necessary to test it.
The time is too short, I was thinking and writing for an hour, actually I had a lot of thoughts in my heart, but I actually couldn’t write it out, I feel that the writing is very low and rough, everyone will just read it, think it is well written, remember Like it, forward it to more friends, thank you! ! !
long
according to
close
Note
Official account: Wang Dali tests the road to advancement
WeChat group: wanglilitesting
QQ group: 212683165
Automation | Performance | Security | Test Development
If you like it, click "Favorite" and "Watching" below to share with your friends!