Użyj zrzutów ekranu, aby uzyskać wygląd całego ekranu, OCR dla widocznego tekstu i dopasowania obrazu do znanego celu wizualnego. Najsilniejsze testy wizualne Androida łączą jedno skupione stwierdzenie ze stabilnym czasem i dowodami niepowodzeń.
Krótka odpowiedź: przetestuj rzecz, która musi pozostać prawdziwa
Korzystaj z testów zrzutów ekranu, gdy cały ekran, komponent, odstępy, kolor lub typografia muszą pozostać spójne wizualnie. Użyj OCR, jeśli wymaganie dotyczy słów, które dana osoba może zobaczyć, zwłaszcza tekstu zlokalizowanego lub renderowanego dynamicznie. Użyj dopasowywania obrazów, gdy musi pojawić się znana ikona, przycisk, plakietka lub ilustracja, nawet jeśli nie ma wiarygodnego identyfikatora interfejsu użytkownika.
Zacznij od selektora interfejsu użytkownika lub stanu dostępności, gdy wymaganie jest semantyczne: istnieje formant, jest on włączony, jest wybrany lub udostępnia stabilną etykietę. Dodaj wykrywanie obiektów tylko wtedy, gdy cel należy do klasy wizualnej i może zmienić rozmiar lub położenie za bardzo w przypadku jednego szablonu. Metody te to warstwy, a nie konkurencyjne platformy testowe.
- Zapytaj, jakie dowody przekonałyby recenzenta, że wymóg został spełniony.
- Wybierz najwęższy niezawodny sygnał zamiast domyślnie porównywać każdy piksel.
- Ustabilizuj ekran przed obserwacją, a następnie zapisz artefakt, jeśli potwierdzenie się nie powiedzie.
Porównanie metod testowania wizualnego Androida
| Metoda | Najlepsze dla | Główna słabość | Przydatne dowody |
|---|---|---|---|
| Interfejs użytkownika lub stan dostępności | Kontrole, etykiety, stan włączony, wybór, struktura nawigacji | Elementy renderowane na zamówienie lub niedostępne mogą być niewidoczne w drzewie interfejsu użytkownika | Hierarchia interfejsu użytkownika, wybrane właściwości, zrzut ekranu |
| Zrzut ekranu lub złoty obraz | Układ, odstępy, kolory, typografia, wygląd komponentów | Dane dynamiczne, animacje, różnice między urządzeniami i zmiany renderowania mogą powodować zakłócenia | Bieżący obraz, zatwierdzony poziom bazowy, różnica wizualna |
| OCR | Widoczny tekst, lokalizacja, rachunki, komunikaty o stanie, wartości renderowane jako piksele | Jakość rozpoznawania zależy od przycięcia, skali, kontrastu, danych językowych, rotacji i segmentacji | Uprawa źródłowa, rozpoznany tekst, lista zaufania lub lista wyników |
| Dopasowanie szablonu | Znana ikona, przycisk, znaczek, miniatura lub mały stabilny region | Motyw, skala, kompresja i przeprojektowanie mogą unieważnić szablon | Szablon, region wyszukiwania, najlepsze dopasowanie, wynik, zrzut ekranu |
| Wykrywanie obiektów | Obiekt wizualny, którego klasa pozostaje znacząca, gdy zmienia się jego położenie lub rozmiar | Wymaga zgodnego modelu, klas oznaczonych etykietami, progów i walidacji modelu | Wersja modelu, klasa, pudełko, partytura, zrzut ekranu |
Oficjalne wskazówki dotyczące testowania zrzutów ekranu w systemie Android opisują porównanie bieżącego renderowania z zatwierdzonym obrazem referencyjnym. Wtyczka obrazu Appium umożliwia dopasowywanie funkcji, dopasowywanie szablonów i porównywanie podobieństw. OpenCV dokumentuje mechanikę przesuwania szablonu na obraz, podczas gdy Tesseract dokumentuje znaczenie wstępnego przetwarzania OCR i segmentacji strony. Narzędzia są różne, ale pytanie dotyczące projektu testu pozostaje takie samo: jaka obserwacja potwierdza ten wymóg?
Wybierz właściwe twierdzenie za pomocą czterech pytań
1. Czy wymaganie ma charakter semantyczny czy wizualny?
Jeśli test wykaże, że przycisk Prześlij jest włączony, sprawdź najpierw stan interfejsu użytkownika. Jeśli pojawi się komunikat „Przycisk Prześlij nie został przycięty po zmianie czcionki”, użyj zrzutu ekranu lub kontroli wizualnej. Zapytanie semantyczne jest zwykle łatwiejsze w utrzymaniu, ale nie może udowodnić wyglądu.
2. Czy dokładny tekst ma znaczenie?
Użyj OCR, gdy wymagany jest ciąg znaków widoczny dla użytkownika, a tekst nie jest niezawodnie widoczny w drzewie interfejsu użytkownika. Ogranicz rozpoznawanie do najmniejszego znaczącego regionu, wybierz właściwy język i porównaj znormalizowany wynik. Zachowaj zrzut ekranu, ponieważ sam poprawny ciąg OCR nie może wykazywać obcięcia, nakładania się ani słabego kontrastu.
3. Czy istnieje jeden stabilny cel wizualny?
Użyj dopasowania szablonu dla znanej ikony lub małej kontrolki. Przytnij mocno szablon, przeszukaj interesujący Cię obszar i ustaw próg na podstawie rzeczywistych próbek dodatnich i ujemnych. Jeden uniwersalny próg rzadko można obronić w przypadku motywów, rozdzielczości i skompresowanych zdalnych strumieni.
4. Czy cała kompozycja musi pozostać spójna?
Użyj porównania zrzutów ekranu, gdy liczy się związek między wieloma elementami. Kontroluj czcionki, ustawienia regionalne, konfigurację urządzenia, paski systemowe, czas, dane sieciowe, animacje i zawartość zarodkową. Jeśli nie można kontrolować tych wejść, zamaskuj lub przytnij obszary dynamiczne, zamiast akceptować trwale zaszumiony test.
Zbuduj test wizualny, który zawodzi
- Doprowadź aplikację do nazwanego stanu początkowego na autoryzowanym urządzeniu lub emulatorze.
- Poczekaj na stabilny stan, a nie tylko stałe opóźnienie. UI Automator zapewnia stabilność oczekiwania, a sygnał gotowości dla konkretnej aplikacji jest jeszcze lepszy.
- Przechwyć najmniejszy region źródłowy zawierający wymagane dowody.
- Uruchom jedno podstawowe potwierdzenie: stan interfejsu użytkownika, OCR, szablon, wykrywanie lub porównanie zrzutów ekranu.
- Zapisz obraz źródłowy i uporządkowany wynik przed podjęciem następnej akcji.
- W przypadku niepowodzenia zatrzymaj się lub postępuj zgodnie ze sprawdzoną ścieżką odzyskiwania. Nie dotykaj pobliskiego sobowtóra, aby po prostu kontynuować test.
Kontrola wzrokowa staje się bezpieczniejsza, gdy zezwala na przejście. Obserwuj bieżący stan, wykonaj asercję, wykonaj dozwolone działanie dopiero po sukcesie i zweryfikuj warunek końcowy. Jest to ta sama zasada projektowa, którą opisano wprzewodnik dotyczący automatycznego rozpoznawania obrazu: rozpoznanie nie jest dowodem zakończenia przepływu pracy.
W przypadku pracy na prawdziwym urządzeniu dublowanie ekranu Androida do testowania aplikacji mobilnych zapewnia recenzentowi podgląd na żywo podczas projektowania testu. Przewodnik po testach dymnych QA automatyzacji Androida wyjaśnia, jak utrzymać powtarzalne kontrole wąskie i odtwarzalne.
Trzy praktyczne scenariusze testów wizualnych Androida
Kontrola jakości lokalizacji na ekranie kasy
Użyj stanu interfejsu użytkownika, aby przejść do ekranu kasy, OCR, aby potwierdzić zlokalizowaną etykietę sumy i działania, oraz skupiony zrzut ekranu, aby pokazać, że ciągi znaków nie są obcięte ani nakładają się. Uruchom każde ustawienie regionalne z kontrolowanymi danymi testowymi. Samo porównanie pikseli na pełnym ekranie będzie zbyt czułe na długość przetłumaczonego ciągu, podczas gdy samo OCR nie przeoczy uszkodzeń układu.
Sprawdzanie przeprojektowanej ikony paska narzędzi
Użyj szablonu zaakceptowanej ikony w małym obszarze paska narzędzi. Zachowaj osobne szablony, jeśli obsługiwane są zarówno jasne, jak i ciemne motywy. Jeśli dopasowanie się nie powiedzie, dołącz przycięcie paska narzędzi i wynik najlepszego kandydata. Jeśli ikona została celowo przeprojektowana, przejrzyj i zastąp szablon, zamiast obniżać próg do momentu przejścia dowolnego kształtu.
Test dymny prawdziwego telefonu po wdrożeniu
Zacznij od znanego stanu konta i aplikacji, poczekaj na ekran docelowy, potwierdź jego tożsamość, wykonaj jedną dozwoloną akcję i zweryfikuj kolejny nazwany stan. Zrób zrzut ekranu przy każdej awarii. Gęstość urządzeń, okna dialogowe uprawnień, klawiatury, powiadomienia i aktualizacje systemu są częścią środowiska prawdziwego telefonu, więc test powinien je zgłosić, a nie ukrywać.
Typowe fałszywe awarie i sposoby zapobiegania im
| Objaw | Prawdopodobna przyczyna | Lepsza reakcja |
|---|---|---|
| Różnica zrzutów ekranu zmienia się przy każdym uruchomieniu | Zegar, animacja, reklamy, dane początkowe, klawiatura, pasek systemowy lub zawartość sieciowa | Zamroź dane wejściowe, poczekaj na stabilność, przytnij lub zamaskuj tylko region dynamiczny |
| OCR zwraca wiarygodny, ale błędny tekst | Zły język, niski kontrast, małe przycięcie, rotacja, szum lub nieodpowiednia segmentacja | Zapisz kadr, popraw skalę i kontrast, świadomie wybieraj język i segmentację |
| Dopasowanie szablonu działa tylko na jednym telefonie | Różna gęstość, motyw, skalowanie, współczynnik proporcji lub kompresja | Użyj regionu zainteresowania i zatwierdzonych szablonów dla obsługiwanych wariantów wizualnych |
| Znaleziono odpowiedni obraz, ale dotknięcie kończy się niepowodzeniem | Współrzędne meczu nie zostały przekształcone na bieżący ekran lub nakładka blokuje wprowadzanie danych | Oddziel rozpoznanie od działania i zweryfikuj kolejny stan |
| Test jest kontynuowany na niewłaściwym ekranie | Brak warunku końcowego lub krawędzi awarii | Nazwij oczekiwane stany i zatrzymaj się, gdy bieżący ekran znajdzie się poza przeglądaną ścieżką |
| Detektor obiektów znajduje niewłaściwą klasę | Model lub etykiety nie pasują do domeny aplikacji, próg nie został zweryfikowany | Użyj kompatybilnego modelu, zapisz wersję i wynik, przetestuj próbki negatywne |
Dyskusje społeczności na temat testów regresyjnych Androida często powracają do tych samych kosztów utrzymania: matryc urządzeń, niestabilnego taktowania, przeglądu stanu bazowego i ekranów, których zawartość się zmienia. To nie są powody, aby rezygnować z testów wizualnych. Są to powody, dla których należy wyraźnie określić środowisko testowe, akceptowaną wariancję i artefakty błędów.
Jak LaiCai Flow pasuje do testów wizualnych
LaiCai Flowto funkcja automatyzacji dostępna w LaiCai Screen Mirroring. Przepływ może łączyć przechwytywanie zrzutów ekranu, sprawdzanie interfejsu użytkownika, OCR, dopasowywanie szablonów, wykrywanie obiektów, warunki, akcje i wyraźne przejścia dotyczące sukcesu lub niepowodzenia. Dzięki temu tester może modelować ekran jako stan, zamiast traktować rozpoznawanie jako izolowaną sztuczkę.
DziękiLaiCai Flow Insidekompatybilny profil może działać poprzez LaiCai Android Agent na telefonie po wdrożeniu. Zgodność nadal zależy od każdego węzła i zasobu używanego przez ten profil. Lokalny OCR korzysta z Tesseraktu; dopasowywanie szablonów wykorzystuje wybrany zasób obrazu i konfigurowalną punktację; zgodne wykrywanie lokalne wykorzystuje obsługiwany model. Węzeł sieci lub model zdalny nadal potrzebuje własnej zależności sieciowej.
Nie oznacza to, że każdy test wizualny jest automatycznie wiarygodny. Zespoły nadal potrzebują reprezentatywnych linii bazowych, szablonów, regionów OCR, modeli, progów, przypadków negatywnych i warunków końcowych. Zaletą jest to, że te decyzje i przejścia można przeglądać w jednym przepływie pracy. Przewodnik po automatyzacjiAI dla Androidazapewnia szerszy pogląd na tworzenie i wykonywanie na rzeczywistych urządzeniach.
Minimalny pakiet dowodów w przypadku nieudanego testu wizualnego
- Nazwa testu, kompilacja aplikacji, model urządzenia, wersja Androida, ustawienia regionalne, motyw i orientacja.
- Zrzut ekranu źródłowego lub przycięty obszar używany w twierdzeniu.
- Oczekiwana wartość bazowa, szablon, tekst, klasa lub właściwość interfejsu użytkownika.
- Zaobserwowana różnica, wynik OCR, obwiednia, wynik dopasowania lub wartość interfejsu użytkownika.
- Poprzedni nazwany stan, próba działania, oczekiwany następny stan i przyczyna zatrzymania.
- Wersja zasobu, modelu lub wersji bazowej, aby recenzent mógł odtworzyć decyzję.
Etykieta Pass/Fail bez tego kontekstu zmusza następną osobę do odtworzenia całego przebiegu. Kompaktowy pakiet dowodów zamienia awarię w decyzję, którą można zweryfikować: napraw produkt, ustabilizuj test, zaktualizuj zatwierdzony zasób wizualny lub odrzuć nieobsługiwaną konfigurację urządzenia.
Często zadawane pytania dotyczące testów wizualnych Androida
Czy każdy test interfejsu użytkownika Androida powinien zawierać zrzut ekranu?
Nie. Używaj zrzutów ekranu, gdy wygląd ma znaczenie lub gdy artefakt awarii pomoże recenzentowi. Twierdzenia semantyczne są zwykle lepsze w przypadku zachowań, które drzewo interfejsu użytkownika niezawodnie ujawnia.
Czy OCR jest lepszy niż dopasowywanie obrazów?
OCR odpowiada na pytania dotyczące widocznego tekstu. Dopasowywanie obrazów odpowiada na pytania dotyczące znanego wzorca wizualnego. Jeśli wymaganie obejmuje zarówno etykietę, jak i jej wygląd, użyj OCR wraz ze zrzutem ekranu lub sprawdzeniem szablonu.
Czy testy zrzutów ekranu można uruchomić na prawdziwych telefonach z Androidem?
Tak, ale prawdziwe urządzenia wprowadzają więcej zmian niż kontrolowany moduł renderujący lub emulator po stronie hosta. Zapisz konfigurację urządzenia, ustabilizuj interfejs użytkownika i dane systemu oraz ustal oczekiwania względem matrycy urządzenia, którą faktycznie obsługujesz.
Kiedy należy używać wykrywania obiektów?
Używaj go, gdy znacząca klasa obiektów przesuwa się lub skaluje poza tolerancję stabilnego szablonu i tylko wtedy, gdy kompatybilny model został zweryfikowany na rzeczywistych obrazach aplikacji. Nie dodawaj detektora tylko dlatego, że brzmi bardziej zaawansowanie.
Zanim wybierzesz technologię, wybierz dowody
Rzetelne testy wizualne Androida zaczynają się od jednego zdania: co musi udowodnić recenzent? Wybierz stan interfejsu użytkownika dla semantyki, zrzutów ekranu dla kompozycji, OCR dla tekstu, dopasowywania szablonów dla znanego celu wizualnego i wykrywania obiektów dla zweryfikowanej klasy o zmiennej geometrii.
Następnie uczyń obserwację częścią zmiany stanu: stabilizuj, przechwytuj, potwierdzaj, działaj dopiero po sukcesie, weryfikuj warunek końcowy i zachowaj dowody niepowodzenia. Taki projekt jest łatwiejszy do zrozumienia niż zbiór niepowiązanych ze sobą połączeń wizyjnych – i znacznie łatwiejszy w utrzymaniu w przypadku zmiany aplikacji lub urządzenia.
- Programiści Androida: testowanie zrzutów ekranu
- Programiści Androida: testowanie zrzutów ekranu podglądu tworzenia aplikacji
- Programiści Androida: Automator interfejsu użytkownika
- Appium: wtyczki obrazów i tryby porównania
- OpenCV: Dopasowywanie szablonów
- Tesseract: Poprawa jakości OCR
- Dyskusja programistów Androida: testowanie zrzutów ekranu