Часть 6 — Тестирование и одобрение в App Store

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

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

Тест на всех платформах

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

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

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

Устройства в облаке

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

Xamarin Test Cloud предлагает простой способ тестировать iOS и Android приложения на сотнях различных устройств.

Управление тестированием

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

  • Распространение – Управление подготовкой обеспечения (особенно для iOS-устройств) и получения обновленных версий программного обеспечения для тестеров.
  • Обратная связь — сбор информации об использовании приложений, а также подробную информацию о любых ошибках, которые могут возникнуть.

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

Xamarin Insights Preview предлагает решение второй части этого вопроса, обеспечивая отчетность об авариях и иную сложную информацию об использовании приложения.

Автоматизации тестирования

Xamarin UITest может быть использован для создания автоматизированных сценариев тестирования пользовательского интерфейса, которые могут быть запущены локально или загружены на Test Cloud.

Модульное тестирование

Touch.Unit

Xamarin.iOS включает в себя модульное тестирование под названием Touch.Unit, которое наследует JUnit/NUnit стиль написания тестов.

Обратитесь к документации модульного тестирования в Xamarin.iOS  для написании тестов и запуска Touch.Unit.

Andr.Unit

Существует эквивалент Touch.Unit для Android с открытым исходным кодом под названием Andr.Unit. Вы можете скачать его с github и прочитать об этом инструменте в блоге @spouliot.

Windows Phone

Вот некоторые ссылки для установки модульного тестирования для Windows Phone:

Одобрение в App Store

Apple и Microsoft являются единственным магазином на своих платформах: в App Store и Marketplace соответственно. Оба блокируют свои устройства и осуществляют строгую процедуру проверки приложений, чтобы контролировать качество приложений доступных для загрузки. Открытый характер Android, означает, что существует целый ряд вариантов магазинов приложений, начиная от Google Play, который широко доступен и не имеет никакой процедуры проверки, до Amazon Appstore для Android и конкретно-аппаратных решений, таких как, как Samsung Apps, которые имеют более ограниченное распространение и существующую процедуру утверждения.

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

Подготовка

Первый совет: планировать запуск вашего приложения заранее и сделать запас времени для возможного отказа и повторного представления. Каждый магазин требует от вас, создать учетную запись перед отправкой вашего приложения — сделайте это как можно раньше. В то время как регистрация в Google Play занимает всего несколько минут, если ваши приложения бесплатны. Процесс становится намного сложнее, если вы продаете их и необходимо предоставить банковскую и налоговую информацию. Процесс в Apple и Microsoft  является гораздо более сложным, чем в Google, утверждение вашего аккаунта может занять неделю или больше. Все это нужно учитывать в при планировании запуска распространения приложения.

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

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

Качество

Это кажется очевидным, но приложения часто получают отказ, поскольку они не отвечают определенный уровень качества: в конце концов, это и есть причина, по которой курированные магазины имеют процесс утверждения в первую очередь!

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

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

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

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

Следующий список является хорошей отправной точкой для проверки крайних случаев, которые могут быть пропущены:

  • Пользователи могут «запретить» доступ к услугам – особенно в iOS, доступ к данным, например сведения о географическом положении предоставляется только в случае, если пользователь предоставляет разрешение вашему приложению. Тестеры приложения часто должны повторно установить приложение в своем первоначальном состоянии и запретить любые запросы разрешений, чтобы убедиться, что приложение ведет себя соответствующим образом. Переключайте разрешения приложения, чтобы проверить правильное поведение, если пользователи изменят свое мнение.
  • Пользователи во всем мире — не думайте, что приложение будет использоваться только в городе или стране, где оно было разработано! Код, который работает с GPS координатами, значениями даты и времени и валюты могут быть разными, в зависимости от местоположения и локализации клиента. Все платформы предлагают симулятор, который позволяет указать различные места и локализацию — использовать его для проверки местоположения в других полушариях и с разными культурами, форматами дат и валют. Значения широты и долготы может быть положительным или отрицательным, десятичный разделитель может быть точкой или запятой, и даты можно форматировать множество способов – с этим надо справиться!
  • Медленные сетевые соединения — разработчики приложений часто работают в «идеальном мире» быстрого, всегда работающего подключения к сети, которое, как очевидно, отсутствует в реальном мире. Тестирование с помощью медленного подключения к сети (например, плохое соединение 3G), а также без какого-либо доступа к сети имеет решающее значение для обеспечения того, что бы не приводить к сбоям приложение. Процесс утверждения приложения всегда будет включать в себя испытание с устройством в авиарежиме, поэтому убедитесь, что вы проверили это у себя.
  • Разное оборудование – не забудьте проверить на старом, медленном оборудовании, которое планируется поддерживать. Существует два аспекта, которые могут повлиять на ваше приложение: производительность, которое может оказаться непригодным для использования на старых устройства и поддержка аппаратных функций, таких как камера, микрофон, GPS, гироскоп или другой дополнительный компонент. Приложения должны ухудшать функционал (деградировать) корректно (без сбоев) когда компонент недоступен.

Руководство должно быть больше, чем просто «руководство»

Apple известен тем, что строго следует своим принципам Human Interface Guidelines и в качестве одного из основных преимуществ своей платформы считают последовательность (и ощутимое повышение удобства использования). Microsoft принял аналогичный подход к приложениями Windows, реализующим интерфейс в Metro-стиле. Процесс утверждения для обеих платформ будет включать в себя оценку приложения на соответствия существующей философии дизайна.

То есть нельзя сказать, что инновационный пользовательский интерфейс не поддерживается или не поощряется, но есть определенные вещи, которые вы «просто не должны делать», или ваше приложение будет отклонено.

Для iOS это распространяется на злоупотреблении встроенными значками иконок или использование других, хорошо организованной метафор не последовательно; например, нельзя использовать значок «создать» только для создания нового содержимого.

Разработчики Windows также должны быть осторожны; распространенная ошибка — не должным образом используемая аппаратная кнопка «Назад» в соответствии с рекомендациями Microsoft.

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

Реализация платформо-специфичных возможностей

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

  • Покупки из приложения — приложения НЕ должны реализовывать внешние платежные механизмы для цифровых продуктов, включая игровую валюту, функций приложения, журнал подписки и многое другое. Приложения для iOS должны использовать службы Apple iTunes для этого вида функциональности. Существует лазейка – такие приложения, как Kindle Reader и некоторые другие приложения на основе подписки, которые позволяют приобретать контент в другом месте. «Где то» у пользователя находится его «аккаунт», к которому затем он можете получить доступ через приложение. Однако в этом случае приложение не должно содержать ссылки или «перехода» на процесс покупки вне приложения (или еще раз, оно будет отклонено).
  • iCloud backup – с появлением iCloud, рецензенты от Apple стали гораздо строже относительно того, как приложения используют для хранилище iCloud (для обеспечения удобного удаленного резервного копирования данных пользователей). Приложение, которое не должным образом использует пространство для хранения резервных копий данных приложения может получить отказ, поэтому используйте папку кэша соответствующим образом и следуйте руководящих принципов Apple, связанных с хранением данных.
  • Киоск (Newsstand) – периодические издания приложений, отлично подходит для использования киоска Apple, однако приложениям необходимо реализовать хотя бы автоматическое обновление подписки и поддержку фоновой загрузки для утверждения.
  • Карты – как правило используются возмости добавления пометок и других возможностей для мобильных карт, однако будьте осторожны, чтобы не скрывать информационные «титры» карты (например, логотип Google в iOS5), так как это приведет к отказу.

Управление метаданными

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

  • Изображения – следуйте рекомендациям платформы для значков приложений и хранилища изображений. Не используйте изображения торговых марок, известны случаи, когда приложения были отклонены, потому что их иконки содержат изображения iPhone!
  • Торговые марки — Избегайте использования любых товарных знаков, кроме ваших собственных. Программам было отказано за упоминание товарных знаков в описании приложения или даже в ключевых словах на Apple App Store.
  • Описание – не используйте слово «бета» или каким-либо образом указывайте, что приложение еще не готово к прайм-тайм. Не говоря уже о других мобильных платформах (даже если ваше приложение является кроссплатформенным). Самое главное убедитесь, что приложение делает именно то, что вы говорите. Если вы перечислите несколько функций в вашем описании, то лучше, если бы бытло очевидно, как использовать каждую из этих функций, или вы получите отказ — «функции, упомянутые в описании приложения не реализованы».

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

App Stores:  Не для всех

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

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

Apple предоставляет возможность внутреннего распространения для разработчиков, зарегистрированных в iOS Developer Enterprise Program, которая обходит процесс утверждения в App Store и позволяет компаниям распространять собственные  приложений для своих сотрудников. К сожалению, эта лицензия не учитывает потребности в экстранет для распределение приложений для других закрытых групп клиентов или поставщиков. См. Enterprise (and Ad-Hoc) Deployment

App Store резюме

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


Оригинал статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *