Appium 资料摘抄

升级Appium版本,借机重读官方文档等, Appium 不建议参考中文文档,中英文文档仔细比对一下就知道原因了,可能参考中文文档调试半天不通结果一查英文文档api已变。

(↓↓ 官方tutorial http://appium.io/slate/en/master/?java#)

Client/Server Architecture

Appium is at its heart a webserver that exposes a REST API. It receives connections from a client, listens for commands, executes those commands on a mobile device, and responds with an HTTP response representing the result of the command execution. The fact that we have a client/server architecture opens up a lot of possibilities: we can write our test code in any language that has a http client API, but it is easier to use one of the Appium client libraries. We can put the server on a different machine than our tests are running on. We can write test code and rely on a cloud service like Sauce Labs to receive and interpret the commands.
The Appium server itself defines custom extensions to the official protocols, giving Appium users helpful access to various device behaviors (such as installing/uninstalling apps during the course of a test session). This is why we need Appium-specific clients, not just the ‘vanilla’ Selenium clients. Of course, Appium client libraries only add functionality (in fact, they simply extend the standard Selenium clients), so they can still be used to run regular Selenium sessions.

Session

Automation is always performed in the context of a session. Clients initiate a session with a server in ways specific to each library, but they all end up sending a POST /session request to the server, with a JSON object called the ‘desired capabilities’ object. At this point the server will start up the automation session and respond with a session ID which is used for sending further commands.

(↓↓ http://appium.io/slate/en/tutorial/android.html?java#)

Ending the session

Once we’re done with a testing session, it’s very important to cleanly quit. If a session is not terminated properly then appium will consider the session to still be in progress. This blocks all future sessions from working.
All the selenium bindings offer a quit method. This should be invoked once the testing session is over.

uiautomatorviewer

Ensure that no Android appium sessions are running. Appium uses uiautomator internally and this will prevent uiautomatorviewer from working if they’re both running at the same time.

disabling animations

After that we’re returning to the home page by using back();. The back method will return even though the app hasn’t finished transitioning. I recommend disabling animations under in Dev Settings. This can also be done programmatically.
DevSettings-animation

wait for

The driver.manage().timeouts() line of Java code requested that appium wait 30 seconds for elements to appear before giving up.

driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);

Searching the Source Code

appium is composed of modules. The module related to uiautomator is appium-uiautomator. To find out what happens on Android when we request the page source, search for dumpWindowHierarchy. From there we can tell what uiautomator method appium is using to get the source code.
Android is open source and so are the testing tools. This is helpful to identify how methods are implemented. UiDevice.java contains a dumpWindowHierarchy method. The JavaDoc says the data is saved to /data/local/tmp. However upon looking at the actual code, the location is dynamically defined depending on where the device has it’s data directory. Open source is wonderful for quickly understanding the best way to automate on Android.

(↓↓ http://appium.io/slate/en/master/?java#)

setUp

Make sure you have not installed Node or Appium with sudo, otherwise you’ll run into problems).
If you’ve installed Node from the Node website, it requires that you use sudo for npm. This is not ideal. Try to get node with nvm, n or brew install node instead!
如何检查node是否root安装?
which node 找到node路径,再 ls -l 该路径即可查看安装用户。

To verify that all of Appium’s dependencies are met

1
2
appium-doctor --android
appium-doctor --ios

Android support

  • Support for automating multiple apps in one session: Yes (but not when using the Selendroid backend)
  • Support for automating multiple devices simultaneously: Yes, though Appium must be started using different ports for the server parameters --port, --bootstrap-port (or --selendroid-port) and/or --chromedriver-port. See the server args doc for more information on these parameters.
Parallel Android Tests

Appium provides a way for users to automate multiple Android sessions on a single machine. All it involves is starting multiple Appium servers with different flags.

The important flags for automating multiple Android sessions are:

  • -p the main Appium port
  • -U the device id
  • -bp the Appium bootstrap port
  • –chromedriver-port the chromedriver port (if using webviews or chrome)
  • –selendroid-port the selendroid port (if using selendroid)
    More information on these flags can be found here.
    If we had two devices with the ID’s 43364 and 32456, we would start two different Appium servers with the following commands:
    node . -p 4492 -bp 2251 -U 32456
    node . -p 4491 -bp 2252 -U 43364

As long as your Appium and Appium bootstrap ports are between 0 and 65536, all they have to be is different so that two Appium servers aren’t trying to listen on the same port. Be sure that your -u flag corresponds with the correct device ID. This is how Appium knows which device to communicate with, so it must be accurate.
(running local parallel iOS tests aren’t possible. )

Appium on real iOS devices

To get started on a real device, you will need the following:
  • An Apple Developer ID and a valid Developer Account with a configured distribution certificate and provisioning profile.
  • An iPad or iPhone. Make sure this has been set up for development in Xcode. See this article for more information.
  • A signed .ipa file of your app, or the source code to build one.
  • A Mac with Xcode and the Xcode Command Line Developer Tools.
TROUBLESHOOTING IDEAS
  • Make sure UDID is correct by checking it in Xcode Organizer or iTunes. It is a long string (20+ chars).
  • Make sure that you can run your tests against the Simulator.
  • Double check that you can invoke your automation from Instruments.
  • Make sure Instruments is not already running.
  • Make sure UI Automation is enabled on your device. Settings -> Developer -> Enable UI Automation
AUTHORIZING IOS ON THE COMPUTER

ou need to authorize use of the iOS Simulator by running the authorize-ios binary made available through npm. Install the program by running
npm install -g authorize-ios
You need to do this every time you install a new version of Xcode. sudo authorize-ios

FILES GENERATED BY IOS TEST RUNS

Testing on iOS generates files that can sometimes get large. These include logs, temporary files, and derived data from Xcode runs. Generally the following locations are where they are found, should they need to be deleted:
$HOME/Library/Logs/CoreSimulator/*
For Instruments-based tests (iOS not using XCUITest as automationName):
/Library/Caches/com.apple.dt.instruments/*
For XCUITest-based tests:
$HOME/Library/Developer/Xcode/DerivedData/*

Known issues
  • Sometimes iOS UI elements become invalidated milliseconds after they are found. This results in an error that looks like (null) cannot be tapped. Sometimes the only solution is to put the finding-and-clicking code in a retry block.

版本更新

Migrating your tests from Appium 0.18.x to Appium 1.x

New Client Libraries

you’ll be doing something like (to use Python as an example):
from appium import webdriver
Instead of:
from selenium import webdriver
(不过java包里面没找到appium下的webdriver,仍在selenium中)

capabilities
  • no longer used:

    • device
    • version
  • appbrowserName 互斥
    appium旧版本带横线的capabilities已经改成camelCase格式,如appPackage

New Locator Strategies
  • removed:

    • name
    • tag name (被class name代替)
  • added

    • accessibility_id : to do what name used to do

Note about class name and xpath strategies: these now require the fully-qualified class name for your element.
also added the following locator strategies:

  • -android uiautomator
  • -ios uiautomation
    注意:-IOS UIAUTOMATION LOCATOR STRATEGY,This locator strategy was specifically built on UIAutomation, so it is not included in the XCUITest automation backend. We will be working on a similar “native”-type locator strategy in coming releases.
  • 备注:[1]
    谷歌官方的UIAutomation在Android4.3更新了版本。
    • Android4.3之前:使用inputManager或者更早的WindowsManager来注入KeyEvent
    • Android4.3之后:使用Accessibility APIs来注入事件。(AccessibilityService本来是做一些辅助功能的,提供了一系列的事件回调,帮助我们指示一些用户及界面的状态变化,主要给残障人群提供帮助。)
HYBRID SUPPORT THROUGH CONTEXT, NOT WINDOW

To get all of the available contexts, or the particular context the application is is, you use

1
2
Set<String> contextNames = driver.getContextHandles();
String context = driver.getContext();

to switch between them:

1
driver.context(contextName);
NO MORE EXECUTE_SCRIPT(“MOBILE: XXX”)

All the mobile: methods have been removed, and have been replaced by native methods in the Appium client libraries. This means that a method call like driver.execute("mobile: lock", [5]) will now look something more like driver.lock(5) (where lock has been turned into a native client method). Of course, the details on calling these methods will differ by client.

Of particular note, the gesture methods have been replaced by the new TouchAction / MultiAction API which allows for a much more powerful and general way of putting gestural automation together. Refer to your Appium client for usage notes on TouchAction / MultiAction.

Migrating your iOS tests from UIAutomation (iOS 9.2 and below) to XCUITest (iOS 9.3 and up)

For iOS automation, Appium relies on system frameworks provided by Apple. For iOS 9.2 and below, Apple’s only automation technology was called UIAutomation, and it ran in the context of a process called “Instruments”. As of iOS 10, Apple has completely removed the UIAutomation instrument, thus making it impossible for Appium to allow testing in the way it used to. Fortunately, Apple introduced a new automation technology, called XCUITest, beginning with iOS 9.3. For iOS 10 and up, this will be the only supported automation framework from Apple.

Troubleshooting

Android
  • If you get this error after upgrading to Android SDK 22: {ANDROID_HOME}/tools/ant/uibuild.xml:155: SDK does not have any Build Tools installed.

In the Android SDK 22, the platform and build tools are split up into their own items in the SDK manager. Make sure you install the build-tools and platform-tools.

  • It’s sometimes useful to run
    adb kill-server && adb devices
iOS
  • Make sure Instruments.app is not open
  • If you’re running the simulator, make sure your actual device is not plugged in
  • Make sure the accessibility helper is turned off in your Settings app
  • Make sure the app is compiled for the version of the simulator that’s being run
  • Make sure the app is compiled for the simulator (or real device) as appropriate (e.g., in debug mode for the simulator), or you might get a posix spawn error.
  • If you’ve ever run Appium with sudo, you might need to sudo rm /tmp/instruments_sock and try again as not-sudo.
  • If this is the first time you’ve run Appium, make sure to authorize the use of Instruments. See running on OSX documentation.
  • If Instruments is crashing when running against a physical device (“exited with code 253”), ensure Xcode has downloaded device symbols. Go to Window -> Devices, and it should start automatically. This is needed after iOS version upgrades.
  • If you see iOS Simulator failed to install the application. and the paths are correct, try restarting the computer.
  • If you have custom elements in your app, they will not be automatable by UIAutomation (and therefore Appium) by default. You need to set the accessibility status to ‘enabled’ on them. The way to do this in code is:
    [myCustomView setAccessibilityEnabled:YES];

  • Tests on iOS may exhibit symptoms similar to a memory leak including sluggish performance or hangs. If you experience this problem, it’s likely due to a known issue with NSLog. One option is to remove NSLog from your code. However, there are several more nuanced approaches that may also help without requiring that you refactor.

API 文档

http://appium.github.io/java-client/


adb 无线连接手机

  1. usb连接手机,adb tcpip 5555
  2. adb connect 手机IP
  3. adb devices确认手机已经连上
  • 查看手机ip,adb shell netcfg (ifconfig 不行)
  • 注意手机电脑同无线网
  • 切回usb连接,adb usb
  • 注意无线连接时,adb devices 是获取不到udid的,若是appium程序中指定了设备udid,则会找不到

实际使用发现,有时候间隔一些时间,adb devices 会找不到设备,需要重新 adb connect 才可以,网络不稳定?

[1] 摘自博客