Générer un rapport

Générez un rapport depuis un plan de test Azure DevOps. TestPulse lit les données du périmètre choisi et sauvegarde le rapport dans votre historique Extension Data ; il ne modifie pas les résultats de test.

Sélectionner un plan de test

Utilisez le menu déroulant avec autocomplétion pour rechercher les plans par nom ou chemin d’itération. Les suites se chargent en arbre — les sous-suites sont indentées sous leur parent.

Tout développer / Tout réduire pour naviguer.
Décochez une suite pour l’exclure du rapport.
Les plans marqués INACTIVE sont masqués par défaut — un toggle les affiche.
Exclure vides décoche en un clic toutes les suites sans cas de test (les suites en erreur de chargement ne sont jamais touchées). Un badge (N masquées) apparaît à côté du compteur, et la préférence est mémorisée.
Filtrer les suites par nom — saisissez dans le champ de filtre pour réduire l’arbre (accents et casse ignorés). Tout ancêtre d’une correspondance reste visible, pour ne jamais perdre le repère dans la hiérarchie.
Rechercher un plan par son identifiant dans le même champ d’autocomplétion. S’il est introuvable, vous êtes invité à inclure les plans inactifs.
Suites d’exigences uniquement restreint la traçabilité aux suites basées sur exigence — utile sur un plan de non-régression dont les cas de test portent des années de liens sans rapport. Désactivée par défaut ; un point d’interrogation explique les deux modes.

Les suites vides s’affichent par défaut, et la hiérarchie affichée correspond toujours à Azure DevOps : une suite parente vide portant un enfant visible n’est jamais retirée, et une suite masquée n’est jamais remontée au mauvais niveau.

Les suites, les cas de test, les résultats d’exécution et l’historique des exécutions sont chacun lus jusqu’à épuisement. Si l’un d’eux ne peut pas être confirmé complet, son propre bandeau distinct le signale sur le rapport — jamais dans un export. Un bandeau sur le contenu des cas n’implique jamais que le taux de passage soit affecté, et celui sur l’historique n’implique jamais que la liste des suites le soit.

Champs du formulaire

Les champs obligatoires dépendent de Paramètres → Configuration des champs. Numéro de change, Incident, Request, Objectifs et critères sont facultatifs par défaut ; suivez les indications de votre formulaire. Contact IT, Contact Business, Testeur et Approbateur proposent l’autocomplétion des utilisateurs Azure DevOps (tapez au moins 2 caractères).

Champ	Description
Titre du rapport	Nom affiché sur la page de garde.
Environnement	DEV / QA / UAT / PREPROD / PROD (configurable).
Référence projet	Code ou identifiant du projet.
Numéro de change	Optionnel — référence du changement.
Incident / Request	Champs de référence optionnels à côté du numéro de change.
Application	Nom de l’application testée.
Domaine fonctionnel	Domaine ou module concerné.
Fonctionnalités testées	Description des fonctionnalités couvertes.
Périmètre de tests	Portée et limites des tests.
Objectifs	Multi-lignes — les sauts de ligne sont préservés dans les exports.
Critères d’entrée	Multi-lignes — conditions pour démarrer la campagne.
Critères de sortie	Multi-lignes — conditions pour arrêter la campagne.
Testeur	Personne ayant réalisé les tests (autocomplétion ADO).
Approbateur	Personne approuvant le rapport (autocomplétion ADO).
Rôle approbateur	Fonction de l’approbateur.
Date du rapport	Pré-remplie à la date du jour.
Build associé	Lier un build ADO — autocomplétion depuis les builds récents (branche et statut affichés) ; lien cliquable dans PDF, HTML et Word.

Champs supplémentaires et visibilité

Dans Paramètres → Champs du formulaire, vous pouvez ajouter jusqu’à trois champs personnalisés, de type texte ou liste déroulante, et choisir s’ils sont obligatoires. Leurs valeurs figurent dans PDF, HTML et Word, pas dans Excel ou PowerPoint. Visible contrôle le formulaire et les sections d’export qui prennent en charge ce réglage. Le toggle Page de garde agit seulement sur la couverture PDF. Ces réglages ne garantissent pas que les métadonnées fixes des exports Excel ou PowerPoint soient masquées ; relisez le fichier avant de le partager. Voir les formats d’export.

Validation

Chaque champ peut porter un pattern regex (Paramètres → Configuration des champs) :

Bloquant — la génération est impossible si le champ n’est pas conforme.
Avertissement — la génération continue, avec une alerte orange.

La validation s’exécute en temps réel dans le formulaire (indicateur rouge / orange par champ) et à nouveau au moment de la génération. Longueur douce — un seuil optionnel par champ. Au-delà, un indice orange, non bloquant apparaît (« n / seuil — risque de débordement sur la page de garde »). Il ne bloque jamais la génération et ne tronque jamais la valeur — il aide seulement à garder une page de garde lisible.

Les contacts (IT, Business, Testeur, Approbateur) sont des identités Azure DevOps : ni regex ni longueur douce — tout pattern stocké est ignoré. Ils sont regroupés sous « Contacts & validation ».

Lire le rapport généré

Résultats affiche le dernier résultat par cas de test ; Historique complet liste chaque exécution, une ligne par exécution.
Les deux portent une colonne Run : le numéro d’exécution, cliquable, qui ouvre le résultat exact dans Azure DevOps — pas seulement l’exécution qui le contenait. Les liens passent par la navigation d’Azure DevOps elle-même, donc fonctionnent aussi depuis une fiche work item sandboxée on-premises.
Les compteurs d’onglets suivent le filtre actif : filtrer sur un seul cas de test ne laisse plus l’un d’eux annoncer le plan entier.
Les bugs viennent, par défaut, des exécutions des plans sélectionnés, du plus récent au plus ancien — voir Les bugs du rapport.
Chaque suite s’affiche par son chemin (CH › SALES › Pre-Payment), dernier niveau en gras, chemin complet en infobulle ; les suites homonymes gardent leurs propres chiffres.

Prise en main

Ateliers guidés

Concepts