Automatyzacja laboratorium Android: urządzenia i emulatory

Zmień małą pulę telefonów z Androidem i emulatorów w powtarzalne laboratorium urządzeń z wyraźnymi stanami startowymi, obserwowalne kontrole, ograniczone oczekiwania, dowody awarii, i jasne build- versus- buy regule.

Krótka odpowiedź: zautomatyzować pętlę operacyjną, a nie półkę

Laboratorium urządzeń Android staje się przydatne, gdy każdy bieg rozpoczyna się od określonego stanu, wykonuje jeden ograniczony czek, weryfikuje stan i pozostawia dowody, które inna osoba może przejrzeć. Telefony, centra USB, stoiska i etykiety są tylko warstwą fizyczną. Automatyzacja laboratorium Android to warstwa operacyjna, która przekształca te urządzenia w powtarzalne uwolnienie, wsparcie i kontrole lokalizacji.

Jeśli nadal wybierasz telefony, kable, zasilanie lub przechowywanie, rozpocząć odniskowartościowy poradnik konfiguracji urządzenia AndroidTen artykuł zaczyna się po tym, jak ten sprzęt istnieje. Wyjaśnia jak połączyć prawdziwe urządzenia i emulatory, zdefiniować małą matrycę testową, stworzyć kartę uruchamiania urządzenia, synchronizować na obserwowalnym stanie, przechwycić zrzuty ekranu i logi, i zdecydować, kiedy hostowane urządzenie chmura jest lepszym wyborem.

Celem nie jest zastąpienie testów jednostkowych, Testy komponujące, Espresso, Automator UI, Appium, Urządzenia do zarządzania zbożem lub Firebase Test Lab. Te narzędzia mają inne granice. AnAI Android narzędzie do automatyzacjijest tu najbardziej przydatna jako widoczna warstwa przepływu pracy do kontroli urządzeń realnych, które operatorzy, recenzenci QA i zespoły wsparcia muszą zrozumieć.

Dać prawdziwe urządzenia i emulatory różnych miejsc pracy

Laboratorium nie potrzebuje każdego testu na każdym urządzeniu. Emulatory szybko tworzą, resetują, parametryzują i biegną równolegle. Prawdziwe telefony ujawniają firmware sprzedawcy, kamery fizyczne, Bluetooth, biometryczne promby, zachowanie termiczne, ograniczenia tła, dostarczanie powiadomień, stan USB i powierzchnie wejściowe, które wirtualne urządzenie może nie powielać wiernie. Użyj tych różnic do podziału odpowiedzialności zamiast argumentowania za jedną uniwersalną platformą.

Praktyczny wzór startowy to szeroki wirtualny poziom i wąski poziom fizyczny. Uruchom szybkie kontrole deterministyczne w wirtualnych konfiguracjach, a następnie przekierować mały pakiet krytyczny przez dwa lub trzy prawdziwe telefony wybrane dla rzeczywistego ryzyka klienta. Rozwiń tylko wtedy, gdy dane o awarii pokazują, że inny model, wersja Android, locale lub zachowanie sprzedawcy zmienia wynik.

Zdefiniuj macierz urządzenia z jednym powodem w wierszu

Firebase Test Lab opisuje matrycę testową jako kombinację wybranych urządzeń i konfiguracji testowej. Pomysł ten działa również na miejscowe laboratorium, ale matryca powinna być raczej oparta na ryzyku niż wyczerpująca. Każdy rząd potrzebuje powodu, właściciela i oczekiwanej decyzji. Telefon, który istnieje tylko dlatego, że był dostępny będzie spokojnie zużywać ładowania, resetować i czas konserwacji bez poprawy zaufania do wydania.

• Zachowaj jeden bieżący poziom bazowy Android dla głównej ścieżki wydania.
• Zachować jeden starszy obsługiwany poziom API dla kompatybilności i uaktualnienia zachowania.
• Dodawanie jednego prawdziwego telefonu specyficznego dla Vendorów tylko wtedy, gdy jego oprogramowanie firmowe, uprawnienia, polityka baterii lub udział klienta stwarza szczególne ryzyko.
• Dodaj konfigurację na małym ekranie lub w skali high-font- scale, gdy układ i dostępność mają znaczenie.
• Dodaj lokal, motyw, orientację, sieć lub stan konta tylko do kontroli, których wynik może się zmienić pod tym warunkiem.
• Wiersze macierzy Retire, które nie znajdują już różnych wad lub obsługują obecny segment klienta.

Nazwa decyzji każdy wiersz obsługuje: zablokować wydanie, zebrać dowody przeglądu, odtworzyć przypadek wsparcia, lub zbadać podejrzewany device- specyficzny błąd. Decyzja ta kontroluje, ile niezawodności, izolacji i sprawozdawczości potrzebuje wiersz. Bloker wydania wymaga mocniejszych zasad resetowania i asertyfikacji niż nadzorowane kontrole rozpoznawcze.

Utwórz kartę startową przed automatyzacją zapisu

Najmniejszą użyteczną specyfikacją do sprawdzenia laboratoryjnego jest karta startowa. Zapobiega ukrytym założeniom życia w pamięci jednego operatora i daje automatyzację stabilnego kontraktu. Przed wybraniem węzłów, selektorów lub kodu ramowego zapisz kartę w widocznych warunkach.

Nie definiuj sukcesu jako sekwencji kranów. Określić stan widoczny lub ustrukturyzowany, który musi istnieć po sekwencji. Układy UI zmieniają się; warunki biznesowe są bardziej trwałe. Sprawdzenie logowania jest skuteczne, ponieważ istnieje oczekiwany stan konta i powierzchnia domu, a nie dlatego, że automatyzacja dotykała współrzędnych, gdzie był kiedyś przycisk.

Zmień stan bez wymazywania dowodów

Współdzielone urządzenia zawodzą w sposób, który wygląda jak wady aplikacji: nieregularne konta, zgoda buforowana, w oczekiwaniu na aktualizacje, zmienione uprawnienia, niskie przechowywanie, nieoczekiwana klawiatura, otwarte okno systemowe, narzucenie powiadomień, lub poprzedni bieg lewo w połowie przez wymeldowanie. Zresetuj tylko stan nazwany przez kartę startową i przechwyć awarię zanim odzysk ją zmieni.

1. Zidentyfikować urządzenie i zbudować przed dotknięciem stanu.
2. Uchwyć bieżący ekran, gdy poprzedni bieg zakończył się niespodziewanie.
3. Zwrócić aplikację do deklarowanego stanu startowego używając najmniej destrukcyjnego resetu, który jest wystarczający.
4. Potwierdź sieć, czas, przechowywanie, orientację, lokalizację, skalę czcionki i wymagane uprawnienia.
5. Weryfikacja znacznika stanu startowego przed pierwszym działaniem biznesowym.
6. Kwartalny urządzenie, jeśli reset wielokrotnie nie powiodło się; nie konwertuj awarii infrastruktury w błąd produktu.

Pełne wycieranie nie jest automatycznie bezpieczniejsze. Może zniszczyć dokładny stan potrzebny do odtworzenia wady i dodaje czas konfiguracji, który zachęca zespoły do pomijania kontroli. Zachowaj oddzielne profile do świeżej instalacji, upgraded-install, signed- in, signed- out i restored- account, gdy te stany niosą różne zagrożenia.

Synchronizuj stan zamiast dłużej spać

Wskazówki Android stabilności ostrzega przed arbitralnym spaniem, ponieważ wydajność urządzenia i asynchroniczna praca różnią się. Stałe opóźnienie może być zbyt krótkie na telefon zajęty i niepotrzebnie powolne na szybki. Preferuj wyraźne oczekiwanie na znaczący warunek, z timeout i artefakt awarii, gdy ten warunek nigdy się nie pojawia.

• Po uruchomieniu aplikacji, czekać na stabilny element interfejsu użytkownika lub stan ekranu, a nie odgadnąć liczbę sekund.
• Po naciśnięciu, zweryfikuj stan przed wysłaniem następnego wejścia.
• Użyj ograniczonego powtórzenia dla stanów, które naprawdę potrzebują sondażu; napisz końcową obserwację dotyczącą czasu.
• Traktuj dialogi autoryzacji systemu, uaktualnij podpowiedzi i nakładki OEM jako nazwane gałęzie, a nie przypadkowy hałas.
• Zatrzymaj, gdy widoczny stan znajduje się poza zatwierdzonym zbiorem, zwłaszcza przed dokonaniem płatności, usunięciem, zgodą lub zmianą konta.

BieżącyLaiCai FlowKontrakt jest zgodny z tym widocznym modelem: obserwacje UI, OCR, dopasowanie szablonów oraz stan obserwacji przechwytywania ekranu; węzły wejściowe i wskaźnik wykonują jedną operację; uchwyty węzłów przepływu czekają, gałęzie, pętle ograniczone, przepływy dziecka, zwroty i zatrzymania. Prowadzenie odrębnej obserwacji, decyzji i działań ułatwia dokonywanie przeglądów i jest bezpieczniejsze.

Zbuduj czytelnyLaiCai Floww przypadku kontroli laboratoryjnych

LaiCai Flowjest funkcją automatyzacji wewnątrzLaiCai Screen Mirroring. Dla device- lab run, zachować główny przepływ na poziomie recenzent QA może przeczytać: przygotować urządzenie, otwarty cel, uruchomić krytyczne sprawdzenie, zebrać dowody i zakończyć. Umieść wieloetapowe szczegóły techniczne w małych ruchach dzieci zamiast odsłonić długi łańcuch meczów, selekcji, kranów i czeka. WLaiCai Flowprzewodnikwyjaśnia jak organizowane są Profile i Flows.

1. Przeczytaj kontekst connected- device i wybierz zamierzony pseudonim seryjny; nie zakładaj, że pierwsze urządzenie jest poprawne.
2. Potwierdź pakiet i aktualny stan interfejsu użytkownika przed otwarciem lub zmianą aplikacji.
3. Użyj interfejsu użytkownika, gdy informacje o dostępności są stabilne, OCR, gdy widoczny tekst jest dowodem, i szablon dopasowujący tylko dla zatwierdzonego celu obrazu.
4. Wyraźne zaczekanie pomiędzy działaniami a późniejszymi obserwacjami zależnymi od scenariusza.
5. Sprawdź stan po każdej fazie, która zmienia stan ekranu lub aplikacji.
6. Uchwyć zrzut ekranu lub nagranie tylko wtedy, gdy obsługuje o nazwie decyzji przeglądu.
7. Zwrot wyraźnego wyniku fazy; zatrzymanie biegu, gdy kolejne działanie nie jest uzasadnione obecną obserwacją.

Podczas przygotowywania do tego przewodnika, kontekst read- tylko LaiCai poinformował 73 dostępne typy węzłów i jeden podłączony telefon Samsung Android 16. Potwierdza to obecną umowę i ścieżkę uświadamiania, która nie jest punktem odniesienia dla wyników. Weryfikacja własnej aplikacji, urządzeń, aktywów i obsługi runtime przed traktowaniem Profile jako infrastruktury wydania.

Zbierz pakiet awarii, nie czerwoną kropkę

Nieudany sprawdzian powinien odpowiadać na to, co uruchomiono, gdzie uruchomiono, co system zaobserwował i dlaczego bieg się zatrzymał. Firebase Test Lab ujawnia użyteczny model, zwracając status testu wraz z logami, zrzutami ekranu i filmami, jeśli są dostępne. Lokalne laboratorium potrzebuje tej samej dyscypliny, nawet jeśli jego przechowywanie jest prostsze.

• Uruchom ID, timestamp, Workflow version, build version i environment.
• Model urządzenia, wersja Android, stabilny pseudonim seryjny, rozmiar ekranu, locale, motyw i orientacja.
• Uruchom stan, identyfikator urządzenia wejściowego i ostatnią zakończoną fazę biznesową.
• Oczekiwany stan postcondition i rzeczywisty wybrany wynik UI, OCR, obrazu lub framework.
• Zrzut ekranu przed odzyskaniem, krótkie nagranie tylko wtedy, gdy ruch ma znaczenie, i ograniczony odpowiedni fragment dziennika.
• Klasyfikacja: defekt produktu, defekt testu, infrastruktura urządzenia, dane, środowisko lub wymaga przeglądu przez człowieka.

Użyj stabilnych nazw plików i manifestu zamiast nieuporządkowanego folderu screenshot. Redakcyjne dane osobowe lub tajne przed udostępnieniem. Nie wysyłaj całego dziennika urządzeń, gdy wystarczy krótki odstęp czasu od awarii. Dowody powinny ograniczyć pracę następnej osoby bez tworzenia nowego problemu prywatności lub zatrzymania.

Wybierz kontrole, które zdobywają czas urządzenia

Prawdziwe minuty urządzenia są ograniczone, ponieważ urządzenia wymagają ładowania, czyszczenia, aktualizacji i dostępu człowieka. Daj je do pracy, których widzialne lub fizyczne zachowanie ma znaczenie. Dobrymi pierwszymi kandydatami są po wdrożeniu kontroli dymu, zezwolenia i systemu- UI ścieżki, aparat lub Bluetooth konfiguracja, przepływy powiadomień, dowody lokalizacji, regresje swoiste vendor- i dokładne reprodukcje wsparcia.

Zachowaj logikę biznesową, parsowanie, formatowanie i zachowanie komponentów w szybszych testach blisko kodu. Używanie prawdziwego urządzenia do udowodnienia granic, których te testy nie mogą udowodnić: zainstalowanej budowy, systemu operacyjnego, zewnętrznej aplikacji, powierzchni wejściowej, przejścia sieciowego lub widocznej dla człowieka kompozycji. WPorównanie narzędzi do testowania automatyki Androidpomaga przyporządkować każdy wymóg do odpowiedniej warstwy.

Krytyczna paczka pięciu niezawodnych podróży jest cenniejsza niż pięćdziesiąt przepływów, którym nikt nie ufa. Zacznij od jednej reprezentatywnej ścieżki, zmierzenia resetu i kosztów triage, a następnie dodaj pokrycie tylko wtedy, gdy nowa kontrola chroni konkretne wydanie, klienta lub decyzji operacyjnej.

Zmierz laboratorium zanim go wyskalujesz

Zespoły dyskutujące na temat samohostowanych gospodarstw urządzeń wielokrotnie powracają do tych samych wejść build- versus- buy: zachowanie kolejki, szczytowa zbieżność, czas oczekiwania, uruchomienie lub reset awarii, wysiłek konserwacyjny i wady, które pojawiają się tylko na urządzeniach fizycznych. Namierz te sygnały przez kilka cykli wydania przed zakupem więcej sprzętu lub migracji wszystko do chmury.

• Kolejka czeka na godzinę i priorytet przepływu pracy.
• Wykorzystanie urządzenia i czas niedostępny do ładowania, aktualizacji lub naprawy.
• Uruchomić stan lub zresetować awarię przez urządzenie.
• Reruny spowodowane przez płaskostopie automatyzacji, a nie zmiany produktu.
• Mediana czasu od niepowodzenia do przydatnej klasyfikacji.
• Odrębne wady wykrywane tylko na prawdziwych urządzeniach, konkretnych sprzedawcach lub konkretnych wersjach Android.
• Minuty operatora na udany przebieg i na utrzymywany przepływ pracy.

To są wskaźniki zarządzania, a nie deski rozdzielcze. Jeśli kolejka oczekujących jest niska, ale utrzymanie dominuje, usługi hostowane mogą zmniejszyć koszty własności. Jeżeli prywatność, lokalne urządzenia peryferyjne, szybkie interaktywne debugowanie lub powtarzające się odtwarzanie ma więcej znaczenia niż szeroki zakres modeli, małe lokalne laboratorium może pozostać właściwym środkiem ciężkości.

Użyj hybrydowej zasady build- versus- buy

Lokalne i hostowane laboratoria są uzupełnieniem. Urządzenia zarządzane ogrodem mogą definiować urządzenia wirtualne w konstrukcji i grupować je do wykonywania testów. Firebase Test Lab może rozszerzyć matrycę na hostowane urządzenia wirtualne i fizyczne i zwrócić zarządzane artefakty. Lokalna pula zapewnia natychmiastowy dostęp, zastrzeżone urządzenia peryferyjne, nadzorowane debugowanie oraz stabilne urządzenia do powtarzających się kontroli operacyjnych.

Rozsądna hybryda utrzymuje szybkie testy ramowe na zarządzanej wirtualnej infrastrukturze, wysyła wybrane kontrole zgodności do prawdziwych urządzeń i zachowuje małą miejscową ławkę dla wysokiej wartości fizycznych lub nadzorowanych przepływów. Właściwy podział może się zmienić jako zmienna, prywatność i zmienność dowodu urządzenia użytkownika.

Lista kontrolna do automatyzacji laboratorium Android

1. Przypisz jeden cel i decyzję do każdego wiersza macierzy device-.
2. Oddzielny emulator, lokalne real- device, host, framework-test, i wizualny przepływ odpowiedzialności.
3. Utwórz kartę startową z build, device, start state, inputs, postconditions, stops, and proof.
4. Weryfikacja stanu początkowego przed pierwszym działaniem biznesowym.
5. Czekać na obserwowalne warunki zamiast dodawać dłuższe ślepe snu.
6. Zachować obserwacje, decyzje i działania urządzeń jako oddzielne etapy kontroli.
7. Uchwycić dowody przed resetem lub odzyskanie zmienia błąd.
8. Utajnienie infrastruktury, danych, testów, środowiska i wad produktu oddzielnie.
9. Kolejka utworów, wykorzystanie, resetowanie niezawodności, powtarzanie zwrotów, czas próby i tylko fizyczne wady.
10. Użyj hybrydowej strategii local- i-host, gdy dowody ją wspierają.

Zacznij od jednego prawdziwego telefonu, konfiguracji emulatora i jednej karty startowej. Sprawcie, aby pętla była niezawodna i możliwa do przewidzenia przed dodaniem innego urządzenia lub przepływu pracy. Kiedy obserwowalna warstwa device- lab pasuje do zespołu, odkryjAI Android automatyzacja zLaiCai Flowi zachować szczegóły wdrażania wprzewodnik Flow.

Nota redakcyjna:BeePOS LLC, firma zaLaiCai Screen Mirroring, badał ten przewodnik za pomocą oficjalnej dokumentacji Android i Firebase podłączony poniżej, aktualne tylko ponownie LaiCai produktów umów, i publicznych dyskusji QA. Możliwości produktu są identyfikowane oddzielnie od wytycznych dotyczących neutralnego przepływu pracy. Pytania lub poprawki można wysłać na adres support @ laicaiapp.com.

• Deweloperzy systemu Android: Przeskaluj swoje testy z urządzeniami zarządzanymi przez Gradle
• Android Developers: Stabilność testu
• Firebase Test Lab: Zacznij od testów na Androidzie
• Reddit r / QualityAssurance: utrzymanie infrastruktury emulatora Android
• Android Developers: UI Automator