Una valutazione API dovrebbe rispondere se un cliente può recuperare in modo affidabile le prove previste, non se una richiesta di campione restituisce HTTP 200. Definire prima il flusso di lavoro: ad esempio, esportare la ricevuta di un cliente rapporti aggregati in un archivio di prove privato senza perdere pagine o mescolare gli inquilini. Evitare di dare per scontato che qualsiasi prodotto indicato offra questa interfaccia fino alla verifica del contratto attuale.
Appunta il contratto e i confini
Registra provider, endpoint, versione API, metodo di autenticazione, limiti del tenant, campi, regole di impaginazione e limiti documentati. Separare l'identità di un report dal momento in cui è arrivato e dal periodo che copre. Specifica se l'API restituisce report non elaborati, righe normalizzate o risultati derivati. Si tratta di popolazioni di prove diverse e necessitano di regole di riconciliazione diverse.
Documentazione della versione API di GitHub illustra la selezione esplicita della versione con X-GitHub-Api-Version. Questo è un esempio concreto di pratica di controllo delle versioni, non una prova che GitHub esporti DMARC rapporti. Per una valutazione effettiva, registrare tali dettagli in una nota contrattuale rivedibile prima del test. Questa guida non fornisce alcun contratto con il fornitore, endpoint o funzionalità del prodotto.
Testare la provenienza e i campi
Per una riga normalizzata, conservare il reporter, l'ID del report, il periodo originale, l'ora della ricevuta e l'impronta digitale della fonte, se disponibili. Conserva l'artefatto originale sotto controlli di conservazione approvati. RFC 9990 è il riferimento principale per la struttura del report aggregato. Un comodo schema JSON non può trasformare i conteggi riportati in prova dei messaggi consegnati o recuperare informazioni che il destinatario non ha mai fornito.
Chiedi in che modo il servizio rappresenta l'acquisizione parziale, i report non corretti, i dati corretti e i periodi di raccolta mancanti. Una pagina saltata silenziosamente può rendere errata una metrica plausibile. Richiedi un campione che includa errori noti e confrontalo con input conteggiati in modo indipendente, non semplicemente con un altro schermo alimentato dalla stessa esportazione.
Percorsi di fallimento dell'esercizio deliberatamente
Testare un risultato di più pagine, un risultato vuoto, un input duplicato, due record che condividono un timestamp, una credenziale revocata, una richiesta tra tenant e un errore temporaneo. Seguire collegamenti o cursori di continuazione documentati. Per la limitazione della velocità, lo stato del record, le intestazioni pertinenti e la politica di ripetizione. Le migliori pratiche di GitHub raccomandare di rispettare i segnali di limite di velocità ed evitare la concorrenza incontrollata; i limiti esatti appartengono ancora al contratto di servizio vero e proprio.
Supponiamo che la pagina uno venga memorizzata ma la pagina due fallisca. Un HTTP 200 per la prima richiesta non può giustificare un'esportazione completa; mantenere lo stato parziale e utilizzare il processo di continuazione o riavvio supportato dal provider. Separatamente, una richiesta autenticata con successo per un altro tenant di prova autorizzato deve comunque essere negata quando al chiamante non è concessa tale concessione. Questi casi ipotetici mettono alla prova diversi requisiti: completezza e autorizzazione.
Per un nuovo test, distinguere una risposta documentata al limite di velocità da un errore di autorizzazione permanente. Documentazione sui limiti di velocità di GitHub spiega che può segnalare la limitazione della velocità con 403 o 429, quindi non classificare ogni 403 come permanentemente non riprovabile senza leggere il contesto dell'errore e le intestazioni documentate. Applicare le regole di attesa e riprova limitate del provider effettivo. Qui non è stato eseguito alcun orologio virtuale, test di riavvio, chiamata del fornitore o controllo del controllo degli accessi in tempo reale.
Decidi cosa è accettabile
Creare un registro di valutazione elencando ogni comportamento richiesto, le prove ottenute e l'incertezza rimanente. Trattare l'isolamento del tenant mancante o la perdita irrecuperabile di dati come condizioni di arresto. La mancanza di credenziali di produzione non impedisce necessariamente la valutazione documentale, ma impedisce di affermare che i controlli di accesso in tempo reale siano stati testati.
Concordare il passaggio successivo con il proprietario del servizio: ottenere una sandbox, implementare un adattatore protetto o restringere il flusso di lavoro alle esportazioni supportate. Conservare il contratto bloccato e testare i dispositivi in modo che una modifica del fornitore possa essere valutata in un secondo momento. Mantenere le dichiarazioni specifiche del prodotto limitate alla capacità documentata e osservata; nessuna integrazione dell'API EmailAuth è verificata da questa guida.