A letter to the netizen Wonderfei (for details about how to choose an automation framework). For details about wonderfei, see
Note: This letter was intended to be sent to Wonerfei, but since only 200 words can be sent each time, I simply posted it to my blog and asked Wonderfei to come and see it, this is my own temporary summary. At the same time, I hope you can help me with Wonderfei. After all, my opinion is not necessarily correct and complete.
Hi Wonderfei,
Hello, I am a newbie to blogs, so I didn't notice the private messages you sent me. Sorry.
First of all, because I am a newbie, I am also learning various frameworks and then selecting the appropriate automation framework for the company's projects. I just want to study the mobile automation testing framework for a short time, therefore, I can only express my own opinions to various frameworks from the perspective of my own cognition so far, you can see if you can accept one or two of them (for me, it will take a while to learn the frameworks to determine which one or more of them are suitable for our projects, maybe I will write a formal summary ).
According to your requirements, MonkeyRunner and Robotium should not be considered, but I still want to tell you that Robotium is actually quite good, if you do not consider cross-process calls to other apps. As for MonkeyRunner, I don't recommend much, you can refer to a comment I gave to instructor Jin sunshine, replying to MonkenRunner's methods and suggestions for locating controls through HierarchyViewer (I finally posted this article ). As for Robotium, you can compare the Note test examples written by various frameworks in your blog. It can be seen that Robotium has many introductions compared with other frameworks. Moreover, it has developed much longer than UIAutomator and Appium, therefore, it should be more mature, and it is convenient to integrate and debug with Eclipse. If there are deficiencies in the latter two, I think the following are the points:
- 1. All operations are abstracted into a Solo class, which lacks object-oriented programming ideas and sometimes makes people uncomfortable. If you are familiar with process-oriented language ideas such as C, there should be no problem.
- 2. There are several methods to obtain controls: Text, ID, ClassName, and Index. There is no diversity of the latter two
- 3. cross-process: Because the bottom layer uses the Instrument framework, the test package and the tested application package are packaged together to run as a process, and the thread communicates through the instrumentaiton, as a result, this process cannot be escaped from sandbox)
- 4. cannot perform a simulated keyboard test (but it is also a huge advantage of Robotium, because it is not as difficult as the latter two to call the keyboard to cause various input problems ), because Robotium does not directly perform operations on the text attribute of the control through the keyboard driver, you should understand what I mean if you have done UI programming, because remember that your test code and target application are packaged in the same process. In the same process, you want to access a variable of another thread and use the corresponding IPC (Interprocess Communication) of course, there is no problem with the mechanism.
Then we can compare the subject UIAutomator with Appium. I personally see this:
- 1. UIAutomator is born by google, so it can ensure the development and maintenance power in the future, unless google goes bankrupt (what I don't know here is why google's attitude towards Monkeyrunner is so confusing, for more information, see my comments on MonkeyRunner)
- 2. although Appium is not born by a father-in-law, it is powerful enough to arm it with omnipotent capabilities (android, ios, firefox, and browser). For android alone, the underlying layer is still UIAutomator, so as long as it can keep up with the update of UIAutomator in time, I am not very worried about the function above.
- 3. however, this architecture also applies to Appium: UIautomator/seledroid <-> Appium Server <-> Selenium/AppiumDriver <-> Test Case (Organization of Appium architecture framework), as a result, the framework is a little complicated. When a problem occurs, debugging is difficult to locate and I don't know which module has an error. However, debugging is always better than UIAutomator. At least Appium can be directly integrated into eclipse for debugging. UiAutomator needs to be pushed to the target machine and then executed. How can we debug it? All I know so far is the original print.
- 4. Backward compatibility problem: Appium can be used to kill through the underlying UIAutomator/Selendroid (do not remember if it is the name); UIAutomator can only be used at API Level 17 or above.
- 5. Language Support: appium is basically kill, and UIAutomator uses java.
- 6. cross-platform: As you said, there is no problem with both android and ios. If you need to extend it to ios later, we recommend that you use appium.
- 7. Number of bugs: there may be some problems with UIAutomator Appium, and there may be issues with uiautomation or Appium. ^_^ (but I am still very optimistic about Appium)
- 8. There are bugs in input problems. For details, please refer to my blog, especially Chinese input. This is one of the reasons why I specifically proposed Robotum.
- 9. webView support: UIAutomator is said to have been supported at the beginning of this year, and I have not studied this requirement. The Selenium USED IN THE Appium framework is the most popular open-source Web Testing Framework on PC, so it must be supported. Note that you need a bit of android programming knowledge. WebView refers not only to the WebView control, but also to the situation where the webview is encapsulated into a cross-platform app using sencha + phonegap, if not, google.
I didn't think of other differences now. I hope it will help you. From my perspective, I think it is inevitable that UIAutomator will continue to develop, but it cannot eventually support ios. As for Appium, I also have great confidence that it will continue to develop in a good direction. Considering its cross-platform support, it is based on node. js (very popular now), compatibility, etc. If I were you, I would consider using Appium (leave Robotium alone, if you want to think about it again, You Need To summarize ^_^ according to what I have said before ).
I think this can be analogous to the previous relationship between Microsoft and Borland. The API is Windows, but the IDE is Borland and the directors of various specialties. Unfortunately (or fortunately) after that, Microsoft beat Borland to its teeth, but this was an off-the-shelf question ......
By the way, I may post this email to my blog, and hope other netizens can give you some comments. I wanted to read about easy_monkey tonight. I wrote this email for you and it turned into a temporary summary. Pai_^
The following is a comment on MonkeyRunner)
Bytes -----------------------------------------------------------------------------------------------------------------
Reply to haorenmin2008: First of all, let's worship it!
For the latter, it is true that uiautomation or requires the API Level17 or above.
For the former, since there is no MonkeyRunner project experience, I do not dare to comment on it if it is very powerful, but in my recent tryout process, the monks have the following immature Cognition:
- 1. I felt that the function was not very stable. I tried a MonkeyDevice's getProperty method before, and sometimes it failed to succeed.
- 2. Poor performance, especially when we need to use the hierarchyviewer function.
- 3. Only MonkeyImage sameAs can be used for screenshot comparison. Although hierarchyviewer can be used for getText, it is still very limited.
- 4. The control positioning is mainly based on the ID provided by the coordinate points and HierarchyViewer. Previously, if the UI layout was slightly changed, it would need to be changed. There was no high-level abstraction like other control frameworks, and no changes were needed unless the control was changed; in the latter case, many controls do not have IDs or multiple controls have the same IDs.
- 5. Not very debuggable (at least I have found a good debugging method over the past few days, such as integrated debugging methods such as IDE Ecilpse)
- 6. I am also worried about the stability of HierarchyViewer. An exception is reported when the control information is retrieved several times.
- 7. scarce data, not only Baidu, but also google
- 8. google's support is confusing. The API provided by the sdk is different from the API provided by the official website. Taking MonkeyDevice as an example, the API provided by the sdk is unavailable, google generates no more than 10 pages, and many users report repeated problems.
- 9. again, I really don't understand why I have to call jython in the java library. First of all, I won't talk about performance loss (this must be true, native library is of course the most efficient to call in native language), I want to use the following "device. "device = MonkeyRunner. waitForConnection () \ n device. ", but only by directly calling the device = MonkeyDevice (xxx) instantiated by a constructor can this be done. I don't believe this is my configuration problem, another jython standard compiler is used to call the standard library.
Of course, it also has its advantages.
Best Regards
Kevin Zhu
Bytes -------------------------------------------------------------------------------------------------------------------
Wonderfei: Hi, I saw you write a lot about Android automated testing. I recently planned to implement Android UI automated testing in the project, mainly used for regression testing, which of the following is the most popular robotium and appium? Which of the following is more recommended for future use?
