Concevoir des cas d'échec avec un proxy de débogage
Choisissez les modifications HTTP, les délais et les échanges interrompus en fonction du comportement client qu'un test via proxy doit solliciter.
Un proxy de débogage est utile lorsqu'un client doit rencontrer une réponse que le serveur normal produit rarement. Définissez d'abord le comportement du client, puis choisissez l'intervention qui produit cette condition.
« La requête a échoué » est un cas de test trop vague. Une réponse d'erreur HTTP valide, une réponse qui n'arrive jamais et une connexion interrompue au milieu d'un téléchargement demandent des choses différentes à l'application.
| Cas | Comportement à examiner |
|---|---|
| Une réponse d'erreur HTTP complète | Si le client lit le statut et applique la politique d'erreur prévue |
| Une réponse retardée | Si l'utilisateur peut annuler et si le délai d'attente s'applique à l'étape prévue |
| Un champ d'en-tête ou de corps inattendu | Si l'analyse et la validation échouent clairement |
| Un échange interrompu | Si les données incomplètes restent distinguables d'un résultat terminé |
Utilisez une intervention à la bonne couche
Charles fournit des points d'arrêt qui suspendent une requête ou une réponse avant de la transmettre. Le message intercepté peut être examiné et modifié, laissé passer ou abandonné. Son outil Rewrite applique des modifications répétables aux en-têtes, URL ou corps correspondants. La limitation contrôle la bande passante et la latence ajoutée.
Ces contrôles peuvent solliciter le comportement d'un client HTTP, mais une limite de bande passante n'est pas un modèle précis d'une perte aléatoire de paquets IP. Un proxy peut mettre les données en tampon, réutiliser des connexions et ouvrir une connexion amont distincte. Choisissez un outil de dégradation réseau lorsque la condition requise se situe précisément sous HTTP.
Gardez chaque cas interprétable
Faites correspondre étroitement l'hôte et le chemin visés. Commencez par un échange normal, activez une seule modification et notez ce qui a été changé. Si une nouvelle tentative atteint un second point de terminaison, décidez si la même règle doit affecter cette tentative. Sinon, une réécriture inconditionnelle peut transformer chaque chemin de récupération en l'échec d'origine.
Pour un envoi ou une opération de type paiement, une réponse perdue ne prouve pas que le serveur a rejeté la requête. Intégrez cette ambiguïté dans le cas de nouvelle tentative plutôt que d'affirmer que toute défaillance de transport peut être répétée sans risque.
Inspecter ou modifier du contenu HTTPS exige que le client participe à la configuration d'inspection TLS du proxy de débogage. Un proxy qui ne transporte que CONNECT voit des octets applicatifs chiffrés. Utilisez une configuration de test isolée et restaurez ensuite son routage et ses réglages de confiance afin que les observations ultérieures décrivent le client normal.