Софт

тестирование Android приложений

Рейтинг: 4.9/5.0 (1244 проголосовавших)

Категория: Windows

Описание

Компьютерра: Тестирование приложений для Android как инструмент выхода в ТОП на Google Play

Тестирование приложений для Android как инструмент выхода в ТОП на Google Play

авторы: Дмитрий Куриленко, компания Promwad 13 марта 2013

По итогам 2012 года операционная система Android стала лидером среди мобильных платформ: её доля на мировом рынке превысила 53 процента. Для сравнения: доля ОС компании Apple — 36 процентов (данные аналитической компании СomScore). Даже на европейском рынке, где долгое время фаворитом была iOS, Android вытеснил своих конкурентов. Ещё одно достижение — более 25 миллиардов загруженных приложений в Google Plaу.

Эта статистика демонстрирует огромный потенциал операционной системы компании Google на рынке мобильных приложений. С одной стороны, разработчики программ для Android получают большие возможности для роста, с другой — сталкиваются с жёсткой конкуренцией и высокими требованиями к качеству со стороны пользователей. В таких условиях особое значение приобретает всестороннее тестирование продуктов для магазина приложений Google Play.

Мировая доля продаж смартфонов на базе мобильных ОС в 2008—2012 гг. Источник: Enders Analysis

Смартфоны и планшеты под управлением Android имеют значительные отличия в программной и аппаратной части. Они могут иметь разный форм-фактор и разрешение экрана, использовать свою версию ОС и систему команд процессора, обеспечивать поддержку фронтальной камеры, NFC, внешней клавиатуры и других модулей. Всё это нужно учесть при разработке приложений.

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

Ошибки допускают все — и начинающие программисты, и опытные команды известных компаний. Например, недавно в сообществе «Хабрахабр» была опубликована статья с целым списком багов и недоработок в приложении «Яндекс.Метро» для смартфонов на ОС Android.

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

Разработчики программных продуктов для ОС Android могут выполнять комплексную проверку качества или концентрироваться на отдельных задачах: функциональном, автоматизированном, нагрузочном, стрессовом или на юзабилити-тестировании. Остановимся на этом вопросе подробнее.

Функциональное тестирование позволяет проверить приложение на соответствие требованиям в спецификации. В рамках этой задачи можно проводить полное тестирование или проверить только базовые функции. Один из самых распространённых способов функционального тестирования — это метод чёрного ящика. В этом случае приложение исследуется с точки зрения внешнего мира, то есть специалист не использует информацию о внутреннем устройстве программы.

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

Ещё один интересный тип тестирования — интеграционное. Именно оно гарантирует корректную работу программы на устройствах с различными параметрами. Команда тестировщиков использует различные модели планшетов и смартфонов под управлением ОС Android. Важно понимать, что программные эмуляторы не могут полностью заменить работу настоящих устройств, поэтому без своего парка тестовых гаджетов реализовать такой проект будет довольно сложно.

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

Автоматизированные тесты позволяют проверить многие параметры приложения: инсталляцию и удаление приложения, реакцию на команды пользователя и системные события, элементы интерфейса и вид приложения в зависимости от положения датчиков. Для проверки всей этой функциональности используются следующие популярные инструменты автоматизированного тестирования:

  • Monkey для стресс-тестирования;
  • Adb для быстрого управления;
  • Monkeyrunner для тестирования с реализацией скриптов на Jython (Python на языке Java);
  • тестовые проекты на языке java.

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

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

В некоторых случаях команды разработчиков пытаются сокращать бюджет всего проекта по разработке программного продукта за счёт тестирования. Насколько это обоснованно? На этот вопрос помогает ответить исследовательское тестирование — первичное изучение функциональности и качества Android-приложений. Бюджет такой задачи может составлять от 200 до 400 долларов. По её результатам можно будет понять, нужно ли проводить более углублённое тестирование.

В любом случае, разработчики и владельцы Android-приложений должны быть уверены в том, что их программа будет корректно работать на любых типах смартфонов и планшетов под управлением этой ОС. Это одна из составляющих успеха на рынке Google Play.

Тестирование Android Приложений:

  • скачать
  • скачать
  • Другие статьи, обзоры программ, новости

    Тестирование Android-приложения с помощью Eclipse Testdroid Recorder

    Тестирование Android-приложения с помощью Eclipse + Testdroid Recorder

    Апрель 13, 2012 в 17:40. Просмотров: 198

    1. Создайте учетную запись на сайте "Testdroid ".
    2. Установите плагин "Testdroid" в Eclipse: "Help" -> "Eclipse Marketplace", в поле "Find" вписываем "Testdroid Recorder". После того, как плагин будет найден, жмите "Install".
    3. В качестве примера создайте Android-проект из sample: "File" -> "New" -> "Other" -> "Android Project". В окне "New Android Project" задать имя проекта и выбрать "Create project from existing samples", нажать кнопку "Next". В следующем окне выберите нужную версию Android, которая имеет примеры. В окне "Select Sample" выберите "NotePad" и нажмите кнопку "Finish".
    4. Выделите созданный проект и вызовите контекстное меню. Затем "Android Tools" -> "New Test Project". Задайте имя проекта <AddNoteTest> и сохраните проект.
    5. Выделите созданный проект и вызовите контекстное меню. Затем "Build Path" -> "Configure Build Path. ". В открывшемся окне перейдите на вкладку "Libraries", нажмите кнопку "Add External JARs" и выберите файл robotium-solo-<version>.jar (последнюю версию можно скачать на оф.сайте ). Перейдите на вкладку "Order and Export" и отметьте чек-бокс напротив robotium-solo-<version>.jar. Нажмите кнопку "ОК".
    6. В пакете com.example.android.notepad.test создайте новый класс с именем <AddNoteTest> и со следующим содержанием:

    7. Выделите созданный проект и вызовите контекстное меню. Затем "Run As. " -> "Android JUnit Test". В зависимости от того, где вы тестируете приложение (эмулятор или телефон), на экране устройства запуститься приложение, в котором начнут автоматически происходить действия, описанные в тесте.

    В следующей заметке я расскажу, как с помощью Testdroid Recorder создавать Record/Play тесты.

    Ручное и автоматизированное тестирование Android-приложений

    Ручное и автоматизированное тестирование Android-приложений

    ч. 1
    Ручное и автоматизированное тестирование
    Android-приложений

    Ковалевская А.А.
    Дыкоменко К.С.

    Научный руководитель: Макаренко Н.В.

    Филиал учреждения образования "Белорусский государственный технологический университет" "Витебский государственный технологический колледж"

    Цель исследования. изучить особенности ручного и автоматизированного тестирования Android-приложений.

    1. Ручное тестирование Android-приложений

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

    2. Автоматизированное тестирование Android-приложений

    В данном разделе раскрыто понятие автоматизированного тестирования программного обеспечения и описана ситуация, когда его целесообразно применять.

    В данном подразделе описывается, для чего служит Android SDK.

    2.2 Запись и воспроизведение теста

    В данном подразделе описываются возможности инструмента MonkeyRunner, а также перечень этапов работы с MonkeyRecorder.

    В связи с ростом количества смартфонов и устройств на Android все большую популярность набирают мобильные приложения.

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

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

    Тестирование – это поиск дефектов или багов (от англ. bug (жук)) в приложении. Термин «баг» используют для обозначения ошибки, из-за которой приложение выдает неожиданное поведение. По одной из версий данный термин стал активно использоваться, после того как в 1946 году учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле, и Грейс Хоппер ( американский ученый, одна из первых, кто писала программы для гарвардского компьютера Марк I) произнесла этот термин. Извлечённое насекомое было вклеено скотчем в технический дневник с сопроводительной надписью: «First actual case of bug being found» («первый реальный случай, когда был найден жук»).

    Планируя процесс тестирования тестировщик часто составляет тест-кейсы. В самом простом случае тест-кейс включает в себя:

    краткое описание (то, что тестируем);

    последовательность действий (шаги, которые выполняет тестировщик, чтобы проверить какую-либо функциональность);

    ожидаемый результат (то, что должно получиться после выполнения действий).

    В дальнейшем по данным тест-кейсам тестируется приложение. Выполняя последовательность действий из тест-кейса, тестировщик получает фактический результат, который сравнивает с ожидаемым. Если данные результаты не совпадают, то это означает, что тестировщик нашел баг.

    В данном исследовании мы рассмотрим особенности ручного тестирования Android-приложений, а также изучим автоматизированное тестирование с помощью инструмента MonkeyRunner.

    1Ручное тестирование Android-приложений


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

    Тестирование мобильных приложений существенно отличается от тестирования приложений, предназначенных для использования на персональных компьютерах.

    Приведем ряд основных моментов, которые нужно протестировать:

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

    Мультитач и размер экрана. Корректность удаления 2-х элементов или просмотр двух элементов, нажатием на них одновременно. Проверка многократного быстрого нажатия на кнопку – часто при этом может случиться падение приложения. В приложении должны отсутствовать пустые экраны, чтобы пользователь не оказался в ситуации, в которой не очевидно, что делать. Также все элементы должны быть такого размера, чтобы пользователь мог однозначно нажать на них.

    Стабильность. Работа приложения при множестве запущенных приложений и долгое время, а также в случае недостатка места для установки или работы приложения. Поведение приложения при отсутствии в некоторых устройствах поддерживаемых приложением функций.

    Адаптация приложения к портретной и альбомной ориентациям устройства.

    Стресс. Реакция приложения на внешние прерывания:

    входящие и исходящие SMS, MMS, звонки, оповещения других приложений;

    переход устройства в режим ожидания;

    выключение устройства, разрядка устройства;

    переход в другое приложение.

    Интернационализация. Проверка корректности работы приложения на разных языках (если данное приложение мультиязычное).

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

    Обновление. Корректность обновления приложения до новой версии.

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

    Нами было произведено тестирование мобильного приложения «FM» (файловый менеджер для Android). Планируя процесс тестирования мы составили ряд тест-кейсов. Например, тест-кейс для проверки неактивности кнопки перехода по закладке, если данная закладка была удалена:


    1. Запустить приложение FM

    2. Нажать на иконку с изображением дискеты для добавления закладки

    3. Ввести в поле «Имя» название закладки, например, «Главная»

    4. Нажать на пункт списка «Закладки»

    5. Нажать на пункт списка «Главная»

    6. Удалить закладку (нажать на иконку с изображением корзины в правом верхнем углу)

    7. В окне подтверждения удаления нажать «Yes»

    8. Попытаться нажать на кнопку-стрелку рядом с надписью «Избранное»


    TC ID – уникальный идентификатор тест-кейса (или номер тест-кейса)

    Priority – приоритет: низкий, средний, высокий

    IDEA – краткое описание того, что проверяется с помощью данного тест-кейса; здесь же находятся предпосылки для тест-кейса (необходимые данные для проверки по данному тест-кейсу)

    Revision History – история изменений. Содержит информацию о дате создания/изменения тест-кейса, имени тестировщика, а также действиях: новый тест-кейс; тест-кейс изменен (можно указать, что конкретно менялось).

    PROCEDURE – последовательность шагов (сценарий)

    EXPECTED RESULT – ожидаемый результат

    Протестировав приложение по данному тест-кейсу, мы обнаружили следующий баг:

    Краткое описание. Активность кнопки перехода по закладке, после удаления закладки.

    Шаги по воспроизведению:

    1. Запустить приложение FM

    2. Нажать на иконку с изображением дискеты для добавления закладки

    3. Ввести в поле «Имя» название закладки, например, «Главная»

    4. Нажать на пункт «Закладки»

    5. Нажать на «Главная»

    6. Удалить закладку (нажать на иконку с изображением корзины в правом верхнем углу)

    7. В окне подтверждения удаления нажать «Yes»

    8. Попытаться нажать на кнопку-стрелку рядом с надписью «Избранное»

    Фактический результат. Кнопка-стрелка активна. После нажатия на нее появляется неинформативная ошибка, которая показана на рисунке 1:

    Рисунок - Окно с ошибкой

    Ожидаемый результат. Кнопка-стрелка неактивна.

    2Автоматизированное тестирование Android-приложений


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

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

    Используя инструмент MonkeyRunner, предназначенный для автоматизированного тестирования Android-приложений, мы автоматизировали ряд тест-кейсов для нашего мобильногоприложения «FM» (файловый менеджер для Android).

    2.1Android SDK


    MonkeyRunner входит в состав Android SDK.

    SDK (от англ. software development kit) — комплект средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определённого пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ.

    Android SDK представляет собой эмулятор устройства и применяется для тестирования приложений под Android. Кроме того AndroidSDK предлагает набор инструментов для почти мгновенного создания приложений.

    2.2Запись и воспроизведениетеста


    Утилита MonkeyRunner предоставляет API для написания скриптов, которые управляют Android устройстами. С помощью MonkeyRunner можно написать скрипт на языке Python, который устанавливает Android приложение, запускает его, имитирует действия пользователя, снимает скриншоты и сохраняет их на компьютер. Утилита MonkeyRunner использует Jython (это реализация языка Python на языке Java) для выполнения скриптов.

    С помощью MonkeyRunner можно запустить MonkeyRecorder, с помощью которого можно записывать различные действия, выполняемые на Android-устройстве. Однако MonkeyRunner оперирует координатами для выбора элемента управления, поэтому при изменении размеров экрана придется перезаписывать тест.

    Перечень этапов работы:

    Установить Python (например, в c:\Python27)

    Прописать путь к c:\Python27 в переменной среды Path

    Прописать путь в переменных среды к каталогу tools из AndroidSDK

    Скопировать следующие скрипты в папку tools:

    monkey_recorder.py (это MonkeyRecorder)

    monkey_playback.py (воспроизведение теста, записанного с помощью MonkeyRecorder)

    Запустить командную строку и ввести (предварительно запустить эмулятор и открыть приложение на нем или подключить реальное устройство (планшет, телефон) к компьютеру):

    Далее записать действия с помощью MonkeyRecorder и нажать на кнопку Export Actions. Сохранить файл с расширением txt (например, r1.txt).

    Для воспроизведения записанного теста в командной строке необходимо набрать следующее:

    monkeyrunner.bat monkey_playback.py r1.txt

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

    Мы провели ручное тестирование мобильного приложения «FM» (файловый менеджер для Android) по предварительно составленным тест-кейсам. В ходе данного тестирования мы нашли ряд багов, которые задокументировали, чтобы впоследствии данные баги можно было исправить.

    Мы также узнали:

    об использовании Android SDK;

    о возможностях утилиты MonkeyRunner при автоматизированном тестировании Android-приложений;

    о возможностях MonkeyRecorder, а также применили его для автоматизации наших тест-кейсов.

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

    Список использованных источников

    1. В.В. Липаев. Тестирование программ. /М. Радио и связь, 1986. – 296с.

    2. Г. Майерс. Искусство тестирования программ. / М. Финансы и статистика,1982. – 176 с.

    3. И.В. Винниченко. Автоматизация процессов тестирования. / СПб. Питер,2005. – 203 с.

    4. Л. Тамре. Введение в тестирование программного обеспечения. / М. Издательский дом «Вильямс»,2003. – 368 с.

    5. Р. Савин. Тестирование Dot COM, или Пособие по жестокому обращению с багами в интернет-стартапах. / М. Дело,2007. – 312 с.

    6. Э. Дастин, Д. Рэшка, Д. Пол. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация. / М. Издательство «ЛОРИ»,2003. – 567 с.

    Тест Android

    Тест Android. Robotium UI тестирования Введение

    Robotium - вообще это библиотека для обычных Unit тестов, которая представляет собой просто jar-файл, подключаемый к вашему тестовому проекту. Разработчики же данной библиотеки говорят "Этот как Selenium, только для Android". Чтобы тестировать приложения, необходимо их собрать с этой библиотекой. Возможно тестировать приложения без исходников, но процесс нетривиальный. Тесты пишутся на Java. Для тестирования создается стандартный тестовый проект, в который добавляется библиотека Robotium. Тестовый проект можно запускать как на эмуляторе, так и на девайсе. Robotium использует синтаксис JUnit3.

    Для работы необходимо:

    1. Eclipse
    2. Android SDK
    3. Android Project
    4. Robotium

    Первых три пункта опустим это не относится к данной статье. Поговорим конкретно о создании теста Robotium. Для работы необходимо скачать на сайте Robotium Solo 3.6

    • Открываем тестируемый проект в Eclipse.
    • Создаем новый Android JUnit Test Project.

    • Задаем ему имя, выбираем тестируемый проект.
    • Устанавливаем необходимую версию Android.

    Что же произошло после этих всех манипуляций при создании проекта.

    Создался "простой" проект Android.

    Но в файле манифест было указано дополнительные параметры о том что это тестовый проект, также был указан пакет тестируемого проекта "ru.example.bank".

    Далее нам нужно будет добавить библиотеку Robotium, скачанную ранее. Кликнув на вновь созданный тестовый проект и в "Properties" в разделе "Java Build Patch" во вкладке "libraries" добавить библиотеку. Вот наш проект подготовлен к написанию самого теста. И импортировать его.

    Теперь мы создаем класс в этом проекте. В классе необходимо импортировать проект и классы которые мы собираемся тестировать. Так же для UI тестирования необходимо наследовать от класса ActivityInstrumentationTestCase2<Class> где Class это тот класс который мы собираемся тестировать, а для unit test наследовать от базового класса AndroidTestCase.

    Дальше мы в методе классе, указываем ссылку на базовый класс.

    Прописываем еще один метод который запускается до начала теста. В нем мы вызываем Activity.

    Также есть метод который выполняется после завершения теста. В котором закрываются все Activity которые были открыты во время теста.

    Тест

    Теперь можно писать само тестирования. Каждый 1 тест это 1 метод в классе.

    Возможности

    Solo, которого мы и создаем в начале нашего тестового класса. Именно он, по средствам своих методов (Robotium API) будет нажимать, выбирать, кликать и вводить текст в нашем приложении. Инструментарий у робота богат.

    Методы для манипулирования компонентами UI:

    Различные скролл и драг

    Ожидание на появление чего-то или кого-то, или просто заснуть на время

    Пример UI теста Юнит тестирование

    При юнит тестировании можно вызывать методы тестируемого кода для этого уже Robotium не нужен. Достаточно Junit plugin для Eclipse. Проект создается точно так же только уже без библиотеки Robotium.

    Пример Источники и дополнительные материалы

    Тестирование мобильных приложений на Android

    Тестирование Android приложений

    Тестирование Android приложений

    Взрывной рост использования мобильных смартфонов и разработки мобильных приложений делает автоматизацию тестирования ключевым требованием успешной и быстрой поставки качественных мобильных приложений. Автоматизированное функциональное тестирование помогает обеспечить необходимую функциональность мобильного приложения и надлежащую работу пользовательского интерфейса. Однако существует необходимость выйти за рамки функционального тестирования мобильных приложений. Существует множество аспектов производительности мобильных приложений, которые нужно измерять и улучшать. Есть прямая взаимосвязь между производительностью и удобством использования мобильных приложений.

    Тестирование является важной частью процесса разработки мобильных приложений. Для Android оно имеет особенную важность, поскольку используемые устройства довольно сильно отличаются друг от друга по следующим параметрам:

    • размером и разрешением экрана;
    • версией Android;
    • форм-фактор устройства;
    • системы команд процессора;
    • фронтальная камеры, NFC, внешняя клавиатура и т.д.

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

    Автоматическое тестирование приложений для Android

    Рассмотрим несколько средств для автоматического тестирования функциональности, которые входят в состав Android SDK или распространяются с открытым исходным кодом.

    Принцип автоматического тестирования приложений

    Наша задача — с наибольшей точностью автоматизировать действия, выполняемые вручную. Рассмотрим эти действия. Будем использовать несколько приложений и несколько устройств с Android. Для каждого приложения и каждого устройства нужно выполнить следующие действия:

    • Установить приложение на устройство
    • Запустить приложение
    • Протестировать приложение, используя выбранный метод
    • Удалить приложение
    • Сбросить устройство в исходное состояние
    • На каждом этапе нужно собирать и анализировать данные (журналы и снимки экрана). Ниже описываются средства для автоматизации этих действий.
    • Управление устройствами Android

    Прежде всего необходимо выбрать компьютер, который будет использоваться для запуска автоматических тестов, и установить на нем Android SDK. В данном примере мы используем настольный компьютер с операционной системой Linux*. На каждом устройстве необходимо отключить экран блокировки и увеличить «время перед переходом в спящий режим» до максимального значения. Для некоторых методик тестирования также нужно отключить изменение ориентации экрана. В составе Android SDK предусмотрено две программы для управления устройствами с Android: ADB и monkeyrunner* ADB (Android Debug Bridge) — это программа командной строки для управления устройствами с Android.

    Методы автоматического тестирования Android

    Тестирование с помощью Monkey*

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

    Основное преимущество Monkey в отсутствии затрат на обслуживание. К тому же нагрузочное тестирование может выявлять сложные и малозаметные ошибки.

    Недостатки тестирования с помощью Monkey:

    • Monkey не может имитировать сложные нагрузки, такие как проверка подлинности. В таких случаях функциональность приложений остается непротестированной.
    • Игры со сложным управлением, требующие быстрой реакции пользователей и сложных жестов, будут выполнены с самого начала или же вовсе не запустятся.
    • Крайне сложно воспроизводить ошибки, обнаруженные с помощью Monkey.
    • Monkey не проверяет состояние приложения во время тестирования.

    Автоматическое тестирование с помощью Monkey можно считать неплохой начальной проверкой для любого приложения. Этот метод может дать достаточно полезные результаты для определенного приложения. Но при низком качестве тестирования следует использовать другие методы.

    Тестирование с помощью MonkeyRunner

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

    Тестирование с помощью getevent и sendevent

    Программы getevent и sendevent позволяют пользователю записывать последовательность действий и затем воспроизводить ее. Для запуска этих программ не требуются права доступа root.

    • Последовательности событий можно записать без дополнительных затрат в ходе ручного тестирования, если оно проводится;
    • Для записи последовательности событий не требуются навыки программирования.
    • Последовательности необходимо записывать отдельно для каждого приложения и для каждого устройства. При изменении интерфейса приложение потребуется переделать все записанные действия;
    • Этот метод не проверяет состояние приложения во время тестирования. Если отклик приложения задерживается (например, из-за длительной загрузки веб-страницы), то результаты тестирования будут неверными;
    • Воспроизведение быстрых и сложных последовательностей занимает больше времени, чем их запись. Поэтому такой метод не всегда подходит для тестирования динамических игр, где важно быстрое реагирование.
    Тестирование с помощью Robotium

    Robotium не входит в состав Android SDK, эта программа распространяется с открытым исходным кодом. Сценарии Robotium определяют действия на уровне пользовательского интерфейса приложений, а не на уровне устройства ввода. Например, в сценарии требуется коснуться кнопки «ОК». В этом случае скрипт monkeyrunner будет построен следующим образом: «имитировать касание экрана в точке с координатами (x0, y0)». Скрипт Robotium будет построен иначе: «нажать кнопку с текстом «ОК».

    Описание действий на уровне интерфейса позволяет сделать тестовый скрипт независимым от расположения и размеров элементов интерфейса, разрешения и ориентации экрана. Кроме того, в Robotium можно проверять реакцию приложения на действия. Например, предположим, что после нажатия кнопки «ОК» должен появиться список с элементом «Элемент 1». В Robotium можно проверять имена элементов списков. Проверка состояния приложения после каждого шага позволяет с легкостью находить шаг, на котором произошла ошибка.

    • Для каждого приложения требуется разрабатывать тестовый сценарий на языке Java*. Для этого требуется время и навыки программирования;
    • При смене интерфейса приложения потребуется переделать последовательность событий;
    • Создавать сценарии Robotium сложнее, чем записывать события с помощью getevent / sendevent;

    В целом, Robotium позволяет создавать тестовые сценарии высшего качества с разумными затратами.

    Сравнение методов тестирования мобильных приложений

    Черная Команда: Robotium: Функциональное тестирование Android приложений

    Robotium:Функциональное тестирование Android приложений

    Что есть robotium? Вообще это библиотека, которая представляет собой просто jar-файл, подключаемый к вашему тестовому проекту. Разработчики же данной библиотеки говорят "Этот как Selenium, только для Android". Начну я свой рассказа пожалуй с того, что из себя представляет Android проект.

    Структура Android проекта

    Приложение андроид состоит из нескольких основных ресурсов: это манифест приложения (xml файл), набор различных ресурсов и собственно сами исходники.
    Что ж там есть в этом проекте то?
    - директория gen - тут лежат файлы сгенерированные джавой.
    - файл AndroidManifest.xml - файл манифеста приложения, предоставляет основную информацию о программе системе
    - директория src - исходные коды приложения
    - директория assets - произвольные файлы и подпапки
    - директория res - этот каталог содержит ресурсы приложения. Как правило содержит подпапки drawable, anim, layout, menu, values, xml и raw.

    Приложения в Android используют четыре основные компонента:

    -Activities - это визуальный компонент приложения, который отвечает за UI. Приложение может содержать как несколько Activity. так и вовсе не содержать.

    -Services - это то что выполняется пока приложение не находится в фокусе. Сервис может запускаться вместе с системой и "висеть" в фоне выполняя некоторые действия. Взаимодействовать с Service можно посредством интерфейсов.

    -Broadcast receivers - один из важнейших компонентов приложения. Broadcast receiver также как и сервис не имеет видимого интерфейса. Это что-то на подобие перехватчика событий

    - Content providers - предоставляет определенные данные другим приложением. Эти данные могут храниться в файловой системе, SQLite базе данных, или еще где-то.

    Основные методы жизненного цикла приложения
    • protected void onCreate (Bundle savedInstanceState);
    • protected void onStart();
    • protected void onRestart();
    • protected void onResume();
    • protected void onPause();
    • protected void onStop();
    • protected void onDestroy();
    onCreate

    Вызывается при создании активности. Этот метод принимает один параметр — объект Bundie, содержащий предыдущее состояние активности (если это состояние было сохранено). Система может запускать и останавливать текущие окна в зависимости от происходящих событий. Android вызывает метод onCreate() после запуска или перезапуска Activity. Внутри этого метода настраивают статический интерфейс активности. Инициализирует статические данные активности, связывают данные со списками и т. д. Связывает с необходимыми данными и ресурсами. Задает внешний вид через методsetContentView().

    onStart

    За onCreate() всегда следует вызов onStart(), но перед onStart() не обязательно должен идти onCreate(), так как onStart() может вызываться и для возобновления работы приостановленного приложения (приложение останавливается методом onStop()). При вызове onStart() окно еще не видно пользователю, но вскоре будет видно. Вызывается непосредственно перед тем, как активность становится видимой пользователю. Сопровождается вызовом метода onResume(), если активность получает передний план, или вызовом метода onStop(), если становится скрытой;

    onResume

    Метод onResume() вызывается после onStart(), даже когда окно работает в приоритетном режиме и пользователь может его наблюдать. В этот момент пользователь взаимодеиствует с созданным вами окном. Приложение получает монопольные ресурсы. Запускает воспроизведение анимации, аудио и видео. Также может вызываться после onPause().

    onPause

    Когда пользователь решает перейти к работе с новым окном, система вызовет для прерываемого окна метод onPause(). По сути происходит свертывание активности. Сохраняет незафиксированные данные. Деактивирует и выпускает монопольные ресурсы. Останавливает воспроизведение видео, аудио и анимацию. От onPause() можно перейти к вызову либо onResume(), либо onStop().

    onStop

    Метод onStop() вызывается, когда окно становится невидимым для пользователя. Это может произойти при ее уничтожении, или если была запущена другая активность (существующая или новая), перекрывшая окно текущей активности. Всегда сопровождает любой вызов метода onRestart(), если активность возвращается, чтобы взаимодействовать с пользователем, или метода onDestroy(), если эта активность уничтожается.

    onRestart

    Если окно возвращается в приоритетный режим после вызова onStop(), то в этом случае вызывается метод onRestart(). Т.е. вызывается после того, как активность была остановлена и снова была запущена пользователем. Всегда сопровождается вызовом метода onStart()

    onDestroy

    Метод вызывается по окончании работы активности, при вызове метода finish() или в случае, когда система уничтожает этот экземпляр активности для освобождения ресурсов. Эти два сценария уничтожения можно определить вызовом метода isFinishing(). Вызывается перед уничтожением активности. Это последний запрос, который получает активность от системы. Если определенное окно находится в верхней позиции в стеке, но невидимо пользователю и система решает завершить это окно, вызывается метод onDestroy(). В этом случае метод удаляет все статические данные активности. Отдает все используемые ресурсы.

    Из всего выше перечисленного нам понадобится только джава класс R.

    Напишем примерочные тесты на Robotium


    Для начала скачаем саму библиотеку Robotiumа
    После установим Android SDK на компик, так же установим eclipse и соответствующий плагин для android, который можно найти обычным поиском в eclipse market. Ну и естественно все настроим.


    После того как все настроено и установлено, создадим стандартный пример приложения андроид из Android Project Sample, который представляет из себя обычный блокнот NotePad

    Ну и запустим его

    Видим что открылся эмулятор и все запустилось и работает


    После чего создадим Android JUnit Test Project, к которому мы подключим нашу библиотеку robotium.jar. Тестовый проект создадим на основе android приложения NodePad

    Ну и в тестовом классе напишем следующий код:


    import com.example.android.notepad.NotesList;
    import com.jayway.android.robotium.solo.Solo;
    import android.test.ActivityInstrumentationTestCase2;
    import android.test.suitebuilder.annotation.Smoke;


    public class NotePadTest extends ActivityInstrumentationTestCase2<NotesList><


    private Solo solo;


    public NotePadTest() <
    super("com.example.android.notepad", NotesList.class);


    public void setUp() throws Exception <
    solo = new Solo(getInstrumentation(), getActivity());
    >


    @Smoke
    public void testAddNote() throws Exception <
    solo.clickOnMenuItem("Add note");
    //Assert that NoteEditor activity is opened
    solo.assertCurrentActivity("Expected NoteEditor activity", "NoteEditor");
    //In text field 0, add Note 1
    solo.enterText(0, "Archik 1");
    solo.goBack();
    //Clicks on menu item
    solo.clickOnMenuItem("Add note");
    //In text field 0, add Note 2
    solo.enterText(0, "Archik 2");
    //Go back to first activity named "NotesList"
    solo.goBackToActivity("NotesList");
    boolean expected = true;
    boolean actual = solo.searchText("Archik 1") && solo.searchText("Archik 2");
    //Assert that Note 1 & Note 2 are found
    assertEquals("Archik 1 and/or Archik 2 are not found", expected, actual);


    @Smoke
    public void testEditNote() throws Exception <
    // Click on the second list line
    solo.clickInList(2);
    // Change orientation of activity
    solo.setActivityOrientation(Solo.LANDSCAPE);
    // Change title
    solo.clickOnMenuItem("Edit title");
    //In first text field (0), add test
    solo.enterText(0, " test");
    solo.goBackToActivity("NotesList");
    boolean expected = true;
    // (Regexp) case insensitive
    boolean actual = solo.searchText("(?i).*?archik 1 test");
    //Assert that Note 1 test is found
    assertEquals("Archik 1 test is not found", expected, actual);


    @Smoke
    public void testRemoveNote() throws Exception <
    //(Regexp) case insensitive/text that contains "test"
    solo.clickOnText("(?i).*?test.*");
    //Delete Note 1 test
    solo.clickOnMenuItem("Delete");
    //Note 1 test & Note 2 should not be found
    boolean expected = false;
    boolean actual = solo.searchText("Archik 1 test");
    //Assert that Note 1 test is not found
    assertEquals("Archik 1 Test is found", expected, actual);
    solo.clickLongOnText("Archik 2");
    //Clicks on Delete in the context menu
    solo.clickOnText("(?i).*?Delete.*");
    actual = solo.searchText("Archik 2");
    //Assert that Note 2 is not found
    assertEquals("Archik 2 is found", expected, actual);
    >


    @Override
    public void tearDown() throws Exception <
    //Robotium will finish all the activities that have been opened
    solo.finishOpenedActivities();
    >
    >


    После чего запустим наши тесты


    Главной фишкой является эдакий роботик-муравей под названием Solo, которого мы и создаем в начале нашего тестового класса


    Именно он, по средствам своих методов (Robotium API) будет деркать, тыкать, кликать и вводить текст в нашем приложении. Инструментарий у робота богат.


    Методы для манипулирования компонентами УИ:
    clickOnScreen
    clickOnMenuItem
    clickOnImageButton
    clickOnRadioButton
    clickOnText
    clickOnToggleButton
    clickOnView
    clickOnImage
    clickOnCheckBox
    clickOnButton
    clickOnEditText
    и др.

    Различные скроллы и драг
    scrollDown
    scrollDownList(
    scrollToSide
    scrollUp
    scrollUpList
    drag
    и др.

    Ожидалки на появление чего-то или кого-то, или просто заснуть на время
    waitForDialogToClose
    waitForText
    waitForView
    sleep

    Как же робот находит элементы? Так же как и в Selenium по локаторам, а точнее id элементам.
    Возвращаясь к началу топика, я заострил внимание на класс в Android приложении R.java.
    Он содержит пространство имен под названием id. В этом пространстве содержаться айдишки всех элементов графического интерфейса нашего приложения. По принципу whitebox testing мы можем обращаться к ним в наших тестах solo.getView(R.id.TextView01);

    Так же можно искать элементы и методом черной коробки. Solo робот сам идентифицирует компоненты юая обычными числами начиная с 0. Т.е. если у нас на экране 2 поля ввода текста, то ввести текст в них мы сможем вот так:

    //Enter 10 in first editfield

    //Enter 20 in second editfield

    Так же мы можем искать элементы по тексту, даже используя регулярные выражения (примеры кода выше). Таким образом мы можем автоматизировать тестирование даже не имея исходников приложения, достаточно иметь apk файл. Есть возможность тестирования на реальном девайсе так же.

    Я не пишу и не хочу писать код. Где рекордер?

    Не вопрос. Рекордер есть, при чем в виде плагина к эклипсу под название Testdroid Recorder


    Установим этот плагин и зарегаемся на их сайте. После чего создадим Testdroid Test в эклипсе в уже созданном тестовом проекте андроид приложения.

    Выберим приложение к которому будем записывать тест и за одно куда его сохранять


    После чего подконнектимся к своему аккаунту созданному на сайте Testdroid


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


    Во время записи есть возможность сэмулировать действие PrtScr андроид экрана :)
    После записи мы можем отредактировать наш код. На самом деле рекордер записывает много лишних действий, в основном ожидалок, которые можно закомментарить

    Отредактированный тест можно запускать, так же как и junit тест. Собственно весь testdroid и построен на основе robotium.
    Так же его плагин позволяет нам запускать наши тесты не у себя на машине а в "облаках"