Hopper is a software test tool that simulates random user input on mobile devices providing a sometimes meaningful mean time to failure (MTTF) number. It is designed to find bugs and is not intended to run scenario tests or do "specific user things" - it is completely random.
Hopper stresses the entire device and will execute anything accessible through the UI many, many times. It has no knowledge of where it is at any time and has limited ability to detect poor system health. Hopper executes randomly, thus different bugs might be encountered each time the tool runs. Fixing enough bugs to impact MTTF may take many runs. Reproducing specific runs and/or finding the particular bug that caused any specific failure can prove to be difficult.
While Hopper excels at finding system stability bugs quickly, it was never designed to debug or diagnose the source of any particular problem. It utilizes a "system snapshot" log at regular intervals which can help you understand fault.
Determining device MTTF via stress testing and debugging is a simple process: run a stress tool until the device fails, diagnose the failure, fix the bug, and re-start the stress tool. In theory, each time a bug gets fixed, MTTF increases because the tool runs longer without a failure.
How to read and analyze Hopper's log? For example, what is "connect state"? how to know which application fails to be launched? how call stacks help to analyze and etc. etc
There is too much information in log file, which are important, which are useless and etc. etc
It's hardly to find an article on hopper's log.
Agree with jinglu1977. Hopper is useless if I don't know what the log is talking about.
Is there any resource to describe how to read hopper log?