Используйте снимки экрана для полноэкранного отображения, оптическое распознавание текста для видимого текста и сопоставление изображений с известным визуальным объектом. Самые сильные визуальные тесты Android сочетают в себе одно сфокусированное утверждение со стабильным временем и доказательствами ошибок.
Короткий ответ: проверяйте то, что должно оставаться правдой
Используйте тестирование скриншотов, когда весь экран, компонент, интервал, цвет или типографика должны оставаться визуально единообразными. Используйте OCR, когда требуется, чтобы человек мог видеть слова, особенно локализованный или динамически отображаемый текст. Используйте сопоставление изображений, когда известный значок, кнопка, значок или иллюстрация должны появиться, даже если у них нет надежного идентификатора пользовательского интерфейса.
Начните с селектора пользовательского интерфейса или состояния доступности, если требование является семантическим: элемент управления существует, включен, выбран или предоставляет стабильную метку. Добавляйте обнаружение объектов только в том случае, если цель принадлежит визуальному классу и может слишком сильно изменить размер или положение для одного шаблона. Эти методы представляют собой уровни, а не конкурирующие среды тестирования.
- Спросите, какие доказательства могли бы убедить рецензента в том, что требование выполнено.
- Выбирайте самый узкий надежный сигнал вместо сравнения каждого пикселя по умолчанию.
- Прежде чем наблюдать за ним, стабилизируйте экран, а затем сохраните артефакт, если утверждение не удастся.
Сравнение методов визуального тестирования Android
| Метод | Лучшее для | Основная слабость | Полезные доказательства |
|---|---|---|---|
| Состояние пользовательского интерфейса или доступности | Элементы управления, метки, включенное состояние, выбор, структура навигации | Пользовательские или недоступные элементы могут быть невидимы для дерева пользовательского интерфейса. | Иерархия пользовательского интерфейса, выбранные свойства, снимок экрана |
| Скриншот или золотое изображение | Компоновка, интервалы, цвета, типографика, внешний вид компонентов. | Динамические данные, анимация, различия устройств и изменения рендеринга могут создавать шумные различия. | Текущее изображение, утвержденная базовая линия, визуальная разница |
| оптическое распознавание текста | Видимый текст, локализация, квитанции, сообщения о состоянии, значения, отображаемые в виде пикселей. | Качество распознавания зависит от обрезки, масштаба, контрастности, языковых данных, вращения и сегментации. | Исходное кадрирование, распознанный текст, достоверность или список результатов |
| Соответствие шаблону | Известный значок, кнопка, значок, миниатюра или небольшая стабильная область. | Тема, масштаб, сжатие и редизайн могут сделать шаблон недействительным. | Шаблон, регион поиска, лучшее совпадение, оценка, скриншот |
| Обнаружение объектов | Визуальный объект, класс которого остается значимым при изменении положения или размера. | Требуется совместимая модель, помеченные классы, пороговые значения и проверка модели. | Версия модели, класс, коробка, оценка, скриншот |
Официальное руководство Android по тестированию скриншотов описывает сравнение текущего рендеринга с утвержденным эталонным изображением. Плагин изображений Appium обеспечивает сопоставление функций, сопоставление шаблонов и сравнение сходства. OpenCV документирует механизм наложения шаблона на изображение, а Tesseract документирует, почему предварительная обработка OCR и сегментация страниц так важны. Инструменты различаются, но вопрос дизайна теста остается прежним: какое наблюдение подтверждает это требование?
Выберите правильное утверждение, ответив на четыре вопроса.
1. Является ли требование смысловым или визуальным?
Если тест показывает, что «кнопка «Отправить» включена», сначала проверьте состояние пользовательского интерфейса. Если там написано: «Кнопка «Отправить» не обрезается после изменения шрифта», используйте снимок экрана или целенаправленную визуальную проверку. Семантический запрос обычно легче поддерживать, но он не может доказать внешний вид.
2. Имеет ли значение точный текст?
Используйте OCR, когда строка, обращенная к пользователю, является требованием, а текст не отображается надежно через дерево пользовательского интерфейса. Ограничьте распознавание наименьшей значимой областью, выберите правильный язык и сравните нормализованный результат. Сохраните снимок экрана, потому что сама по себе правильная строка OCR не может показать усечение, перекрытие или плохой контраст.
3. Есть ли одна стабильная визуальная цель?
Используйте сопоставление шаблонов для известного значка или небольшого элемента управления. Плотно обрежьте шаблон, выполните поиск внутри интересующей области и установите пороговое значение для реальных положительных и отрицательных образцов. Один универсальный порог редко можно защитить применительно к темам, разрешениям и сжатым удаленным потокам.
4. Должна ли вся композиция оставаться целостной?
Используйте сравнение скриншотов, когда важна взаимосвязь между многими элементами. Управляйте шрифтами, языковым стандартом, конфигурацией устройства, системными панелями, временем, сетевыми данными, анимацией и исходным контентом. Если этими входами невозможно управлять, замаскируйте или обрежьте динамические области вместо того, чтобы принимать тест с постоянным шумом.
Создайте визуальный тест, который провалится с пользой
- Переведите приложение в указанное начальное состояние на авторизованном устройстве или в эмуляторе.
- Дождитесь стабильного состояния, а не просто фиксированной задержки. UI Automator обеспечивает стабильность ожидания, а сигнал готовности для конкретного приложения еще лучше.
- Захватите наименьший исходный регион, содержащий необходимые доказательства.
- Запустите одно основное утверждение: состояние пользовательского интерфейса, распознавание текста, шаблон, обнаружение или сравнение снимков экрана.
- Сохраните исходное изображение и структурированный результат, прежде чем предпринимать следующие действия.
- В случае сбоя остановитесь или следуйте проверенному пути восстановления. Не нажимайте на ближайшего двойника просто для продолжения теста.
Визуальная проверка становится безопаснее, если она разрешает переход. Наблюдайте за текущим состоянием, делайте утверждение, выполняйте разрешенное действие только после успеха и проверяйте постусловие. Это тот же принцип проектирования, который описан в руководствепо автоматическому распознаванию изображений: распознавание не является доказательством завершения рабочего процесса.
Для работы на реальном устройствеЗеркалирование экрана Android для тестирования мобильных приложенийдает проверяющему возможность просмотра в реальном времени во время разработки теста. Руководство по дымовому тестированиюдля автоматизации Androidобъясняет, как сделать повторные проверки узкими и воспроизводимыми.
Три практических сценария визуального тестирования Android
Контроль качества локализации на экране оформления заказа
Используйте состояние пользовательского интерфейса для перехода к экрану оформления заказа, распознавание текста для подтверждения локализованной суммы и метки действия, а также выделенный снимок экрана, чтобы показать, что строки не обрезаны и не перекрываются. Запустите каждую локаль с контролируемыми тестовыми данными. Одно только полноэкранное сравнение пикселей будет слишком чувствительным к длине переведенной строки, а само по себе распознавание текста не приведет к повреждению макета.
Проверка обновленного значка на панели инструментов
Используйте шаблон принятого значка в небольшой области панели инструментов. Сохраняйте отдельные шаблоны, если поддерживаются как светлые, так и темные темы. Если совпадение не удалось, прикрепите обрезку панели инструментов и оценку лучшего кандидата. Если значок намеренно изменен, просмотрите и замените шаблон, а не снижайте пороговое значение до тех пор, пока не будет принята какая-либо форма.
Проверка дыма на реальном телефоне после развертывания
Начните с известного состояния учетной записи и приложения, дождитесь целевого экрана, подтвердите его личность, выполните одно разрешенное действие и проверьте следующее именованное состояние. Делайте скриншоты при каждом сбое. Плотность устройств, диалоговые окна разрешений, клавиатуры, уведомления и обновления системы являются частью реальной среды телефона, поэтому тест должен сообщать о них, а не скрывать их.
Распространенные ложные сбои и как их предотвратить
| Симптом | Вероятная причина | Лучший ответ |
|---|---|---|
| Разница в скриншотах меняется при каждом запуске | Часы, анимация, реклама, начальные данные, клавиатура, системная панель или сетевой контент. | Заморозить входные данные, дождаться стабильности, обрезать или замаскировать только динамическую область. |
| OCR возвращает правдоподобный, но неверный текст | Неправильный язык, низкий контраст, крошечное кадрирование, вращение, шум или неподходящая сегментация. | Сохраняйте кадрирование, улучшайте масштаб и контрастность, обдуманно выбирайте язык и сегментацию. |
| Сопоставление шаблонов работает только на одном телефоне. | Различная плотность, тема, масштабирование, соотношение сторон или сжатие. | Используйте интересующую область и проверенные шаблоны для поддерживаемых визуальных вариантов. |
| Правильное изображение найдено, но нажатие не удается. | Координаты совпадения не были преобразованы в текущий экран или наложение блокирует ввод. | Отделите распознавание от действия и проверьте следующее состояние |
| Тест продолжается на неправильном экране | Нет постусловия или края отказа | Называйте ожидаемые состояния и останавливайтесь, когда текущий экран выходит за пределы просматриваемого пути. |
| Детектор объектов находит неправильный класс | Модель или ярлыки не соответствуют домену приложения, пороговое значение не проверено. | Используйте совместимую модель, записывайте версию и оценку, тестируйте отрицательные образцы. |
Дискуссии сообщества о регрессионном тестировании Android часто возвращаются к одним и тем же затратам на обслуживание: матрицы устройств, нестабильное время, базовый обзор и экраны, содержимое которых меняется. Это не повод отказываться от визуального тестирования. Это причины для того, чтобы сделать тестовую среду, допустимые отклонения и артефакты ошибок явными.
Как LaiCai Flow вписывается в визуальное тестирование
LaiCai Flow— это функция автоматизации внутри LaiCai Screen Mirroring. Поток может сочетать в себе захват снимков экрана, проверки пользовательского интерфейса, распознавание текста, сопоставление шаблонов, обнаружение объектов, условия, действия и явные переходы успеха или неудачи. Это позволяет тестировщику моделировать экран как состояние, а не рассматривать распознавание как изолированный прием.
При использованииLaiCai Flow Insideсовместимый профиль может запускаться через LaiCai Android Agent на телефоне после развертывания. Совместимость по-прежнему зависит от каждого узла и актива, используемого этим профилем. Локальное распознавание текста использует Tesseract; при сопоставлении шаблонов используется выбранный ресурс изображения и настраиваемая оценка; совместимое локальное обнаружение использует поддерживаемую модель. Сетевой узел или удаленная модель по-прежнему нуждаются в собственной сетевой зависимости.
Это не делает каждый визуальный тест автоматически надежным. Командам по-прежнему нужны репрезентативные базовые показатели, шаблоны, регионы OCR, модели, пороговые значения, отрицательные случаи и постусловия. Ценность в том, что эти решения и переходы можно просмотреть в одном рабочем процессе. Руководство по автоматизации AndroidAIпредоставляет более широкий взгляд на разработку и выполнение на реальном устройстве.
Минимальный набор доказательств неудавшегося визуального теста
- Название теста, сборка приложения, модель устройства, версия Android, языковой стандарт, тема и ориентация.
- Исходный снимок экрана или обрезанная область, используемая утверждением.
- Ожидаемое базовое состояние, шаблон, текст, класс или свойство пользовательского интерфейса.
- Наблюдаемая разница, результат OCR, ограничивающая рамка, оценка соответствия или значение пользовательского интерфейса.
- Предыдущее названное состояние, предпринятое действие, ожидаемое следующее состояние и причина остановки.
- Актив, модель или базовая версия, чтобы проверяющий мог воспроизвести решение.
Метка «пройдено/не пройдено» без этого контекста заставляет следующего человека воспроизвести весь цикл. Компактный пакет доказательств превращает сбой в решение, подлежащее проверке: исправьте продукт, стабилизируйте тест, обновите утвержденный визуальный ресурс или отклоните неподдерживаемую конфигурацию устройства.
Часто задаваемые вопросы по визуальному тестированию Android
Должен ли каждый тест пользовательского интерфейса Android включать снимок экрана?
Нет. Используйте скриншоты, когда внешний вид имеет значение или когда артефакт сбоя поможет рецензенту. Семантические утверждения обычно лучше подходят для поведения, которое надежно демонстрирует дерево пользовательского интерфейса.
OCR лучше, чем сопоставление изображений?
OCR отвечает на вопросы о видимом тексте. Сопоставление изображений отвечает на вопросы об известном визуальном образце. Если требование включает в себя как метку, так и ее внешний вид, используйте распознавание текста и проверку сфокусированного снимка экрана или шаблона.
Могут ли скриншоты тестироваться на реальных телефонах Android?
Да, но в реальных устройствах больше вариаций, чем в управляемом рендеринге или эмуляторе на стороне хоста. Запишите конфигурацию устройства, стабилизируйте пользовательский интерфейс и данные системы, а также задайте ожидания для матрицы устройств, которую вы действительно поддерживаете.
Когда мне следует использовать обнаружение объектов?
Используйте его, когда значимый класс объектов выходит за пределы допуска стабильного шаблона или масштабируется, и только тогда, когда совместимая модель проверена на реальных изображениях приложения. Не добавляйте детектор только потому, что это звучит более продвинуто.
Прежде чем выбирать технологию, выберите доказательства
Надежное визуальное тестирование Android начинается с одного предложения: что должен доказать рецензент? Выберите состояние пользовательского интерфейса для семантики, снимки экрана для композиции, распознавание текста для текста, сопоставление шаблонов с известным визуальным объектом и обнаружение объектов для проверенного класса с изменяемой геометрией.
Затем сделайте наблюдение частью перехода между состояниями: стабилизируйте, зафиксируйте, утвердите, действуйте только после успеха, проверьте постусловие и сохраните доказательства неудачи. Этот дизайн легче понять, чем набор разрозненных вызовов машинного зрения, и его гораздо легче поддерживать при изменении приложения или устройства.
- Разработчики Android: тестирование скриншотов
- Разработчики Android: тестирование создания скриншотов предварительного просмотра
- Разработчики Android: UI Automator
- Appium: плагин изображений и режимы сравнения
- OpenCV: сопоставление шаблонов
- Tesseract: улучшение качества распознавания
- Обсуждение Android-разработчиков: тестирование скриншотов