Концепции и реализация Jetpack Compose
Тестирование на доступность позволяет оценить приложение с точки зрения пользователя и выявить проблемы с удобством использования, которые вы могли бы упустить. Тестирование на доступность может показать возможности для повышения функциональности и универсальности вашего приложения для всех пользователей, включая людей с ограниченными возможностями.
В данном документе описаны следующие подходы:
- Тестирование с использованием аналитических инструментов : используйте инструменты для выявления возможностей улучшения доступности вашего приложения.
- Автоматизированное тестирование : включите тестирование доступности в Espresso и Robolectric.
Тестирование с использованием аналитических инструментов
Инструменты анализа могут выявить возможности для улучшения доступности, которые вы могли бы упустить при ручном тестировании.
Сканер доступности
Приложение «Сканер доступности» сканирует ваш экран и предлагает способы улучшения доступности вашего приложения. «Сканер доступности» использует структуру тестирования доступности (Accessibility Test Framework) и предоставляет конкретные рекомендации после анализа меток контента, кликабельных элементов, контраста и многого другого.
В Android Studio интегрирована платформа для проверки доступности Android, которая помогает выявлять проблемы доступности в ваших макетах. Чтобы открыть панель, нажмите кнопку «Отчет об ошибке» в редакторе макетов.
Рисунок 1. Демонстрация работы сканера доступности.
Для получения более подробной информации обратитесь к следующим ресурсам:
UI Automator Viewer
Инструмент uiautomatorviewer предоставляет удобный графический интерфейс для сканирования и анализа компонентов пользовательского интерфейса, отображаемых в данный момент на устройстве под управлением Android. С помощью UI Automator можно проверить иерархию макета и просмотреть свойства компонентов пользовательского интерфейса, видимых на переднем плане устройства. Эта информация позволяет создавать более точные тесты, например, путем создания селектора пользовательского интерфейса, соответствующего определенному свойству видимости. Инструмент находится в каталоге tools комплекта разработки Android SDK.
В тестировании доступности этот инструмент полезен для отладки проблем, обнаруженных с помощью других методов тестирования. Например, если ручное тестирование показывает, что в представлении отсутствует необходимый для озвучивания текст или представление получает фокус, когда этого делать не следует, вы можете использовать этот инструмент, чтобы помочь найти источник проблемы.
Чтобы узнать больше о UI Automator Viewer, см. раздел «Написание автоматизированных тестов с помощью UI Automator» .
Ворс
Android Studio отображает предупреждения линтера о различных проблемах доступности и предоставляет ссылки на соответствующие места в исходном коде. В следующем примере у изображения отсутствует атрибут contentDescription . Отсутствие описания содержимого приводит к следующему сообщению:
[Accessibility] Missing 'contentDescription' attribute on image
На рисунке 2 показан пример того, как это сообщение отображается в Android Studio:
contentDescription .Автоматизированное тестирование
Платформа Android поддерживает несколько фреймворков для тестирования, таких как Espresso, который позволяет создавать и запускать автоматизированные тесты для оценки доступности вашего приложения.
Эспрессо
Espresso — это библиотека для тестирования Android-приложений, разработанная для быстрого и простого тестирования пользовательского интерфейса. Она позволяет взаимодействовать с тестируемыми компонентами интерфейса в вашем приложении и проверять, выполняются ли определенные действия или условия.
Чтобы посмотреть видеообзор тестирования доступности с помощью Espresso, посмотрите следующее видео с 31:54 по 34:19: Инклюзивный дизайн и тестирование: повышение доступности вашего приложения — Google I/O 2016 .
В этом разделе описывается, как запускать проверки доступности с помощью Espresso.
Включить проверки
Вы можете включить и настроить проверку доступности с помощью класса AccessibilityChecks :
Котлин
import androidx.test.espresso.accessibility.AccessibilityChecks
@RunWith(AndroidJUnit4::class)
@LargeTest
class MyWelcomeWorkflowIntegrationTest {
init {
AccessibilityChecks.enable()
}
}
Java
import androidx.test.espresso.accessibility.AccessibilityChecks;
@RunWith(AndroidJUnit4.class)
@LargeTest
public class MyWelcomeWorkflowIntegrationTest {
@BeforeClass
public void enableAccessibilityChecks() {
AccessibilityChecks.enable();
}
}
По умолчанию проверки выполняются при выполнении любого действия с представлением, определенного в ViewActions . Каждая проверка включает представление, на котором выполняется действие, а также все дочерние представления. Вы можете оценить всю иерархию представлений экрана во время каждой проверки, передав true в setRunChecksFromRootView() , как показано в следующем фрагменте кода:
Котлин
AccessibilityChecks.enable().setRunChecksFromRootView(true)
Java
AccessibilityChecks.enable().setRunChecksFromRootView(true);
Скрыть подмножества результатов
После того, как Espresso выполнит проверку доступности вашего приложения, вы можете обнаружить несколько возможностей для улучшения доступности, которые вы не можете устранить немедленно. Чтобы тесты Espresso перестали постоянно давать сбои из-за этих результатов, вы можете временно игнорировать их. Фреймворк тестирования доступности (ATF) предоставляет эту функциональность с помощью метода setSuppressingResultMatcher() , который указывает Espresso подавлять все результаты, удовлетворяющие заданному выражению сопоставления.
Когда вы вносите изменения в приложение, касающиеся одного аспекта доступности, для Espresso полезно показывать результаты по как можно большему числу других аспектов доступности. Поэтому лучше скрывать только конкретные известные возможности для улучшения.
При временном подавлении результатов проверки доступности, которые вы планируете исправить позже, важно не подавить случайно аналогичные результаты. Поэтому используйте сопоставители с узкой областью видимости. Для этого выберите сопоставитель таким образом, чтобы Espresso подавлял данный результат только в том случае, если он удовлетворяет каждой из следующих проверок доступности:
- Проверки доступности определенного типа, например, те, которые проверяют размер сенсорной области.
- Проверки доступности, которые оценивают конкретный элемент пользовательского интерфейса, например, кнопку.
ATF определяет несколько параметров сопоставления , которые помогут вам определить, какие результаты отображать в тестах Espresso. В следующем примере подавляются результаты проверок, связанных с цветовым контрастом одного элемента TextView . Идентификатор элемента — countTV .
Котлин
AccessibilityChecks.enable().apply {
setSuppressingResultMatcher(
allOf(
matchesCheck(TextContrastCheck::class.java),
matchesViews(withId(R.id.countTV))
)
)
}
Java
AccessibilityValidator myChecksValidator =
AccessibilityChecks.enable()
.setSuppressingResultMatcher(
allOf(
matchesCheck(TextContrastCheck.class),
matchesViews(withId(R.id.countTV))));