Automation testing on android

10 Android UI Automation Testing Hacks

Quality is king when it comes to mobile application testing. When we download apps that don’t work as they should, the most common response is to uninstall the app from our devices. In fact, 80% of mobile users will abandon an app permanently if they encounter a bug 3 times.

Even some of the most used apps, like Microsoft’s Skype, can suffer from critical bugs that escape testing into production, ultimately impacting their usability and security.

Quality is an ongoing issue, with a majority of mobile users reporting they have had an app crash in the last 6 months. Apps that don’t undergo proper testing are especially liable to have unforeseen issues. Mobile apps can only be released confidently when the proper testing has been performed prior to going live.

With 1,000’s of variants in the market, Android is typically the area most companies are struggling to test adequately. With this in mind, we will focus our attention on Android, but first, let’s consider the overall approaches we should take with testing our application.

Should I Automate My Android App Testing?

The age old question remains – should I test my android app manually, or should I invest in Android UI automation? Manual testing is the process of testing the app with a human tester, just as a user would. Automated testing uses tooling to drive interactions with the UI programmatically.

One of the main benefits of mobile automation testing is the ability to run tests reliably and repeatedly. Human users are susceptible to making errors and entering incorrect information. Furthermore, properly implemented Android UI automation can allow for testing of multiple devices and OS types at a single time, in parallel. Therefore, using Android UI automation can result in better test coverage and overall user ratings, leading to an app’s success in the marketplace.

With these pros and cons outlined, we will focus on UI automation for Android, and some quick hacks we can implement to improve our experience with this approach.

10 Android UI Automation Testing Hacks

1. Use automation testing tools that fit your landscape

One of the most popular testing tools, Appium, can be used to create UI automation for both iOS and Android apps. There’s no question that Appium is very useful if you are releasing apps across both platforms.

But if you are only releasing Android apps, Espresso and UIAutomator may be your best bet since they’re created by Android’s own creator, Google. They are deeply integrated into the existing Android development tools, which will make testing even more time-efficient and productive.

❗ You might find this speed benchmark quite interesting when considering such various tools for mobile automation testing: Fastest Mobile Automation Testing Tool – Appium vs. XCUITest vs. TestProject vs. UiAutomator vs. Espresso.

2. Automate first around critical aspects of the app

Understand the most critical paths for your customer, and automate around them. For example, photo editor apps require accuracy to touch commands. So, you should focus your UI automation efforts first around the touch accuracy. Eventually, you should strive to automate all of the major functionality, but starting with the most essential tests will ensure you don’t have any critical regressions. While users don’t find any bugs enjoyable, they will certainly be most impactful when they block key functionality in the app.

3. Utilize customer data analytics to focus device coverage

Automated app testing on all mobile devices and operating systems is nearly impossible, especially with Android’s thousands of device and operating system combinations. Instead, focus on the key device and operating system variants to see if you can regularly test on enough devices to cover

80% of your user base or more. The Google Play Console provides a great overview of the device and operating systems that your app customers are using.

4. Prepare for the latest OS releases

New OS versions are constantly emerging, and users will be frustrated if their brand new device isn’t supported. Make sure to track the Android Developers Previews to get a head start on understanding changes in the latest Android version.

5. Create a backlog specific to UI automation

Building Android UI automation is a development task, just like writing code to create a new feature. As such, we should make sure we track all of these efforts, keep them properly prioritized, and understand the effort of these tasks before diving into the work.

6. Automation requires the tester and developer to communicate

To make UI automation testing time-efficient, developers should have constant communication with the testing team while developing the app. Often times, developers can tweak the app in certain ways to make it more “testable”, by providing streamlined ways to set up users, identify locators, or use dummy payment methods.

7. XPath: use with caution

Google doesn’t provide XPath type queries natively, and writing proper XPath queries can be useful when deployed properly. Approach with caution though, as performance will often suffer and the locators can be brittle, resulting in slow running tests with frequent failures. Instead, investigate using easier to identify options such as accessibility IDs as your locators.

8. Organize selectors for rapid element identification

This follows the previous tip in regards to selectors. Organize selectors to prioritize those you use most often, so if you were to use accessibility IDs first, prioritize those in the list. This will ensure quicker test creation, test execution, and test repair.

9. Create atomic tests where possible

It’s true, most of your test scenarios might start with a shared step such as logging in to the application or creating a new account. However, this doesn’t mean every test should need to start with this step, because doing so will not increase test coverage and will only add time to your test execution. Use end-to-end tests sparingly. Find ways, through API’s or other methods, to skip repeated steps where possible and build tests that can cover the specific functionality that needs to be tested.

10. Don’t let your device farm hold you back

All too often, teams will not test on a common device or operating system simply because they did not have it available in house. Today, there are plenty of solutions to overcome that problem – whether with device emulators like Genymotion, or with real device clouds such as BrowserStack and Sauce Labs. Even if you can only afford to test some device variants every once in a while, some testing is better than no testing at all.

Conclusion

Android UI automation can be a difficult task, but it is an important one which can determine the success or failure of your app. With the right tools, knowledge, and mindset, Android UI automation will become a manageable routine for your testing team.

Got any hacks we missed? We’d love to hear about them! Share in the comments below 👇

About the author

Dan shares his newfound knowledge with other Android enthusiasts on joyofandroid.com while enjoying photography and cooking steak.

Join TestProject Community

Get full access to the world’s first cloud-based, open source friendly testing community. Enjoy TestProject’s end-to-end test automation Platform, Forum, Blog and Docs — All for FREE.

Источник

Автотесты на Android. Картина целиком

Автотесты под Android — это непросто. Чтобы выстроить процесс автотестирования, надо запланировать и решить множество задач. Но самая большая беда заключается в том, что нигде нет полного описания, что вообще включает в себя автотестирование под Android, каковы его основные стадии. Отсутствует цельная картина. Этой статьей мы хотим восполнить пробел.

Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.

Зачем нужны автотесты?

Есть мнение, что UI-тесты не нужны, если у вас достаточное количество юнит- и интеграционных тестов. Но от следующей метафоры никуда не деться. Представьте, что вы собираете велосипед. У вас есть два хорошо протестированных колеса, протестированная рама вместе с седлом, протестированная система педалей с цепью и рулем. То есть мы с вами имеем хороший набор интеграционных и юнит-тестов. А велосипед-то в итоге поедет? Чтобы это проверить, вы нанимаете ручных тестировщиков, которые перед каждым релизом должны убедиться, что безупречные детали корректно взаимодействуют друг с другом, и велосипед будет ездить и доставлять пользователю удовольствие.

Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.

При этом, когда релизный цикл у вас длиной в несколько месяцев, вполне достаточно работы ручных тестировщиков и некоторого покрытия кода юнит- и интеграционными тестами. Однако во времена, когда релизный цикл стремительно сокращается до одной-двух недель (а то и еще меньше), сил ручных тестировщиков зачастую уже не хватает, что вынуждает или жертвовать качеством проверки, или нанимать больше специалистов.

Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У «Авито» есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project — стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.

Картина целиком

Итак, обещанная картина целиком.

Если вы чего-то не понимаете, не переживайте. Мы сейчас пройдемся подробно по всем пунктам.

Процесс написания тестов

На первом шаге давайте попробуем написать тесты у себя на машине и запустить их локально.

Выбор инструментов для написания автотестов

Стоит сразу определиться со стеком технологий, который мы будем использовать для написания тестов.

Первая развилка — это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.

Спойлер — мы за нативные решения. По нашему опыту, они:

• стабильнее;
• быстрее;
• лучше интегрированы в IDE;
• не содержат слоев, которые вносят нестабильность и заставляют иметь суперширокие экспертные знания.

Кроме того, Google поддерживает Espresso и UI Automator.

Больше почитать про сравнение вы можете в статьях:

На чистом Espresso и UIAutomator нынче редко кто пишет. Разработчики сделали различные удобные обертки, которые решают их проблемы. Сейчас у нас готовится статья об этих инструментах с классификацией и сравнением. Если кратко, то фреймворк, на который мы делаем ставку, это Kaspresso.

Kaspresso

Kaspresso — это фреймворк, который:

• предоставляет DSL, значительно облегчающий написание автотестов;
• дает встроенную многоуровневую защиту от флекающих тестов;
• ускоряет работу UI Automator;
• предоставляет полные логи о том, что происходит в тесте;
• дает возможность запуска любых ADB-команд внутри тестов;
• предоставляет механизм интерцепторов для перехвата всех действий и проверок. На данном механизме построено логирование и защита от нестабильных тестов;
• описывает лучшие практики (исходя из нашего опыта) по написанию автотестов.

Вы можете прочитать о Kaspresso на GitHub и Habr.

Test runner

Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.

Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим — Orchestrator. AndroidJUnitRunner делает то, что от него и требуется — просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.

Но со временем требований к раннеру становится все больше. Вот некоторые из них:

• запускать отдельные группы тестов;
• запускать тесты только на определенных девайсах;
• перезапускать упавшие тесты (вторая волна защиты от последствий нестабильных тестов после Kaspresso);
• эффективно распределять тесты по девайсам с учетом истории прогонов и успешности предыдущих запусков;
• подготавливать отчеты о прогоне в разных форматах;
• отображать результаты прогона (желательно Allure based);
• поддержать истории прогонов для дальнейшего анализа;
• просто интегрироваться с вашей инфраструктурой.

На рынке есть несколько сторонних раннеров. Среди всех них, самым перспективным мы считаем Marathon, который довольно быстро настраивается и удовлетворяет части обозначенных выше требований. Например, он поддерживает распараллеливание тестов и подготовку результатов прогона в формате, пригодном для отображения в Allure.

Однако, Marаthon, к сожалению, не обладает некоторыми важными, по нашему мнению, свойствами. В частности, в нем нет:

• Простой и нативной интеграции раннера с инфраструктурой, которая выдает эмуляторы. А еще лучше возможности сразу же запустить ваши тесты в облаке. Впрочем, это проблема не только Marathon — к сожалению, ни один известный нам раннер не берет на себя ответственность за получение эмуляторов, это всегда ложится на плечи разработчиков.
• Плотной интеграции с фреймворками типа Kaspresso для получения максимальной, точной и корректной информации о тесте.

Кроме того, мы считаем, что раннер должен быть платформенным, то есть либо для Android, либо для iOS. Это обусловлено уникальной спецификой каждой ОС и вытекающей отсюда сложностью внесения изменений в раннер.

Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все лучшие и зарекомендовавшие себя наработки и идеи. Ждите будущих анонсов!

На чем запускать тесты

Параллельно с вопросом о том, какой раннер выбрать для тестов, перед вами встает другой: а на чем лучше запускать тесты? Есть три опции:

1. Настоящий девайс.
   Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя — как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
   Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них — необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот.
2. Чистый эмулятор.
   Под «чистым» мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
   Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
   Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус — это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение.
3. Docker-образ Android-эмулятора.
   Docker решает недостатки чистых эмуляторов.
   Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора — это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
   Минусы. Более высокий входной порог.

Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:

Как уже было упомянуто выше, подготовка образа требует некоторой сноровки. Плюс зачастую есть желание эмулятор преднастроить: выключить анимацию, залогиниться в аккаунт Google, выключить Google Play Protect и многое другое. Все эти вещи непросто организовать. Поэтому в скором времени мы хотим выкатить подробную документацию о том, как готовить и использовать образы быстро.

Инфраструктура

Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.

Однако эта область — темный лес для части Android-разработчиков и автоматизаторов. Оно и немудрено, ведь инфраструктура требует знаний железа, конфигурирования серверов, DevOps-практик и прочего. Поэтому обязательно наладьте контакты с людьми, которые во всем этом разбираются, у себя в компании или вовне, ведь они сильно помогут и уберегут вас от ошибок.

Итак, что вам примерно предстоит:

• Выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ.
• Самое трудоемкое — это развертывание внутренней инфраструктуры с нуля. В этом случае необходимо подобрать железо, которое будет максимально использоваться автотестами. Придется измерять нагрузку на CPU/GPU/Memory/Disk, а еще пробовать разное количество одновременно запущенных эмуляторов и смотреть за стабильностью тестов. Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.
  Дальнейшая накатка необходимого ПО, встраивание в сети и прочее — это все за DevOps-инженерами.
• На выходе должен быть какой-то сервис, единая точка, которая отдает вам эмуляторы. Это может быть Kubernetes, может быть облачный сервис типа Google Cloud Engine или какое-то кастомное решение.
  В его настройке опять-таки помогают DevOps-инженеры.
• Связка полученного сервиса с Test Runner.
  Одна из задач Avito Runner — сделать такую связку максимально простой и прозрачной, а также предоставить точки расширения, которые помогут вам легко внедрить свой кастомный сервис.

В ближайшее время мы планируем выпустить Avito Runner и статьи, которые помогут настроить инфраструктуру.

Остальное

Не забывайте про такие немаловажные моменты, как:

• вывод отчета по прогону тестов (Allure);
• внедрение/синхронизация с TMS;
• интеграция в CI/CD;
• обучение разработчиков и тестировщиков;
• процессы — кто, когда, сколько и какие автотесты пишет.

Про все это мы еще обязательно поговорим.

Заключение

Мы постарались описать основные части становления автотестирования под Android. Надеемся, что теперь у вас в головах сложится тот самый пазл, который позволит видеть картину целиком.

Источник