test analysis
one. The importance of locating bugs:
1. It can be confirmed whether the discovered problem is a real problem. Many times, we find the cause of the problem and maybe it's not a bug at all. If the cause is clear, false positives will be reduced.
2. After finding the cause of the bug, you can clearly refer to a certain development to improve the speed of repairing the defect.
3. Reduce the defect rate. It will give us a more comprehensive understanding of bugs, and it will also help us to analyze and classify bugs in the future. According to bug analysis, we can take precautions in a targeted manner, thereby improving product quality and reducing defects.
2. Problem positioning skills :
User level issues -> Web page/software interface -> Middleware -> Backend services -> Database
1. User-level problems : refers to the user's own environmental problems or operation problems, such as the environment is blocked, or the operation is incorrect.
2. Problems may also be found during normal operation of the web page . Such problems are generally found through observation and the use of some common sense, such as style problems. After the Web page is operated, such as issuing a request, it may enter the middleware level. The middleware I am talking about here is in a broad sense, such as LVS, CDN, various cache servers, and so on.
3. The service will be forwarded to our real backend service layer , and the web server, application server such as nginx, tomcat will receive the request. If memory overflow is found, it may be a problem with the tomcat configuration; if the request returns 404, it may also be an improper configuration of nginx.
4. At the database level : there may be a missing field, or the field value may be empty, etc. These may have planted the wrong seeds when designing the database, causing the program to call the wrong data in the database to generate bugs. This type of problem does not count It is common, but it is also one of the most easily overlooked situations. Sometimes starting from the database to locate bugs may also find the design flaws of the database.
5. Network level: Usually this is caused when the network conditions are poor, such as the mobile phone's mobile network signal is not good, or the company's network is unstable, resulting in js/css not fully loaded or request timeout, etc., This kind of problem is actually not caused by program bugs, so you don't need to submit bugs, and you don't need to let developers check the code without any clue. Of course, if possible, it can also be given to the developer as an optimization suggestion, and let him optimize the code, such as compressing js/css, increasing the timeout period, and retrying mechanism after timeout.
three. Regarding the positioning of testers:
1. Don't rush to locate the problem first, record the operation steps first, and confirm that it can be reproduced. Then the exclusion is that the network is unreachable, and the operating posture is incorrect and so on. Another type of problem is dirty data. We sometimes encounter errors reported by the server. After viewing the log, a null pointer is reported. It is very likely that the data in the associated table in the database has been artificially deleted. Other problems are caused by the influence of tools, so don't panic when you find the problem, and confirm that it is not your own problem.
2. The 4xx status code generally indicates that it is a client-side problem (of course, it may also be a server-side configuration problem). For example, if 401 occurs, then check whether you have brought the correct authentication information; if 403 occurs, check whether you have permission. Access; 404 depends on whether the corresponding URL actually exists. 5xx generally indicates a server-side problem. For example, if an error of 500 occurs, it means that it is an internal server error. At this time, it is necessary to cooperate with the server log to locate it; if an error of 502 occurs, it may be caused by the server hanging up; if an error of 503 occurs, it may be caused by network overload; if a 504 occurs, it may be caused by a program Excessive execution time resulted in timeout.
3. Look at the server log, if there is a 5xx problem, or check whether the SQL executed by the back-end interface is correct, our most common troubleshooting method is to look at the server log such as the tomcat log. problem lies in. Testers should develop the habit of reading logs.
4. Sometimes, the front-end and server-side interactions are correct, but not reasonable from a testing point of view. At this time, we should look through the requirements document (if not, just throw this question directly). If it does not match the requirements document, then it is necessary to see who should change it reasonably, whether it is the front-end change, the server-side change, or both. There is a principle here that the front end should undertake as little logic as possible and only be responsible for rendering and presentation. Of course, don't think that the requirements document is all correct, it may also have errors, we should also find bugs in the requirements document, and then coordinate with PM and urge FE or RD to make changes.
5. Of course, after we find the problem or locate the cause of the problem, we must take one step, which is to confirm the problem again. The so-called confirmation problem is to find out whether the problem occurs every time, is a probabilistic event, or is a tool-related problem (for example, does it still appear after changing browsers? If it does not appear after changing browsers, it is likely to be a front-end compatibility problem) . For example, the page-turning control, the system we are testing has many pages with page-turning controls, so we need to see if this problem occurs on every page, and then we will provide a unified description when reporting bugs, which is also more convenient for developers to batch process and prevent Missed change.