After working for many years, I have been engaged in software testing since graduation. I have been engaged in software testing for 6 years without realizing it. The long-term testing work has given me a relatively in-depth understanding of software testing. But there are still occasional mistakes in work today, and there is still a long way to go before a good test engineer, the road is long and the days are long, and it is okay to slow down. Below is a summary of my work experience.
After 6 years of software testing, how did I quickly grow from a rookie to a test engineer?
1. Familiar with business requirements specification
The main work of test engineers is reflected in test reports and test cases. Only by being familiar with the business requirements of the project can we design comprehensive test cases with high coverage and multiple exception flows. Some details are even more detailed than product managers. . As long as you encounter any unclear and questionable places, you must ask the product manager to confirm.
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 made, and it is not necessary to care about how it is done. This kind of thinking is incorrect. After understanding the detailed design of development, you will know what the entire process of the business is like, and will you know whether the development has taken all scenarios and exception flows into consideration, and whether you really understand the business requirements.
3. Test yourself as a user
Test the software as a user, simulating all the actions a user might perform, keeping in mind every page, 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, preferably with a screenshot of the problem. After each test is completed, be sure to write a test report, summarizing the problems you encountered or what you think is unreasonable. The logic should be clear and the number of words should be concise.
4. Continue to learn and understand the basics of software
If you don't understand the basic knowledge of software, the test will always stay on the display, just click on the page, you don't know how the back end works, how the front end and the back end are connected, and you can't even listen to what the developers are saying. Understand, the detailed design of the development is just according to his, and will not ask questions with the spirit of doubt. At least you need to know what language the software is written in, what framework is used, and what database is used.
5. Maintain passion and interest in work
Test work is repetitive work over and over, and a use case may be executed many times. Every time a project is upgraded, a regression test is required, and it takes a lot of time and energy to execute the original hundreds of use cases again. The process is very boring. If you can maintain passion and interest, each execution will be regarded as the first The freshness of one execution makes it a lot easier to work with.
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, I sometimes encounter some problems. I don’t know whether it is a front-end or a back-end problem. Sometimes the bug is dispatched incorrectly, which will directly affect the progress of solving the bug. Sometimes when testing some list data, it is found that the query list data is If it does not meet the requirements, 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. The 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. The front-end display has a data list and a query condition is the status. The status is divided into: all, success, and failure.
When the query is successful, the data displayed in the front-end list fails. At this time, you may wonder if the front-end display 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 returns 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, it is 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 the problem.
2. View backend logs
When doing a test, be sure to open the back-end log. When an error message pops up when operating on the front-end page, how to analyze the front-end or back-end error can be reflected in the log. If the back-end log does not report an error, Then it is considered to be a front-end problem. If there is a log error in the back-end, it is considered to be a back-end problem. Take a screenshot of the log and paste it into the bug details, which can facilitate development and check the problem. When operating, check whether the SQL statement in the log is written normally. , whether it meets the requirements of the operation, you can simply analyze it yourself.
3. View 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, how the tables are connected, and when there is a lot of table data When there is no old data transfer table processing, these need to be checked again.
4. Find 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 will take 20 seconds to add one, and it will take 1 hour to add 200. Sometimes it takes more than 1 hour to test the data export function. When there are 10,000 pieces of data, go asynchronous, and it will take several days to add 10,000 pieces of data, which is a waste of time and energy. At this time, you can find data in the database yourself, insert data directly into the table you need to use, and write a for loop. You can do it easily.
5. Record the script
When doing testing, every time the project is upgraded, a regression test must be performed. You can use some tools to assist, to achieve a multiplier effect. I use badboy. First, record some actions I want to operate, such as some of the list. Add, delete, modify, save it in jmeter format after recording, and then use jmeter to open the script and run it. "View Result Tree" to judge the result status of the run.
I have been learning and practicing automated testing for two years, and I have gained some. The following summarizes some of my automated testing ideas.
1. The advantages of automated testing
①Reduce the cost of return
②Improve regression coverage
③Improve the return 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 bugs
②Not all systems and all functions are suitable for automated testing
③Automated script writing and maintenance takes a long time
3. What projects are suitable for automated testing
①The demand for the project is stable, with little change
②The project has a long cycle and can be iterated continuously
③The project supports many platforms, such as multi-browser compatibility test, mobile phone multi-system version test, etc.
④ Testing activities that cannot be achieved through manual testing, such as stress testing
4. Classification of automated tests
①Interface automation test
②Automated testing of UI pages
At the very beginning, I also started with interface automation, because the projects I worked at that time were mainly based on data query and statistics. I didn’t know how to start the automated testing of UI pages. Later, I went to the Internet to see how others did it. I found that many people say that projects with statistical data like this are basically impossible to do UI automation testing. Later, I thought that even if it is a list of statistical data, I don’t need every item and every field to check, just check some of them. The field is fine, so it is much simpler, first I will get the first field of the first item of a list on the page, and then I will connect to the database to get the value of this field, and compare the two values. It's the same, then there's no problem.
Although automation cannot completely replace manual work, it saves manual repetition. Some items may be difficult 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 coding language of automation tools/frameworks, preferably with a certain coding ability, and the code logic must be clear, otherwise it will not only guarantee the logic, business and robustness of the use case Factors such as sexuality cannot guarantee efficiency.
Finally: [May help you]
These materials should be the most comprehensive and complete preparation warehouse for friends who are considering advanced [software testing] skills. This warehouse has also accompanied me through the most difficult journey, and I hope it can also help you.
Follow my WeChat public account [Program Yuanmuzi] to get it for free
My learning exchange group: 644956177 There are technical experts in the group to communicate and share~