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

BeePOS LLC  |   |  9 мин чтения

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

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

Почему команды поддержки держат более одного телефона Android

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

Цель не в том, чтобы владеть каждой моделью. Задача состоит в том, чтобы обеспечить достаточное освещение, чтобы быстро ответить на три вопроса: может ли команда воспроизвести отчет, какое условие вызывает его, и какие доказательства позволят продолжить разработку, не повторяя весь разговор о поддержке? AWS Device Farm также идентифицирует представителей службы поддержки клиентов наряду с разработчиками и командами QA и описывает взаимодействие с реальными устройствами как способ отладки и воспроизведения проблем клиентов.

  • Аутентификация, оплата, уведомление, разрешение, камера, Bluetooth и сбои фонового процесса.
  • Макеты, которые разбиваются на определенную плотность экрана, масштаб шрифта, язык или режим навигации.
  • Проблемы с обновлением или установкой, связанные с выпуском Android или прошивкой производителя.
  • Проблемы, которые появляются только после изменения сети, фона приложения, ограничения батареи или прерывания.
  • Клиент сообщает, что перед эскалацией требуется скриншот, короткая запись, детали устройства и точные шаги воспроизведения.

Соберите минимальные данные перед выбором телефона

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

Полевое полеПочему это важноДопустимые доказательства
Версия приложения и сборкаПодтверждает проверенное программное обеспечениеПро экран, версию магазина или идентификатор сборки
Модель телефона и версия для AndroidВыберите ближайшее реальное устройствоНастройки скриншота или диагностического текста
Точное начальное состояниеПредотвращение скрытых различий в настройкахПодписанное состояние, разрешения, флаги функций и предварительный экран
Шаги и ожидаемый результатДелает отчет воспроизводимымПронумерованные шаги плюс то, что должно было произойти
Реальный результат и срокиРазделяет визуальные, аварийные, сетевые и задержки отказовСкриншот, короткая запись, временная метка или текст ошибки
Сеть, язык и регионОбнаружены экологические условияWi-Fi / мобильное состояние, местоположение, часовой пояс и рынок
частотаРуководители повторяют счетВсегда, прерывистый, первый запуск или после длительного простоя

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

Создайте матрицу небольшого устройства из доказательств клиентов

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

  1. Экспорт лучших моделей устройств и версий Android из надежных данных о продукте.
  2. Группы аналогичных устройств от производителя прошивки, уровня производительности, характеристик экрана и генерации ОС.
  3. Выберите наименьший физический набор, который охватывает наибольшую долю важных случаев.
  4. Добавьте модель только тогда, когда билеты или риск продукта оправдывают ее стоимость обслуживания.
  5. Просмотрите матрицу ежеквартально и удалите устройства, которые больше не представляют значимого трафика или риска.

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

Организуйте службу поддержки нескольких телефонов

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

Управление несколькими Android-телефонамииз общего рабочего пространства, когда команде необходимо сравнить экраны, переместить между устройствами или повторить этап авторизованной настройки. вLaiCai Screen MirroringУстройства могут быть видны с одной рабочей станции Windows или macOS, поэтому оператор тратит меньше времени на сбор телефонов и больше времени на сравнение состояния корпуса. Группировка полезна для разделения чистых исходных линий, активных корпусов поддержки, устройств низкого класса и телефонов, ожидающих сброса.

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

Пропуск контролируемой репродукции

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

  1. Создайте карту с телефонным кодом, сборкой приложений, типом учетной записи, сетью, локализацией и стартовым экраном.
  2. Воспроизводите точные шаги клиента на ближайшем соответствующем телефоне.
  3. Повторите тот же путь на известном хорошем базовом телефоне.
  4. Измените только одно предполагаемое состояние и пройдите путь снова.
  5. Остановитесь, когда триггер изолирован или согласованный предел попытки достигнут.
  6. Запишите как успешные, так и неудачные попытки; отрицательные доказательства сужают следующее расследование.

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

Создание пакета доказательств инженерия может воспроизводить

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

артефактВключатьизбегать
Резюме делаОдно предложение, описывающее неудачу и влияние на бизнесРасшифровка чата без заключения
окружающая средаТелефонный код, модель, версия Android, сборка приложений, локализация и сетьНепроверенные догадки о телефоне клиента
ШагиПронумерованные действия из определенного начального состоянияШаги, такие как «использовать приложение обычно»
Визуальное доказательствоОдин сфокусированный снимок экрана или короткая записьДлинные записи, содержащие несвязанные экраны
ЛогсСоответствующий временной диапазон и идентификаторыПолные журналы, содержащие секреты или несвязанные данные о клиентах
сравнениеРезультат на пораженном телефоне и базовом телефонеСпецифика устройства после тестирования только одного телефона
Показатели воспроизводстваПопытки и наблюдаемые неудачиНеподтвержденное заявление, такое как «случайно происходит»

Файлы имен с идентификатором билета, кодом телефона, сборкой и меткой времени. Передача должна позволить инженеру понять сбой в течение нескольких минут, не открывая несколько потоков чата. Для более широкого рабочего процесса QA см.Отзеркаливание экрана Android для тестирования мобильных приложений.

Выберите местные телефоны, эмуляторы или сервис облачных устройств.

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

окружающая средаЛучшее дляОсновное ограничение
эмуляторБыстрая настройка, ранние проверки пользовательского интерфейса, повторяемые виртуальные конфигурацииНе может воспроизвести каждое аппаратное обеспечение, прошивку, датчик, тепловое или несущее поведение
Местный телефонный столЧастые интерактивные кейсы, демонстрации поддержки, повторяющиеся модели, рабочие процессы USB / Bluetooth / камерыОграничено устройствами, которыми владеет и поддерживает команда
Облачный сервис реального устройстваРедкие модели, широкий охват релизов, параллельные автоматизированные запуски, удаленные командыСтоимость сеанса, доступность, правила обработки данных и меньший физический доступ
Репродукция с помощью клиентаУсловия, которые существуют только в среде клиентаТребует тщательных инструкций, согласия и строгой минимизации данных.

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

Защита данных клиентов при воспроизведении

Устранение неполадок в реальном устройстве может раскрыть личную информацию, если процесс небрежен. Используйте синтетические учетные записи и данные тестирования по умолчанию. Если производственные данные действительно необходимы, получите правильную авторизацию, ограничьте доступ, захватите только то, что нужно в случае, и следуйте политике хранения компании. AWS также предупреждает пользователей об отказе от ввода учетных данных, личной информации или других конфиденциальных данных, поскольку сеансы могут создавать журналы и видео.

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

Пилотируйте рабочий процесс с помощью трех телефонов

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

  1. Выберите десять недавних билетов, которые были задержаны из-за неопределенности устройства.
  2. Определите необходимые поля приема и один шаблон пакета доказательств.
  3. Подготовьте три телефона с чистыми тестовыми аккаунтами.
  4. Отслеживайте время до первого значимого воспроизведения, прояснения, принятия эскалации и нерешенных пробелов в устройствах.
  5. Проверьте, какой телефон или состояние окружающей среды действительно изменили результат.
  6. Расширяться только тогда, когда доказательства показывают неоднократный разрыв в охвате.

Результат проверки прост: инженер поддержки должен иметь возможность получить чехол, выбрать подходящий телефон, воспроизвести путь и доставить автономную передачу без поиска нескольких несвязанных систем. Если совместное рабочее пространство поможет пилоту,LaiCai Screen MirroringВыбранные телефоны Android могут быть видимыми и управляемыми с одного компьютера Windows или macOS.

Часто задаваемые вопросы

Сколько телефонов на Android нужно команде поддержки?

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

Должна ли поддержка воспроизводить каждый отчет клиента?

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

Может ли синхронизированное управление воспроизводить ошибку на каждом телефоне одновременно?

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

LaiCai заменит платформу управления мобильными устройствами

Нет.LaiCai Screen MirroringЭто локальный инструмент визуального контроля и рабочего процесса. Распределенные корпоративные парки, которые нуждаются в регистрации с нулевым касанием, обеспечении соблюдения политики, распространении приложений, инвентаризации или удаленной стирке, должны использовать соответствующую систему MDM или EMM.

Источники

Скачать бесплатную версию

Предыдущая версия 4.4.0: macOSWindows EXE

Примечание: поддерживается только зеркалирование экрана Android.