Parser, który akceptuje jeden dobry raport XML, przeszedł tylko wąski test. Przydatny zestaw walidacji sprawdza, co wyodrębnia, co odrzuca, jak radzi sobie z obsługiwanymi odmianami i czy suma zmian jest powtarzana. Traktuj oczekiwane znormalizowane wartości jako część urządzenia, a nie jako wynik, który test może wymyślić.
Zadeklaruj wspieraną umowę
Referencje: RFC 9990 §3.1.1, RFC 9990 §3.2.
Zapisz wersję parsera, środowiska wykonawczego, dekompresora i schematu. Określ, które formaty raportów i rozszerzenia są obsługiwane oraz w jaki sposób obsługiwane są starsze dane wejściowe. RFC 9990 definiuje bieżący format zbiorczy i model rozszerzenia; obsługa starszych formatów to osobna decyzja dotycząca zgodności.
Najpierw zbuduj minimalne prawidłowe urządzenie. Zapisz bajty, skrót, oczekiwane metadane, interwał, źródłowy adres IP, liczbę, tożsamości i dopasowane wyniki. Nie uważaj, że udane parsowanie XML jest wystarczające: sprawdź typy pól i ich znaczenia. Zachowaj rozróżnienie brakujących wartości opcjonalnych od nieprawidłowych wymaganych danych.
Przetestuj typowe błędy semantyczne
Referencje: RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11, RFC 9989 §5.3.5.
Uwzględnij surowe DKIM przejść pod niepowiązaną domenę z wyrównanym niepowodzeniem DKIM i surowe SPF przejść bez wyrównanie. Uwzględnij przypadek, w którym jeden wyrównany mechanizm działa, a drugi zawodzi. Sprawdź, czy znormalizowany wynik nie wymaga zaliczenia obu mechanizmów lub zrównania sukcesu z wyrównaniem.
Dodaj zgłoszoną dyspozycję, która różni się od uproszczonego wniosku z opublikowanych zasad. Zachowaj dostępne przyczyny zastąpienia. W przypadku bieżącego schematu uwzględnij przekazaną wartość ActionDispositionType, zamiast odrzucać ją jako nieznaną starszą wartość; RFC 9990 Dodatek A definiuje to jako przechodzące DMARC z egzekwującą polityką. Zachowaj wyraźne oddzielenie oczekiwań w starszym formacie. Przetestuj wiele wyników DKIM bez usuwania wszystkich oprócz pierwszego podpisu. Celem jest zachowanie treści raportu, a nie tworzenie nowej oceny odbiorcy na podstawie niekompletnych danych.
Ćwicz przypadki strukturalne i bezpieczeństwa
Referencje: RFC 9990 §3.2, RFC 9990 §8.1.
Odniesienie: Zapobieganie podmiotom zewnętrznym OWASP XML, wskazówki ogólne.
Użyj nieprawidłowych wymaganych wartości, zniekształconego kodu XML, obsługiwanych rozszerzeń przestrzeni nazw, nieobsługiwanych wersji, brakujących elementów opcjonalnych i nadmiernego zagnieżdżenia. Testuj w izolacji skompresowane i rozszerzone limity rozmiaru, przerywane dane wejściowe i nieszkodliwe wskaźniki zewnętrzne. Określ, czy każde wejście ma zostać zaakceptowane, poddane kwarantannie czy odrzucone i dlaczego.
Obsługiwane rozszerzenie nie powinno zniknąć po cichu, jeśli dalsza analiza twierdzi, że je zachowuje. Nieobsługiwana konstrukcja powinna generować wyraźny wynik zgodności, a nie być przeklasyfikowana jako nieudane uwierzytelnienie. Staraj się, aby testy bezpieczeństwa były małe i ograniczone pod względem zasobów; nie generuj destrukcyjnych obciążeń tylko po to, aby zademonstrować limit.
Sprawdź duplikaty i zachowanie transakcji
Referencje: RFC 9990 §3.5.4.
Zaimportuj urządzenie, odtwórz je ponownie i zrestartuj proces roboczy przed ponownym odtworzeniem. Zliczony raport powinien pozostać pojedynczy zgodnie z udokumentowaną zasadą duplikatu. Dodaj inny załącznik, podając tę samą tożsamość raportu i wymagaj wyraźnej decyzji o konflikcie. Same identyczne identyfikatory nie upoważniają do odrzucenia różnych dowodów bez sprawdzenia.
Wstrzyknij kontrolowane przerwanie przed zatwierdzeniem. Potwierdź, że żadne rekordy częściowe nie wpływają na metryki produkcyjne i że dozwolona ponowna próba raz daje oczekiwany wynik. Testuj wyniki obserwacji zerowej jako niedostępne, zamiast dzielić przez zero lub uzyskać idealny współczynnik zdawalności.
Przepracuj rząd akceptacji
Urządzenie syntetyczne F1 zawiera 90 obserwacji z wyrównanym przejściem DKIM i dziesięć bez wyrównanego mechanizmu przejścia. Oczekiwana liczba uwzględnionych podań to 100, a oczekiwana liczba zaobserwowanych podań to 90. Ponowne użycie klawisza F1 musi pozostawić obie wartości niezmienione. Celowo obciętą kopię należy odrzucić bez zwiększania którejkolwiek wartości całkowitej.
Zapisz oczekiwane wartości przed wykonaniem. Porównaj rzeczywistą produkcję, pomiary zasobów i diagnostykę z tą wartością bazową. Jest to specyfikacja akceptacji analizatora składni, a nie twierdzenie, że przeszedł ją jakikolwiek parser komercyjny lub dzierżawcy. Oddzielny nowy model arytmetyki/powtórki offline sprawdza wartości 100/90 i niezmienione zliczenia w przypadku powtarzającej się tożsamości; nie analizuje ani nie sprawdza raportu XML RFC 9990 . Jeśli sprawa zakończy się niepowodzeniem, zachowaj defekt i dokładne mocowanie, aby późniejsza rewizja mogła go odtworzyć.
Zmiany bramek w zarejestrowanych wynikach
Zachowaj macierz zawierającą identyfikator urządzenia, skrót, cel, oczekiwany wynik, rzeczywisty wynik, konfigurację parsera i decyzję dotyczącą przeglądu. Wymagaj, aby wszystkie obowiązkowe przypadki zostały zaliczone we wdrożonej wersji, z udokumentowanymi wyjątkami dotyczącymi nieobsługiwanych funkcji. Uruchom ponownie po zmianach zależności lub normalizacji i porównaj efekty metryk historycznych przed ponownym przetworzeniem zapisanych raportów. Walidacja parsera powinna chronić zarówno dostępność systemu, jak i znaczenie liczb, których ludzie używają do podejmowania decyzji politycznych.