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

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

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

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

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

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

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

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

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

  1. Используя GIT,
  2. Дженкинс
  3. АБР
  4. Сценарий пакетной / командной оболочки.

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

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

  1. Загрузите последний код из GIT. Использует команду git.
  2. Обновите идентификатор версии.
  3. Выполните процесс сборки командной строки Android для создания приложения.
  4. Выполните те же шаги для приложения для тестирования модулей.
  5. Установите оба приложения на устройство или устройства, подключенные к этому серверу.
  6. Запустите тестовое приложение, используя ADB на этих устройствах.
  7. Соберите журнал испытаний модулей (стиль Junit).
  8. Отправляйте журнал всем заинтересованным сторонам.

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

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

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

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

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

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

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

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

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

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

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

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

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