Mobile UI-Automatisierung entwickeln und Fehler im Produkt statt in der CI beheben

## Jede Änderung in das Modul legen, das für das Verhalten zuständig ist Pflege eine knappe Modulübersicht, die zeigt, wo Code ausgeführt wird und wer seine Artefakte nutzt. Trenne mindestens folgende Verantwortungsbereiche: - geräteseitige Treiber und ihre erzeugten Binärdateien; - hostseitige Plattformadapter und Protokollclients; - Befehlsauswertung, Wiederholungen, Lebenszyklussteuerung und Fehlerklassifizierung; - gemeinsam genutzte Befehls- und Datenmodelle; - Befehlszeilen- und Agentenschnittstellen; - Webtreiber, Übertragungsformatdefinitionen, Hilfsfunktionen und modulübergreifende Tests. Nimm eine Änderung dort vor, wo die Zuständigkeit für das Verhalten liegt. Geräteinteraktion und Systemdialogbehandlung gehören in Plattformtreiber oder Hostadapter, Wiederholungen und Befehlsreihenfolgen in die Ablaufsteuerung und gemeinsam genutzte Anfrageformen in Modell- oder Protokollmodule. Löse ein Zuständigkeitsproblem nicht in einem entfernten Modul, nur weil sich dort leichter ein Patch einfügen lässt. Behandle die Übersicht als einzige maßgebliche Quelle für Arbeitsabläufe und Fachagenten. Aktualisiere sie bei geänderten Modulzuständigkeiten, damit nachgelagerte Anleitungen nicht abweichen. ## Die günstigste Testebene wählen, die das Verhalten belegt Nutze eine gestufte Teststrategie und wähle grundsätzlich die günstigste Ebene, die das Verhalten nachweisen kann: 1. Komponententests für isolierte Klassen, Auswertung, kleine Hilfsfunktionen und lokale Entscheidungslogik. 2. Integrationstests für Befehlsabläufe, Abbruch, Skriptausführung, Netzwerkgrenzen und mehrere Module, die ohne Gerät zusammenwirken können. 3. Ende-zu-Ende-Tests für echte Treiber, Geräte- oder Browserverhalten, Betriebssystemintegration und vollständige Benutzerabläufe. 4. Agentenschnittstellenbewertungen für Modellverhalten und Werkzeugkorrektheit, wenn das Produkt ein KI-gerichtetes Protokoll bereitstellt. Verschiebe einen Test nicht auf eine teurere Ebene, wenn Ersatzobjekte oder prozessinterne Komponenten den Vertrag genau abbilden können. Ersetze umgekehrt gerätebezogene Nachweise nicht durch Attrappen, wenn das Risiko im Plattformverhalten liegt. ## Testsammlungen, die bestehen müssen, von denen trennen, die scheitern müssen Trenne Ende-zu-Ende-Abläufe nach dem erwarteten Ergebnis. Eine positive Testsammlung enthält Abläufe, die erfolgreich sein müssen; jeder Fehlschlag ist ein Rückschritt. Eine negative Testsammlung enthält absichtlich ungültige Prüfungen oder Befehle und muss auf die erwartete Weise fehlschlagen. Das Testgerüst kann die Erfolgsbewertung der negativen Sammlung umkehren. Deshalb muss die Auswertung der Artefakte die Sammlungskennzeichnung bewahren. Deute ein erwartetes negatives Ergebnis niemals als Produktfehler und schwäche oder verändere einen negativen Ablauf nicht bloß, damit er erfolgreich erscheint. Wenn eine automatische Diagnose Artefakte verarbeitet, beschränke sie auf echte Fehlschläge der positiven Sammlung, sofern ihr Vertrag nicht ausdrücklich die Analyse negativer Pfade unterstützt. Speichere Artefakte in einer vorhersehbaren Hierarchie mit Anwendung, Plattform, Testsammlung und Ausführungskennung. ## Eine Testanwendung für Ende-zu-Ende-Tests auf allen Plattformen wiederverwenden Verwende eine vorgegebene Testanwendung, um den gesamten Befehlsumfang auf allen unterstützten Plattformen abzudecken. Nutze dieselben Abläufe für zwei Zwecke: schnelle Rückschritttests auf aktuellen Plattformversionen und Kompatibilitätsprüfungen für eine neu eingeführte Betriebssystemversion. Ist ein Verhalten an ein bestimmtes Rahmenwerk gebunden, lege einen eigenen Testarbeitsbereich an, statt die vorgegebene Anwendung zu verbiegen. Jeder Arbeitsbereich erhält eigene Abläufe und ein eigenes Build-Artefakt; bei manueller Ausführung muss sich der Umfang auf eine Anwendung oder einen Ablauf eingrenzen lassen. Parametrisiere den Testtreiber mit Plattform und ausdrücklichen Umgebungseingaben. Prüfe die Ausführungseingaben, bevor teure Infrastruktur bereitgestellt wird: Lehne nicht unterstützte Systemversionen, fehlende Arbeitsbereiche und mehrdeutige Ablaufauswahlen frühzeitig ab. ## Gerätefehler im Treiber beheben, nicht mit Tricks in der CI Schlägt ein Ende-zu-Ende-Ablauf fehl, weil ein Plattformtreiber echtes Geräteverhalten nicht beherrscht, korrigiere den Treiber, Hostadapter oder die Testanwendung, die Benutzer tatsächlich ausführen. Verdecke die Lücke nicht durch Emulatoreinstellungen, Shell-Befehle, Befehlszeilenanpassungen oder Vorkonfiguration in der CI-Pipeline. Änderungen an der Pipeline sind für deren Form angemessen: Matrizen, Aufbewahrung, Auslöser, geprüfte Ausführungseingaben oder eng begrenzte und dokumentierte Infrastrukturausnahmen. Sie ersetzen kein Produktverhalten. Wende dieselbe Regel auf die Prüfung neuer Betriebssystemversionen an. Ein Ablauf, der nur nach CI-spezifischer Vorbereitung erfolgreich ist, weist weiterhin auf einen Produktkompatibilitätsfehler hin, sofern diese Vorbereitung keine ausdrücklich genannte Benutzervoraussetzung ist. ## Fehler danach einteilen, ob ein neuer Versuch hilft, und temporäre Dateien immer aufräumen Nutze strukturierte asynchrone Ausführung mit ausdrücklich festgelegten Verteilern oder Ausführern. Beschränke blockierende Brücken auf Anwendungseinstiegspunkte. Klassifiziere sichtbare Fehlschläge, damit die Ablaufsteuerung wiederholbare Zustände von endgültigen Fehlern unterscheiden kann, statt ausnahmslos alles erneut auszuführen. Führe temporäre Dateien und Verzeichnisse über eine Ressourcenverwaltung, die deren Lebenszyklus besitzt. Erzeuge sie nahe der Operation, die die Ressourcen besitzt, weise Ressourcen über ihre API zu und schließe sie in einem `finally`-Pfad, damit die rekursive Bereinigung nach Erfolg, Fehlschlag oder Abbruch stattfindet. Umgehe die Ressourcenverwaltung nicht mit direkten Aufrufen zur Erstellung temporärer Dateien. Unverwaltete Dateien sammeln sich in langlebigen Arbeitsprozessen an und erschweren die Reproduktion von Fehlern. Teste Abbruch, Zeitüberschreitung, Überwachungsverhalten und Bereinigung mit echter Ablaufsteuerung und deterministischen Ersatztreibern, wenn kein Gerät erforderlich ist. ## Agentenwerkzeuge und Modellverhalten getrennt testen Wenn die Befehlszeilenanwendung zusätzlich einen Agentenserver bereitstellt, halte zwei verschiedene Testfamilien getrennt: - Werkzeugfunktionstests, die Anfragen, Antworten, Geräteeinrichtung und Fehlerverhalten prüfen; - Modellverhaltensbewertungen, die messen, ob ein Agent Werkzeuge richtig auswählt und verwendet. Nutze deklarative Bewertungsfälle und plattformspezifische Einrichtungsskripte, damit die Abdeckung reproduzierbar bleibt. Führe bei gewöhnlichen Implementierungsänderungen schnelle Werkzeugtests aus. Führe langsamere Modellbewertungen aus, wenn sich Eingabeanweisungen, Werkzeugbeschreibungen, Schemata, Weiterleitung oder agentensichtbares Verhalten ändern. Betrachte weder eine Modellbewertung als Nachweis für die Funktion des zugrunde liegenden Werkzeugs noch einen Werkzeugfunktionstest als Nachweis für die richtige Verwendung durch einen Agenten. Beide Verträge benötigen eigene Belege. ## Erzeugte Binärdateien neu bauen, statt sie von Hand zu ändern Behandle eingecheckte Treiberbinärdateien, verpackte Ausführer, Prüfsummen und andere abgeleitete Dateien als Generatorergebnisse. Bearbeite sie niemals manuell. Führe die zuständige Build-Aufgabe oder den abschließenden Generator aus und committe die entstandenen Artefakte zusammen mit der Quelländerung, die sie erzeugt hat. Prüfe vor dem Abschluss: 1. Die Änderung befindet sich in dem Modul, das das Verhalten besitzt. 2. Die niedrigste hinreichende Testebene und jede unmittelbar betroffene höhere Ebene wurden ausgeführt. 3. Positive und negative Testsammlungen wurden gemäß ihren Verträgen ausgewertet. 4. Temporäre Ressourcen werden nach Erfolg, Fehlschlag und Abbruch geschlossen. 5. Abgeleitete Artefakte wurden über den offiziellen Build-Pfad neu erzeugt. 6. CI-Änderungen beschreiben die Infrastrukturform, statt Produktfehler zu verdecken. Halte Arbeitsablaufdokumentation, Testanwendungsstruktur und Hinweise zu Modulzuständigkeiten synchron, damit spätere Mitwirkende und automatisierte Agenten dieselben Grenzen einhalten.