01 The importance of positioning problems
Many testers may say that my duty is to find bugs. As for finding the cause and fixing it, that is a matter of development. What does it matter to me?
Well, my answer is, if you just want to do the most basic and duty-bound thing as a tester, then you can think of it this way. However, if you want to get ahead in testing or even development, you need to know why.
So why is the issue of positioning so important?
1. It can be clear whether a problem is really a "bug". Many times, we find the cause of the problem and find that it is not a bug at all. When the cause is identified, false positives are reduced. For example, Damei in our team, none of the 500 bugs in the year was invalid.
2. After finding the cause of the bug, you can clearly point it to a certain developer to prevent them from pushing around and speed up the repair of bugs.
3. Let developers admire you and improve development's trust in testing.
4. I can learn a lot in this process, which helps to understand the internal logic of the product, the understanding of the architecture, and the direction of the data flow. With the understanding of the business architecture logic, it will in turn promote the positioning of the problem.
5. Can reduce defect rate. This is arguably the most important. In the bug system, we will ask developers to record the cause of the bug. Only when we have a more comprehensive understanding of bugs, can we judge whether the development and writing are the real reasons, and it will also help us analyze and classify bugs in the future. According to the bug analysis, we can plan ahead in a targeted manner, and then Improve product quality and reduce defects.
Therefore, the positioning problem is very important.
Next, let's discuss the methods and techniques of positioning problems.
02 Problem positioning skills
First of all, the positioning problem has a general idea, and this idea is consistent with the direction of the data. Roughly like this:
First of all, when a bug occurs in the system, you must record and save the bug phenomenon. The preservation phenomenon is to prove that the bug has occurred. If the bug is fixed and reproduces, it is okay. Evidence, to develop a good habit of preserving the scene
When it comes to BUG, it is still necessary to reflect the professionalism of the test. The title is concise, the problem environment is clearly identified, the problem is described in detail, the system error representation map, the interface parameter transfer and return reference map, and the server log is posted when necessary. In summary, it should not One less bug label, not one less
1. For small products, one person coordinates the front and back ends
For some small programs, for example, the front and back ends are developed with node and php languages. When the front and back ends of the whole system are developed in the same way, then the editor can confidently tell you that when there is a problem with the system, the bug is raised boldly, and the sudden death Mention, the responsible person cannot be wrong!
2. Conventional system, multi-person development collaboration
Pre-test: Before the test, the tester is familiar with the system, business, environment deployment, developers, etc.
Before the test, open F12 of the corresponding browser and directly open a new tab, or use a packet capture tool, etc. When the system has problems, check the corresponding requests, log information, etc., so that we can fully locate whether it is the front-end or the back-end personnel. problem, we will introduce the following common methods
1. Analyze problem scenarios and make predictions
Check the appearance of the page first, judge the possible cause of the problem according to the appearance of the problem, narrow down the scope, and prepare the recording tool to record the problem
The prompt that the system page cannot be accessed normally should look for the backend at the beginning of 5, and check the request address or corresponding permissions first if it starts with 4, then enter the system page to open normally, and find the backend directly if it prompts that the abnormal code is wrong
Enter the system page to display abnormal pictures, video related prompts, Flash and other related information to install Flash. If it still doesn’t work, find the front end, and the interface UI displays compatibility errors. Find the front end
If the system access is normal, enter the operation page, and the functional error message is reported, then enter the following link, capture the packet and check the corresponding request body, log, etc.
2. Pay attention to the status code of the request body
Status codes starting with 4** are generally problems with the client (front end); for example, the common 404 confirms whether the requested address is wrong, and 403 confirms whether there is permission to access. For details, please refer to Baidu
Status codes starting with 5** are generally server (backend) problems. For example, the common 500 indicates an internal server error, 503 network overload causes server delay, 502 server crashes, etc. For details, please refer to Baidu
3. Pay attention to the input and participation response data of the request
By accessing the page where the error is reported, we analyze the request package through F12 when loading the error request, and check the corresponding input parameters and response data
For example, if the request input parameter is wrong, then the bug belongs to the front-end error; the input parameter standard can be verified according to the input content or selected content of the front-end page, and the input parameter format and whether it is required can be analyzed according to the interface document or Confirm with development
For example, if the request is not responded to or the response data is wrong, then the bug is a backend error; it is generally an error reported by the database view, such as deleting a certain table query and reporting an error null pointer, etc.
If there is no problem with the input parameters or response data of the request, you can report to the developer whether it is a browser parsing problem, and you can change the browser to test
4. View logs
For the error report of the server type, we can log in to the log platform or view the printed log in the log directory corresponding to the server
Commonly used to view the log command tail, /error to quickly retrieve keywords, interface names and other related content
Get the corresponding log, paste the log file into the bug list, and assign it to the backend to improve professionalism. Testers should also develop the habit of reading logs, and they will understand after just looking at them.
5. Rules of Thumb
When encountering server configuration-related error information on the front-end page of the system, such as Nginx or code and SQL-related prompt error information, go directly to the back-end for processing, such as JAVA *, .PHP, SQL and other abnormal error reports
For front-end character verification, format verification, etc., browser interface UI compatibility and plug-ins, or APPs and small programs to call related functions of mobile phones to take photos, and voice cannot be called normally, directly go to the front-end
Let's talk about the n-axes of testers' positioning problems.
1. Let the bullets fly for a while
Don’t rush to locate the problem first, save the crime scene first, and confirm that it can be reproduced. Then rule out the low-level problems of QA. Why save the scene? If it cannot be reproduced in the future, it cannot prove the existence of the problem. What are the low-level questions of QA? The common ones are that the hosts are incorrect, the network is unreachable, and the operation posture is incorrect, etc. This is actually the user-level problem mentioned above, and the users here are QA personnel. There are often QA personnel who find a problem and quickly call the developer to take a look. At this time, the developer quietly says "Is the host right?"
Another type of problem is dirty data. We sometimes encounter a 500 error reported by the server. After checking the log, a null pointer is reported, so it is likely that the data in the associated table in the database was artificially deleted. There are also problems caused by the influence of tools, such as fiddler. So don't panic if you find a problem, let the bullets fly for a while, and then confirm that it is not your problem.
2. Visually check the page performance
This is the observation of the Web page mentioned above. No longer.
3. Look at the status code
The 4xx status code generally indicates a client problem (of course, it may also be a server configuration problem). For example, if 401 occurs, it depends on whether the correct authentication information is brought; if 403 occurs, it depends on whether there is permission to access; 404 depends on whether the corresponding URL actually exists.
5xx generally indicates a server-side problem. For example, if a 500 error occurs, it means that it is an internal server error. At this time, you need to cooperate with the server log to locate it; if 502 occurs, it may be caused by the server hanging; if 503 occurs, it may be caused by network overload; if 504 occurs, it may be caused by a program. Excessive execution time resulted in a timeout.
4. Look at the server log
If a 5xx problem occurs, or to check whether the SQL executed by the backend interface is correct, our most common troubleshooting method is to look at server logs such as tomcat logs. Developers will generally display key information and error messages to find the problem. Testers should develop the habit of reading logs. Moreover, if you develop in the future, you must also develop the habit of logging, otherwise you really don’t know where to cry if you find a problem.
5. Whether there is an error in the request and return of the interface and the execution of js
In point 3, we talked about the status code problem, and clarified the problems of 4xx and 5xx. So, if the interface returns 200, must it be normal?
Suppose there is a situation where you want to test a page-turning control. When you turn to the second page, you find that the content is exactly the same as the first page, and the interface request returns 200. How will you investigate at this time?
At this time, it depends on whether the parameters sent by the front end are normal, and the content returned by the back end is normal, that is, the request and return of the interface.
Let's look at the problem with the page turning control. We look at the request of the interface (F12 console to check the network request or the packet capture tool). Generally, according to the development habit, there will be pn and ps parameters to see if the passed value is correct. If the request parameters are incorrect, then it is a problem with the front end. If it is correct, then look at the response to see if the returned content is correct, so as to know whether it is a front-end problem or a server-side problem. If you find that the js execution reports an error, it means that there is a problem with the front end, such as a cross-domain problem.
If the request URL is incorrect, it is a front-end bug. If the parameter passed is incorrect, it is a front-end bug. If the response content is incorrect, it is a back-end bug. If it is a back-end problem where the response content is incorrect, then you need to continue to dig deeper. Is it an error when the interface spits out data, or the data in the database is wrong, or the data in the cache is wrong (if the cache is used) . It is often seen that some back-end developers are responsible for the interface, some are responsible for writing to the database, and some are responsible for maintaining the cache, so if you find that it is a back-end problem, you can further confirm which part of the problem it is.
6. Look at the requirements document
Sometimes, the interaction between the front end and the server is correct, but it doesn't make sense 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 depends on who is reasonable to change, whether it is the front-end change, the server-side change, or both. There is a principle here, that is, the front end undertakes as little logic as possible, and is only responsible for rendering and displaying. 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 to urge FE or RD to make changes. In this regard, it has to be said that some development is better, he will have his own ideas, and he can find errors in the requirements document during development, while some development is unconditional and mindless execution.
7. Back-end generation page problem
The back-end generates pages, and the most common ones are some frameworks similar to jsp, php, and python that do not separate the front and back ends. This is special, and it is common in projects developed by a single person. The troubleshooting of this project is the same as other projects. The idea is the same, but the modification of front-end and back-end bugs may be the same person.
8. Development provides testability support
Sometimes, when multi-faceted cooperation is involved and testing is not easy, development needs to provide testability support. For example, to check whether the request sent by an interface to another interface is correct, you can let the development print out the complete request log. There are also some logical switches, modifying the number of page data items, etc., all of which belong to the category of testability support.
9. Configuration problems
In many cases, bugs are not code problems, but problems with tomcat configuration, nginx configuration, jdbc configuration, etc. At this level, it is best for testers to be able to understand their various configurations, and they may think of problems in this area after discovering problems.
10. Rules of Thumb
There is nothing new under the sun, experienced people have already encountered the same problem. Experts are often able to see through the internal problems of superficial phenomena at a glance, and then go straight to the topic, report or solve them quickly, leaving others in a mess in the wind...
11. Others
There may be construction problems that are common. For example, the code itself is correct, but something goes wrong after merging the code to the trunk. The common problem is when there is a conflict in the code and it is manually resolved. So for a while, I liked to ask if there was any conflict when the development merged the code. If there was a conflict, where was the conflict, and I had to focus on it.
In addition, after locating the problem, you need to consider the specific situation, and decide whether to tell him the specific reason based on the developer's mentality. Some developers are not open enough, and they will feel that you have robbed him of his job. As for the development of open, you will cooperate more tacitly.
Of course, after we discover 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, or is it a probabilistic event, or a tool-related problem (for example, does it still appear in another browser? If it does not appear in another browser, it is likely to be a front-end compatibility problem) . For example, the page-turning control, many pages of our system to be tested have page-turning controls, so we need to see if this problem occurs on every page, and then give a unified description when reporting bugs, which is also more convenient for developers to process in batches to prevent omission.
Finally: The complete software testing video tutorial below has been sorted out and uploaded, and friends who need it can get the software testing interview documents by themselves【保100%免费】
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Ali, Tencent, and Byte, and some Byte bosses have given authoritative answers. Finish this set The interview materials believe that everyone can find a satisfactory job.
