

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Test de version
<a name="release-management-release-testing"></a>

Les tests de version génèrent et exécutent des plans de test pour valider les modifications du code dans des environnements réalistes. L'agent de test des versions exécute des tests exploratoires UAT et de régression (régression fonctionnelle, validation du parcours utilisateur, tests d'intégration et exploration de cas extrêmes) sur vos applications Web et API REST déployées.

## Comment fonctionnent les tests de version
<a name="how-release-testing-works"></a>

**Important**  
**Les tests de version exécutent des requêtes réelles sur votre application cible, y compris des opérations d'écriture (POST, PUT, DELETE). L'agent explore les points de terminaison, soumet des formulaires et teste la gestion des erreurs. Ces actions peuvent créer, modifier ou supprimer des données dans l'application cible. À utiliser uniquement lorsque votre profil de risque peut accepter des actions mutantes dans le cadre des tests exploratoires. Assurez-vous que vos applications peuvent tolérer les opérations d'écriture exploratoires sans conséquences imprévues, telles que l'envoi de notifications aux clients, le traitement des paiements ou la suppression définitive d'enregistrements. Nous vous recommandons de procéder à des déploiements intermédiaires ; les applications de production ne doivent être ciblées que lorsque les opérations d'écriture de votre application sont sûres pour les tests automatisés.

Lorsqu'il est déclenché, l'agent de test de version :

1. **Génère un plan de test** — Crée un plan de test basé sur les modifications du code ou sur une intention de test fournie par l'utilisateur. Lorsqu'il est déclenché par une pull request ou une branche, le plan cible les fonctionnalités concernées. En cas de déclenchement manuel ou à partir du chat, vous pouvez fournir une intention de test décrivant les éléments à valider. Le plan couvre l'exactitude fonctionnelle, le comportement d'intégration et les scénarios destinés aux utilisateurs.

1. **Exécute des tests sur une application en cours d'exécution** : à partir d'une URL cible (application Web ou point de terminaison d'API), l'agent explore l'application et exécute les tests générés. Pour les applications Web, cela inclut l'interaction avec l'interface utilisateur basée sur le navigateur et l'inspection visuelle. Pour les API, cela inclut le test direct des points de terminaison HTTP, la validation du schéma et la vérification de la gestion des erreurs.

1. Résultats **des rapports** : les résultats sont renvoyés avec les défaillances spécifiques, les fonctionnalités affectées, les étapes de reproduction et les correctifs recommandés.

Les tests de version prennent en charge les applications Web (React, Angular, Vue, rendues par le serveur) et les API REST.

## Types de tests pris en charge
<a name="supported-test-types"></a>
+ **Test de l'interface utilisateur** : Browser-based tests avec interactions visuelles pour les applications Web
+ **Test d'API — Test** direct des points de terminaison HTTP pour les API REST

## Définition des profils de test
<a name="defining-test-profiles"></a>

Les profils de test définissent les applications Web et API que vous souhaitez tester ainsi que les configurations nécessaires. Chaque profil de test spécifie une application cible et son type de test.

Pour créer un profil de test :

1. Dans l'application Web DevOps Agent, accédez à **Release Manager** dans le volet de navigation de gauche.

1. Cliquez sur le bouton **Tester les profils**.

1. Choisissez **Ajouter un profil de test**.

1. Remplissez le formulaire avec les informations suivantes :
   + **Nom : nom** descriptif du profil de test (par exemple, « MyApp  Staging »)
   + **URL cible** : URL d'un déploiement intermédiaire ou test de votre application. L'agent envoie du trafic HTTP réel, y compris des opérations d'écriture (POST, PUT, DELETE). N'utilisez pas d'URL de production à moins de comprendre et d'accepter le risque de modification des données.
   + **Type de test** : sélectionnez un test d'**interface utilisateur (test** basé sur un navigateur avec interactions visuelles) ou un test d'**API (test** direct des points de terminaison HTTP)

1. Choisissez **Ajouter un profil de test** pour enregistrer.

**Remarque :** L'application doit être accessible via l'Internet public. Les points de terminaison du réseau privé ne sont actuellement pas pris en charge.

## Exécution de tests à partir d'un profil de test
<a name="running-tests-from-a-test-profile"></a>

Sur la page **Profils de test**, vous pouvez déclencher manuellement un test :

1. Trouvez votre profil de test dans la liste.

1. Choisissez **Commencer les tests**.

1. (Facultatif) Spécifiez des instructions spécifiques et les éléments à tester dans **Intention du test**. Par exemple, « Vérifiez que le flux de paiement gère correctement les coupons expirés » ou « Testez le formulaire d'inscription de l'utilisateur avec des entrées non valides ».

L'agent générera un plan de test basé sur votre intention (ou explorera de manière approfondie si aucune intention n'est fournie), exécutera des tests et publiera les résultats dans la section **Release Manager** sous les modifications proposées.

## Exécution de tests depuis le chat de DevOps l'agent
<a name="running-tests-from-devops-agent-chat"></a>

Depuis le chat de DevOps l'agent, vous pouvez demander des tests de version. Demandez à l'agent de répertorier vos profils de test ou de préciser lequel exécuter. L'agent demandera toutes les informations de suivi nécessaires, telles que les éléments à tester ou les domaines sur lesquels se concentrer.

Exemples :
+ « Lister mes profils de test »
+ « Exécuter le profil de test my-test-profile »
+ « Effectuez des tests de version sur mon application à l'https://staging.myapp.comadresse et vérifiez le flux de paiement »

L'agent rend compte de la progression au fur et à mesure qu'il explore l'application et renvoie les résultats avec des résultats spécifiques, des captures d'écran (pour les tests d'interface utilisateur) et des étapes de reproduction.

## Exécution de tests depuis votre IDE
<a name="running-tests-from-your-ide"></a>

Depuis Kiro IDE ou Claude Code, l'agent de codage peut lancer des tests de version :

Installez d'abord le [plugin [Kiro power]() ou Claude Code]().
+ Spécifiez une exigence ou une intention de test décrivant les éléments à valider (par exemple, « vérifier que le flux de connexion fonctionne après le refacteur d'authentification »)
+ L'agent de codage transmet l'intention de test et un profil de test cible à l'agent de test de libération.
+ L'agent de test des versions génère et exécute des tests, puis rapporte les résultats
+ Si des problèmes sont découverts, l'agent de codage propose de les corriger sur place

**Remarque :** Les tests basés sur une pull request directement depuis l'IDE ne sont pas pris en charge actuellement. Utilisez un profil de test avec une URL d'application déployée et fournissez une exigence de test pour cibler les tests.

## Tests de rejet dans les CI/CD pipelines
<a name="release-testing-in-cicd-pipelines"></a>

### GitHub Actions
<a name="github-actions"></a>

L'`aws-actions/devops-agent-release-testing@v1` GitHub action déclenche l'agent de test de version après le déploiement et rapporte les résultats sous forme de GitHub Check Run lors de votre commit ou de votre pull request.

#### Conditions préalables
<a name="prerequisites"></a>
+ Un [profil de test](#defining-test-profiles) configuré dans votre espace agent
+ A [Invocation de DevOps l'agent via Webhook](configuring-integrations-and-knowledge-invoking-devops-agent-through-webhook.md) configuré dans votre espace d'agent

#### Étape 1 : configurer les secrets GitHub du référentiel
<a name="step-1-configure-github-repository-secrets"></a>

Dans votre GitHub dépôt, allez dans **Paramètres → Secrets et variables → Actions → Secrets du dépôt** et ajoutez :


| Secret | Description | 
| --- | --- | 
| DEVOPS\_AGENT\_WEBHOOK\_URL | L'URL du webhook depuis votre espace agent | 
| DEVOPS\_AGENT\_WEBHOOK\_SECRET | Le secret de signature du webhook depuis votre espace agent | 

Pour plus d'informations sur la création d'un point de terminaison Webhook, consultez[Invocation de DevOps l'agent via Webhook](configuring-integrations-and-knowledge-invoking-devops-agent-through-webhook.md).

#### Étape 2 : ajouter l'action à votre flux de travail
<a name="step-2-add-the-action-to-your-workflow"></a>

Ajoutez l'étape de test de version à votre flux de travail (par exemple,`.github/workflows/release-tests.yml`) :

```
name: Release Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  checks: write
  contents: read
  pull-requests: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Release Tests
        uses: aws-actions/devops-agent-qa@v1
        with:
          webhook-url: ${{ secrets.DEVOPS_AGENT_WEBHOOK_URL }}
          webhook-secret: ${{ secrets.DEVOPS_AGENT_WEBHOOK_SECRET }}
          test-profile-id: <YOUR_TEST_PROFILE_ID>
          test-requirement: <WHAT_TO_TEST>  # optional
        env:
          GITHUB_TOKEN: ${{ github.token }}
```

`<YOUR_TEST_PROFILE_ID>`Remplacez-le par l'ID du profil de test de votre espace agent (commence par`ki-`). La `test-requirement` saisie est facultative. Utilisez-la pour concentrer l'agent sur des domaines spécifiques (par exemple, « vérifier le flux de connexion après le refactorisation de l'authentification »).

#### Entrées d'action
<a name="action-inputs"></a>


| Input | Obligatoire | Description | 
| --- | --- | --- | 
| URL du webhook | Oui | L'URL du webhook depuis votre espace agent | 
| secret du webhook | Oui | Le secret de signature du webhook pour l'authentification HMAC-SHA256  | 
| identifiant du profil de test | Oui | L'ID du profil de test à déclencher (commence parki-) | 
| exigence d'essai | Non | Zone de focalisation optionnelle pour les tests | 

#### Autorisations de flux de travail requises
<a name="required-workflow-permissions"></a>


| Autorisations | Raison | 
| --- | --- | 
| contenu : lire | Obligatoire pour actions/checkout les séjours en repos privé | 
| pull-requests : lecture | Résoudre le numéro PR à partir du commit de fusion SHA | 

#### Comment ça marche
<a name="how-it-works"></a>

1. Votre flux de travail se déclenche (par exemple, après le déploiement dans un environnement intermédiaire).

1. L'action crée un Check Run (`in_progress`) sur le commit ou le PR, qui apparaît comme un check en attente.

1. L'action signe et envoie un webhook à votre espace agent.

1. L'agent de test de version prend en charge la tâche et exécute des tests sur votre application.

1. Les résultats sont présentés sous forme GitHub de test (pass/fail avec un résumé détaillé).

Vous pouvez consulter les détails complets de l'exécution (chronologie, scénarios de test, captures d'écran pour les tests d'interface utilisateur) dans l'application Web DevOps Agent liée à votre espace agent.

## Révision des résultats des tests
<a name="reviewing-test-results"></a>

Les résultats des tests apparaissent dans la section **Modifications** de l'application Web de l' DevOps agent sous les modifications proposées. Chaque essai montre :
+ **État** : terminé, en échec ou en cours
+ **Catégorie** — Test de version
+ **Durée** — Combien de temps a duré le test
+ **Source** : s'il a été déclenché manuellement, à partir d'un chat ou d'un CI/CD pipeline

Sélectionnez un test pour afficher les résultats détaillés, notamment les échecs de test spécifiques, les captures d'écran (pour les tests d'interface utilisateur), les étapes de reproduction et les correctifs recommandés.