auto-qa

Auto-QA : Moteur de test QA autonome basé sur les intentions

Une chaîne d'outils de test QA web autonome qui exécute des parcours utilisateur de bout en bout sur n'importe quelle application web (serveur de développement local ou site en ligne) à l'aide d'intentions en langage clair, d'heuristiques d'accessibilité W3C auto-réparatrices, d'isolation active des modales et de compilation native @playwright/test.

---

1. Règle de décision du double mode de fonctionnement

Avant d'entreprendre toute action, inspectez vos outils déclarés :

• MODE 1 : Mode Outil MCP : Si des outils commençant par auto_qa_ (par exemple auto_qa_execute_and_heal) sont disponibles dans votre liste d'outils active, appelez-les directement via JSON-RPC.
• MODE 2 : Mode CLI Antigravity Skill (Par défaut et autonome) : Si aucun outil MCP auto_qa_* n'est déclaré, exécutez toutes les actions QA via run_command en utilisant la CLI unifiée :

  node "<skillPath>/scripts/cli.js" <commande>
  

  (Résolvez <skillPath> en ~/.gemini/config/skills/auto-qa ou la racine du dépôt).

---

2. Le cycle de vie des tests en 3 étapes

Étape 1 : Découverte de la surface (Mapper les contrôles accessibles)

Explorez l'URL cible pour extraire les boutons interactifs, les champs de saisie, les liens et les boîtes de dialogue modales.

• Mode MCP : Appelez auto_qa_generate_code_summary(projectPath, url).
• Mode CLI Skill :

  node "<skillPath>/scripts/cli.js" discover http://localhost:3000 -o auto_qa_tests/tmp/surface.json
  

Étape 2 : Rédaction du plan d'intention (auto_qa_frontend_test_plan.json)

Rédigez le plan de test déclaratif dans auto_qa_tests/auto_qa_frontend_test_plan.json.

• Mode MCP : Appelez auto_qa_generate_frontend_test_plan(projectPath, name, planSteps).
• Mode CLI Skill : Écrivez le fichier JSON directement en utilisant votre outil de création de fichier :

{
  "$schema": "https://raw.githubusercontent.com/TestSprite/testsprite-cli/main/schemas/plan.schema.json",
  "projectId": "nom-du-projet",
  "type": "frontend",
  "name": "Flux d'inscription et de connexion utilisateur",
  "targetUrl": "http://localhost:3000",
  "priority": "p0",
  "planSteps": [
    { "type": "action", "description": "navigate to http://localhost:3000/login" },
    { "type": "action", "description": "type '[email protected]' into 'Email'" },
    { "type": "action", "description": "type 'TestPass123!' into 'Password'" },
    { "type": "action", "description": "click 'Sign In'" },
    { "type": "assertion", "description": "verify 'Dashboard' is visible" },
    { "type": "assertion", "description": "verify URL contains '/dashboard'" }
  ]
}

Verbes d'intention pris en charge (Insensibles à la casse, guillemets simples ou doubles) :

• Actions :
  • navigate to <http(s)://url> / go to </path or http(s)://url>
  • type '<texte>' into '<cible>' / fill '<texte>' into '<cible>'
  • click '<cible>' / press '<cible>'
  • select '<option>' from '<cible>'
  • check '<cible>' / tick '<cible>'
• Assertions :
  • verify '<cible>' is visible / appears
  • verify '<cible>' is not visible / disappears
  • verify text '<texte>' / contains '<texte>'
  • verify URL contains '<chemin>'

Étape 3 : Exécution, auto-réparation et compilation du code

Exécutez le plan de test déclaratif avec une résolution auto-réparatrice des éléments, capturez des captures d'écran en cas d'échec et exportez le code natif.

• Mode MCP :
  • Exécuter : auto_qa_execute_and_heal(projectPath, planFile, baseUrl)
  • Exporter : auto_qa_compile_to_playwright(planPath, outputPath)
• Mode CLI Skill :
  • Exécuter le test :

    node "<skillPath>/scripts/cli.js" run auto_qa_tests/auto_qa_frontend_test_plan.json -u http://localhost:3000
    

    (Remarque : Un code de sortie 1 indique un échec d'assertion lors du test. Inspectez auto_qa_tests/artifacts/ pour les captures d'écran et auto_qa_tests/auto-qa-test-report.md pour les temps des étapes et les traces d'erreur).
  • Compiler en TypeScript Playwright natif :

    node "<skillPath>/scripts/cli.js" compile auto_qa_tests/auto_qa_frontend_test_plan.json -o tests/e2e/flow.spec.ts
    

---

3. Résumé des sous-commandes CLI

Sous-commande	Objectif	Sortie par défaut
doctor	Vérification préalable de Node, Playwright et du binaire Chromium.	Statut dans le terminal
discover <url> [-o <fichier>]	Explore le site Web et extrait les boutons, les champs de saisie, les liens, les modales et l'arborescence d'accessibilité.	Carte de surface JSON
run <fichierPlan> [-u <url>] [-o <dossier>]	Exécute le plan d'intention avec résolution auto-réparatrice.	auto_qa_tests/artifacts/ + auto-qa-test-report.md
compile <fichierPlan> [-o <fichier>]	Compile le plan déclaratif en .spec.ts natif @playwright/test.	<nomPlan>.spec.ts
bootstrap [dossier] [-u <url>]	Initialise auto_qa_tests/tmp/config.json.	config.json
mcp	Démarre le serveur MCP stdio JSON-RPC 2.0.	Flux stdio

---

4. La stratégie de vérification en 5 couches

Lorsqu'on vous demande de « Tout tester » ou d'auditer une application Web inconnue :

1. Couche 1 : Navigation et routes : Explorez les liens de la barre de navigation et du pied de page ; vérifiez l'absence de réponses 404.
2. Couche 2 : Contrôles interactifs : Testez les menus déroulants, les accordéons, les bascules de thème et les boutons de filtre.
3. Couche 3 : Entonnoirs de validation de formulaire :
   • Chemin heureux : Soumettez des entrées valides → vérifiez la bannière de succès ou la mise à jour d'état.
   • Chemin d'erreur : Soumettez des champs obligatoires vides → vérifiez les alertes de validation en ligne.
4. Couche 4 : Cycle de vie de l'authentification : Connexion valide, rejet d'identifiants invalides, persistance de session et déconnexion.
5. Couche 5 : Workflows CRUD de base : Créer un élément → vérifier qu'il est listé ; modifier un élément → vérifier qu'il est mis à jour ; supprimer un élément → vérifier qu'il est supprimé.