Why is positioning so important?
- It can be clear whether a problem is really a "bug"
Many times, we find the cause of the problem, and it turns out that it is not a bug at all. When the cause is clear, false positives are reduced - Multiple systems interact, which can clearly point out which system is defective, prevent "kicking the ball" and improve the efficiency of problem solving
- Enhance the trust between development and testing, communicate more effectively, cooperate better, and improve the timeliness of developing and modifying bugs
- A more effective understanding of the system's internal logic and data flow processing flow can improve the level of testers. After the defect is repaired, the impacted test range can be evaluated more accurately and retested more accurately.
- Can reduce defect rate
- This is arguably the most important. In the bug system, developers are required 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
01. Before positioning the cause
When encountering a problem, don't rush to locate the cause.
1. Save the records generated by bugs:
The first thing to do is to save the records generated by the bug to ensure that it can be reproduced.
Why keep records? Because if it cannot be reproduced in the future, it cannot prove the existence of the bug.
2. Eliminate low-level problems:
Then there are low-level problems that exclude QA , common low-level problems:
- [hosts is wrong]
The hosts file is mainly to speed up the resolution speed of a domain name or website, so as to achieve fast access, and can also block websites.
Abnormal hosts may cause some webpages to be inaccessible and can be loaded, but the webpage cannot be displayed normally. - [Network failure]: packet capture, ping
- Caused by the impact of tools, such as fiddler
- And incorrect operating posture, etc.
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
3. Exclude data problems (dirty data):
Sometimes the server will report a 500 error. After checking the log, a null pointer will be reported, so it is likely that the data in the associated table in the database has been artificially deleted.
- Dirty data: The data retrieved from the target has expired, is wrong or meaningless, this kind of data is called dirty data
- Dirty read: Dirty read is called dirty read
02. The idea of positioning the problem
Check order:
User environment level -> presentation level -> logic control level -> service level -> database level
1. User environment level
It mainly refers to whether the basic environment can be used. for example:
- Whether the network is pinged
- Are the ip and port configurations correct?
- Does the jdk version meet the standard?
It may be that the system runs abnormally due to the incompatibility of the jdk version. This kind of problem depends on the actual situation to decide whether to be compatible. - Proxy is set up on the network
- Weak network (such as js/css not fully loaded, request timed out)
- browser does not support
- The system version does not support
- database is deleted
- Test environment dirty data
- Project configuration switch
- The test environment has cut branches, etc.
After the inspection is complete, you can go to the second step
2. User display layer
Some problems found by users through viewing and other operations during use:
- Page styles (css style issues)
- Tips for js during interaction (js interaction problem)
- Prompt information for terminal control
- Display of text (html text problem)
3. Logic control layer
In the process of user operation, whether the business processing logic is implemented according to the previous design. Or there is an exception in the middle link, such as cache server (such as redis), message middleware (such as rabbitMQ), data access middleware, etc.
4. Service layer
The service layer often checks the configuration of the server, for example, it may be a problem with tomcat configuration, nginx configuration, jdbc configuration, etc. It is best for testers to understand their configurations.
5. Database layer
There may be different database versions between the test environment and the official environment, and different data formats and length limits for the front and back ends. After the user operation is completed, the transaction process is very smooth, which does not mean that there is no problem with the entire transaction, and testers need to check whether the tables and fields registered in the database are correct
- If you find that the registered fields are inconsistent with the expected results, you can check the log to check whether the fields sent in the request message are correct and consistent with those filled in at the front desk
- Some operations will register multiple tables, so it is necessary to check whether the registration or update of multiple tables is correct, and the tester also needs to be familiar with the data table structure of the system under test
6. Rules of thumb
Experienced testers have seen some bugs many times, can quickly find the root cause, go straight to the topic, report or solve the bug quickly
7. Others
Common bugs may also have construction reasons
- For example, the code itself is correct, but there is a problem after merging the code to the trunk
- For example, when there is a conflict in the code, it is manually resolved
03. How to locate the problem
1. Common positioning strategies:
Commonly used positioning strategies are divided into three categories: original class (brute force), backtracking class (backtracking), exclusion class (causeeliminations)
- Primitive class location method
The original class positioning method is the most commonly used and the least efficient method. It is only used in desperate situations. The main idea is to "find errors through the computer".
- Backtracking
Backtracking can be successfully used to debug programs
The method is to manually trace back along the control flow from the place where the bug symptom occurs, until the root cause of the error is found. Unfortunately, when the program becomes larger, the possible traceback routes increase significantly, so that manual traceback is out of reach. .
- Exclusion
Based on the principles of induction and deduction, the concept of "divide and conquer" is adopted.
First determine all the data related to the occurrence of the bug, imagine a cause of the bug, and use these data to prove or refute it. Or list all possible causes at once and eliminate them one by one through testing. As long as a certain test result shows that a certain hypothesis has emerged, immediately refine the data and pursue the victory
2. View the status code
4xx status code: generally indicates a client problem (of course, it may also be a server configuration problem), such as:
- If 401 occurs, it depends on whether the correct authentication information is brought
- If 403 occurs, it depends on whether you have permission to access
- 404 depends on whether the corresponding URL actually exists
5xx status code: generally indicates that there is a problem with the server . for example:
- If a 500 error occurs, it means that it is an internal server error. At this time, it is necessary to cooperate with the server log to locate
- If a 502 error occurs, the problem may be caused by the server hanging
- 503 errors may be caused by network overload
- If a 504 error occurs, it may be that the program execution time is too long, resulting in a timeout
3. Check the server log
If a 5xx problem occurs, or you need to check whether the SQL executed by the backend interface is correct, our most common troubleshooting method is to check server log , such as the tomcat log. Developers generally type out key information and error messages to find out where the problem lies. Therefore, testers should also develop the habit of reading logs.
4. Check configuration
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.
5. View 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 it does not match the requirements document, then it is necessary to see what is more reasonable to change, whether to change the front end, the server end, 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.
6. Seek testability support from development
Sometimes, some tests related to the development process also require development 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, as well as some logical switches, modify the number of data items on the page, etc., all belong to the category of testability support.
04. Common tools for bug location
Firefox——firebug、web developer、live http - headers、http fox
IE plug-in - httpwatch
Third-party tool - fiddler
Slow network simulation tool - firefox throttle
05. How to distinguish front-end/back-end bugs
Why distinguish front-end/back-end bugs?
- If it is a system developed by multiple people, it is impossible to clearly locate who caused the bug, and it is easy to submit it to the wrong developer.
- At the same time, when submitting to the front-end and back-end developers, everyone will have a dependency mentality, and the bug will be kicked around by the developer like a ball, delaying the time for development to solve the bug.
- In addition, if the team is large in scale, or is composed of project teams from various places, it will inevitably increase communication costs. This requires us to first indicate whose bugs are submitted when submitting bugs in project management software such as ZenTao or Jira. Avoid kicking the ball with each other.
- Therefore, the test must learn to distinguish front-end or back-end bugs by itself. After bug classification and processing, the efficiency of the entire team will be improved.
What are the characteristics of front-end and back-end bugs?
1. Use packet capture tools for analysis
Generally, there are packet capture (packet) tools such as httpwatch, firebug, fiddler, and charles.
- Httpwatch and firebug are browser plug-ins that require additional downloads
- fiddler, charles also need to download the installation package and install it separately
- There is also a simple and practical packet capture tool, that is the browser's F12 debugger
2. Locating front-end bugs
Front-end bugs are usually related to functions, interfaces, and compatibility , and involve jstl, jsp, js, css, and html. There are two main bugs:
- JS-related
- page
3. Locating back-end bugs
The background involves servlet, jms, ejb, and many frameworks struts, hibernate, spring, ibatis, etc.
Bugs are difficult to fix, but they are easy to find. The main thing is to look at the console for errors, and then locate the error line number. If there is no problem with the configuration file, then the general error is a null pointer, or the array subscript is out of bounds. Looking at the nearby variables and the parameters of the method can basically locate the error.
06. After locating the problem
After finding the problem or locating the cause of the problem, one must proceed, which is to confirm the problem again. The so-called confirmation problem is to find out whether the problem occurs every time, is it a probability event, or is a tool-related problem:
- For example, does the browser still appear? If another browser does not appear, it is likely to be a front-end compatibility problem.
- For example, the page-turning control, many pages of the system to be tested have page-turning controls, so it is necessary to check whether this problem occurs on every page, and then provide a unified explanation when reporting bugs, which is also more convenient for developers to process in batches and prevent leaks. change.
The following are supporting learning materials. For friends who do [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse also accompanied me through the most difficult journey. I hope it can help you too!
Software testing interview applet
The software test question bank maxed out by millions of people! ! ! Who is who knows! ! ! The most comprehensive quiz mini program on the whole network, you can use your mobile phone to do the quizzes, on the subway or on the bus, roll it up!
The following interview question sections are covered:
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
Information acquisition method:
