Una evaluación de API debe responder si un cliente puede recuperar de manera confiable la evidencia deseada, no si una solicitud de muestra devuelve HTTP 200. Primero defina el flujo de trabajo: por ejemplo, exporte la información recibida de un cliente. informes agregados en un almacén de pruebas privado sin perder páginas ni mezclar inquilinos. Evite asumir que cualquier producto nombrado ofrece esta interfaz hasta que se verifique su contrato actual.
Fijar el contrato y los límites
Registre el proveedor, el punto final, la versión de API, el método de autenticación, los límites del inquilino, los campos, las reglas de paginación y los límites documentados. Separe la identidad de un informe del momento en que llegó y el período que cubre. Especifique si la API devuelve informes sin procesar, filas normalizadas o resultados derivados. Se trata de poblaciones de pruebas diferentes y necesitan reglas de conciliación diferentes.
Documentación de la versión API de GitHub ilustra la selección de versión explícita con X-GitHub-Api-Version. Ese es un ejemplo concreto de práctica de control de versiones, no evidencia de que GitHub exporte DMARC informes. Para una evaluación real, registre esos detalles en una nota de contrato revisable antes de realizar la prueba. Esta guía no proporciona ningún contrato de proveedor, terminal o capacidad del producto.
Procedencia de la prueba y campos
Para una fila normalizada, conserve el informante, la identificación del informe, el período original, la hora de recepción y la huella digital de origen cuando estén disponibles. Preservar el artefacto original bajo controles de retención aprobados. RFC 9990 es la referencia principal para la estructura del informe agregado. Un esquema JSON conveniente no puede convertir los recuentos informados en prueba de mensajes entregados ni recuperar información que el receptor nunca proporcionó.
Pregunte cómo el servicio representa la ingesta parcial, los informes con formato incorrecto, los datos corregidos y los períodos de recopilación faltantes. Una página omitida silenciosamente puede hacer que una métrica plausible sea errónea. Solicite una muestra que incluya errores conocidos y compárela con entradas contadas de forma independiente, no simplemente con otra pantalla impulsada por la misma exportación.
Ejercer rutas de falla deliberadamente
Pruebe un resultado de varias páginas, un resultado vacío, una entrada duplicada, dos registros que comparten una marca de tiempo, una credencial revocada, una solicitud entre inquilinos y un error transitorio. Siga los enlaces o cursores de continuación documentados. Para limitación de velocidad, estado de registro, encabezados relevantes y política de reintento. Las mejores prácticas de GitHub recomendar respetar las señales de límite de tasas y evitar la concurrencia incontrolada; Los límites exactos todavía pertenecen al contrato de servicio real.
Supongamos que la página uno está almacenada pero la página dos falla. Un HTTP 200 para la primera solicitud no puede justificar una exportación completa; conservar el estado parcial y utilizar el proceso de reinicio o continuación admitido por el proveedor. Por otra parte, una solicitud autenticada exitosamente para otro inquilino de prueba autorizado aún debe denegarse cuando la persona que llama carece de esa concesión. Estos casos hipotéticos ponen a prueba diferentes requisitos: integridad y autorización.
Para una prueba de reintento, distinga una respuesta de límite de velocidad documentada de una falla de permiso permanente. Documentación de límite de velocidad de GitHub explica que puede informar la limitación de velocidad con 403 o 429, por lo que no clasifique cada 403 como permanentemente no reintentable sin leer su contexto de error y encabezados documentados. Aplique las reglas limitadas de espera y reintento del proveedor real. Aquí no se ejecutó ningún reloj virtual, prueba de reinicio, llamada de proveedor o verificación de control de acceso en vivo.
Decidir qué es aceptable
Cree un registro de evaluación que enumere cada comportamiento requerido, la evidencia obtenida y la incertidumbre restante. Trate el aislamiento de inquilinos faltante o la pérdida de datos irrecuperable como condiciones de detención. La falta de credenciales de producción no tiene por qué impedir la evaluación documental, pero sí impide afirmar que se probaron controles de acceso en vivo.
Acuerde el siguiente paso con el propietario del servicio: obtener un espacio aislado, implementar un adaptador protegido o limitar el flujo de trabajo a exportaciones admitidas. Conserve el contrato fijado y pruebe los accesorios para poder evaluar un cambio de proveedor más adelante. Mantener las afirmaciones específicas del producto limitadas a la capacidad documentada y observada; Esta guía no verifica ninguna integración de la API EmailAuth .