Automatyzacja Androida z AI w testach lokalizacji aplikacji

Zbuduj aplikację Android do testowania lokalizacji pracy, która łączy pseudolocales, kontroli języka rzeczywistego, RTL przeglądu, OCR, screenshots, i osądu człowieka bez mnożenia każdego testu przez każde locale.

Krótka odpowiedź: Automatyzacja trasy, przegląd języka

Niezawodne badanie lokalizacji aplikacji Android oddziela powtarzalną pracę urządzenia od oceny języka. Automatyzuj konfigurację języka, uruchamianie aplikacji, nawigację, czekanie, zrzuty ekranu, sprawdzanie stanu wiedzy i zbieranie dowodów. Zachować jakość tłumaczenia, ton, znaczenie kulturowe, niejednoznaczne obcinanie i równowaga wizualna pod kontrolą człowieka. Celem nie jest przeprowadzenie każdego testu w każdym języku. Ma to na celu stworzenie małej, ryzykownej matrycy, która ujawnia niepowodzenia, które mogą dotrzeć do użytkowników.

Ma to znaczenie, ponieważ wady lokalizacji to nie tylko złe słowa. Obejmują one zaszyfrowane struny, brakujące zasoby, rozszerzanie tekstu, zepsute układy prawa do lewego, nieprawidłowe daty lub walutę, niedopasowanie klawiszy, nieczytelne czcionki, przyciski przyciskowe i ustawienia językowe, które nie utrzymują się. AnAI Android narzędzie do automatyzacjimoże pomóc powtórzyć widoczną trasę i zebrać dowody, ale nie może zdecydować, czy zdanie brzmi naturalnie dla lokalnego klienta.

Poniższy przepływ pracy łączy oficjalne funkcje lokalizacji Androida z obserwowalnymi kontrolami urządzeń. Nie twierdzi, żeLaiCai FlowZastępuje testy jednostkowe, Testy komponujące, Espresso, Automator UI, Appium, system zarządzania tłumaczeniami lub przegląd języka natived. Użyj każdej warstwy do dowodów, które najlepiej produkuje.

Zacznij od macierzy wydania lokalizacji, a nie listy języków

Lista obsługiwanych języków nie jest planem testowym. Matryca release łączy lokalizację z ekranem, stan urządzenia, format danych, kierunek pisania, i ryzyko biznesowe, które sprawiają, że locale znaczące. Bez tego połączenia zespoły często otwierają ekran domowy w kilku językach, robią zrzut ekranu i pomijają błędy w kasie, wyszukiwaniu, odzyskiwaniu konta, powiadomieniach lub ustawieniach.

Wybierz locale bazowe, jedno locale ekspansyjno-ciężkie, jedno locale kompaktowe lub złożone i jedno locale RTL dla każdego wydania. Dodać lokale specyficzne dla rynku tylko do przepływów, które niosą ze sobą istotne ryzyko biznesowe.Firebase Test Lab 's Android matrycapodobnie traktuje locale jako jeden wymiar obok modelu urządzenia, wersji Android i orientacji; jest to przydatny model planowania, nawet przy przeprowadzaniu kontroli własnych urządzeń.

Użyj Android pseudolocales przed przybyciem tłumaczeń

Pseudolocales są najtańszym systemem wczesnego ostrzegania w obiegu pracy.Przewodnik po Androidzieopisuje`en-XA`, który rozszerza i akcentuje angielski tekst, oraz`ar-XB`, który ćwiczy prawo do lewego zachowania. Mogą one ujawniać zaszyfrowane struny, pękniętą konkatenację strun, ciśnienie układowe, dwukierunkowe problemy tekstowe i elementy, które nie są lustrzane, zanim tłumacz dostarcza kopię końcową.

• Uruchom pierwszą podróż użytkownika w`en-XA`i nagrać każdy ciąg, który pozostaje po angielsku; może być zaszyfrowany lub poza ścieżką zasobów lokalizacyjnych.
• Powtórz tę samą podróż w`ar-XB`i sprawdzić kolejność nawigacji, strzałki tylne, zakładki, wskaźniki postępu, mieszane numery i interpunkcji.
• Błąd przechwytywania, pusty, pozwolenie, upgrade i stan potwierdzenia; są one mniej widoczne podczas zwykłego przeglądu ścieżki happy-.
• Traktuj pseudolocale jako błąd lokalizacji, a nie jako dowód, że konkretne prawdziwe tłumaczenie jest błędne.

Deweloperzy mogą również wcześniej sprawdzić wybrane ekrany.Dokumentacja lokalizacji systemu AndroidorazStwórz podgląd narzędziwsparcie lokalnych podglądów, w tym przykładów RTL. Te kontrole przylegające do kodu są szybkie i powinny wykrywać problemy na odpowiednim poziomie przed pełnym przepływem pracy urządzenia.

Przetestuj ścieżkę językową, którą użytkownicy rzeczywiście podejmują

Przetłumaczony ekran nie wystarczy, jeśli użytkownicy nie mogą wybrać, zatrzymać lub zresetować języka.Przewodnik językowy dla Androidawyjaśnia, że Android 13 i później zapewnić scentralizowane ustawienie systemu dla preferowanego języka aplikacji, podczas gdy AndroidX obsługuje kompatybilne aplikacje locale obsługi starszych wersji. Aplikacje mogą również mieć swój własny wybór języka. Każda obsługiwana ścieżka wejścia wymaga małego testu stanu-przejścia.

1. Zacznij od stanu czystego o nazwie: świeża instalacja, zmodernizowana instalacja, signed- na koncie lub przywrócona kopia zapasowa.
2. Wybierz lokalizację poprzez zamierzoną ścieżkę systemową lub in- app i potwierdź, czy aplikacja ponownie się uruchamia, odtwarza aktywność lub aktualizuje na miejscu.
3. Nawigacja z dala od ustawień i potwierdzić docelowy locale pojawia się na ekranie-krytyczny biznes.
4. Zamknij i ponownie otwórz aplikację, a następnie sprawdź, czy preferencje utrzymują się.
5. Przywróć do domyślnego systemu i potwierdź, że nieświeże przetłumaczone zasoby nie pozostają.
6. Na starszych wersjach Android, testować rzeczywistą ścieżkę kompatybilności zamiast zakładając zachowanie Android 13.

Język urządzenia i język klawiatury są odrębne obawy.Dokumentacja testowania lokalizacji BrowserStackzauważa, że zmiana języka na urządzeniu z systemem Android niekoniecznie zmienia język klawiatury. Zachowaj to rozróżnienie w macierzy, tak aby niepowodzenie tekstowego wejścia nie zostało błędnie zdiagnozowane jako awaria zasobów.

Wybierz reprezentatywne ekrany z podziałem na ryzyko

Nie mnożyć każdego istniejącego testu end-to-end przez każde położenie. Wybierz ekrany, w których lokalizacja zmienia zachowanie, układ, zaufanie lub pieniądze. Kompaktowy zestaw zazwyczaj obejmuje onboarding, sign- in, nawigację domową, wyszukiwanie, jedną stronę szczegółową, jeden formularz, jedną powierzchnię płatności lub potwierdzenia, ustawienia, powiadomienia i najważniejszy stan błędu.

Kontrola priorytetowa ze stałą szerokością, przyległe ikony, wiele zmiennych, zasady mnogości, dynamiczny tekst serwera, karty kompaktowe, nawigacja dolna i przetłumaczony tekst nad obrazami. Dołącz jeden ekran z maksymalną zawartością realistyczną, a nie tylko puste dane demo. Jeśli aplikacja obsługuje tablety, składy lub krajobraz, należy je dodać tylko wtedy, gdy układ naprawdę się zmienia.

Daj każdemu wybranemu ekranie właściciela i powód. Na przykład, potwierdzenie checkout istnieje, aby zweryfikować walutę, pakowanie linii, etykiety przycisków i kopię prawną; ekran recordt- recovery istnieje do weryfikacji metody wprowadzania, komunikatów błędów i dwukierunkowych adresów e-mail. To sprawia, że niepowodzenia można podjąć zamiast tworzyć folder niewyjaśnionych zrzutów ekranu.

Dopasuj metodę dowodową do błędu lokalizacji

Żaden pojedynczy lokalizator ani technika obrazu nie udowadnia jakości lokalizacji. Wybierz najmniejszą obserwację, która może poprzeć decyzję. IstniejącePrzewodnik do testów wizualnych Androidwyjaśnia szersze różnice między stanem UI, OCR, dopasowanie obrazu, wykrywanie obiektów i zrzuty ekranu; lokalizacja QA stosuje te metody do ryzyka specyficznego dla języka.

W bieżącymLaiCai Flowkontrakt, OCR zwraca zbiór wyników, a nie jedną magiczną odpowiedź. Przepływ musi wybrać odpowiedni segment przed porównaniem tekstu lub pozycji. Podobnie, dopasowanie wizualne informuje o znanym stanie; nie powinno być rozciągane na twierdzenie, że każdy piksel lub zdanie jest poprawne.

Zbuduj obserwowalny przepływ lokalizacji na prawdziwych urządzeniach z systemem Android

Obserwowalny strumień pracy wizualnej jest przydatny, gdy zespół musi powtórzyć tę samą nawigację na prawdziwych urządzeniach z Androidem i przekazać powtarzalny dowód.LaiCai Flowjest funkcją automatyzacji wewnątrzLaiCai Screen Mirroring. Może organizować widoczne kroki, takie jak oczekiwania, kontroli stanu UI, OCR, dopasowanie szablonów, zrzuty ekranu, warunki, ograniczone pętle, i wyraźne przystanki. WLaiCai Flowprzewodnikobejmuje przepływ produktów.

1. Nazwa budowy, urządzenia, wersji Android, locale, motyw, skalę czcionek i stan konta startowego.
2. Otwórz ścieżkę aplikacji lub ustawień i użyj wyraźnego oczekiwania przed obserwacjami zależnymi od ekranu.
3. Nawiguj jedną fazę poziomu użytkownika na raz, zachowując techniczne szczegóły wyszukiwania wewnątrz czytelnych przepływów dzieci, gdy podróż staje się złożona.
4. Sprawdzić stabilny stan ekranu przed każdym destrukcyjnym lub zmieniającym stan działania.
5. Uchwyć wymagany zrzut ekranu i wybrany wynik OCR za pomocą identyfikatora lokalizacji i ekranu.
6. Weryfikacja stanu po nawigacji zamiast zakładania, że tap się powiodło.
7. Zatrzymaj z dowodami, gdy ekran jest nieznany; nie kliknij dalej przez nieoczekiwany język lub okno dialogowe.

Warstwa ta uzupełnia testy oparte na kodach. Testy komponentów i oprzyrządowania powinny nadal posiadać sprawdzanie zasobów, logikę stanu, semantykę dostępności i stwierdzenia deterministyczne w pobliżu aplikacji. Widoczny przepływ jest najsilniejszy, gdy przeglądacze wsparcia, lokalizacji lub wydania potrzebują powtarzalnej trasy i ludzkiego pakietu dowodów. WAndroid QA-test pracyzapewnia powiązany ogólny wzór.

Dać RTL i zawartość dwukierunkową własną przepustkę testową

RTL nie jest elementem do dodania na końcu listy kontrolnej LTR. Uruchom dedykowaną przepustkę z arabskim lub innym obsługiwanym locale RTL i zawierać mixed- direction treści, takich jak adresy e-mail, numery telefonów, ceny, struny wersji, adresy URL, kody, i łacińskie nazwy marki. Kombinacje te ujawniają interpunkcję i niepowodzenia, których w pełni przetłumaczony akapit może nie wykazać.

• Potwierdź, że nawigacja, szuflady, karty, kierunek postępu i ikony kierunkowe odbijają się tylko wtedy, gdy ich znaczenie powinno odzwierciedlać.
• Sprawdź, czy liczby, jednostki, nazwy produktów i kursory wejściowe pozostają czytelne w zdaniach RTL.
• Sprawdź wyrównanie w pustych stanach, dialogach, batonikach, wyjaśnieniach o pozwoleniach i komunikatach o walidacji.
• Przekręty testowe i zwrotna nawigacja przez zachowanie, nie zakładając, że każdy gest zmienia kierunek tekstu.
• Do interpunkcji, frazowania, przerw w liniach i interpretacji kulturowej użyj recenzenta w języku natived.

Stosowanie`ar-XB`wcześnie, aby ujawnić usterki strukturalne, a następnie uruchomić co najmniej jeden prawdziwy RTL locale przed zwolnieniem. Pseudolocale może ujawnić wady lustrzane, ale nie potwierdza typografii lub znaczenia produkcji kopii arabskiej.

Formaty testowe, wejścia, powiadomienia i powierzchnie zewnętrzne

Niektóre z najdroższych awarii lokalizacyjnych siedzą poza głównym ekranem in- app. Dodawanie ukierunkowanych kontroli daty i czasu, separatorów dziesiętnych, umieszczania waluty, porządku adresów, jednostek pomiarowych, numerów telefonów, formularzy w liczbie mnogiej, wejścia do klawiatury, zachowania schowka, tekstu powiadomienia, głębokich linków, zawartości stron internetowych i każdego okna dialogowego systemu, od którego podróż zależy.

Zapis, który locale napędza każdą wartość. Język aplikacji, locale systemu, kraj konta, preferencje serwera, strefa czasowa i klawiatura mogą się nie zgadzać. Zrzut ekranu pokazujący zaskakującą wartość jest użytecznym dowodem, ale raport o błędzie musi również nazwać te wejścia, aby inżynieria mogła odtworzyć źródło rozbieżności.

Traktuj listy sklepów i promocyjne zrzuty ekranu jako oddzielną powierzchnię wydania. Ich tekst może pochodzić z innego repozytorium, a obrazy mogą być generowane przez inny rurociąg. Ponownie użyj tego samego planu inwentaryzacji ekranu i nazewnictwa, ale nie znakuj aplikacji zlokalizowanej tylko dlatego, że opis sklepu jest tłumaczony.

Zachować ludzką recenzję, gdzie automatyzacja jest słaba

Automatyzacja jest dobra w powtarzaniu trasy i wykrywaniu znanych dowodów. Ludzie pozostają lepsi w znaczeniu, ton, kontekst, dopasowanie kulturowe, hierarchia wizualna, humor, dwuznaczność i decydowanie, czy przerwa w linii tylko wygląda inaczej lub rzeczywiście szkodzi zrozumieniu. Zbuduj przekazanie celowo zamiast traktować ręczną recenzję jako nieplanowany wyjątek.

• Automate: konfiguracja lokalna, uruchomienie, nawigacja, oczekiwanie, stabilne sprawdzanie stanu, wybrana obecność tekstu, zrzuty ekranu, nazewnictwo plików i opakowanie dowodów.
• Ręczne przeglądanie: znaczenie tłumaczenia, naturalność, niuanse prawne, dostępność złożonych skryptów, niejednoznaczne skrócenie, obraz kulturowy i równowaga wizualna.
• Eskalacja do testów kodowych: dokładne mapowanie zasobów, logika mnoga, funkcje formatowania deterministycznego i semantyki komponentów.
• Escalate do urządzenia lub testów ramowych: uprawnienia systemowe, zachowanie cross- app, integracja klawiatury i przejścia cyklu życia.

Przydatna zasada zatrzymania jest prosta: gdy widoczny stan nie jest jednym z zatwierdzonych stanów, zbieraj dowody i przestań. Nie pozwól automatyzacji kontynuować poprzez nieznany ekran zgody, krok płatności, destrukcyjne działania, lub nieprzetłumaczone ścieżki systemowej. WPorównanie narzędzi do testowania automatyki Androidmoże pomóc przyporządkować każde stwierdzenie do właściwej warstwy.

Utwórz pakiet dowodowy, na którym zespół może działać

Deska rozdzielcza bez kontekstu tworzy kolejne dochodzenie. Każde wykrycie lokalizacji powinno identyfikować budowę, pakiet aplikacji i wersję, lokalizację i region, wersję Android, urządzenie i rozdzielczość, skalę czcionki, motyw, stan początkowy, nazwę ekranu, oczekiwany wynik, rzeczywisty wynik, a także zrzut ekranu lub wybraną obserwację, która wspiera roszczenie.

Użyj stabilnych nazw plików, takich jak`build-locale-device-screen-state.png`, następnie zachować jeden manifest, który mapuje pliki do matrycy testowej. Oddzielna oczekiwana zmienność wizualna od wad: inna przerwa w linii może być możliwa do przyjęcia, podczas gdy ukryta cena, nieosiągalny przycisk, odwrócony znak marki lub brakujący komunikat błędu nie jest. Przypisz stopień ciężkości na podstawie wpływu użytkownika, nie na podstawie różnicy pikseli.

Ponieważ żadne urządzenie zarządzane przez LaiCai nie było dostępne w kontekście obecnej generacji, artykuł ten opisuje raczej przepływ pracy oparty na umowie, niż deklarowanie wyników odniesienia dla danej aplikacji, urządzenia lub lokalizacji. Uruchom reprezentatywnego pilota w środowisku przed rozszerzeniem matrycy.

Lista kontrolna wydania dla kontroli jakości lokalizacji Androida

1. Zdefiniuj wspieraną listę lokalizacji, lokalizacje awaryjne, ścieżki wyboru języka i rynki wysokiego ryzyka.
2. Biegnij`en-XA`oraz`ar-XB`na ekranach reprezentatywnych przed ostatecznym tłumaczeniem.
3. Weryfikacja rzeczywistego przełączania języka per- app, systemowego i in- app, gdzie każda ścieżka jest obsługiwana.
4. Pokryć jeden ekspansyjno- ciężki locale, jeden kompleks- script locale i jeden RTL locale na małym ekranie.
5. Włączenie stanów błędów, pustych, wczytywania, potwierdzania, autoryzacji, aktualizacji i powiadomień.
6. Sprawdź formaty regionalne, metody wprowadzania, skalę czcionek, jasny / ciemny motyw i trwałość języka.
7. Użyj stanu UI, OCR, szablonu dopasowywania, zrzutów ekranu i recenzji człowieka tylko dla roszczeń mogą wspierać.
8. Zapisz pakiet z dowodami i zatrzymaj się w nierozpoznanych stanach.
9. Mieć native- język recenzent zatwierdza znaczenie, ton, interpunkcja, i dopasowanie kulturowe.
10. Zachowaj pierwotną automatyzację CTA na stronie właściciela o lokalizacji i użyj przewodników wspierających szczegóły wdrażania.

O autorze: BeePOS LLC rozwijaLaiCai Screen Mirroringi jegoLaiCai Flowfunkcja automatyzacji. Ten przewodnik jest oparty na aktualnej dokumentacji Android, zaobserwowanych praktyk testowania lokalizacji, i opublikowaneLaiCai FlowKontrakt węzłowy. Pytania o produkt mogą być wysyłane przezFirma LaiCai i strona wsparcia.

Źródła

• Programiści Android: Sprawdź swoją aplikację pseudolocales
• Android Deweloperzy: Preferencje językowe Per- app
• Android Developers: Lokalizacja aplikacji
• Programiści Android: Podgląd interfejsu użytkownika z kompostowalnymi podglądami
• Baza ognia: Zacznij testować na Androida z Test Lab
• BrowserStack: Testy lokalizacyjne przy użyciu aplikacji Live