Pojęcia i implementacja w Jetpack Compose
Testowanie ułatwień dostępu pozwala sprawdzić aplikację z perspektywy użytkownika i wykryć problemy z użytecznością, które mogłyby Ci umknąć. Testy ułatwień dostępu mogą ujawnić możliwości zwiększenia funkcjonalności i wszechstronności aplikacji dla wszystkich użytkowników, w tym osób z niepełnosprawnościami.
W tym dokumencie opisujemy te podejścia:
- Testowanie za pomocą narzędzi analitycznych: używaj narzędzi, aby odkrywać możliwości poprawy dostępności aplikacji.
- Testowanie automatyczne: włącz testowanie ułatwień dostępu w Espresso i Robolectric.
Testowanie za pomocą narzędzi analitycznych
Narzędzia analityczne mogą wykrywać możliwości poprawy ułatwień dostępu, które możesz pominąć podczas testów ręcznych.
Accessibility Scanner
Aplikacja Accessibility Scanner skanuje ekran i wyświetla sugestie dotyczące ułatwień dostępu w aplikacji. Korzysta ona z platformy testów ułatwień dostępu i wyświetla konkretne sugestie po sprawdzeniu etykiet treści, elementów, w które można kliknąć, kontrastu i innych elementów.
Platforma testowa ułatwień dostępu na Androida jest zintegrowana z Androidem Studio, aby pomagać Ci w znajdowaniu problemów z ułatwieniami dostępu w układach. Aby otworzyć panel, kliknij przycisk raportu o błędzie ! w [narzędziu] Layout Editor.
Rysunek 1. Prezentacja aplikacji Accessibility Scanner.
Więcej informacji znajdziesz w tych materiałach:
Wyświetlający UI Automator
Narzędzie uiautomatorviewer udostępnia wygodny interfejs graficzny do skanowania i analizowania komponentów interfejsu wyświetlanych obecnie na urządzeniu z Androidem. Za pomocą UI Automatora możesz sprawdzić hierarchię układu i wyświetlić właściwości komponentów interfejsu widocznych na pierwszym planie urządzenia. Te informacje umożliwiają tworzenie bardziej szczegółowych testów, np. przez utworzenie selektora interfejsu, który pasuje do określonej widocznej właściwości. Narzędzie znajduje się w katalogu tools
pakietu Android SDK.
Podczas testowania ułatwień dostępu to narzędzie jest przydatne do debugowania problemów wykrytych za pomocą innych metod testowania. Jeśli na przykład podczas testowania ręcznego okaże się, że widok nie zawiera wymaganego tekstu do odczytania lub otrzymuje fokus, gdy nie powinien, możesz użyć tego narzędzia, aby zlokalizować źródło problemu.
Więcej informacji o UI Automator Viewer znajdziesz w artykule Pisanie testów automatycznych za pomocą UI Automator.
Lint
Android Studio wyświetla ostrzeżenia narzędzia lint dotyczące różnych problemów z dostępnością i zawiera linki do odpowiednich miejsc w kodzie źródłowym. W poniższym przykładzie obraz nie ma atrybutu contentDescription. Brak opisu treści
powoduje wyświetlenie tego komunikatu:
[Accessibility] Missing 'contentDescription' attribute on image
Ilustracja 2 przedstawia przykład tego, jak ten komunikat wyświetla się w Android Studio:
contentDescription.Automatyczne testowanie
Platforma Android obsługuje kilka platform testowych, np. Espresso, która umożliwia tworzenie i uruchamianie automatycznych testów oceniających dostępność aplikacji.
Espresso
Espresso to biblioteka testowa Androida, która ułatwia i przyspiesza testowanie interfejsu. Umożliwia interakcję z komponentami interfejsu testowanej aplikacji i sprawdzanie, czy występują określone zachowania lub czy spełnione są konkretne warunki.
Aby obejrzeć film z omówieniem testowania dostępności za pomocą Espresso, zobacz poniższy film od minuty 31:54 do 34:19: Inclusive design and testing: Making your app more accessible - Google I/O 2016.
Z tej sekcji dowiesz się, jak przeprowadzać testy dostępności za pomocą Espresso.
Włączanie sprawdzania
Testowanie ułatwień dostępu możesz włączyć i skonfigurować za pomocą klasy
AccessibilityChecks:
Kotlin
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();
}
}
Domyślnie sprawdzanie jest przeprowadzane, gdy wykonasz dowolną czynność związaną z wyświetlaniem zdefiniowaną w ViewActions. Każde sprawdzenie obejmuje widok, w którym wykonano działanie, oraz wszystkie widoki podrzędne. Podczas każdego sprawdzania możesz ocenić całą hierarchię widoków ekranu, przekazując wartość true do funkcji setRunChecksFromRootView(), jak pokazano w tym fragmencie kodu:
Kotlin
AccessibilityChecks.enable().setRunChecksFromRootView(true)
Java
AccessibilityChecks.enable().setRunChecksFromRootView(true);
Ukrywanie podzbiorów wyników
Po przeprowadzeniu przez Espresso testów ułatwień dostępu w aplikacji możesz znaleźć kilka możliwości poprawy ułatwień dostępu, których nie możesz od razu wykorzystać. Aby zapobiec ciągłemu niepowodzeniu testów Espresso z powodu tych wyników, możesz je tymczasowo zignorować. Platforma Accessibility Test Framework (ATF) udostępnia tę funkcję za pomocą metody setSuppressingResultMatcher(), która nakazuje Espresso pomijanie wszystkich wyników spełniających podane wyrażenie dopasowujące.
Gdy wprowadzisz w aplikacji zmiany dotyczące jednego aspektu ułatwień dostępu, warto, aby Espresso wyświetlało wyniki dotyczące jak największej liczby innych aspektów ułatwień dostępu. Z tego powodu najlepiej jest pomijać tylko konkretne, znane możliwości poprawy.
Gdy tymczasowo pomijasz wyniki testów ułatwień dostępu, które planujesz rozwiązać później, ważne jest, aby nie pominąć przypadkowo podobnych wyników. Z tego powodu używaj dopasowań o wąskim zakresie. Aby to zrobić, wybierz matcher, tak aby Espresso pomijało dany wynik tylko wtedy, gdy spełnia każdy z tych testów dostępności:
- Sprawdzanie ułatwień dostępu określonego typu, np. sprawdzanie rozmiaru obszaru docelowego dotyku.
- Sprawdzanie ułatwień dostępu, które ocenia konkretny element interfejsu, np. przycisk.
ATF definiuje kilka funkcji dopasowywania, które pomagają określać, jakie wyniki mają być wyświetlane w testach Espresso. Poniższy przykład pomija wyniki testów dotyczących kontrastu kolorów pojedynczego elementu TextView. Identyfikator elementu to countTV.
Kotlin
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))));