One Thursday morning, I made a cup of tea, and I was about to sit on my seat, and listened to the developer. How did you test the bug? What can a screenshot show? The crash shown in the screenshot above is okay if it is a must, if it is not, how do we locate it? At least give me a log?
At that time, my inner activity was: You left work last night, we left to test, and we found two crashes in 5 minutes. These two crashes are two buttons that users must operate. You even clicked after you finished the package. It was released directly without a point. What about the good self-test and the good version quality?
But it said, you want a log, you said earlier, can't we just give you a log?
What type of log? There must be constraints...
My name is Pippi and I am a software testing engineer. The above experience is my real experience.
The reason for the above problem can be said to be that there is no clear specification in the project or that the project has clear specification but not implemented according to the specification.
I believe this is also a common problem of some companies, or a common problem of some developers and testers.
There are many reasons for common problems, and one of them may be tacit understanding of each other.
For example, when a developer sees a crashing bug mentioned by a tester, he may be desperate in his heart, let me wipe it? No logs? Forget it, let me reproduce a wave by myself first, and then through unremitting efforts.
There are two situations, one is to reproduce, and the bug list is reported to the tester to inform that it has been resolved.
The second is that it can't be reproduced, and the bug is reported to the tester to inform it that it has not reproduced.
After the test saw the first situation, it returned to a wave, and it was solved. I happily closed the bug list. After the test saw the second situation, I wiped it? Can't this be reproduced?
After talking about taking the phone, after unremitting efforts, it finally did not reproduce, and then sighed to the sky, is it so magical? In the end, this bug was tested and closed, and the result of the closing was that it could not be reproduced or was resolved.
In the end, we fall into an endless loop. Testing still raises bugs according to habit, and development still solves bugs according to habit. After all, the harmony of socialism requires the efforts of each of us~
Some friends will say, it shouldn't. Generally, won't such error logs be directly transmitted to the database or stored locally?
Let's talk about the first case first. If an application needs to be tested under a weak network or even without a network, it happens that the program has an error at this time. Can you ensure that the log file is inserted into the database? There is a chance for a weak network, but there is probably no chance without a network.
Let's talk about the second case. Log logs are stored locally, and there are generally two ways to do it locally.
The first is that the mobile phone has its own log storage function, and the second is that the developer writes a method to capture the error log in the program and saves it locally. We won’t discuss the first case because it has something to do with the mobile phone system and there is no absolute way to control it.
Let's discuss the second method. The second method is indeed one of the ways to solve the problem, but there is also a situation where the company does not want users to see related log information, which requires developers to isolate the test environment and the online environment. This method is more recommended.
But as testers, we should also think about it, when you sent the phone to development, did the phone get water?
Hahahaha.....
So apart from developers helping us generate logs, how should our testers capture the logs?
There are many answers, such as Android studio, monitor.bat under SDK, adb command, etc.
For these, I believe most people have heard of it, or are very familiar with it.
At first I tried to use monitor.bat under Android studio and SDK to capture Log, but when I opened Android studio and monitor.ba, I felt a headache because it was all in English, and later I picked up the most commonly used adb command , I never wanted to change it after using it.
Hahahaha...
Why choose adb command?
The reason I chose is relatively simple,
The first is that the adb command is more concise,
The second is that the adb command can help testers perform monkey stress tests.
The third is that the adb command can help us capture the Log information of an activity.
Here are some common adb commands.
1. View the device
adb devices
2. Install and uninstall software
adb uninstall <software name>
adb uninstall -k <software name>
3. Enter the shell environment of the device or simulator
adb shell
4. Print log information
adb logcat
............
There are too many adb commands, and Baidu has answers. I will not give examples one by one here. Let’s go back to today’s topic.
How to get the log.
This requires the fourth command above: adb logcat.
If you use adb logcat directly, it basically prints all log logs, which is inconvenient for us to troubleshoot.
So we made a simple optimization, using adb.exe logcat | find "xxx" >E:/1.txt.
The xxx here is your package name. If you don’t know the package name of your APP, it is recommended to use an APP called package name viewer. This software can view all the package names of your mobile phone.
If you are testing your phone, you can check the package names such as settings and clock in your phone.
Anyway, it's good to use it.
Hahahaha...
The following E:/1.txt is to save the obtained Log information in your local.
The general operation is to install the adb environment on the computer first
Then turn on the USB debugging on the phone (note that I'm talking about Android phones ~ Apple’s related adb commands are also available on Baidu).
Then open cmd and enter adb.exe logcat | find "xxx" >E:/1.txt
At this time, if your phone does not open this program, no logs will be generated. When you open, all logs will only record the logs of the current program.
For example, after you run the command adb.exe logcat | find "xxx" >E:/1.txt and open the application you want to test, it crashes. At this time, you can press ctrl+c to terminate the log output.
At this time, your 1.txt records the crash information (note that the 1.txt file does not need to be created).
So what information do we testers need to see in the Log? After all, it may be a file of tens of K or even a few M.
I usually search for errors, crashes, and ANRs in the Log (of course there are many more, you can also Baidu)
If there are these related words in your log, then congratulations, your log can be handed over to the development, of course, if you want to be able to read the relevant log information, you can learn java and Android related knowledge.
Finally, remember one thing.
Once I asked the developer after get off work, why didn’t I leave?
Development said, I will write a few more Bugs........
My wish is-world peace
Above are some videos and interview questions I collected.
For software testing friends, it should be the most comprehensive and complete interview preparation warehouse. In order to better organize each module, I also refer to many high-quality blog posts and projects on the Internet, and strive not to miss every knowledge point. Friends relied on these contents to review, and got offers from big factories such as BATJ. This warehouse has also helped many software test learners, and I hope it can also help you.
Follow my WeChat public account [Programmer Erhei] Get it for free