Дмитрий Мячин
Через несколько текстов наш цикл подойдет к концу. Эта часть не самая увлекательная, однако она ближе всего к конкретному описанию того, что называется тестированием. Я попытался разбавить всю эту скукоту наглядными примерами, скриншотами. Книги с картинками читают охотнее? По крайней мере популярные «блоггеры» (а я — популярный, у меня есть минимум 8 читателей, скоро продамся кому-нибудь и работать перестану!) часто ставят всякие картинки, возможно это и работает.
Как бы то ни было, здесь можно получить минимальное понимание того, что есть в Android SDK, и что из этого нужно тестировщику. А главное — зачем. Ещё тут есть море грамматических ошибок, наверное, так как писать большую часть текста приходилось ночью, а я по ночам люблю спать и после 22 часов, как правило, уже сплю (Нет, уже нету. Прим. ред.).
Уверен, вам было интересно узнать, во сколько я засыпаю. Читайте дальше, там ещё интереснее!
Android SDK
Мы подбираемся всё ближе и ближе к инструментам и методам тестирования. Инструменты для тестирования, а также всякий вспомогательный инструментарий, входит в состав Android SDK. Самые нужные компоненты из состава SDK, конкретно для тестировщиков, это инструменты SDK, они же SDK tools, инструменты сборки, они же Build tools (внезапно, да?) и инструменты платформы, они же Platform tools. Нет никакого смысла запоминать это. Я просто сказал названия папок из установленного пакета Android SDK.
В этих папках лежит много чего, но я расскажу про минимальный полезный набор.
SDK Tools
Здесь лежит набор инструментов, без которых нет смысла даже начинать тестирование. Без этих инструментов у вас будет не тестирование, а ловля рыбы в мутной воде. Ключевыми инструментами здесь являются следующие: emulator, monitor, monkeyrunner и, для автоматизаторов, uiautomatorviewer.
Эмулятор
Вообще называется он «Android Virtual Device» (AVD). Он позволяет создавать виртуальные устройства как из шаблонов, типа Nexus 6, Nexus 4, просто «Устройство с экраном на 7 дюймов», так и совсем кастомные, а также делать свои шаблоны. Достоинство и недостаток виртуальных устройств именно в их эмуляции. В отличие от виртуальных машин, где, очень грубо и просто говоря, аппаратные возможности и сами устройства хостовой ОС пробрасываются в гостевую ОС, эмулятор вынужден предоставлять совершенно другую архитектуру — ARM. И от того эмулятор ужасно тормозит. За этого его не любят.
Впрочем на процессорах Intel в хостовую ОС можно установить HAXM (Intel Hardware Accelerated Execution), который также можно найти в SDK (в Extras), и получить отличный прирост производительности эмулятора процессора Intel. Однако это доступно только для владельцев Intel и на процессорах от AMD HAXM не работает. Но в любом случае, x86 эмуляторы побыстрее ARM’овских.
Вторая, но гораздо более важная проблема, заключается в том, что периодически эмулятор просто отваливается. Вы можете взаимодействовать с ним мышкой и горячими клавишами, но не можете подцепиться через adb (про который я расскажу дальше). Без доступа по adb эмулятор становится просто не нужен. Здесь, кстати, может спасти альтернативный эмулятор — Genymotion, который сделан для исправления типичных проблем штатного эмулятора (и очень популярен!).
Почему же эмулятор ещё жив, если есть реальные устройства, есть альтернативы? Благодаря эмулятору вы можете, например, посмотреть, как будет выглядеть интерфейс приложения на устройстве, которого у вас нет: вы можете в несколько кликов создать виртуальное устройство, задав нужное разрешение, плотность точек, соотношение сторон, и поглядеть на интерфейс. Можно и быстро посмотреть реакцию на типовые ситуации — изменение громкости, поворот экрана, изменение скорости подключения к сети и подобное. К тому же образы Android (кстати, образы Android для эмулятора — практически оригинальный AOSP!) обновляются очень оперативно. У вас может не быть образа для устройства Nexus, но для эмулятора он всегда есть. Эмулятор всегда под рукой.
Monitor
Или, как его звали в молодости, DDMS. DDMS теперь (на самом деле давно) «деприкейтед», то есть объявлен устаревшим, и эту аббревиатуру можно не запоминать. Расшифровывается она, кстати, Dalvik Debug Monitor Service. Dalvik — это и есть та виртуальная машина, в которой работают приложения Android. Dalvik жил до Android 4.4 включительно, а в Android 5.0 он был заменён на виртуальную машину ART — Android Runtime.
Одно из ключевых отличий ART от Dalvik, это то, что Dalvik компилировал приложения при первом запуске («кэш Далвика» — это вот они), обеспечивая значительное ускорение при повторных вызовах, а ART — при установке. Впрочем, даже эта JIT, Just In Time, то есть «на лету», компиляция байт-кода в машинный появилась лишь в Android 2.2, а до того всё было на одном интерпретаторе. То есть при Dalvik приложения быстрее устанавливаются, но задают жару системе при первом старте. При ART приложения заметно, прямо сильно заметно, дольше устанавливаются, зато запускаются шустрее и не создают таких нагрузок при первом старте. На самом деле различий больше, но нас они особо не касаются. Лично мне знание всех этих различий ни разу не пригодилось в работе.
Так вот, Monitor, который запускается файлом monitor.bat, представляет собой, кроме всего прочего, графическую оболочку для Logcat. Что это такое, я расскажу позже. Здесь нам важно, что в этой оболочке мы можем искать нужные строки, фильтровать их, отслеживать поведение продукта, да ещё пусть и с примитивной, но всё-таки подсветкой. Возможностей у Monitor больше, но они либо практически бесполезны, если у вас есть более одного устройства, либо слишком хардкорны для ознакомительной лекции.
Monkeyrunner
Это инструмент, предоставляющий API для взаимодействия с приложениями на устройстве путём отправки на это устройство разных событий. Средствами Monkeyrunnerможно очень быстро написать скрипт, который будет запускать нужные действия: тыкать в нужные места, вызывать меню, стучать по клавиатуре (включая набор заданных текстов), менять громкость устройства, гасить экран и всё такое прочее. К сожалению, писать сложные тестовые приложения на нём очень трудно, всё же он ориентирован на простоту. Зато с его помощью можно достаточно быстро сделать тестовые сценарии, которые будут помогать находить регрессионные ошибки в, скажем, интерфейсе.
Этот инструмент имеет встроенные возможности для снятия скриншотов и даже сравнения их между собой! Не следует путать Monkeyrunner и Monkey, о котором я расскажу позже.
Uiautomatorviewer
Это полезный инструмент, облегчающий написание автотестов Gray box. Что такое White box, Black box и Gray box тестирование?
White box — мы знаем о приложении всё, при желании даже в код можем заглянуть. Более того, наше тестовое приложение может обращаться напрямую к тестируемому приложению, топая грязными ногами в его песочнице
Black box — мы не знаем о приложении ничего. Мы люди простые — мы видим поле ввода, мы вводим туда данные. Ноль, единицу, огромное число, отрицательное число, число с десятичной точкой, число с десятичной запятой, текст, символы юникода, null’ы, скриптовые сценарии, вставляем из буфера обмена сочинения Льва Толстого, картинки, музыкальные файлы, ставим символ юникода, чтобы текст вводился справа налево… В общем — любимое развлечение при типичном исследовательском тестировании
Gray box — мы кое-что знаем о приложении, но особо с этим сделать ничего не можем. К примеру, мы знаем, как и почему текст меняется при нажатии на кнопку, но программно именно на эту кнопку нажать не можем. «Именно на эту» — это обращение уровня findViewById(R.id.btnPressMeButton), а не уровня «кнопка, которая лежит вот на этом экране, но не первая, а вторая». Когда вы пытаетесь своей маме по телефон объяснить, как сделать скриншот, это вот оно. Вы знаете, как это происходит, вы точно знаете, что должно получиться на каждом из шагов, но сами этого сделать не можете
Так вот когда нужно автоматизировать ввод данных в поле и нажатие на кнопку, то нужно узнать, а что это за ресурсы такие, чтобы обращаться напрямую к ним. Можно, конечно, по координатам тыкать, но это просто смешно — даже одно и тоже устройство может быть в двух положениях, а устройств с разными экранами и разрешениями экранов миллиарды. Здесь на помощь и приходит инструмент Uiautomatorviewer.
Мы подключаем устройство к компьютеру или же запускаем эмулятор
Запускаем приложение и просим этот инструмент собрать данные обо всём, что он «видит»
Инструмент очень подробно разбирает всё приложение на элементарные элементы и показывает все доступные их свойства. В итоге мы можем своим автотестом обращаться чётко к нужным ресурсам вне зависимости от того, на каком устройстве это приложение было запущено. Что ещё ценно, этот инструмент позволяет сохранить данные о разобранных экранах. Мы можем взять устройство на время, быстро сохранить нужные экраны нужных приложений и вернуть его. А дальше писать сценарий автотеста, посматривая в сохранённые данные.
Чем же это хуже тестирования «белого ящика»? Тем, что это всё так сладко только в теории. На практике же графический интерфейс приложения может быть построен таким образом, что на нём будет множество «одинаковых» элементов.
На скриншоте типичный пример, когда обратиться к конкретному элементу можно, но это уже выходит за рамки «охохо, сейчас мы тут всё быстренько автоматизируем». У переключателя тот же ID ресурса, что и у всех других переключателей. Нет, в R.java (в этом файле перечислены вообще все ресурсы, какие они есть в приложении) у них разные ID, но снаружи этого не видно.
Теперь, чтобы переключить конкретно этот переключатель, нужно рекурсивно перебирать Layouts (это, грубо говоря, форма с пазами, в которые все элементы интерфейса вставляются, а форма уже «следит», чтобы из пазов ничего не уезжало) и по косвенным признакам находить нужный, чтобы уже в нём забраться внутрь и щёлкнуть тумблером. Либо же сразу обратиться к нужному «лайауту» по его индексу (здесь он имеет индекс 6), внутри которого выбрать дочерний с индексом 1, внутри которого щёлкнуть тумблером.
В первом случае кода будет намного больше, зато небольшие перетасовки интерфейса не сломают автотест, потому что ориентируется он по косвенным признакам (скажем, читает текст и сравнивает с эталонным), однако это уже слабо подходит для тестирования локализаций (потому что в локализациях тексты, понятное дело, меняются). Во втором случае кода совсем мало, можно даже в пару строк уложиться, зато просто перестановка двух «вьюх» (View здесь — это каждый из элементов интерфейса: каждая кнопка, каждая надпись, каждый переключатель — всё это самостоятельные «вьюхи») относительно друг друга полностью сломает автотест. Зато этот метод идеален для тестирования локализаций, потому что для локализаций интерфейс меняют очень редко и нужно, как правило, проверять именно уместились ли надписи, и правильные ли они в целом. А это, между прочим, Uiautomatorviewer умеет! Просто потому, что он получает ровно те строки, которые видны. То есть если строка вылезает за пределы экрана, вылезшую часть он не «прочтёт».
Продолжение следует.
о чем статья вообще? что за хрень бесполезная