I have been working in software testing for many years, and I have been engaged in software testing since graduation. Unknowingly, I have been engaged in software testing for more than 3 years. The long-term testing work has given me a deeper understanding of software testing. But now I still make mistakes occasionally at work, and there is still a long way to go before being an excellent test engineer. The following summarizes my work experience.
1. Work experience
1. Familiar with the business requirements specification
The main work of a test engineer is reflected in test reports and test cases. Only by being familiar with the business requirements of the project can we design comprehensive, high-coverage, and multi-abnormal test cases. Some details are even more meticulous than product managers. . As long as you encounter any unclear or doubtful places, you must ask the product manager for confirmation.
2. Familiar with the development of detailed design
Many test engineers may think that the detailed design of the development does not need to be understood, as long as the function of the software is done, it is fine, and there is no need to care about how it is done. This kind of thinking is incorrect. After understanding the detailed design of the development, you will know what the whole process of the business is like, and you will know whether the development has taken all scenarios and exception flows into consideration, and whether you have really understood the business requirements.
3. Test yourself as a user
Treat yourself as a user to test the software, simulate all behaviors that the user may operate, and keep in mind every page and every function of the software. When encountering a problem and raising a bug, the title and content should be described clearly, concisely, without ambiguity, and the steps to reproduce should be written, and it is best to attach a screenshot of the problem. After each test is completed, you must write a test report, summarizing the problems you have encountered or what you think is unreasonable. The logic must be clear and the number of words should be concise.
4. Keep learning and understand the basics of software
If you don’t understand the basics of the software, the test will always stay on the display, just click on the page, don’t know how the backend works, how the frontend and the backend are connected, and you can’t even hear what the development is saying I understand, after reading the detailed design of the development, I just follow his instructions, and I will not ask questions with a questioning spirit. At least you need to know what language the software is written in, what framework is used, and what database is used. Only when you understand the basic software knowledge can you communicate with developers without talking about it.
5. Maintain enthusiasm and interest in work
Testing work is repetitive work over and over again, and a use case may be executed many times. Every time a project is upgraded, a regression test is required. It takes a lot of time and energy to execute the original hundreds of use cases. The process is very boring. If you can maintain your passion and interest, every execution is regarded as the first As fresh as one-time execution, it will be much easier to work with.
2. Testing skills
When I was working, I summarized some of my testing tips.
1. Press F12 to view the debugging interface and analyze whether the bug belongs to the front end or the back end
When testing, sometimes you will encounter some problems. I don’t know whether it is a front-end or a back-end problem. Sometimes the bug is wrongly assigned, which will directly affect the progress of solving the bug. Sometimes when testing some list data, it is found that the query list data If it does not match, it is difficult to judge whether it is a front-end problem or a back-end problem. At this time, you can press F12 to enter the debugging interface and select the Network interface. Headers here can see the front-end request address and request parameters, and Respons can see the back-end return data.
Here is an example to illustrate that the front-end display has a data list with a query condition of status, and the status is divided into: all, success, and failure. When the query is successful, the data displayed in the front-end list is failed. At this time, you may wonder if the front end displayed an error. First, press F12 to view the debugging interface to see if the data returned by the back end is in a successful state. As a result, the back end returned data in a failed state. At this time, it may be I wonder if the backend is wrong, don’t worry, and finally check the request address and parameters in the Headers. At this time, I found that the request parameters are wrong, not the parameters of the status success, but the parameters of the status failure, so that it can be determined that it is the front end problem.
2. Check the backend log
When doing the test, be sure to open the back-end log. When operating on the front-end page, when an error message pops up suddenly, how to analyze whether it is a front-end or back-end error can be reflected in the log. If the back-end log does not report an error, It is considered to be a front-end problem. If there is an error in the back-end log, it is considered to be a back-end problem. Take a screenshot of the log and paste it in the bug details, which can facilitate development and check the problem. When operating, check whether the SQL statement written in the log is normal , Whether it meets the requirements of the operation can be simply analyzed by yourself.
3. Check the database
When doing the test, be sure to check which tables correspond to each module in the database, whether the table fields meet the requirements, whether the table design is reasonable, whether there is an index, whether there is a unique key, and how the tables are related. When there are a lot of table data At the time, whether the old data has been moved to the table or not, these need to be checked again.
4. Create data
When doing tests, sometimes you need to query many pages of the list, and you need a lot of data. If you add it manually, it takes 20 seconds to add one, and it takes 1 hour to add 200. Sometimes the test data export function exceeds 1 When there are 10,000 pieces of data, it is asynchronous. If you add 10,000 pieces, it will take a few days, which is a waste of time and energy. At this time, you can create data in the database yourself, insert data directly into the table you need to use, and write a for loop It can be easily done.
5. Record script
When doing the test, every time the project is upgraded, a regression test is required. Some tools can be used to assist to achieve twice the result with half the effort. I am using badboy. First, record some actions I want to operate, such as some of the list Add, delete, modify, save the recording in jmeter format, and then use jmeter to open the script and run it. Of course, sometimes it does not run smoothly, so you need to manually modify the script, or add a "monitor "Tool-View Result Tree" to judge the result status of the operation.
3. Automated testing ideas
I have really learned and practiced automated testing for two years, and I have gained a lot. Let me summarize some of my automated testing ideas.
1. Advantages of automated testing
① Reduce return cost
② Improve regression coverage
③ Improve regression efficiency
④ Improve the stability of regression
2. Disadvantages of automated testing
① Automation is more suitable for regression and smoke, and it is difficult to find BUG
② Not all systems and functions are suitable for automated testing
③ Automated scripting and maintenance take a long time
3. What projects are suitable for automated testing
① The demand for the project is stable and does not change much
② The project cycle is long and iterative
③ The project supports many platforms, such as multi-browser compatibility testing, mobile phone multi-system version testing, etc.
④ Testing activities that cannot be achieved through manual testing, such as stress testing
4. Classification of automated testing
① Interface automated testing
② Automated testing of UI pages
At the beginning, I also started from interface automation, because the projects I was working at that time were mainly data query and statistics, and I didn’t know how to start the automated testing of UI pages. Later, I went online to see how other people did it. I found that many people said that such statistical data projects basically cannot do UI automation testing. Later, I thought that even if it is a list of statistical data, it is not necessary to check every item and every field. Just check some The field is fine, so it is much simpler. First, I will get the first field of the first item in a list on the page, and then connect to the database to get the value of this field. Compare the two values It is the same, then there is no problem.
Although automation cannot completely replace manual work, it does save the repetition of manual work. Some items may not be easy to operate in the work. As long as it is used flexibly, there is no automation that cannot be done. If you want to automate well, you must have coding ability. At least you must be familiar with the code language of the automation tool/framework. It is best to have a certain coding ability. At the same time, the code logic must be clear, otherwise the logic, business and robustness of the use case will not be guaranteed. Factors such as sex cannot guarantee efficiency.
In the end, many friends have the idea of learning automated testing. Here I share a video tutorial on automated testing at Station B. You can watch it by yourself:
Public account fan benefits
-
Get a full set of software testing resources for free
-
Software testing interview question brushing applet is free to use
-
Free use of GPT exclusively for testers
