Узнайте, когда в автоматизации Android следует использовать селекторы пользовательского интерфейса, оптическое распознавание текста, сопоставление шаблонов или обнаружение объектов, а также как безопасно остановиться, если визуальные доказательства неясны. LaiCai Screen Mirroring.
Визуальная автоматизация начинается с решения, а не с нажатия
Автоматизация Android становится хрупкой, когда рабочий процесс предполагает, что следующая кнопка всегда находится в одной и той же координате. Экраны мобильных устройств меняются в зависимости от размера устройства, языка, масштаба шрифта, состояния клавиатуры, разрешений, синхронизации сети и обновлений приложений. Более безопасный рабочий процесс сначала наблюдает за текущим экраном, выбирает доказательства, проверяет, достаточно ли хорош результат, и только затем выполняет действие. Этот шаблон «наблюдение-выбор-действие» является основой автоматизации визуального пользовательского интерфейса.
В LaiCai Flow узлы наблюдения, такие как анализ пользовательского интерфейса, поиск пользовательского интерфейса, распознавание текста, сопоставление шаблонов и обнаружение объектов, не щелкают сами по себе. Они возвращают структурированные результаты. Отдельный шаг данных может выбрать лучший элемент, а шаг указателя может коснуться его центра. Такое разделение делает график доступным для просмотра и предотвращает возможность незаметного превращения результата распознавания в действие.
Для LaiCai Screen Mirroring полезным обещанием не является идеальное распознавание. Это видимый рабочий процесс автоматизации Android, в котором команды могут проверять снимки экрана, результаты распознавания, пороговые значения, журналы, ветки и условия остановки, прежде чем повторять задачу на авторизованных устройствах или эмуляторах.
Выбирайте селекторы пользовательского интерфейса перед распознаванием текста, если структура надежна.
Специальные возможности Android и иерархия пользовательского интерфейса могут предоставлять текст, описания контента, границы, имена классов и другие структурированные свойства. Когда цель надежно отображается в этой иерархии, селектор пользовательского интерфейса обычно легче поддерживать, чем распознавание текста или сопоставление изображений. Он может оставаться полезным для тем, небольших изменений цвета и различной плотности пикселей.
Начните с проверки текущего дерева пользовательского интерфейса. Найдите стабильный текст или описание контента, затем отфильтруйте или выберите результат перед нажатием. Не думайте, что такая фраза, как «найти видимый текст», всегда должна означать OCR; экранные доказательства должны решить. Структурированный селектор предпочтительнее, если приложение предоставляет осмысленную структуру.
У селекторов все еще есть ограничения. Представления Canvas, игры, потоковые поверхности, пользовательский рендеринг и некоторые WebView могут представлять мало полезной иерархии. Переведенные метки также меняются. Когда цель видна человеку, но отсутствует в дереве пользовательского интерфейса, OCR или распознавание изображений становятся разумным запасным вариантом, а не первым инструментом по умолчанию.
Используйте OCR, когда текст виден, но селекторы недоступны.
OCR полезен, когда деловое значение передается видимыми словами: статус заказа, локализованная метка, сообщение с подтверждением, баннер ошибки, цена, имя тестовой учетной записи или результат поиска. Flow может захватить экран, прочитать ограниченную область или полный кадр, нормализовать результат и сравнить его с ожидаемым текстом, прежде чем продолжить.
OCR является вероятностным. Мелкие шрифты, сжатие, градиенты, анимация, необычные сценарии, низкий контраст и перекрывающиеся элементы управления могут снизить точность. Фиксированная область также может не попасть в цель при изменении макета, ориентации, клавиатуры или языкового стандарта. Таким образом, LaiCai рассматривает повторно используемые области OCR как явные активы; создание фиксированной области требует от пользователя понимания этого позиционного предположения.
Надежная проверка записывает как распознанный текст, так и снимок экрана, использованный для его создания. Используйте правило минимальной уверенности там, где оно возможно, принимайте небольшой набор допустимых вариантов и останавливайтесь, указывая удобочитаемую причину, когда требуемый текст отсутствует. Никогда не преобразуйте результат оптического распознавания символов с низкой достоверностью непосредственно в деструктивную информацию.
Используйте сопоставление шаблонов для стабильных визуальных целей.
Сопоставление шаблонов подходит, когда стабильная визуальная цель не имеет надежного текста или переключателя пользовательского интерфейса: отличительного значка, значка, элемента управления игрой, пользовательского графического подтверждения или кнопки, состоящей только из изображения. Шаблон должен быть взят из реального захваченного экрана, а Flow должен ссылаться на существующий ресурс, а не придумывать файл или цель.
Качество сопоставления зависит от качества обрезки, масштаба, темы, цветового режима, анимации и региона поиска. Плотный шаблон может быть заметным, но хрупким; широкий урожай может включать в себя изменение содержания. Команды должны тестировать более одного реалистичного состояния устройства и поддерживать достаточно высокий порог, чтобы избежать несвязанных совпадений, не делая при этом нормальные вариации невозможными.
Текущий контекст ресурса LaiCai подтверждает, что шаблоны являются именованными ресурсами, которые можно повторно использовать, и что сопоставление поддерживает область поиска по оценке, режиму и соотношению экрана. В статье не утверждается, что везде работает один шаблон. Темный режим, локализация, адаптивный макет или редизайн могут потребовать селектора, другого шаблона или намеренной остановки.
Обнаружение объектов решает другую проблему.
Обнаружение объектов не является более мощной версией OCR. Он отвечает на другой вопрос: где находится экземпляр обученного класса, например человека, транспортного средства или объекта, специфичного для продукта? OCR извлекает текст; сопоставление шаблонов ищет визуальное сходство; обнаружение находит классы, определенные моделью.
Используйте обнаружение только в том случае, если доступная модель содержит класс, необходимый рабочему процессу. Поток должен читать метаданные модели и список классов, а не угадывать метки. Выходные данные обнаружения по-прежнему требуют логики выбора — например, наивысшая достоверность, ближайший центр или все элементы выше порогового значения — перед любым действием указателя.
Для обычных кнопок приложений селекторы пользовательского интерфейса, OCR или шаблоны часто проще. Обнаружение становится полезным для переменных объектов, внешний вид или положение которых меняется. Он по-прежнему должен оставлять доказательства и останавливаться, когда достоверность, класс или количество не соответствуют ожиданиям рабочего процесса.
Создание безопасного потока наблюдения-выбора-действия
Безопасный поток можно выразить в виде шести видимых этапов: захват состояния, проверка структуры пользовательского интерфейса, выбор подходящего метода распознавания, выбор результата, проверка достоверности или бизнес-значения и действие. После действия подождите, пока экран стабилизируется, и снова наблюдайте.
Рассмотрите возможность проверки качества локализации. Откройте промежуточную сборку, дождитесь главного экрана, перейдите с помощью стабильных селекторов, сделайте снимок переведенного экрана, запустите распознавание заголовка, сохраните снимок экрана и остановитесь, если ожидаемая локализованная фраза отсутствует. Поток предоставляет доказательства без изменения производственных данных.
Сохраняйте консервативность обработки сбоев. Если поиск пользовательского интерфейса не возвращает элемент, OCR пропускает необходимый текст, оценка шаблона слишком низкая или обнаружение обнаруживает неожиданное количество, позвольте потоку завершиться неудачей или перейдите к четкому пути доказательства и остановки. Не возвращайте ошибку обратно к тому же действию в невидимом цикле повтора.
Устранение неполадок с распознаванием, не скрывая неопределенности.
Если распознавание не удается, сначала проверьте снимок экрана и необработанный результат, а не снижайте каждый порог. Убедитесь, что приложение находится на ожидаемой странице, клавиатура или диалоговое окно разрешений не закрывают цель, ожидание достаточно продолжительное и область поиска содержит элемент.
Для оптического распознавания символов сравните сценарии, пробелы, пунктуацию, заглавные буквы и возможные замены символов. Для шаблонов проверьте масштаб, тему, обрезку и конкурирующие совпадения. При поиске в пользовательском интерфейсе проверьте, находится ли цель за кадром или скрыта в иерархии. Для обнаружения проверьте выбранную модель и ее фактический список классов.
Изменяйте по одной переменной и по возможности повторно запускайте проверку только для чтения. Более низкий порог может увеличить отзыв, но также и ложноположительные результаты. Более крупный регион может найти цель, но будет отвлекать внимание. Правильный результат — это не «узел пройден»; это достаточно убедительное доказательство для следующего одобренного действия.
Практические рабочие процессы для обеспечения качества, локализации и поддержки.
Команды обеспечения качества могут использовать визуальные проверки путей дыма, баннеров ошибок, диалоговых окон согласия, снимков экрана и доказательств выпуска. Группы локализации могут сравнивать заголовки, обрезанные метки, отсутствующие переводы и неожиданный резервный текст на разных устройствах и языках. Группы поддержки могут воспроизвести указанный путь и передать разработчикам снимки экрана и журналы.
Эти рабочие процессы дополняют модульные, инструментальные и интеграционные тесты на уровне кода; они их не заменяют. Визуальные проверки особенно полезны для отображаемого состояния, которое видит человек, тогда как тесты на уровне кода лучше подходят для внутренней логики и детерминированных утверждений.
Используйте обзор инструмента автоматизации AI Android, руководство LaiCai Flow, руководство по зеркалированию экрана Android и рабочий процесс тестирования мобильных приложений в качестве следующего пути чтения.
Контрольный список проверки перед первым реальным запуском
Перед первым реальным запуском убедитесь, что устройство и приложение авторизованы, состояние запуска является явным, а рабочий процесс не угадывает пакеты, активы, координаты или классы модели. Убедитесь, что каждый результат распознавания выбран намеренно и что деликатные действия требуют строгого условия или проверки человеком.
Убедитесь, что снимки экрана и журналы не раскрывают личные данные клиентов. Добавьте явную границу остановки перед оплатой, удалением, настройками учетной записи, исходящими сообщениями или необратимыми производственными изменениями. Избегайте фиктивного взаимодействия, спама, злоупотребления учетной записью, обхода правил, сбора личных данных и мошенничества в играх.
Наконец, посмотрите первый запуск на зеркальном экране Android. Просмотрите график, состояние пользовательского интерфейса, текст оптического распознавания символов, оценки совпадений, выбранные границы, снимки экрана и причину остановки вместе. Надежная система оптического распознавания символов Android и автоматизация распознавания изображений основаны на проверяемых доказательствах, а не на театре доверия.