Comment utiliser Clumsy pour tester un réseau

01

Avant d'utiliser Clumsy

Un test utile commence par une cible contrôlée et une attente écrite.

Notez le comportement à évaluer avant de cliquer sur Start. Exemple : « Avec 300 ms de délai API, l'application doit afficher un chargement, rester réactive et terminer sans perdre le formulaire. » Cette phrase définit cible, dégradation mesurable et résultat visible. N'activez pas tous les contrôles à la fois, sinon la cause d'un échec restera inconnue.

Utilisez Clumsy uniquement sur vos systèmes et flux ou avec une autorisation explicite. Les contrôles qui aident une équipe qualité à reproduire une mauvaise connexion peuvent perturber d'autres personnes. Ce guide ne traite ni triche, ni contournement anti-triche, ni lag switch caché, ni attaque contre un service tiers.

• Choisissez une session réversible.
• Mesurez le temps normal avant la dégradation.
• Testez une application, une adresse ou un port à la fois.
• Sachez cliquer sur Stop et fermer Clumsy avant de commencer.

02

Télécharger, vérifier et extraire Clumsy 0.3

La version officielle actuelle est Clumsy 0.3. Téléchargez-la depuis jagt/clumsy sur GitHub plutôt que depuis un miroir ou un installateur enveloppé. La plupart des PC utilisent Win64 ; Win32 sert aux installations x86 32 bits. En cas de doute, ouvrez Informations système et consultez Type du système.

La version officielle fournit A, B et C pour chaque architecture. Les notes indiquent des signatures WinDivert différentes mais des fonctions identiques. Commencez par A. Si une protection traite cette signature autrement, lisez les notes avant B ou C. Un fichier nommé Clumsy 0.4 ou 0.6 n'est pas automatiquement plus récent : ces numéros sont absents de l'historique vérifié.

03

Choisir un filtre de paquets étroit

Clumsy utilise des expressions WinDivert pour décider quels paquets dégrader. Le filtre délimite le test : une expression étroite réduit l'impact, une expression large peut déstabiliser tout le PC. Commencez par le minimum nécessaire. Pour un service HTTP, ciblez l'hôte, le protocole ou le port plutôt que tout le trafic entrant et sortant.

Le sens compte. Outbound quitte le PC et inbound y revient. Une requête et sa réponse peuvent exiger des observations différentes. Si le test échoue sans explication, arrêtez, revenez à la référence et simplifiez. Ne collez pas une expression d'un forum anonyme sans comprendre sa portée.

04

Lancer le premier test de latence Clumsy

Lag constitue un bon premier module car son effet s'observe sans supprimer volontairement de données. Commencez par 200 à 300 millisecondes et une application dont la réponse normale est connue. Configurez le filtre, activez Lag, saisissez le délai, cliquez sur Start puis effectuez une action connue et comparez-la à la référence.

Ne regardez pas seulement la durée totale. L'interface accuse-t-elle réception du clic ? Affiche-t-elle un chargement ? Peut-on annuler ? La requête expire-t-elle trop tôt ? Le formulaire reste-t-il rempli ? Une application robuste explique que le travail continue et se rétablit. Notez réglages, version et comportement.

1. Mesurer la référenceEffectuez l'action sans Clumsy et notez la réponse.
2. Activer LagChoisissez un délai modéré et désactivez les autres modules.
3. DémarrerVérifiez le filtre, cliquez sur Start et effectuez une action.
4. ObserverContrôlez messages, expiration, tentatives, annulation et état.
5. Arrêter et retesterDésactivez Clumsy et prouvez la récupération.

05

Ajouter une perte de paquets sans perdre le contrôle

La perte est plus perturbatrice que le délai car certains paquets n'arrivent jamais. Commencez avec une faible probabilité et un filtre étroit. Le but n'est pas de rendre la connexion inutilisable, mais d'observer tentatives, reconnexions et échecs partiels. Un faible pourcentage peut révéler un mauvais postulat dans un flux.

Surveillez les opérations dupliquées. Si le client réessaie après la perte d'une réponse, le serveur peut avoir terminé la première demande. Commandes, paiements, messages ou enregistrements nécessitent idempotence et récupération claire. Clumsy révèle le symptôme ; journaux et identifiants expliquent la séquence.

06

Employer Throttle, Duplicate, Out of order et Tamper avec méthode

Throttle convient au débit limité plutôt qu'au retard. Il révèle transferts monopolisant l'interface, progression bloquée ou requêtes parallèles excessives. Duplicate teste l'unicité, Out of order l'ordre et les tampons. Tamper est avancé et réservé aux flux autorisés ; ce ne doit pas être le premier essai.

07

Résoudre démarrage, alertes et récupération

Clumsy dépend de WinDivert pour capturer et réinjecter les paquets. Cette opération de bas niveau peut déclencher autorisations ou analyse de sécurité. Une alerte ne prouve pas un logiciel malveillant et une source officielle ne garantit pas l'autorisation locale. Vérifiez GitHub et checksum, utilisez la bonne architecture, extrayez tout et examinez l'événement au lieu de désactiver aveuglément la protection.

Si Clumsy ne démarre pas, vérifiez que l'archive est complètement extraite et que l'exécutable reste avec WinDivert. Essayez l'architecture adaptée. Si A est bloquée et la politique permet le test, lisez l'explication officielle de B et C. Sur un appareil d'entreprise, demandez à l'administrateur plutôt que de contourner la politique.

• Ne désactivez jamais la protection pour une version inconnue.
• Conservez le ZIP et son checksum dans le dossier du test.
• Utilisez l'administration uniquement avec autorisation.
• Documentez la restauration après chaque session.

08

Transformer un test manuel en procédure qualité répétable

La valeur de Clumsy vient de la répétabilité, pas d'une connexion aléatoirement mauvaise. Nommez le scénario, notez la version, capturez la référence, conservez filtre et valeurs, définissez la réussite et écrivez la récupération exacte. Associez le résultat visible aux journaux client et serveur.

Poursuivez avec la recette de latence ou la recette de perte de paquets.