Le Blog Amazon Web Services

Révolutionner vos tests d’interface utilisateur de bout en bout avec IA Agentique et « Computer Use » d’Anthropic sur Amazon Bedrock (Partie 2)

La première partie de cette série présente l’outil Computer Use d’Anthropic, une capacité de pointe du modèle Sonnet 3.5 v2 qui combine le raisonnement avancé avec l’analyse visuelle. Cet outil permet à Claude de comprendre le contexte informatique, lui permettant d’interpréter le langage humain, de reconnaître les pages web et d’effectuer diverses actions comme prendre des captures d’écran, déplacer la souris, saisir du texte, cliquer, faire défiler, etc.

À mesure que les modèles d’Intelligence Artificielle continuent d’évoluer et de remodeler le paysage technologique, des outils comme Computer Use ouvrent la voie à des innovations révolutionnaires. Cette capacité offre des possibilités transformatrices pour les développeurs, particulièrement en révolutionnant la conception et la mise en œuvre des tests automatisés de bout en bout (E2E), améliorant à la fois l’efficacité et la productivité des workflows de test.

Cet article approfondit la façon dont ces fonctionnalités peuvent être exploitées pour automatiser des workflows de tests E2E avancés qui simulent avec précision les comportements réels des utilisateurs. De plus, il couvre les bonnes pratiques pour écrire des tests efficaces et partager des stratégies pour optimiser les performances en utilisant cette technologie.

Architecture

Ce guide présente des instructions détaillées et pratiques pour implémenter une suite de tests E2E utilisant l’outil Computer Use d’Anthropic dans une application React. Cette solution comprend une application React déployable et un environnement Docker pré-configuré. Elle utilise des outils Bash et Text Editor pour automatiser les workflows de test complets de bout en bout.

Cette solution démontre une application frontend avec un bouton de téléchargement, l’objectif est de s’assurer qu’en cliquant sur le bouton, cela déclenche le téléchargement d’un fichier spécifique, comme « info.txt ». Cette solution automatise l’ensemble du scénario de test – depuis l’initiation de l’action de téléchargement jusqu’à la vérification que « info.txt » a été téléchargé avec succès.

Architecture d'Automatisation de Tests avec Déploiement Conteneurisé

Figure 1 : Architecture d’Automatisation de Tests avec Déploiement Conteneurisé

Configuration

Prérequis

Avant de commencer, assurez-vous de remplir les conditions suivantes :

Compte AWS

Vous devez avoir un compte AWS et un rôle et utilisateur Gestion des identités et des accès AWS (AWS IAM) avec les permissions nécessaires pour activer l’accès au modèle LLM et invoquer les API Bedrock. Si vous n’avez pas de compte AWS, consultez Comment créer et activer un nouveau compte Amazon Web Services ?

Obtenir l’accès au modèle

  • Naviguez dans Amazon Bedrock sur votre compte AWS.
  • Assurez-vous d’être dans la région ‘us-west-2’.
  • Demandez l’accès au LLM ‘Claude 3.5 Sonnet v2’ d’Anthropic.

Figure 2 : Console Amazon Bedrock – Sélection du modèle Claude 3.5 Sonnet pour les tests E2

Obtenir les identifiants AWS

Il existe plusieurs options pour le faire, la plus simple étant de configurer des variables d’environnement dans le terminal

[Linux/MacOs]
export AWS_ACCESS_KEY_ID="your-access-key-id"
export AWS_SECRET_ACCESS_KEY="your-secret-access-key"
export AWS_SESSION_TOKEN="your-session-token"
export AWS_REGION="us-west-2"
Bash

Veuillez suivre le guide AWS pour configurer les variables d’environnement pour l’AWS CLI.
Maintenant que votre environnement est prêt, passons à la suite.

Implémentation

Clonez le Repo

git clone https://github.com/aws-samples/aws-genai-e2e-testing-samples
Bash

Structure du projet
La solution est organisée en deux dossiers principaux : backend et frontend. Le dossier backend contient le framework de test UI, tandis que le dossier frontend inclut l’application UI de démonstration et le fichier de définition pour vos cas de test.

backend/
├── src/
├── requirements.txt
└── .env
frontend/
└── tests/
└── e2e.yml
Dockerfile
Bash

Installez les dépendances
Créez et activez un environnement virtuel Python pour installer les dépendances requises dans un espace isolé, évitant ainsi les conflits avec d’autres projets sur votre machine.

python3 -m venv venv
source .venv/bin/activate

pip3 install -r backend/requirements.txt
Bash

Configurez l’environnement

Configurez votre fichier .env dans le dossier /backend avec l’URL de l’application de test, cela peut être n’importe quelle URL, par exemple https://amazon.com

APP_BASE_URL=http://localhost:3000
Bash

Exécutez l’application UI (Optionnel)
Ce guide inclut une application React exemple que vous pouvez utiliser pour les tests. C’est une simple application tableau de bord avec un bouton de téléchargement pour sauvegarder une image. Si vous testez l’application React incluse, vous devrez d’abord la lancer. Cependant, cette étape est optionnelle si vous testez une autre application. Pour démarrer l’application, naviguez vers le dossier frontend et exécutez la commande suivante :

npm run dev
Bash

Une fois l’application lancée, elle sera accessible à l’adresse http://localhost:3000. L’application est un tableau de bord de démonstration proposant une fonctionnalité de téléchargement. Si elle fonctionne correctement, vous devriez voir une interface utilisateur avec un bouton pour déclencher le téléchargement.

Capture d'écran de l'application

Figure 3 : Interface du dashboard de l’application de test avec bouton de téléchargement

Écrivez vos tests
Écrivez vos cas de test dans le fichier frontend/tests/e2e.yml. Le fichier YAML doit contenir les noms des tests et les prompts descriptifs dans le format suivant :

tests:
  - name: "happy path: download image, verify that its downloaded"
    prompt: |
      You are on the home page. Find the 'Download Image' button and click it.
      Assert that the image is downloaded.
      By checking the downloaded image file in the home downloads folder.
      If the image is downloaded, move it to the 'Tests Demo' folder
      
  - name: "sad path: find non existent file"
    prompt: |
      In my home Downloads folder, I have a 'Tests Demo' folder.
      DO NOT navigate to or look for it in any other paths.
      Verify that I have a file named 'tests-demo.jpg' in the 'Tests Demo' folder.
Bash
  • Écrire des tests clairs et bien définis : Pour simuler un comportement humain réaliste dans votre test de E2E, fournissez des instructions explicites et détaillées pour chaque unité de test. Des prompts clairs réduisent l’ambiguïté et améliorent la qualité des actions de Claude.
  • Définir les réponses attendues : Vous pouvez spécifier la expected_response pour chaque test, que vous pouvez utiliser comme référence pour comparer les réponses de Claude à vos assertions de test. Par exemple :
tests:
  - name: "happy path: download image from dashboard, verify that it is downloaded"
    prompt: |
      You are on the dashboard page. Find the 'Download Image' button and click it.
      ...
      After your assertion, respond with 'True' for valid test or 'False' for invalid test
    expected_response: "True"
Bash

Exécutez vos tests

cd backend
python3 -m src.main
Bash

Figure 4 : Démonstration

Alternativement, vous pouvez exécuter l’application dans un conteneur Docker en suivant ces commandes. Cela démarre le backend et copie vos définitions de test dans l’environnement Docker pour l’exécution.

docker build -t computer_use_poc:v1 .
docker run \
    -e AWS_PROFILE=default \
    -e AWS_REGION=us-west-2 \
    -v $HOME/.aws:/home/computeruse/.aws \
    -v $HOME/.anthropic:/home/computeruse/.anthropic \
    -it computer_use_poc:v1
Bash

Figure 5 : Exemple d’exécution réussie d’un test E2E – Vérification du téléchargement et déplacement d’un fichier

Claude LLM-as-a-judge – Le processus d’exécution des tests

Les tests sont exécutés en envoyant les captures d’écran de l’application React et les prompts système à Claude via un Loop Agent. Claude utilise les captures d’écran pour naviguer et localiser les éléments de l’interface utilisateur et la position de la souris. L’agent en boucle est un script qui interagit avec l’API Anthropic, exécutant les actions et les commandes des outils Computer Use. Claude agit ici comme “juge », en validant les résultats des tests en utilisant les captures d’écran de l’application et en effectuant une série d’actions, comme des clics de souris et des commandes bash. Une fois l’exécution de la boucle terminée, Claude fournit une réponse finale résumant les résultats des tests.

Avec cette solution, nous démontrons comment simuler des workflows de test E2E qui automatisent la façon dont un humain utilise la fonctionnalité de téléchargement d’une application. Non seulement elle peut vérifier que le bouton de téléchargement fonctionne correctement, mais elle s’assure également que le fichier attendu est téléchargé.

Pendant l’exécution du test, vous verrez des logs détaillés dans la console qui suivent les actions de Claude et l’utilisation des outils étape par étape. Une fois qu’un test est terminé, vous recevrez un résultat « PASS » ou « FAIL« , reflétant le résultat de votre cas de test.

Bonnes pratiques

Maintenant que vous avez simulé avec succès votre test E2E, vous pouvez appliquer certaines pratiques pour améliorer les performances de cette solution.

Optimisation des performances avec le prompting

Comme pour toute solution d’IA Générative, un prompt engineering efficace est essentiel pour obtenir des résultats précis et fiables. Voici des conseils pour améliorer les performances de sortie :

  • Gestion des éléments UI cachés ou en bas de page : La capacité de Claude à manipuler les éléments UI dépend de sa technologie de vision. Pour les éléments cachés comme les menus déroulants, les champs de saisie ou les barres de défilement, incluez des instructions claires sur la façon dont Claude peut interagir avec eux. Par exemple :
prompt: |
      You are on the aws blog page. There is a 'Contact us' button on the footer part of the page, you have to scroll down to see it. Click on the button.
      Assert that you have navigated to the Contact us page.
expected_response: "True"
Bash
  • Résultats de test personnalisables: Bien que cette solution utilise par défaut « Pass » et « Fail » pour les résultats des tests, vous pouvez personnaliser les réponses en instruisant Claude sur la façon de correspondre à vos assertions de cas de test spécifiques. Cela peut être fait en mettant à jour les constantes SUCCESS_INDICATOR et FAILURE_INDICATOR dans backend/src/constants.py
SUCCESS_INDICATOR = "pass"
FAILURE_INDICATOR = "fail"
Bash

Conclusion

Cette solution présente un potentiel significatif en utilisant un Agent de test avec l’outil Computer Use d’Anthropic. Elle offre des possibilités de révolutionner la façon dont les développeurs abordent les tests automatisés de bout en bout. La capacité à générer et exécuter automatiquement des tests basés sur des user stories, combinée à la flexibilité d’interagir avec des environnements dynamiques, représente un grand pas en avant dans l’efficacité du cycle de vie du développement logiciel. Cette solution pourrait conduire à plusieurs avantages importants :

  • Amélioration de la précision et de la fiabilité des tests : Avec des tests automatisés en place, les développeurs peuvent s’assurer que les fonctionnalités sont testées de manière approfondie, conduisant à des résultats plus précis et fiables. Cela réduit le temps passé au débogage et augmente la confiance dans le déploiement, permettant de consacrer plus de temps à la création de fonctionnalités innovantes. De plus, le risque de régression diminue, allégeant la charge opérationnelle des équipes.
  • Efficacité en temps et en ressources pour les tests : L’automatisation des tests réduit le besoin de tests manuels pour les applications complexes, qui sont à la fois chronophages et nécessite un besoin humain. Cela peut conduire à des économies significatives en temps de test et en efforts de développement.
  • Usage du language naturel: Il permet aux équipes non-techniques de créer des tests sans avoir besoin de connaissances approfondie en programmation

Notes Finales

Nous avons analysé plusieurs axes d’amélioration qui pourrait améliorer cette solution expérimentale:

  • Packaging : Développer cette solution en TypeScript ou JavaScript pour créer un package NPM pour une intégration facile dans n’importe quelle application frontend.
  • Assertions et Score de Confiance : Nécessite une validation supplémentaire pour les points de données concernant le score de confiance du test.
  • Barrières de protection : Nécessite des garde-fous supplémentaires pour empêcher les prompts malveillants.
  • Exécution Parallèle des Tests : Permettre au framework d’exécuter des tests en parallèle pour une plus grande efficacité.
  • Génération Automatique de tests : L’une des lacunes de cette solution est de s’appuyer sur des tests écrits par les utilisateurs qui peuvent être erronés. Pour améliorer cela, la génération de tests peut être automatisée avec les user stories et le contexte de l’application.
  • Limitation de débit : Des problèmes de limitation de débit avec Bedrock peuvent être perçus. Pour atténuer cela, configurez la limite de débit dans Bedrock et incluez l’instruction suivante dans votre prompt système :
    • « Lors de l’utilisation de vos appels de fonction informatiques, leur traitement peut prendre du temps. Pour améliorer l’efficacité, essayez de chaîner plusieurs appels de fonction en une seule requête. »

Cette solution expérimentale présente plusieurs risques de sécurité qui doivent être pris en compte avant un passage en production:

  • Un utilisateur malveillant pourrait écrire des tests conçus pour faire exécuter des actions malveillantes au LLM contre l’environnement de test.
  • Les tests pourraient également être conçus pour effectuer des attaques ciblées contre le LLM lui-même, comme essayer d’extraire des informations sensibles ou le faire dévier de son comportement normal.
  • L’utilisation d’une image Docker obsolète pourrait exposer des vulnérabilités connues, permettant un accès non autorisé à l’environnement de test.
  • Une page web malveillante testée pourrait tenter d’exploiter des failles de sécurité dans l’environnement de test ou d’exécuter du code malveillant.
  • Le modèle LLM lui-même pourrait avoir des comportements inattendus ou malveillants s’il est mal configuré ou compromis.
  • La page web testée pourrait fournir des captures d’écran malveillantes conçues pour manipuler ou attaquer le LLM.

Pour atténuer ces risques, il est recommandé de:

  • Valider soigneusement tous les cas de test avant exécution
  • Utiliser un environnement de test isolé et sécurisé
  • Maintenir à jour les images Docker et dépendances
  • Implémenter des restrictions d’accès et des mécanismes de surveillance
  • Tester uniquement des sites web de confiance
  • Effectuer des audits de sécurité réguliers
Maryam Khidir

Maryam Khidir

Maryam est ingénieure en développement logiciel AWS et possède une vaste expérience en tant qu’ingénieure en développement front-end et mobile. Chez AWS, elle fait partie de l’équipe Proserve PSE (Product and Solutions Engineering), où elle se concentre sur l’ingénierie de solutions évolutives qui répondent efficacement aux défis des clients et génèrent des résultats percutants.

Jeremy Labrado

Jeremy Labrado

Jeremy est un ingénieur senior en développement logiciel AWS avec une vaste expérience dans les systèmes informatiques et avec un background IoT. Passionné par l’intelligence artificielle, il travaille en étroite collaboration avec les clients pour les aider à mener à bien des projets complexes et ambigus, du début à la fin, avec des résultats percutants pour atteindre leurs objectifs principaux et stimuler l’innovation.

Mo

Mo

Mo est un ingénieur en développement logiciel AWS dans l’équipe l’équipe Produits et solutions de ProServe. Fort d’une expérience dans le développement d’applications d’IA évolutives, il participe activement au développement de solutions d’IA génératives pour les clients AWS.