Создайте рабочий процесс автоматизации поддержки Android, который воспроизводит проблемы приложений, делает снимки экрана и журналы, а также передает полезные данные специалистам по контролю качества или разработчикам. LaiCai Screen Mirroring.
Автоматизация поддержки должна сохранять историю клиента.
Полезный запрос в службу поддержки содержит историю: что клиент пробовал, чего он ожидал, что появилось вместо этого и какое состояние устройства или приложения могло повлиять на результат. Автоматизация поддержки Android должна сохранять эту историю, а не сводить ее к последовательности нажатий. Цель состоит в том, чтобы последовательно воспроизвести одобренный путь и оставить доказательства, которые сможет проверить другая команда.
LaiCai Screen Mirroring использует LaiCai Flow в качестве видимого уровня рабочего процесса. Член группы поддержки может просматривать узлы, наблюдать за экраном Android, делать снимки экрана, вести журналы выполнения и останавливаться, когда наблюдаемое состояние больше не соответствует заявке. Это делает инструмент автоматизации Android с искусственным интеллектом полезным для сбора доказательств, а не для сокрытия решений службы поддержки клиентов в черном ящике.
Всегда следует наблюдать за первым запуском. Проблемы с мобильными устройствами часто зависят от запроса разрешения, клавиатуры, уведомления, анимации загрузки, состояния учетной записи или экрана, который не упоминается в заявке. Просмотр зеркального экрана Android во время чтения журнала потока помогает оператору отличить реальный симптом продукта от неправильного исходного предположения. После того, как наблюдаемый путь станет стабильным и безопасным, тот же контрольный список можно повторить, не теряя при этом доказательств, которые сделали первый запуск понятным.
Превратите заявку в службу поддержки в контрольный список ограниченного воспроизведения.
Перепишите заявку как ограниченный контрольный список перед созданием потока. Укажите стартовый экран, версию приложения, тип учетной записи, состояние сети, языковой стандарт, точные шаги, ожидаемый результат, наблюдаемый результат и точку, в которой рабочий процесс должен остановиться. Запрос типа «страница оформления заказа сломана» слишком расплывчат; «Открыть промежуточную сборку, использовать утвержденную тестовую учетную запись, добавить образец продукта, сделать снимок экрана оплаты и остановиться перед отправкой» — это действенно.
Сделайте первый поток коротким. Воспроизводите только наименьший путь, который может подтвердить или отклонить отчет. Не добавляйте широкие повторные попытки, несвязанную очистку, изменения учетной записи, исходящие сообщения, покупки или деструктивные действия. Узкий контрольный список легче сравнивать на разных устройствах, и его безопаснее использовать для сотрудников службы поддержки.
Запишите среду перед воспроизведением проблемы.
Запишите среду перед первым действием. Полезные поля включают версию Android, модель устройства или профиль эмулятора, размер экрана, версию приложения, языковой стандарт, состояние разрешений, тип подключения, а также то, возникает ли проблема в тестовой или производственной среде. Не угадывайте названия пакетов или сведения об устройстве; прочитайте их из контекста авторизованного устройства, если они доступны.
Свидетельство окружающей среды предотвращает ложную передачу обслуживания. Ошибка, которая появляется только на одной версии Android, языке, состоянии учетной записи или медленной сети, не должна называться универсальной. Добавьте начальный снимок экрана и идентификатор короткого прогона, чтобы последующие снимки экрана и журналы можно было связать с одной и той же попыткой воспроизведения.
Сохраняйте снимки экрана и журналы в точках принятия решения.
Сохраняйте доказательства в точках принятия решения, а не после каждого бессмысленного действия. К положительным моментам относятся состояние запуска, экран непосредственно перед сообщением о сбое, неожиданный экран, баннер ошибки, отсутствующий элемент управления и состояние окончательной остановки. Назовите скриншоты, чтобы инженер по контролю качества мог понять их заказ, не открывая каждый файл.
В журналах должно быть указано, какой шаг был выполнен, какое условие было проверено, какой результат был выбран и почему поток остановился. Избегайте регистрации паролей, токенов, личных сообщений, платежных реквизитов или ненужных идентификаторов клиентов. Снимок экрана и читаемая причина остановки обычно более полезны, чем сотни событий низкого уровня без контекста.
Используйте видимые условия вместо слепого щелчка.
Автоматизация поддержки должна наблюдать, прежде чем действовать. Используйте структуру пользовательского интерфейса, когда существуют стабильные селекторы, распознавание текста, когда необходимый текст виден, но не отображается, и сопоставление изображений только тогда, когда подходит проверенный визуальный ресурс. Узлы наблюдения должны возвращать доказательства; отдельный узел действия можно нажать только после того, как результат соответствует условию рабочего процесса.
Если ожидаемое состояние отсутствует, соберите доказательства и остановитесь. Не нажимайте вслепую на запомненные координаты и не снижайте каждый порог достоверности. Явное ожидание легче просмотреть, чем скрытые паузы, а явный сбой полезнее, чем поток, продолжающийся на неправильном экране.
Защитите данные клиентов на протяжении всего рабочего процесса.
Свидетельства поддержки могут содержать конфиденциальную информацию. По возможности используйте утвержденные тестовые учетные записи. Прежде чем поделиться снимком экрана, проверьте имена, адреса электронной почты, номера телефонов, номера заказов, уведомления, текст чата, местоположение, платежные данные и фоновые приложения. Обрезайте или редактируйте информацию, которая не нужна QA.
Определите правила хранения и доступа для снимков экрана и журналов. Не вставляйте свидетельства клиентов в публичные заявки или широкие чаты. Если для санкционированного расследования необходимы реальные данные клиентов, сведите их к минимуму, запишите, почему они необходимы, и следуйте политике конфиденциальности и удаления данных организации. Автоматизация улучшает повторяемость; он не дает разрешения на сбор дополнительных данных.
Передайте доказательства QA и разработчикам в удобном формате.
Сильная передача содержит исходную сводную информацию о заявке, предварительные условия воспроизведения, среду устройства и приложения, точную версию потока или контрольного списка, снимки экрана по порядку, соответствующие выдержки из журналов, сравнение ожидаемого и фактического результата, частоту воспроизведения и причину остановки. Включите то, что не было протестировано, чтобы отдел контроля качества не принял узкую проверку за широкий охват.
Используйте руководство LaiCai Flow, чтобы обеспечить читаемость шагов графика, руководство по зеркалированию экрана Android, чтобы просматривать тот же экран, который использует Flow, и рабочий процесс удаленного устранения неполадок Android для совместной практики передачи управления. Принимающий инженер должен иметь возможность повторно запустить путь или понять, почему его еще нельзя повторить.
Честно относитесь к результатам, связанным с невозможностью воспроизведения.
«Невозможно воспроизвести» — это результат, а не доказательство того, что клиент неправ. Сравните среду, локаль, разрешения, состояние учетной записи, сеть, флаги функций, сборку приложения и время. Запускайте только согласованные варианты, сохраняйте доказательства для каждого и точно обозначайте результат: воспроизведено, не воспроизведено в проверенных условиях, периодически, заблокировано из-за отсутствующей информации или остановлено в целях конфиденциальности или безопасности.
Если информация отсутствует, попросите предоставить минимальные дополнительные доказательства, которые могут изменить следующий тест. По умолчанию не запрашивайте полноэкранные записи, полные журналы или доступ к учетной записи. Структурированный поток поддержки помогает команде отличить дефект приложения от несоответствия среды, незавершенных шагов, времени или состояния, требующего инженерных инструментов.
Практический контрольный список для групп поддержки.
Перед запуском подтвердите авторизацию, состояние запуска, сборку приложения, тестовую учетную запись, контекст устройства, сеть, языковой стандарт, точки подтверждения, ограничения конфиденциальности и границу остановки. Во время выполнения следите за экраном, используйте явные ожидания и условия и записывайте только доказательства, необходимые для билета. После запуска просмотрите снимки экрана и журналы, прежде чем делиться ими.
Просмотрите пакет доказательств так, как если бы вы были принимающим инженером. Можете ли вы сказать, какой скриншот относится к какому шагу? Отображается ли в журнале невыполненное условие? Ожидаемые и фактические результаты указываются отдельно? Удалены ли личные данные? Идентифицирует ли пакет тестируемую среду и версию Flow? Если на эти вопросы невозможно ответить, повторный запуск автоматизации может привести только к созданию еще более неоднозначных файлов. Короткий, упорядоченный пакет доказательств более ценен, чем большой архив без репродукционного повествования.
Практический результат — улучшение взаимодействия между службами поддержки, контроля качества и разработки. Служба поддержки предоставляет повторяемую историю клиента, отдел контроля качества получает сопоставимые доказательства, а разработчики получают меньший путь с видимым состоянием. Автоматизация поддержки Android работает лучше всего, когда она упрощает анализ неопределенностей и доказательств, а не когда она пытается заменить человеческое суждение.