Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Mobile test automation with Appium in real devi...

dmle
November 22, 2018

Mobile test automation with Appium in real device cloud

Slides from my talk @ Ministry of Testing Meetup, Berlin Germany
Learn about challenges and how to improve your Appium tests for fast and stable execution on real devices in a cloud like Sauce Labs.
Following topics are covered:
• Basic tips on how to use Appium
• Environment: Local vs cloud
• Device selection
• Connectivity Type
• Localisation
• Device allocation
• Appium session
Useful resources:
Appium docs: http://appium.io/docs/en/about-appium/intro
J. Lipps blog about Appium: https://appiumpro.com
SauceLabs docs: https://wiki.saucelabs.com/display/DOCS
StackOverflow: https://stackoverflow.com/search?q=appium

dmle

November 22, 2018
Tweet

More Decks by dmle

Other Decks in Programming

Transcript

  1. It’s not about: ✘ Appium vs Espresso / XCUITest ✘

    Real devices vs emulators ✘ Sauce Labs vs other cloud providers 3 But: ✘ Get familiar with potential challenges ✘ Minimize test flakiness and get the most out of Appium ✘ Stabilize test execution in real device cloud
  2. Keep in mind while using Appium ✘ Install app only

    once 6 ✘ Stop using bad locators ✘ Implicit wait = sleep = bad practice ✘ Every appium call counts ✘ Take care of keyboard ✘ Use API to generate test data / change app status ✘ Start activity / relaunch app / deep links between tests
  3. Fast tests = Avoid using XPath Fast & reliable locators

    ✘ id ✘ Accessibility id ✘ Predicate string 7
  4. “ - Don’t you ever use XPath? 8 XPath of

    total locators (~200): Android: 6% iOS: 4% - I do. Only when really necessary
  5. Devices have different: 15 ✘ OS version ✘ Manufacture customized

    OS ✘ DPI / Screen resolution ✘ CPU / RAM ✘ Default connectivity type ✘ Keyboard ✘ Preinstalled apps
  6. “app_india”: [ “Huawei_Mate_Pro_real”, “HUAWEI_P20_real”, “Samsung_Galaxy_S9_real”, “Samsung_Galaxy_S8_Plus_real” “LG_G7_Thinq_real”, “OnePlus_6_real”, “ASUS_Zenfone_5_real” ]

    Use device matrix 17 ✘ Based on users / local market stats ✘ Different manufactures / OS versions 1. Stabilize tests for matrix 2. Remove unreliable devices 3. Sync matrix every 3+ months 4. Keep it carefully from growth
  7. Define device for test run API: /available 18 Filter matrix

    Select random Start session Dynamic allocation filter by OS version & device type static
  8. Check connection on session start Keep in mind: ✘ Airplane

    Mode: 6+ ✘ Data connection: <=4.4 ✘ Wi-Fi connection: all versions 21 ✘ getNetworkConnection() ✘ setNetworkConnection()
  9. Network Connection (Android only) 22 Value Data Wifi Airplane Mode

    0 (None) 0 0 0 1 (Airplane) 0 0 1 2 (Wifi only) 0 1 0 4 (Data on) 1 0 0 6 (All on) 1 1 0
  10. Check language on session start ✘ Check the element text

    on login ✘ Change via switch button In worst case ✘ Skip tests with localisation checks 24
  11. Once in a while getting exception UnknownError - An unknown

    server-side error occurred while processing the command. Selenium error: Lost contact with app, please check Appium log for more information The environment you requested was unavailable. Unable to install app to the device XXX. Unable to allocate device YYY within 900000ms or 3 tries. This can happen if there were no available devices within the time or your plan's max concurrent test run is not corresponding to your usage 26
  12. 3 iterations of custom mechanism Version 1 Pull device matrix

    Get available devices via API Filter matrix with available Select random one for session Dynamic allocation Version 2 Run v1 for EU device cluster Run v1 for US device cluster Dynamic allocation Version 3 Run v2 Catch session creation error Add device to “black list” Retry v2 with black list filter 28
  13. “ - Run each test separately 31 - It takes

    too long - Use device caching - Still too long
  14. Session start ~ 40 sec IOS ~ 70 sec Running

    suite of 30 tests 32 Cached restart ~ 18 sec IOS ~ 25 sec
  15. Custom sesion restart timeout 1. Define own session restart timeout

    (5 - 7 min) 2. Start session with time counter and enabled device caching 3. Starting from 2nd test check timeout - counter > max_test_time 4. Restart session before N test when timeout reached 5. Save result in SL, get report link, continue execution 34
  16. Appium session handling New session 35 Close current session &

    start new with cached device Test 1 Check session time Test N Retry
  17. 30 tests ~ 13 min Session timeout of 7 min,

    1 restart 39% Time saved! 28 restarts ~ 8.4 min 18 sec / restart 36
  18. Make Appium a better tool Follow the progress: Image comparison:

    https://github.com/appium/appium/blob/ master/docs/en/writing-running-appium/ image-comparison.md Element find plugins: https://github.com/appium/appium/blob/ master/docs/en/advanced-concepts/ele ment-finding-plugins.md Contribute: ✘ Create issues ✘ Add/translate docs ✘ Answer questions ✘ Add new functionality ✘ Support client libraries 38
  19. Let’s summarize: 39 ✘ Follow the best practices with Appium

    ✘ Don’t try to support tests for all the devices in cloud ✘ Make sure to set correct connection and language on device ✘ Don’t fully rely on cloud with device allocation ✘ Be critical to test time execution, try to improve