Как протестировать корпоративное приложение Android на разных устройствах

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

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

Я провел некоторое исследование, и я нашел некоторые автоматизированные инструменты тестирования (например, TestDroid). Кто-нибудь имеет реальный опыт работы с автоматическими инструментами тестирования, такими как TestDroid?

Было бы здорово, если бы кто-то, кто работает в какой-то крупной компании, мог делиться процедурами тестирования, инструментами, советами или рекомендациями, как тестировать корпоративные Android-приложения, когда существует так много устройств с различными версиями ОС, разрешениями и расширениями системы (например, HTC Sense, Samsung TouchWiz).

Спасибо большое, ребята.

ОТВЕТЫ

Ответ 1

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

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

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

  • Используя GIT,
  • Дженкинс
  • ADB
  • Пакет/оболочка script.

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

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

  • загрузите последний код из GIT. использует команду git.
  • Обновить идентификатор версии.
  • Выполнение процесса сборки командной строки для создания приложения.
  • выполните те же действия для приложения unit test.
  • Установите оба приложения на устройство или устройства, подключенные к этому серверу.
  • Запустите тестовое приложение, используя ADB на этих устройствах.
  • Соберите журнал unit test (стиль Junit).
  • Отправляйте журнал всем заинтересованным сторонам.

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

Для тестирования макета/разрешения вы всегда можете сделать снимок экрана с помощью adb или из приложения unit test и прикрепить эти изображения в качестве вложений электронной почты.

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

Ответ 2

Ниже приведена информация о нашем опыте;

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

Существует способ выбора верхних устройств с помощью метода ниже:

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

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

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

Хотя мы решили использовать наши устройства для тестирования, мы пробовали аутсорсинг в прошлом, и есть 3 лучших наших выбора;

Ответ 3

На самом деле, есть много инструментов для автоматического тестирования приложений Android. Взгляните на небольшой обзор самых популярных инструментов, которые используют тестеры Android для автоматического тестирования: http://blog.bughuntress.com/automated-testing/useful-tools-for-android-apps-test-automation. Просматривая их, вы, вероятно, найдете что-то полезное. Все они обычно используются для автоматизации тестирования в крупных компаниях.

Ответ 4

github hook = > Jenkins = > TestFlight отправляет письма в ручные тестеры + запускает тест Robotium с использованием Spoon.

через некоторое время все отчеты передаются PM и команде разработчиков, в случае успеха подписанный apk отправляется на публикацию