Главная » Разработка для Android » ТЕСТИРОВАНИЕ ANDROID-ПРИЛОЖЕНИЙ – ЧАСТЬ 3

0

Важно получить меленые мобильные телефоны в наше распоряжение как можно раньше. Следующая фраза как нельзя лучше описывает важность тестирования на мобильных телефонах: «Тестировать на эмуляторе полезно. однако тестирование на мобильном устройстве — это необходимость». На самом деле. го. что ваше приложение работает на эмуляторе, не значит практически ничего; пользователи будут запускать приложения на реальных мобильных телефонах.

ВНИМАНИЕ! ___________________________________________________________

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

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

ВНИМАНИЕ! ___________________________________________________________

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

Выполнение автоматизированного тестирования

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

•             журналирование информации в приложении для сбора статистики о его производительности и использовании;

•             использование наборов автоматизироманных тестов построенных на базе среды тестирования JUnit.

ЖУРНАЛИРОВАНИЕ ИНФОРМАЦИИ В ПРИЛОЖЕНИИ

В начале этой книги вы узнали, как реализовать встроенный класс Log (android.util.Log), предназначенный для журналирования информации, чтобы реализовать различные уровни диагностического журналирования. Вы можете наблюдать за журналируемой информацией непосредственно из среды разработки Eclipse или при помощи утилиты поставляемой вместе с инструментарием Android SDK.

ВНИМАНИЕ! ___________________________________________________________

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

АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ С ИСПОЛЬЗОВАНИЕМ СРЕДЫ ТЕСТИРОВАНИЯ JUNIT И СРЕДЫ РАЗРАБОТКИ ECLIPSE

Инструментарий Android SDK включает расширения среды тестирования JUnit для тестирования Android-приложений. Автоматизированное тестирование осуществляется путем написания сценариев тестирования на языке Java, которые проверяют, что приложение работает именно так. как предполагается. Данное автоматизированное тестирование может применяться как для модульного тестирования, так и для функционального тестирования, включая тестирование пользовательского интерфейса.

Этот раздел ни в коем случае не претендует на роль полной документации по написанию сценариев тестирования для среды JUnit. Данной теме посвящено множество книг и онлайн-ресурсов, включая сайт www.junit.org.

ЗНАЕТЕ ЛИ ВЫ, ЧТО… __________________________________________________

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

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

Автоматизированное тестирование Android-приложений подразумевает выполнение нескольких простых шагов:

1)        создание тестового проекта;

2)         добавление сценариев тестирования в новый проект;

3)         выполнение тестового проекта.

Рис. 22.2. Значения по умолчанию, установленные мастером создания текстового проекта в среде разработки Eclipse

В следующих разделах подробно рассматривается каждый из яих шагов на примере тестирования одной из возможностей экрана с настройками приложения «Веси There, Done That!».

СОЗДАНИЕ ТЕСТОВОГО ПРОЕКТА

Вспомните, как в часе 1, когда вы впервые создавали проект в среде paзработки Eclipse, в мастере была доступна возможность создания тестового проекта. Теперь вы воспользуетесь этой возможностью, чтобы быстро добавить необходимый проект и приступить к созданию сценариев тестирования.

Удобно, что возможность создания тестового проекта также доступна и для уже существующих проектов. Чтобы создать тестовый проект для существующего Android- проекта в среде разработки Eclipse, выполните следующие шаги:

1.                                 Выберите команду меню File => New => Project (Файл => Создать => Проект).

2.                                 В появившемся диалоговом окне New Project (Новый проект) разверните элемент списка Android и выберите значение Android Test Project (Тестовый проект Android). Нажмите на кнопку Next (Далее).

3.                                 В группе элементов управления Test Target (Цель тестирования) установите переключатель в положение An Existing Android Project (Существующий проект Android) и нажмите на кнопку Browse (Обзор).

4.                                 В открывшемся диалоговом окне Project Selection (Выбор проекта) найдите проект, который вы хотите протестировать, и выберите его. Мастер автоматически заполнит оставшиеся поля ввода подходящими значениями по умолчанию, как показано на рис. 22.2.

5.                                 Нажмите на кнопку Finish (Готово). В результате будет создан ваш новый тестовый проект.

СОЗДАНИЕ СЦЕНАРИЯ ТЕСТИРОВАНИЯ

Теперь, когда у вас есть тестовый проект, вы можете приступать к написанию сценариев тестирования. Вы создадите сценарий тестирования, который будет проверять поведение поля ввода Nickname (Ник) экрана с настройками, управляемого классом QuizSettingsActivity. Для этого сначала выполните следующие шаги, чтобы создать файл пустого сценария тестирования:

Щелкните правой кнопкой мыши по названию пакета внутри папки src вашего тестового проекта.

В открывшемся контекстном меню выберите команду New => JUnlt Test Case (Создать => Сценарий тестирования JUnit).

В ввода Name (Имя) появившегося диалогового окна New JUnlt Test Case (Новый сценарий тестирования JUnit) введите значение QuizSettingsActivityTests.

В пою ввода Superclass (Суперкласс) введите знамение androld.test.ActivityInstrumentationTestCase2<QuizSettingsActivity>. (Не обращайте внимания на предупреждение «Superclass does not exist* (Суперкласс не существует).)

В поле ввода Class Under Test (Тестируемый класс) введите значение com.androidbook.triviaquiz22.QuizSettingsActivity.

Нажмите на кнопку Finish (Готово).

В только что созданном файле вручную добавьте инструкцию import для класса

QuizSettingsActivity (или организуйте ваши инструкции import)

Наконец, добавьте следующий конструктор в только что созданный класс:

public QuizSettingsActivityTests() {

super("com.androidbook.triviaquiz22", QuizSettingsActivity.class);

}

Теперь, когда файл вашего сценария тестирования готов, вы можете протестировать функ­циональность поля ввода Nickname (Ник) и убедиться, что его значение совпадает со значением ника пользователя, которое хранится в экземпляре класса SharedPreferences, и что это значение обновляется после ввода новой строки. Сначала вы должны изменить метод setup(), чтобы выполнить некоторые общие операции. Вы получаете объект типа EditText для параметра Nickname (Ник), который будет использоваться в двух других тестах. Это делает следующий код:

@Override

protected void setUp() throws Exception { super.setUp();

final QuizSettingsActivity settingsActivity = getActivity(); nickname =

(EditText) settingsActivity.findViewById(R.id.EditText Nickname);

}

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

ActivitylnstrumentationTestCase2, как если бы она запускалась в обычной ситуации.

Обычно также переопределяется метод teardown () . Однако для данных тестов вы не создаете никаких объектов, которые должны были бы удалится после выполнения тестов.

Тесты среды тестирования JUnit должны начинаться со слона test. Таким образом, при написании конкретных тестов вы должны содать мстолм, на звания которых начинаются со слова test и включают описание тестируемой операции. Сначала давайте убедимся, что значение, отображаемое в поле ввода Nickname (Ник), соответствует значению, хранящемуся в экземпляре класса SharedPreferences. Добавьте следующий кол в класс QuizSettingsActivityTests, чтобы реализовать данный тест:

public void testNicknameFieldConsistency() { SharedPreferences settings =

getActivity().getSharedPreferences(QuizActivity.GAME_PREFERENC ES,

Context. MODE_PRIVATE); String fromPrefs =

settings.getString(QuizActivity.GAME_PREFERENCES_NICKNAME, "");

String fromField = nickname.getText().toString(); assertTrue("Field should equal prefs value", fromPrefs.equals(fromField));

}

Первые несколько строк представляют собой стандартный код Android- приложения, который должен быть вам уже знаком. Используя среду тестирования Android, вы можете использовать различные объекты Android- приложения в коде тестов. А вот в последней строке непосредственно выполняется тест. Метод assertTrue() проверяет, действительно ли второй параметр равен значению true. Если это не так, к результатам теста добавляется соответствующая строка. В данном случае сравниваются две строки. Они должны быть одинаковыми.

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

private static final String TESTNICK_KEY_PRESSES = "T E S T N I C K ENTER"; // …

public void testUpdateNickname() { Log. w(DEBUG_TAG, "Warning: " +

"If nickname was previously ‘testnick’ this test is invalid.");

getActivity().runOnUiThread(new Runnable() { public void run() {

nickname.setText(""); nickname.requestFocus();

}

});

sendKeys( TESTNICK_KEY_PRESSES); SharedPreferences settings =

getActivity().getSharedPreferences(QuizActivity.GAME_PREFER ENCES,

Context. MODE_PRIVATE); String fromPrefs =

settings.getString(QuizActivity.GAME_PREFERENCES_NICKNAME,

assertTrue("Prefs should be testnick", fromPrefs .equalsIgnoreCase("testnick"));

}

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

ВНИМАНИЕ! ___________________________________________________________

Чтобы весь тестовый метод выполнялся в потоке, управляющем пользовательским интерфейсом, добавьте аннотацию @UiThreadTest перед реализацией вашего метода. Но стоит отметить, что этот подход не будет работать в продемонстрирован­ном примере, поскольку метод sendKeys() не может выполняться в основном потоке. (В этом случае возникнет исключение «This method cannot be called from the main application thread» (Этот метод не может вызываться из основного потока прило­жения).) Вместо этого в потоке, управляющем пользовательским интерфейсом, могут выполняться лишь части теста, как показано выше.

ВЫПОЛНЕНИЕ АВТОМАТИЗИРОВАННЫХ ТЕСТОВ

Теперь, когда вы написали ваши тесты, необходимо запустить их. чтобы протестировать ваш код. Это можно сделать двумя способами. Первый способ наиболее прост и позволяет видеть удобочитаемые результаты непосредственно в среде разработки Eclipse: для этого просто нужно выбрать команду меню Run => Debug As => Android JUnit Test (Выполнение => Отлаживать как => Тест JUnit Android). На панели Console (Консоль) среды разработки Eclipse отображается ход типовой установки как для тестового приложения, так и для тестируемого приложения (рис. 22.3).

Рис. 22.3. Содержимое панели Console (Консоль) среды разработки Eclipse при выполнении тестов JUnit на платформе Android

ВНИМАНИЕ! ___________________________________________________________

Если тестовый проект не выбран, среда разработки Eclipse может попытаться запустить обычное приложение в качестве тестового приложения JUnit, что приведет к появлению множества предупреждений и ошибок. Чтобы избежать этой проблемы, щелкните правой кнопкой мыши по названию проекта на панели Package Explorer (Проводник пакетов) среды разработки Eclipse и выберите в появившемся контекстном меню команду Debug As => Android JUnit Test (Отлаживать как => Тест JUnit Android). В качестве альтернативы вы можете открыть диалоговое окно Debug Configurations (Конфигурации для отладки) и дважды щелкнуть по элементу списка Android JUnit Test (Тест Android JUnit), чтобы создать новую конфигурацию для тестирования, а затем настроить необходимые параметры.

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

Тем не менее наиболее полезной может оказаться панель JUnit. На этой панели собрана информация обо всех прогонах тестов и о времени, которое занимал каждый прогон, а для каждого обнаруженного сбоя включена трассировка стека. На рис. 22.4 показано, как выглядит эта панель в среде разработки Eclipse.

Рис. 22.4. Панель JUnit в среде разработки Eclipse с информацией о выполненных тестах

Android-приложения

Второй способ выполнения тестов доступен только на эмуляторе. Чтобы воспользоваться данным методом, запустите приложение Dev Tools и в появившемся списке выберите пункт Instrumentation (Средства контроля). Если вы следовали всем нашим инструкциям и не устанавливали никаких других тестов, вероятнее всего, вы увидите в открывшемся списке лишь один элемент android.test.InstrumentationTestRunner. Нажатие на этот эле­мент приведет к запуску тестов. При использовании данного метода единственный способ увидеть результаты (за исключением наблюдения за действиями, происходящими на экране, при тестировании пользовательского интерфейса) — просмотр содержимого панели LogCat.

Описание элемента в списке Instrumentation (Средства контроля) может быть изменено. В файле AndroidManifest.xml тестового приложения измените элемент <instrumentation> следующим образом:

instrumentation

android:targetPackage="com.androidbook.triviaquiz22" android:name="android.test.InstrumentationTestRunner" android:label="TriviaQuiz22 Tests" />

Теперь, когда вы снова запустите приложение Dev Tools и в появившемся списке выберете пункт Instrumentation (Средства контроля), вы увидите на экране указанную метку (атрибут label), а не название тестов.

ДОБАВЛЕНИЕ ДОПОЛНИТЕЛЬНЫХ ТЕСТОВ

Теперь в вашем распоряжении есть все инструменты, которые нужны для добавления дополнительных модульных тестов в ваше приложение Инструментарий Android SDK предоставляет ряд классов, которые мот быть реализованы для выполнения широкого спектра тестов, характерных для платформы Android. Вот некоторые из них:

•     ActivityUnitTestCase — использование данного класса похоже на пример тестирования из предыдущего раздела в том плане, что проверяется деятельность, но на более низком уровне. Этот класс может быть использован для модульного тестирования отдельных аспектов деятельности, например, как она реагирует на событие onPause() после вызова метода onFinished(), и т. п. Это отличный способ протестировать жизненный цикл деятельности.

•    ApplicationTestCase — как и класс ActivityUnitTestCase, ЭТОТ класс позволяет тестировать классы Application в полностью контролируемой среде.

•     ProviderTestCase2 — выполняет изолированное тестирование контент- провайдера.

•     ServiceTestCase — выполняет изолированное тестирование службы.

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

ИТОГИ

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

ВОПРОСЫ И ОТВЕТЫ

Вопрос: Существуют ли какие-нибудь программы сертификации дня Android- приложений?

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

Вопрос: Где я могу найти дополнительную информацию по созданию наборов автоматизированных тестов с использованием среды тестирования JUnit?

Ответ: Посетите веб-сайт, посвященный среде тестирования JUnit, по адресу www.junit.org или прочтите одну из множества книг, посвященных этому вопросу.

ПРАКТИКУМ Контрольные вопросы

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

2.      Что из перечисленного свидетельствует о дефекте или ошибке в прило­жении?

A.                               Запуск приложения занимает слишком много времени.

B.                                Происходит аварийный сбой при входящем звонке.

C.                                Текст на немецком языке содержит очень много символов и не умещается на экране.

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

E.                                Приложение входит в бесконечный цикл при выполнении определенных условий.

F.                                Все вышеперечисленное.

3.                     Верно ли это? Автоматизированное тестирование Апс1г(мс1-приложений может выполняться только на эмуляторе.

4.                     Верно ли это? Среда тестирования JUnit, поставляемая вместе с инструментарием Android SDK, может быть использована для тестирования многих вещей. Что из следующею она не позволяет делать”

A.                    Без устали выполнять одни и те же тесты на протяжении всего дня

B.                    Проводить тестирование на старых устройствах.

C.                    Перемещать мобильный телефон по стране, чтобы проверять сигнал со спутников GPS.

D.                    Тестировать поведение приложения в различных сотовых сетях / в сетях различных операторов.

Ответы

1.                     Верно. Инструментарий Android SDK включает ряд пакетов для разработки наборов тестов для автоматизированного тестирования приложения.

2.                     F. Все это дефекты различных типов — дефекты, связанные с произво­дительностью, интеграцией, интернационализацией, удобством пользования и функциональностью. (А) Приложение, для запуска которого требуется продолжительное время, представляет серьезную проблему в плане производительности, поскольку операционная система Android может завершить его. (B) Большинство устройств, работающих под управлением операционной системы Android, в первую очередь телефоны; приложение должно хорошо взаимодействовать с остальной частью системы, что подразумевает элегантную обработку входящих звонков и текстовых сообщений. (C) Хорошо написанное приложение не будет разочаровывать пользователей, использующих иностранные языки, нестандартным пользовательским интерфейсом. (D) Хорошо спроектированный пользовательский интерфейс — важная составляющая успеха приложения. (E) Функциональный дефект, т. е. проблема в бизнес-логике приложения, — это всегда дефект, независимо от вероятности его проявления.

3.                     Неверно. Автоматизированные тесты могут выполняться на любом устройстве Android, подключенному к компьютеру для отладки.

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

Литература: Дэрси JI., Android за 24 часа. Программирование приложений под операционную систему Google/ ДэрсиЛ., КондерШ. — М.: Рид Групп, 2011. — 464 с. — (Профессиональные компьютерные книги). ISBN 978-5-4252-0318-2

По теме:

  • Комментарии