Часть 6. Тестирование и утверждение магазина приложений

  • Статья

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

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

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

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

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

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

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

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

Тест Центра приложений предоставляет простой способ тестирования приложений iOS и Android на сотнях различных устройств. Дополнительные сведения см. в статье "Подготовка приложений Xamarin.Android" и "Подготовка приложений Xamarin.iOS".

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

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

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

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

Visual Studio App Center предлагает решение этих проблем, предоставляя тестовые версии, отчеты о сбоях и сложные сведения об использовании приложений.

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

Xamarin UITest можно использовать для создания скриптов автоматического тестирования пользовательского интерфейса, которые можно запускать локально или отправлять в тест Центра приложений.

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

Touch.Unit

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

Дополнительные сведения о написании тестов и запуске Touch.Unit см. в документации по модульу Xamarin.iOS .

Andr.Unit

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

Утверждения App Store

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

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

Подготовиться

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

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

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

Качество

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

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

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

Проверка пограничных вариантов

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

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

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

Рекомендации — это больше, чем просто "руководство"

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

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

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

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

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

Реализация функций для конкретной платформы

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

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

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

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

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

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

Магазины приложений: не для всех

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

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

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

Сводка по App Store

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

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