Wybierz narzędzie do testowania automatyki Android przy pomocy granicy, którą musisz kontrolować: app-owned UI, system i cross- app behaviour, cross- platform WebDriver tests, lub obserwowalne real- phone workflows.
Krótka odpowiedź: wybrać przez granicę testową, a nie popularność
Nie ma jednego najlepszego narzędzia do testowania Android automatyzacji. Wybierz Test Komponowania lub Espresso, kiedy Twój zespół jest właścicielem aplikacji i potrzebuje asercji blisko swojego kodu UI. Wybierz Automator UI, gdy test musi przekroczyć granice aplikacji lub wchodzić w interakcje z UI systemu Android. Wybierz Appium, gdy ma znaczenie klient w stylu WebDriver-, kilka języków programowania lub wspólna warstwa automatyki Android i iOS. Dodać obserwowalny przepływ wizualny, gdy recenzent musi oglądać prawdziwy telefon, rozpoznać widoczny stan, zebrać zrzuty ekranu lub modelować operacyjny przepływ pracy poza kodem testowym aplikacji.
Narzędzia te rozwiązują różne warstwy tego samego problemu jakości.Oficjalne wytyczne dotyczące testowania interfejsu użytkownika Androiddefiniuje testy UI jako uruchamianie aplikacji, symulowanie interakcji i sprawdzanie poprawnej reakcji. Dlatego przydatny wybór narzędzia rozpoczyna się od dowodów, które musi wytworzyć test, granicy oprogramowania, którą musi przekroczyć, i kto ją utrzyma. Jest to porównanie oparte na badaniach obecnej oficjalnej dokumentacji, a nie punkt odniesienia, twierdząc, że jedna struktura jest ogólnie szybsza lub bardziej wiarygodna.
- App-owned View UI: start with Espresso.
- App-owned Jetpack Composite UI: start with Composite testing API.
- Interfejs systemowy, uprawnienia, wielookienne lub cross- app behavior: rozpocząć od UI Automator.
- Cross- platform WebDriver automatyzacja i elastyczność językowa klienta: ocena Appium.
- Widoczne czarne skrzynie pracy, OCR, stan obrazu i reviewer- przyjazne dowody: dodać wizualną warstwę przepływu.
Narzędzia do testowania automatyki Android w porównaniu
| Narzędzie lub podejście | Najlepsze dopasowanie | Granica wykonania | Selektory pierwotne lub dowody | Główny handel-off |
|---|---|---|---|---|
| Badanie składu | Aplikacje zbudowane z kompozytem Jetpack | Aplikacja lub element badany | Semantyka, atrybuty, działania, twierdzenia | Wymagany jest test-aware Kod kompozycji i ustawienia testu Android |
| Espresso | Testy zachowania oparte na aplikacji View- | Testowana aplikacja | Zobacz matchers, działania, twierdzenia | Niezaprojektowane jako główne narzędzie do szerokich podróży aplikacji |
| Automator UI | System UI, cross- app, multi- window, end- to- end ścieżki Android | Urządzenie Interfejs i zainstalowane aplikacje | węzły dostępności, przewidywania, zrzuty ekranu, stan aplikacji | Specyficzny dla Androida i zazwyczaj utrzymywany w łańcuchu narzędzi do testów na Androidzie |
| Appium z UiAutomator2 | Automatyzacja mobilna w stylu WebDriverName | Klient serwera Appium i sterownika Android | Lokalizatory, funkcje, polecenia sterowników | Więcej części ruchomych: serwer, sterownik, SDK, JDK i konfiguracja urządzenia |
| Przepływ wzrokowy | Obserwowalne kontrole realfonów i operacyjne przepływy pracy | Widoczny stan urządzenia spoza kodu aplikacji | UI drzewo, OCR, szablony, obrazy, zrzuty ekranu, gałęzie | Nie zastępuje twierdzeń jednostki, komponentu lub oprzyrządowania |
Stolik to mapa graniczna, a nie tablica zwycięzców. Dojrzałe zespoły często łączą kilka rzędów. Ekran Komponujący może mieć szybkie testy zachowania komponentów, ścieżkę Automatora UI dla uprawnień i przejść systemowych, pakiet Appium współdzielony z iOS, oraz niewielki monitorowany przepływ telefonu real- phone, który rejestruje dowody po wdrożeniu. Duplikacja staje się problemem tylko wtedy, gdy dwa apartamenty wykazują ten sam wymóg przy tym samym koszcie urządzenia.
Użyj Testów kompozycji lub Espresso do zachowania app-owned
Komponowanie testów i Espresso są najsilniejszymi punktami wyjściowymi, kiedy zespół kontroluje kod aplikacji i wymóg jest semantyczne zachowanie wewnątrz tej aplikacji.Komponowanie API testowaniaznaleźć elementy poprzez semantykę, zweryfikować atrybuty, wykonać działania i zsynchronizować z UI.Espresso wykorzystuje matchery, działania i twierdzeniadla interfejsów opartych na View- a, jednocześnie zniechęcających do niebezpiecznego bezpośredniego dostępu do działań i poglądów z niewłaściwego wątku.
Ta bliskość aplikacji jest przydatna. Badania mogą wstrzykiwać dane determinacyjne, odizolować komponent, włączyć asert lub wybrany stan, a nie z konkretną semantyczną przyczyną. Oznacza to również, że apartament jest połączony z architekturą aplikacji i konstrukcją testową. Ten sprzęg jest odpowiedni, gdy wymóg należy do aplikacji: pojawia się komunikat zatwierdzający, nawigacja wybiera właściwe miejsce docelowe lub przycisk pozostaje wyłączony do czasu, gdy istnieje prawidłowe wejście.
Wybierz test kompozycji, gdy
- Interfejs jest głównie Jetpack Komponować i ujawnia przydatne semantyki.
- Potrzebujesz testów na poziomie komponentu z kontrolowanym stanem oraz testów na poziomie aktywności.
- Idle synchronizacji i Compose- specyficzny czas kontroli pomóc asercji deterministyczne.
Wybierz Espresso kiedy
- Aplikacja jest oparta na View- lub ma ekrany View, które wymagają testów zachowania.
- Test może identyfikować jeden widok za pomocą identyfikatora zasobu lub skoncentrowanego matchera.
- Warunkiem jest interakcja i asertyzacja wewnątrz aplikacji, a nie szeroka podróż.
Użyj Automatora UI dla systemu Android i ścieżek aplikacji krzyżowej
Interfejs Automator wygrywa, gdy urządzenie z systemem Android jest częścią granicy testowej.Nowoczesny interfejs Automator APImożna uruchomić aplikacje, znaleźć elementy z przewidywaniami, obsługiwać dialogi uprawnień, czekać na widoczność aplikacji lub stabilne drzewo dostępności, przeglądać wiele okien i rejestrować zrzuty ekranu. Te możliwości pasują do promów o zezwoleniach, ekranów ustawień, powiadomień, obrazków, ekranu split- screen, zachowań wyrzutni i podróży, które poruszają się między zainstalowanymi aplikacjami.
Ważnym rozróżnieniem nie jest to, że UI Automator jest po prostu "potężniejszy" niż Espresso. Zwraca uwagę na UI z innej pozycji. Ta pozycja zewnętrzna widzi powierzchnie systemu i cross- app, ale ma mniej bezpośredni dostęp do wewnętrznych aplikacji i podwójne testy. Użyj go do cienkich ścieżek końcowych, które naprawdę potrzebują granicy urządzenia; zachować większość logiki aplikacji w szybszych, bardziej skoncentrowanych testów.
Wbieżąca dokumentacja UI Automatorzawiera również built- in conditional element timeout, wyraźna stabilność czeka, screenshots i raportowanie wyników. Te cechy zmniejszają pokusę polegania na stałych spach. Dokumentacja zauważa, że stabilność drzewa accessibility- nie udowadnia, że każde zadanie w tle jest bezczynności, więc najlepsze oczekiwanie pozostaje o nazwie warunek aplikacji, gdy jest dostępne.
Użyj Appium, gdy warstwa mobilna w stylu WebDriver ma znaczenie
Appium jest silnym kandydatem, gdy organizacja chce automatyzacji mobilnej z JavaScript, Java, Python, Ruby lub .NET, już używa koncepcji WebDriver lub chce powiązanych apartamentów Android i iOS za jednym modelem serwera automatyzacji. Na Androidzie,oficjalny szybki start UiAutomator2instaluje sterownik, wybiera go z nazwą automatyki UiAutomator2 i łączy się z emulatorem lub urządzeniem do debugowania USB- poprzez łańcuch narzędzi Android.
Ta elastyczność wiąże się z kosztami operacyjnymi. Wudokumentowane ustawieniezawiera serwer Appium, sterownik platformy, Android SDK i narzędzia platformy, kompatybilny JDK, przygotowanie urządzenia, możliwości i zależności klienta. Naszym zaleceniem redakcyjnym jest posiadanie tych wersji wyraźnie i zatwierdzenie konfiguracji z polecenia lekarza kierowcy zamiast utrzymania nieudokumentowanego przepisu laptopa.
Appium nie jest automatycznie najlepszym wyborem tylko dlatego, że przyszły pakiet iOS jest możliwy. Jeśli aktualnym wymogiem jest mała kodebaza tylko Android z głębokim dostępem do stanu aplikacji, testy natywnego Android mogą pozostać prostsze. Jeżeli platforma QA już standaryzuje sesje urządzeń, klientów językowych, obiektów raportowania i cross- platform, wspólny model Appium może uzasadnić dodatkowe warstwy.
Dodawanie przepływu wizualnego dla obserwowalnych przepływów pracy w polu black- box
Przepływ wizualny jest przydatny, gdy istnieje wymóg, który osoba może obserwować na prawdziwym telefonie, a przepływ pracy musi być zrozumiały poza repozytorium aplikacji. Przykłady obejmują kontrolę dymu po wdrożeniu, reprodukcję wsparcia, ścieżkę operacyjną przez aplikacje trzeciej partii, lokalną kontrolę widocznego tekstu lub zadanie nadzorowanego urządzenia, które musi się zatrzymać zrzut ekranu, gdy stan jest nieznany.
LaiCai Flowmoże łączyć parsowanie UI, odnajdywanie elementów, krany, wejście tekstowe, oczekiwania, oddziały, powtarzanie ograniczone, zrzuty ekranu, OCR, dopasowanie szablonów, wykrywanie obiektów, przepływ dzieci i wyraźne zwroty lub zatrzymania zachowania. To sprawia, że ścieżka decyzyjna staje się widoczna: obserwować stan o nazwie, pozwolić na jedno działanie, zweryfikować stan i zachować dowody na niepowodzenie.LaiCai Flow Insidemoże uruchomić kompatybilny profil poprzezLaiCai Android Agentpo wdrożeniu, ale zgodność zależy od każdego węzła i aktywów wykorzystywanych przez ten profil.
Warstwa ta powinna uzupełniać - a nie zastępować - app- native twierdzenia. OCR jest właściwe, gdy widoczny tekst jest dowodem, ale drzewo UI nie ujawnia go niezawodnie. Dopasowanie szablonu jest odpowiednie dla zwalidowanego celu wizualnego. Zrzut ekranu jest przydatny do oceny składu lub awarii. Żaden z nich nie zastępuje testu jednostkowego logiki biznesowej ani dokładnego twierdzenia komponującego, gdy dostępny jest kod źródłowy. WPrzewodnik do testów wizualnych Androidwyjaśnia, jak wybrać między tymi rodzajami dowodów.
Zbudować warstwową strategię testów Android
- Zapisać wymóg jako obserwowalny wynik, a nie sekwencję kranów.
- Umieść logikę biznesową w testach lokalnych lub części, w których interfejs urządzenia jest niepotrzebny.
- Użyj Testowanie kompozycji lub Espresso do zachowania się i twierdzeń semantycznych.
- Dodaj Automator UI tylko dla granic systemowych, wielookiennych, uprawnień lub cross-app.
- Korzystanie z Appium, gdy jego serwer, klienci, raportowanie lub cross-platform model zapewnia konkretną wartość organizacyjną.
- Dodaj wizualny przepływ real- phone dla dowodów, że apartamenty na poziomie kode- nie może produkować wyraźnie.
- Utrzymuj wąską ścieżkę end-to-end, definiuj stan początkowy, zwiąż każde oczekiwanie i powtórnie, i przechwyć stan awarii zanim odzysk go zmieni.
Jeden wymóg powinien mieć jednego głównego właściciela. Na przykład, walidacja formularza należy do testów na poziomie app; przekazanie zezwolenia należy do ścieżki Automatora UI; wspólna umowa z systemem Android i systemem iOS może należeć do Appium; a po wydaniu real- phone proof run może należeć do przepływu wizualnego. Warstwy mogą odnosić się do tej samej podróży użytkownika bez kopiowania każdego twierdzenia do każdej ramy.
Wreal- phone QA-test przewodnikpokazuje, jak utrzymać rozmieszczonych kontroli małe i powtarzalne. Wprowadnica stopu automatykiobejmuje timeout, ograniczone powtórzenia, warunki pocztowe i przegląd człowieka, gdy obecny ekran nie uzasadnia już kolejne działanie.
Praktyczna lista kontrolna wyboru
| Pytanie | Jeśli tak, zacznij od |
|---|---|
| Czy posiadasz interfejs komponowania i potrzebujesz komponentu semantycznego lub asercji ekranu? | Badanie składu |
| Czy posiadasz interfejs użytkownika na bazie View- i potrzebujesz ukierunkowanych testów zachowania aplikacji? | Espresso |
| Czy ścieżka musi przekraczać ustawienia, uprawnienia, wyrzutnię, okna lub inną aplikację? | Automator UI |
| Czy zespół wymaga klientów WebDriver lub wspólnej architektury automatyki Android i iOS? | Appium |
| Czy niedeweloper musi przeglądać stan widoczny, OCR, obrazy lub zrzuty ekranu na prawdziwym telefonie? | Przepływ wzrokowy |
| Czy wymóg jest głównie logika biznesowa bez urządzenia UI zależności? | Brak: użyć jednostki lokalnej lub testu integracji |
Przed przyjęciem nowej ramy prototyp jednej reprezentatywnej ścieżki i zapisać pełną powierzchnię konserwacji: kod testowy, haki aplikacji, wersje serwera lub sterownika, reset urządzenia, dane testowe, uprawnienia, zrzuty ekranu, logi i własność CI. Najlepszym narzędziem jest ten, który produkuje wiarygodne dowody po kosztach utrzymania zespół faktycznie zapłaci.
Narzędzia do testowania automatyki Android FAQ
Czy UI Automator jest taki sam jak Appium UiAutomator2?
Nie.Interfejs Automator to biblioteka testowa Android i API.Sterownik UiAutomator2 firmy Appium jest sterownikiem platformy Appiumza warstwą Appium / WebDriver. Ich konfiguracja, model klienta i granice utrzymania są różne, nawet jeśli nazwy są powiązane.
Czy Appium może zastąpić test Espresso lub Composite?
Może zautomatyzować wiele z tych samych widocznych podróży, ale naszym zaleceniem nie jest zastąpienie każdego testu na poziomie app.Badanie składuorazEspressosą bliżej stanu aplikacji i semantyczne zachowanie UI. Appium jest najbardziej cenne, gdy jego zewnętrzny klient, architektura kierowcy lub konsystencja cross-platform jest częścią wymogu.
Które narzędzie jest najlepsze do testowania aplikacji trzeciej partii?
Interfejs Automator, Appium, lub recendowany przepływ wizualny czarnej skrzynki są bardziej odpowiednie niż app-wewnętrzne ramy, gdy nie posiadają docelowy kod aplikacji. Potwierdź, że automatyzacja jest autoryzowana, użyj stabilnych, obserwowalnych selektorów, unikaj delikatnych lub destrukcyjnych działań i oczekuj, że trzypartyjne zmiany interfejsu będą wymagały konserwacji.
Czy przepływy wizualne działają w ciągłej integracji?
Mogą uczestniczyć w automatycznym rurociągu, jeżeli sesja urządzenia, aktywa, wejścia, artefakty awarii i interfejs wyników są kontrolowane. Jednakże nadzorowany strumień pracy w zakresie telefonii stacjonarnej i ramy twierdzenia CI służą różnym modelom operacyjnym. Zdecyduj najpierw, czy bieg musi zablokować budowę, przedstawić dowody przeglądu lub pomóc osobie.
Wybierz najmniejszą granicę narzędzia, która potwierdza wymóg
Rozpocząć blisko kodu i rozszerzyć na zewnątrz tylko wtedy, gdy wymaga tego wymóg. Skomponować testy i Espresso udowodnić odpowiednie zachowanie. Interfejs Automator udowadnia system Android i ścieżki cross-app. Appium dostarcza warstwę automatyki mobilnej w stylu WebDrivera. Wizualny przepływ dodaje widoczny stan real- phone, OCR, dowód obrazu i operacyjne przekazanie, że nie-developerzy mogą przejrzeć.
Najsilniejsza strategia automatyki systemu Android nie jest zatem standardem jednego narzędzia. Jest to udokumentowany podział odpowiedzialności: jeden główny właściciel twierdzenia na każde wymaganie, cienkie pokrycie końcowe na drogich granicach, wyraźne warunki zatrzymania i dowody niepowodzenia, które informują następną osobę, co się stało. PoznajAI Android automatyzacja zLaiCai Flowgdy ta obserwowalna warstwa przepływu roboczego pasuje do przypadku użycia.
Nota redakcyjna:BeePOS LLC, firma zaLaiCai Screen Mirroring, zbadał to porównanie z oficjalną dokumentacją Android i Appium powiązaną z odpowiednimi twierdzeniami poniżej. Sekcja produktu jest oznaczona oddzielnie, dzięki czemu czytelnicy mogą odróżnić udokumentowane możliwości ramowe od naszych własnych zaleceń dotyczących przepływu pracy. Pytania lub poprawki można wysłać na adres support @ laicaiapp.com.