как тестировать приложение на iphone

Инструменты для A/B-тестирования iOS-приложений

A/B-тестирование мобильных приложений

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

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

Перед нами стояла задача сравнить как текстовые варианты переменных (тексты ошибок, подсказок), так и изменение интерфейса приложения (например, наличие бокового меню и таббара). Из этого исходили при составлении нашего шорт-листа инструментов для A/B-тестирования. Все сервисы, о которых пойдет речь дальше, предоставляют SDK для iOS и Android, c Windows Phone сложнее, в этом случае использование сервисов возможно через HTTP-запросы.

Apptimize

При создании вариантов есть возможность выбрать базу пользователей для тестирования.

Фреймворк позволяет логировать события:

Также возможна агрегация событий других сервисов аналитики: Google Analytics, Mixpanel, Flurry, Localytics, Omniture.

Цена и количество пользователей: есть ограниченная бесплатная версия, 300$/месяц до 100 000 пользователей, выше — не указано.

Optimizely

Как видим, возможности c Apptimize идентичные. На первый взгляд, визуальный редактор Optimizely чуть менее функционален. Optimizely возможно интегрировать с Fabric, но сервис имеет достаточно скудный инструмент для аналитики.

Цена и количество пользователей: цены не указаны, есть ограниченная бесплатная версия.

Mixpanel

Переменные в Mixpanel называются твиками (tweaks). Для получения твика используется макрос MPTweakValue:

Есть биндинг значений для изменения параметров на лету:

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

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

Визуальный редактор есть, но работает не очень стабильно и часто «отваливается».

Цена и количество пользователей: можно выбрать вариант по количеству пользователей, либо по количеству событий за месяц. Например, 100 000 пользователей обойдутся в 250$, или за 350$ 2 миллиона событий.

SplitForce

Здесь есть работа с блоками:

И возможность отслеживать время событий:

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

Цена и количество пользователей: цены сопоставимы с прочими сервисами, например, 369$ за 150 000 пользователей.

Amazon

Главным преимуществом перед аналогами является его бесплатность. Для того, чтобы использовать функциональность A/B-тестирования от Amazon, необходимо добавить в проект фреймворк Amazon Insights.

SDK предоставляет только «ручной» режим работы с проектами A/B тестирования:

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

Источник

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

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

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

Для удобства я выложил готовое приложение на гитхаб.

Модульные тесты

Для написания модульных тестов я использую замечательный инструмент — Cedar.
Он позволяет писать тесты в стиле RSpec, что улучшает структурированность и читабельность кода.

На гитхабе дано достаточно полное описание того как собрать фрэймворк, но когда встал вопрос сборки на нескольких машинах, был написан простой скрипт на bash’е, который выполнял всю эту рутину.

Для установки необходимо склонировать проект и запустить скрипт install.sh, Cedar будет установлен в /opt/cedar и будут добавлены символические ссылки в домашнюю директорию пользователя (для большего удобства при подключении в проекты).

Давайте напишем первый тест.
Создайте в UnitTests target файл FooBar.mm с таким содержанием:

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

Вернемся к калькулятору. Допустим у нас будет какой-нибудь класс-синглтон, который будет заниматься вычислениями, назовем его CalculationManager. У него должен быть метод который должен возвращать инстанс этого класса, назовем его sharedInstance.
Напишем тест на этот кейс.
Создайте пустой класс CalculationManager в вашем главном target’е и добавьте еще один файл для тестов (к примеру CalculationManager.mm) с таким содержимым:

При запуске видно что тест валится.
Добавьте реализацию чтоб тест проходил успешно и продолжим.

Добавим пару тестов на операции сложения и вычитания.

На этом все, будем считать что прилжение достаточно покрыто модульными тестами, и перейдем к тестированию интерфейса.

Тестирование интерфейса

Существует немало средств для тестирования интерйеса iOS приложений, но я хочу рассказать о тех которыми пользуюсь сам, а именно Calabash-iOS и Frank.

Эти инструменты очень похожи, они оба позволяют писать тесты на Cucumber’е и оба реализованы на Ruby, разница лишь в функционале.
В одном из проектов мне пришлось мигрировать с Frank’а, я просто запустил тесты с использованием Calabash’а и все они прошли почти сразу, пришлось только немного изменить пару шагов.

Сейчас я остановился на Calabash. Думаю что многие iOS разработчики не знакомы с Cucumber, потому и хочу немного рассказать как он работает и как писать тесты.

Cucumber

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

Итак, в Cucumber’е есть несколько главных «сущностей»:

Feature — это набор нескольких связанных по логике сценариев (или не связанных, уж как программист решит). Она состоит из названия и краткого, информативного описания. К примеру:

Scenario — конкретный сценарий описывающий некоторый use case. Состоит из имени и набора шагов.

Step — описание конкретного действия пользователя (нажатие на кнопку/ссылку, ввод текста, свайп и.т.п).

Step definition — реализация конкретного действия пользователя. Выглядит она примерно так:

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

Давайте добавим Calabash в наш проект.
Перейдите в деректорию с проектом и выполните следующие команды:

Calabash добавил к нашему проекту еще один таргет, по умолчанию он имеет шаблон project_name-cal. Нам необходимо выполнить build для этой цели.
Теперь мы почти готовы запустить тесты.
После генерации выводится подсказка как запустить тесты

но на выполнении этой команды все валится, т.к. calabash не знает где находится наше приложение. Для этого необходимо указать еще одну переменную — APP_BUNDLE_PATH. По умолчанию Xcode 4.x хранит приложения по адресу

Теперь все должно пройти хорошо.

Guard

Такой способ не очень удобен, но он вполне оправдан, т.к. calabash не может знать где лежит наше приложение. И тут нам на помощь приходит Guard.
Guard — это гем, который следит за файловой системой и при изменении файлов, за которыми он следит выполняет какие-либо операции. Список guard’ов довольно обширный, но нам нужен guard-calabash-ios.

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

Это создаст Guardfile — файл в котором описаны свойства необходимые guard’у и файлы за которыми нужно следить. (Детальные настройки можно найти на гитхабе.)
Последний штрих — откройте настройки Xcode и установите Derived Data как Relative. Теперь Xcode будет хранить сборки в директории с проектом, что позволит скрипту из guard-calabash-ios найти нужный нам APP_BUNDLE_PATH автоматически.
Теперь для прогона тестов необходимо выполнить в папке с проектом следующее.

Пишем тесты

Теперь когда все работает более удобно мы можем приступить к написанию наших UI-тестов.

Calabash создал папку features, в которой находятся наши сценарии и реализация шагов.
Давайте удостоверимся что наш калькулятор позволит пользователю сложить или вычесть два числа, и показать верный результат в alert view.

Отредактируйте файл my_first.feature

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

Итак, все тесты провалились, что логично.

Давайте добавим UI.

Для доступа к контролам из calabash’а нужно задать им accessibility label. Кроме того к кнопкам можно обращаться по надписи на них, а к текстовым полям по плэйсхолдеру.

Я сделал примитивный интерфейс: два текстовых поля и две кнопки в navigation bar’е, «+» и «-«.
После того как мы добавили контролы на наш экран нам нужно выполнить следующие действия:

1. Добавить outlet’ы для кнопок и текстовых полей
2. Задать плэйсхолдеры нашим текстовым полям «left» и «right»
3. Задать accessibility label’ы для кнопок

5. Добавить метод для отображения результата

6. Перейдите в терминал с запущенным guard’ом и нажмите Enter, это запустит все ваши сценарии, у нас он один и если вы все сделали правильно, то тесты пройдут успешно.

Теперь напишем тест для вычитания.

После запуска Cucumber сообщит что не знает таких шагов, и предложит их реализовать.
Скопируем и немного подредактируем то что он вывел в файл calabash_steps.rb (project_dir/features/steps_definitions/)

В реальной жизни мы скорее всего использовали бы теже методы что и в первом сценарии, но здесь я хотел показать как выглядят step definitions, как вызывать другие шаги из реализации шагов(step %<>), как добраться до какого-либо значения (query) и как писать assert (should).

На этом по тестам все.

Заключение

Описанные тесты и приложение выглядят совершенно нелепо, но я ставил своей целью описать на этом примере основные возможности, которые позволят сразу начать использовать TDD/BDD, надеюсь что это у меня вышло и для статья окажется полезной.

Источник

Системы тестирования iOS-приложений

С чего все начинается

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

Доставка приложения тестерам

Тестеру необходимо, чтобы разрабатываемое Вами приложение было установлено на его устройстве. Как правило, делаете всю предварительную работу Вы сами: в лучшем случае Вы настроили автоматическую сборку c AdHoc-сертификатом, тестер в час X скачивает сборку и устанавливает ее на свое устройтво путем синхронизации через iTunes или с помощью Configuration Utility. В худшем случае Вы сами отправляете сборку письмом или загружая на определенный ресурс.

Тестирование

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

Доработка

Прочитав все, что создано после этого в баг-треккере, Вы приступаете к исправлению. И процесс повторяется до тех пор, пока вы все не исправите.

Проблемы такого подхода

На первом этапе проблемы — это все что находится между вашим финальным коммитом в репозиторий до установки приложения на устройство тестера. Ручные скачивания тестерами сборок, синхранизация с айтюнсом, установки через Configuration Utility, — все это рутина, которую нужно убрать.

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

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

Что поможет?

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

К основным таким решениям на данный момент можно отнести TestFlight и HockeyApp.

Как начать работу

Тестерам в час X приходит письмо:

Нажав на Install, тестер начинает процесс установки приложения с сервера, после чего может начинать свою работу.

Пример того, что Вам нужно добавить в Ваш исходный код для минимальной и необходимой работы TestFlight:

Это все. Вам необходимо это вставить в метод UIApplicationDelegate:

Отличие систем

По упоминаниям в сети, пожалуй, самая популярная система — TestFlight. Но HockeyApp имеет ряд преимуществ перед TestFlight:

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

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

Впервые столкнувшись с такими системами, люди обычно разводят руками и говорят: «Магия».

Источник

Запуск и тестирование своих iOS-приложений на устройстве без аккаунта разработчика и без Jailbreak

Были различные варианты решения этой проблемы от установки на устройство Jailbreak до недорогого варианта добавления UDID устройства к реально существующему аккаунту разработчика. (Последний способ стоит 300 руб). Но как написано выше с выходом XCode 7 эта проблема была решена.

Так что же нужно для запуска своих приложений на реальном устройстве?

Все что вам нужно, это Apple ID! Больше ничего не нужно.

Подключение устройства

Подключите iPhone, Ipod Touch, или IPad к вашему Mac с помощью кабеля USB кабеля. В меню Xcode зайдите Window → Devices, чтобы открыть список устройств. Окно выглядит следующим образом (я использую iPad Air):

В левой панели окна Xcode находится список устройств, которые могут быть использованы для запуска разработанных приложений. Нажмите на изображение вашего устройства, чтобы выбрать его. Если устройство используется впервые вместе с Xcode, вы увидите сообщение что-то вроде, «“iPad is not paired with your computer.«

Для того чтобы связать устройство с Xcode вам нужно разблокировать устройство (Slide to unlock). После разблокировки, на экране устройства появится сообщение с просьбой доверять этому компьютеру. Нажмите «Разрешить» чтобы продолжить. Теперь Xcode выведет страницу, на которой напишет что позволяет использовать устройство для тестирования.

Дайте ему несколько минут — если процесс занимает слишком много времени, возможно потребуется отсоединить устройство и подключить его снова. Есть вероятность, что выскочит сообщение об ошибке: «An error was encountered while enabling development on this device.» Потребуется отключение устройства и перезагрузка его. Также перезапустите Xcode, прежде чем вы снова подключите устройство.

Так должно выглядеть окно с сопряженным устройством:

Настройка AppleID

Теперь, когда устройство сопряжено с компьютером, нужно связать ваш AppleID с Xcode. Можно использовать тот же идентификатор AppleID, что вы уже используете с Itunes и вашим устройством, однако, если вы разрабатываете корпоративное iOS приложение, то можете создать новый AppleID, чтобы разделить процессы разработки. Конечно, если у вас уже есть оплаченный аккаунт разработчика вы должны использовать именно его

Нажмите кнопку «+» внизу и выберите «Add Apple ID«. Xcode попросит логин и пароль от AppleID. Введите их и нажмите «Add«. Xcode проверит ваши данные и добавит их к списку аккаунтов.

Примечание: возможно Xcode не сможет использовать ваш Apple ID при условии, если он был ранее был использован как аккаунт разработчика, срок действия которого в настоящее время истек. Простейшим решением в этом случае является создание нового Apple ID. Это бесплатно и займет всего несколько минут. https://appleid.apple.com

Настройка проекта XCode

Вы все еще должны указать Xcode использовать эту учетную запись при создании вашего приложения. Перейдите к экрану настроек проекта и на вкладке General нажмите на Team, чтобы выбрать ваш Apple ID.

Ниже поля выбора команды вы видите предупреждение, «No code signing identities found» или «No matching provisioning profiles found«. Не лишним будет знать, что означают эти предупреждения. Для того чтобы Xcode мог запустить приложение на вашем iPhone, iPad или iPod, приложение должно быть подписано цифровой подписью с сертификатом на разработку (Development Certificate). Сертификат является электронным документом, который идентифицирует вас как разработчика iOS приложений и действует только в течение ограниченного периода времени. Приложения, которые вы хотите представить в App Store должен быть подписаны другим сертификатом «Distribution Certificat». Для использования Distribution Certificat необходимо быть членом платной программы разработчиков, однако использование сертификата разработки (Development Certificate) является бесплатным. В дополнение к действующему сертификату также необходим так называемый профиль обеспечения (Provisioning Profile) для каждого приложения которое вы разрабатываете. Xcode использует эти документы чтобы подписать приложение для запуска на вашем устройстве.

Специфика данных документов на первоначальных этапах разработки не имеет значения. Просто примите, что вам нужен Provisioning Profile или приложение не будет работать на вашем устройстве. Создание сертификатов и Provisioning Profile, в XCode 7 это очень простая задача!

Нажмите кнопку Fix Issue. Нужно немного подождать пока Xcode автоматически регистрирует устройство с вашей учетной записью, создает новый сертификат разработки, загружает и устанавливает Provisioning Profile на ваше устройство. Раньше вы должны были бы сделать это все вручную, но теперь Xcode 7 берет всю работу на себя. В этот момент возможно вы увидите следующее сообщение об ошибке:

Идентификатор пакета Bundle Identifier — это идентификатор приложения и он должен быть уникальным. Если какое либо другое другое приложение уже использует этот идентификатор, то вы не можете его использовать.

Поэтому для 100% уникальности следует указывать собственное доменное имя для Bundle ID, например ru.proswift.TestApp. Исправить эту ошибку легко: измените Bundle Identifier и повторите попытку.

Также возможно вы получите эту ошибку:

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

В основном окне XCode еще раз выберете ваше устройство и нажмите кнопку Fix Issue и предупреждение должно исчезнуть.

Настройка связки ключей

Все настроено и готово к работе. Нажмите Run, чтобы скомпилировать и запустить приложение. В этот момент вы можете получить всплывающее окно с вопросом «codesign wants to sign using key … in your keychain». Если вышло это сообщение, нажмите Always Allow — т.е. разрешать всегда. Это сообщение говорит о том, что Xcode пытается использовать новый сертификат разработки, который вы только что создали, но просит дать ему разрешение для этого.

Ваше приложение заработало на устройстве без аккаунта разработчика и без Jailbreak? Потрясающие! Если нет, то читайте дальше …

Возможные проблемы и их решение

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

Устройство не подключено.

Как ни странно это самая распространенная ошибка, поэтому я напишу о ней в третий раз в этой статье. Убедитесь, что ваш iPhone, iPod Touch, или iPad подключены к Mac. Устройство должны быть списке устройств Xcode, и на нем не должно быть желтого значка предупреждения, о том что устройство не доверяет компьтеру.

Подозрительный не одобренный Apple разработчик.

Устройство заблокировано.

Если на устройстве установлен пароль, то вы можете получить это предупреждение:

Приложение не будет работать если устройство заблокировано. Для решения нужно разблокировать устройство и запустить компиляцию еще раз.

С нетерпением жду комментариев и критику статьи.

Источник