Инструменты тестирования Android приложений. Часть 1
В цикле этих статей я хочу пролить свет на несколько инструментов для тестирования Android приложений и привести примеры их использования.
Несколько месяцев назад я заинтересовался профессией QA. Причин было много: как минимум, мне хотелось говорить с тестировщиками на одном языке, а еще повысить собственную эффективность в повседневной работе.
Я нашел интересный канал, где проводятся открытые собеседования junior QA, который помог мне узнать больше о работе QA инженеров. Так сложилось, что спустя некоторое время, я присоединился к команде интервьюеров и уже сам задавал вопросы по java core, а также помогал ребятам, которые хотели идти дальше в автоматизацию: подсказывал ресурсы и выступал в роли ментора.
На одном из таких интервью поднялась тема тестирования Android/iOS приложений. Начиналась она с вопросов по гайдлайнам MD и IHI и новинок в последих версиях платформ, но как только зазвучали вопросы о встроенных инструментах, которые будут полезными в ежедневной работе тестировщика, все кандидаты терялись и слабо представляли, о чем идет речь. Именно тогда у меня возникла мысль написать эту статью, собрав информацию по работе с Android и некоторыми инструментами, полезными для начинающих специалистов.
Хочу сказать большое спасибо Вадиму за то, что он делает для QA коммьюнити. Если у вас есть желание попробовать свои силы на живых собеседованиях, то заходите на канал. А также хочу поблагодарить Женю за идею для статьи, Леру и Таню за внесенные правки и помощь в оформлении.
Эта статья будет полезна специалистам QA и разработчикам, начинающим свой путь в мобильной разработке. Сразу уточню, что тестирование бизнес-требований продукта останется за рамками этой статьи — все они могут значительно отличаться от приложения к приложению.
Здесь я поделюсь с вами инструментами, которые помогут упростить и автоматизировать процесс тестирования Android приложений. А также немного расскажу о том, как устроены Android приложения.
Содержание:
- (Вы здесь) Часть 1. Android приложение: что это и как с этим работать
- Часть 2: ADB
- Часть 3: Logcat
- Часть 4: ReTrace
- Часть 5: Побеждаем ANR с помощью ANRWatchdog
Android приложение: что это такое и как с этим работать
Обычно для проведения тестирования QA специалисты получают файл с расширением .apk. Это файл с готовым приложением, которое можно запустить на любом Android девайсе.
APK или Android application package — архив, содержащий в себе исходный код приложения, статические ресурсы (иконки, картинки, строки, размеры верстки), а также файл с описанием всех характеристик и компонентов приложения — Android manifest.
С помощью Android Studio можно открыть любой apk и посмотреть его содержимое (Build → Analyze APK…). В самом исходном коде стоит копаться только в случае, если есть необходимость проверить защищенность приложения: не раскрыли ли случайно разработчики личную информацию пользователей и не зашили ли секретные ключи в обычные строки.
А вот получить доступ к Android manifest будет полезно, ведь в нем можно найти много информации о приложении: от минимальной версии до разрешений, которые запрашивает приложение у пользователя.
Сразу нужно сказать, что Android manifest можно попросить напрямую у разработчиков и он будет более читаемым, но не будет полным — в приложении до сборки есть много манифестов, которые “сшиваются” друг с другом, когда собирается финальный APK.
Итак, Android manifest содержит следующую информацию:
- Версию приложения (поля versionName и versionCode)
- Уникальный пакет приложения (поле package, например “com.example.app”) — пригодится для работы с одним из инструментов из этой статьи
- Поддерживаемые версии android (блок <uses-sdk>)
- Разрешения, которые выдаются приложению (блоки <uses-permission>, их назначение легко гуглится)
- Какие встроенные возможности девайса используются (блоки <uses-feature>)
- Какие типы компонентов есть в приложении (<activity> <service> <receiver> <provider>)
QA специалисту полезно иметь возможность иногда проводить ревизию блоков <uses-feature>, так как некоторые из них могут со временем терять свою актуальность. К примеру, раньше в приложении использовалась камера:
<uses-feature android:name="android.hardware.camera"
android:required="true" />Но в одном из релизов фича с камерой ушла и больше не используется, хотя и прописана в манифесте. Казалось бы, чем это может навредить?
Здесь стоит еще раз обратить внимание на строчку кода выше и конкретно на параметр android:required=”true”. Этот параметр означает, что скачивать приложение из стора могут только пользователи у которых есть камера на телефоне. То есть мы уже отказались от фичи с камерой, но разрешение из манифеста не убрали, и пользователи без камеры все еще не могут скачать наше приложение — мы упускаем аудиторию.
Также проверять стоит и блоки <uses-permission>: если ваше приложение требует доступа к контактам, но по факту эти данные нигде не использует, то многие пользователи могут задаться вопросом: для чего же приложению нужен доступ к этим данным? А особо подозрительные и вовсе предпочтут уйти к более прозрачным конкурентам.
Теперь чуть подробнее остановимся непосредственно на компонентах приложения. Как я сказал, они бывают нескольких видов: <activity>, <service>, <receiver>, <provider>. Компоненты каждого вида могут использоваться несколько раз.
<activity> — это экран приложения, с которым может взаимодействовать пользователь (одна активити = один экран).
<service> — сервис, который не имеет своего UI, но может выполнять какую-то задачу. Например, в приложении может быть сервис, который скачивает последние данные по погоде и сохраняет их в базу данных.
<receiver> — специальный компонент, который слушает системные события и события других приложений. К примеру, когда появляется интернет, все ресиверы, отслеживающие это событие, начинают выполнять запрограммированную в них работу.
<provider> — компонент, который предоставляет другим приложениям информацию из вашего приложения, делая ее общедоступной. По такому принципу работает провайдер приложения “Контакты”.
Следует обратить внимание на то, что в манифесте всегда есть один уникальный блок <activity>, который активируется при клике на иконку приложения — именно он запускает приложение. Выглядит он вот так:
<intent-filter>
<action android:name="android.intent.action.MAIN />
<category android:name="android.intent.category.LAUNCHER />
</intent-filter>К нему мы вернемся чуть позже.
Не так давно появился новый формат поставки приложений на маркетплэйсе — .aab (Android application bundle).
Главное отличие этого формата от .apk в том, что в него упаковываются статические ресурсы специфичные только для девайса, на который скачивается приложение. Например, если приложение поддерживает 16 языков, но на телефоне установлен шведский, то и вместе с приложением скачается только шведский язык (в случае APK на девайс загружаются все языки). Это позволяет значительно сократить размер приложения. Если пользователь вдруг сменит язык, то система оперативно подгрузит новый язык в приложение и отобразит его.
Однако файл .aab нельзя напрямую установить на телефон. В таком случае разработчикам приходится делать две сборки: .apk для тестирования и .aab для маркетплэйса. И здесь вы можете заметить, что нарушается важное правило тестирования — фактически тестируется не то, что будет выложено в релиз.
Но есть одна хитрость: эту проблему легко можно исправить с помощью bundletool. Bundletool — это скрипт для командной строки, в который вы предаете .aab файл и говорите, как назвать .apk, который должен получиться на выходе.
bundletool build-apks -bundle=/path/to/folder/my_app.aab
-output=/other/folder/my_app.apksПосле этого у вас на руках будет стандартный apk архив и вы сможете тестировать именно ту версию, которая пойдет в релиз.
Note: Обычно такие файлы как bundletool называют executable (файлы, которые можно запустить), если консоль пишет вам Command not found: bundletool, то нужно в консоли прописать полный путь до этого файла “/Users/user/test/../bundletool [команды]”, либо добавить папку, где лежит, этот файл в путь окружения, и тогда полный путь можно не писать. Дальше для краткости подразумевается, что путь до консольных файлов записан в пути окружения.
Теперь давайте поговорим о самом функциональном инструменте, который поможет нам напрямую управлять девайсом.
