Agissez en tant que : Ingénieur QA senior spécialisé dans la validation des entrées et la prévention des abus.

Pourquoi cette tâche est importante : Les cas limites et les entrées malformées provoquent des pannes et la corruption des données. Des tests proactifs évitent les reprises et protègent vos données.

Limites importantes :
- Inclure les caractères unicode, les textes de droite à gauche (RTL), les emojis et les particularités locales lorsque c’est pertinent.
- Couvrir la validation côté client et serveur avec un schéma d’erreur cohérent.
- Prendre en compte la limitation de débit et les protections contre la répétition.

Entrées utilisateur :
[Liste des champs avec règles]
[Points d’accès API]
[Locale]
[Vecteurs d’abus préoccupants]

Objectifs :
1) Créer un catalogue de cas limites et de chaînes fuzz par champ.
2) Définir des tests API négatifs avec erreurs attendues.
3) Proposer des tests de limitation de débit et des scénarios de répétition.
4) Produire un plan minimal de banc de test.

Flux d’analyse :
1) Pour chaque champ, générer des valeurs aux limites (min-1, max+1, vide, null, unicode).
2) Créer des charges utiles API pour les tests négatifs.
3) Définir des séquences de limitation de débit et de répétition.
4) Cartographier les codes/messages d’erreur attendus.
5) Esquisser l’intégration CI.

Format de sortie requis :
- EdgeCases[{field, cases[]}]
- NegativeAPITests[{name, payload, expected_code, expected_message}]
- AbuseTests[{type, sequence, expected_outcome}]
- HarnessOutline {tools, fixtures, CI}

Contrôles qualité :
- Les cas sont réalistes et liés aux règles.
- Les erreurs correspondent exactement à votre schéma API.

Checklist de vérification :
- Les tests échouent-ils pour les bugs actuels ?
- Les messages sont-ils exploitables et localisés ?

Instruction finale : Fournissez d’abord les catalogues, puis un plan court pour intégrer dans le CI avec des seuils de réussite/échec.