Ein Parser, der einen guten XML-Bericht akzeptiert, hat nur einen engen Test bestanden. Eine nützliche Validierungssuite prüft, was sie extrahiert, was sie ablehnt, wie sie mit unterstützten Variationen umgeht und ob Wiederholungsversuche die Gesamtsummen ändern. Behandeln Sie erwartete normalisierte Werte als Teil der Vorrichtung und nicht als Ausgabe, die der Test erfinden darf.
Deklarieren Sie den unterstützten Vertrag
Referenzen: RFC 9990 §3.1.1, RFC 9990 §3.2.
Notieren Sie die Parser-, Laufzeit-, Dekomprimierungs- und Schemaversionen. Geben Sie an, welche Berichtsformate und Erweiterungen unterstützt werden und wie mit Legacy-Eingaben umgegangen wird. RFC 9990 definiert das aktuelle Aggregatformat und Erweiterungsmodell; Die Unterstützung älterer Formate ist eine separate Kompatibilitätsentscheidung.
Erstellen Sie zuerst eine minimal gültige Vorrichtung. Speichern Sie Bytes, Hash, erwartete Metadaten, Intervall, Quell-IP, Anzahl, Identitäten und ausgerichtete Ergebnisse. Betrachten Sie eine erfolgreiche XML-Analyse nicht als ausreichend: Überprüfen Sie Feldtypen und Bedeutungen. Halten Sie fehlende optionale Werte von ungültigen erforderlichen Daten getrennt.
Testen Sie die häufigsten semantischen Fehler
Referenzen: RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11, RFC 9989 §5.3.5.
Roh einbeziehen DKIM unter einer nicht verwandten Domäne mit einem ausgerichteten DKIM Fehler passieren und roh SPF ohne passieren Ausrichtung. Schließen Sie einen Fall ein, in dem ein ausgerichteter Mechanismus funktioniert, während der andere ausfällt. Stellen Sie sicher, dass das normalisierte Ergebnis nicht erfordert, dass beide Mechanismen erfolgreich sind, oder setzen Sie rohen Erfolg mit Ausrichtung gleich.
Fügen Sie eine gemeldete Disposition hinzu, die von einer einfachen Schlussfolgerung aus der veröffentlichten Richtlinie abweicht. Behalten Sie die verfügbaren Überschreibungsgründe bei. Schließen Sie für das aktuelle Schema die Wertübergabe ActionDispositionType ein, anstatt sie als unbekannten Legacy-Wert abzulehnen. RFC 9990 Anhang A definiert es zum Übergeben DMARC mit einer durchsetzenden Richtlinie. Halten Sie die Erwartungen an das Legacy-Format explizit getrennt. Testen Sie mehrere DKIM Ergebnisse, ohne alle bis auf die erste Signatur zu löschen. Der Zweck besteht darin, die Aussagen des Berichts zu bewahren und nicht darin, aus unvollständigen Daten eine neue Empfängerbewertung zu erstellen.
Üben Sie Struktur- und Sicherheitsfälle aus
Referenzen: RFC 9990 §3.2, RFC 9990 §8.1.
Referenz: Verhinderung externer OWASP-XML-Entitäten, allgemeine Anleitung.
Verwenden Sie ungültige erforderliche Werte, fehlerhaftes XML, unterstützte Namespace-Erweiterungen, nicht unterstützte Versionen, fehlende optionale Elemente und übermäßig begrenzte Verschachtelung. Testen Sie komprimierte und erweiterte Größenbeschränkungen, unterbrochene Eingaben und harmlose externe Referenz-Sentinels isoliert. Legen Sie fest, ob jede Eingabe akzeptiert, unter Quarantäne gestellt oder abgelehnt wird und warum.
Eine unterstützte Erweiterung sollte nicht stillschweigend verschwinden, wenn eine nachgelagerte Analyse behauptet, sie beizubehalten. Ein nicht unterstütztes Konstrukt sollte zu einem expliziten Kompatibilitätsergebnis führen und nicht als fehlgeschlagene Authentifizierung neu klassifiziert werden. Halten Sie Sicherheitstests klein und ressourcenbegrenzt; Generieren Sie keine destruktiven Arbeitslasten, nur um eine Grenze aufzuzeigen.
Überprüfen Sie das Duplikat- und Transaktionsverhalten
Referenzen: RFC 9990 §3.5.4.
Importieren Sie ein Fixture, spielen Sie es erneut ab und starten Sie den Worker neu, bevor Sie es erneut abspielen. Der gezählte Bericht sollte gemäß der dokumentierten Duplikatregel einzeln bleiben. Fügen Sie einen anderen Anhang hinzu, der dieselbe Berichtsidentität beansprucht, und erfordern Sie eine explizite Konfliktentscheidung. Identische Ausweise allein berechtigen nicht dazu, unterschiedliche Beweise ohne Überprüfung zu verwerfen.
Fügen Sie vor dem Festschreiben eine kontrollierte Unterbrechung ein. Stellen Sie sicher, dass sich keine Teildatensätze auf die Produktionsmetriken auswirken und dass ein zulässiger Wiederholungsversuch einmalig das erwartete Ergebnis liefert. Testen Sie Null-Beobachtungsausgaben als nicht verfügbar, anstatt durch Null zu dividieren oder eine perfekte Erfolgsquote zu ermitteln.
Arbeiten Sie eine Akzeptanzreihe durch
Die synthetische Vorrichtung F1 enthält 90 Beobachtungen mit ausgerichtetem DKIM Durchlauf und zehn ohne ausgerichteten Durchlaufmechanismus. Die erwartete enthaltene Anzahl beträgt 100 und die erwartete Anzahl der beobachteten Durchgänge beträgt 90. Bei der Wiederholung von F1 müssen beide Werte unverändert bleiben. Eine absichtlich gekürzte Kopie sollte ohne Erhöhung der Gesamtsumme abgelehnt werden.
Speichern Sie die erwarteten Werte vor der Ausführung. Vergleichen Sie die tatsächliche Leistung, Ressourcenmessungen und Diagnosen mit dieser Basislinie. Hierbei handelt es sich um eine Parser-Akzeptanzspezifikation und nicht um den Anspruch, dass irgendein kommerzieller Parser oder Mieter-Parser sie bestanden hat. Ein separates neues Offline-Rechen-/Wiedergabemodell prüft die 100/90-Werte und zählt unverändert bei wiederholter Identität; Ein RFC 9990 XML-Bericht wird nicht analysiert oder validiert. Wenn ein Fall fehlschlägt, bewahren Sie den Defekt und die genaue Befestigung auf, damit eine spätere Revision ihn reproduzieren kann.
Gate-Änderungen bei aufgezeichneten Ergebnissen
Führen Sie eine Matrix mit Geräte-ID, Hash, Zweck, erwartetem Ergebnis, tatsächlichem Ergebnis, Parser-Konfiguration und Überprüfungsentscheidung. Fordern Sie, dass alle obligatorischen Fälle bei der bereitgestellten Revision bestanden werden, mit dokumentierten Ausnahmen für nicht unterstützte Funktionen. Nach Abhängigkeits- oder Normalisierungsänderungen erneut ausführen und historische Metrikeffekte vergleichen, bevor gespeicherte Berichte erneut verarbeitet werden. Die Parser-Validierung sollte sowohl die Systemverfügbarkeit als auch die Bedeutung der Zahlen schützen, die Menschen für Richtlinienentscheidungen verwenden.