Diseñar casos de fallo con un proxy de depuración
Elija ediciones HTTP, retrasos e intercambios interrumpidos según el comportamiento del cliente que debe ejercitar una prueba basada en proxy.
Un proxy de depuración resulta útil cuando un cliente necesita encontrarse con una respuesta que el servidor normal rara vez produce. Defina primero el comportamiento del cliente y luego elija la intervención que produce esa condición.
«La petición falló» es un caso de prueba demasiado amplio. Una respuesta de error HTTP válida, una respuesta que nunca llega y una conexión interrumpida a mitad de una descarga exigen cosas distintas de la aplicación.
| Caso | Comportamiento que examinar |
|---|---|
| Una respuesta de error HTTP completa | Si el cliente lee el estado y aplica la política de error prevista |
| Una respuesta retrasada | Si el usuario puede cancelar y el tiempo de espera se aplica en la etapa prevista |
| Un campo de cabecera o de cuerpo inesperado | Si el análisis y la validación fallan con claridad |
| Un intercambio interrumpido | Si los datos incompletos siguen siendo distinguibles de un resultado terminado |
Use una intervención en la capa correcta
Charles ofrece puntos de interrupción que detienen una petición o una respuesta antes de reenviarla. El mensaje interceptado puede examinarse y editarse, dejarse pasar o abortarse. Su herramienta Rewrite aplica cambios repetibles a cabeceras, URL o cuerpos que coincidan. La limitación de velocidad controla el ancho de banda y la latencia añadida.
Estos controles pueden ejercitar el comportamiento de un cliente HTTP, pero un límite de ancho de banda no es un modelo preciso de la pérdida aleatoria de paquetes IP. Un proxy puede almacenar datos en búfer, reutilizar conexiones y abrir una conexión ascendente distinta. Elija una herramienta de degradación de red cuando la condición requerida esté específicamente por debajo de HTTP.
Mantenga cada caso interpretable
Ajuste el host y la ruta previstos de forma estrecha. Empiece con un intercambio normal, active un solo cambio y registre qué se cambió. Si un reintento alcanza un segundo punto de conexión, decida si la misma regla debe afectar a ese intento. De lo contrario, una reescritura incondicional puede convertir cada ruta de recuperación en el fallo original.
En una carga o una operación similar a un pago, una respuesta perdida no demuestra que el servidor rechazara la petición. Incluya esa ambigüedad en el caso de reintento en lugar de afirmar que todo fallo de transporte es seguro de repetir.
Inspeccionar o editar contenido HTTPS exige que el cliente participe en la configuración de inspección TLS del proxy de depuración. Un proxy que solo transporta CONNECT ve bytes de aplicación cifrados. Use una configuración de prueba aislada y restablezca después su enrutamiento y su configuración de confianza para que las observaciones posteriores describan al cliente normal.