Disponible à partir de TestPulse 2.74.0. Utilisez 2.74.2 ou une version ultérieure pour les zones par défaut dans les plans existants, la recherche des cibles et les correctifs de préparation décrits plus bas. Ce guide décrit le parcours Cas de test CSV. L’import de résultats XML reste un parcours distinct.
Ce que vous allez obtenir
Vous partez d’un petit fichier de tests d’une boutique. À la fin, un plan contient :- le test Se connecter avec un compte valide, avec deux étapes, dans une suite statique existante ;
- le test Payer une commande, avec une étape, dans un nouveau chemin Commandes → Paiement ;
- un bilan JSON permettant d’identifier les créations, les rattachements et les opérations qui nécessitent une vérification.
Avant de commencer
Prévoyez un projet d’exercice, un plan lisible et une suite statique existante nommée Authentification. Vous devez pouvoir créer des cas de test, gérer les suites et ajouter des tests au plan. Créer de nouveaux cas exige aussi Create tag definition au niveau du projet, pour les tags techniques de reprise ajoutés par TestPulse. La création d’un nouveau plan nécessite les droits correspondants sur son area path. Les droits de l’extension ne remplacent pas ceux de votre compte : voir Permissions. Commencez avec le CSV d’exercice en français. Il contient uniquement de nouveaux tests ; aucun ID Azure DevOps fictif n’y est utilisé. Le bouton Télécharger le modèle dans l’assistant fournit également une base à adapter.Réaliser l’import
1
Fichier et colonnes
Ouvrez TestPulse → Import → Cas de test CSV, puis Choisir un fichier CSV. Chargez le fichier d’exercice, encodé en UTF-8.Vérifiez les correspondances de colonnes, notamment External Key, Title, Test Step, Step Action, Step Expected et Suite Path. Une colonne contenant des données doit être associée à un champ ou explicitement ignorée. Les messages indiquent les lignes à corriger.Le fichier d’exercice contient trois lignes d’étapes, mais deux cas de test. Les deux lignes portant la clé
BOUTIQUE-001 forment un seul cas avec deux étapes. Ne modifiez pas la clé à chaque étape.2
Plan de test
Choisissez un plan existant. Saisissez une partie de son nom ou son ID dans le sélecteur avec recherche, puis choisissez le plan d’exercice parmi les résultats. Contrôlez son nom et son ID. Saisir du texte ne sélectionne pas un plan.Contrôlez Zone des nouveaux cas de test et l’itération facultative proposées depuis ce plan. Utilisez une zone où vous pouvez créer des cas. Un champ renseigné dans le CSV est prioritaire ; voir les zones par défaut.L’autre option permet de créer un nouveau plan : renseignez ses informations et choisissez explicitement au moins une configuration de test existante et active. Les configurations inactives ne sont pas proposées. Le plan sera créé uniquement lors de l’exécution, après l’aperçu. Pour suivre ce scénario de réutilisation d’une suite, conservez le plan existant.
3
Suites
Pour le groupe Connexion, choisissez Suite existante, recherchez votre suite Authentification par nom, chemin complet ou ID, puis sélectionnez-la. Vérifiez son chemin et son ID : deux suites peuvent porter le même nom sous des parents différents.Pour le groupe Commandes > Paiement, choisissez Créer ou réutiliser un chemin, recherchez et sélectionnez le parent statique voulu par nom, chemin ou ID, puis gardez le chemin
Commandes > Paiement. Les niveaux existants sont réutilisés lorsqu’ils sont identifiés sans ambiguïté ; les niveaux manquants sont prévus pour création.Ces choix peuvent être combinés dans un même import. Si votre fichier n’a pas de classement, sélectionnez plusieurs cas sans groupe et utilisez Créer un groupe, puis affectez ce groupe à une destination.Seules les suites statiques sont proposées comme cibles. Les suites basées sur une requête ou une exigence ne font pas partie de ce parcours.4
Aperçu
Cliquez sur Préparer l’aperçu. L’assistant lit Azure DevOps pour vérifier la cible et les cas existants. Il transmet aussi le contenu des nouveaux cas à Azure DevOps pour valider les champs et les règles du projet, sans enregistrer de work item. Il présente ensuite les opérations prévues.Contrôlez le plan, les chemins complets, les tests à créer ou réutiliser, les zones et itérations résolues des nouveaux cas, les suites à créer ou réutiliser et les rattachements. Dans ce scénario, vous attendez deux nouveaux tests et deux rattachements. Le nombre de suites à créer dépend de la présence de Commandes et Paiement dans votre plan.Corrigez les blocages avant de continuer. Vérifiez aussi les données de chaque test : un aperçu valide ne garantit pas que le scénario métier soit correct.
5
Résultat
Si l’aperçu correspond au changement voulu, cliquez sur Confirmer et importer. Gardez l’onglet ouvert pendant les opérations.Lisez le bilan, puis utilisez Télécharger le bilan JSON. Suivez les liens vers les objets pour contrôler le résultat dans Azure DevOps.Si vous devez interrompre l’import, Arrêter après l’opération en cours laisse finir la requête déjà envoyée. Les créations réussies restent présentes. Pour continuer, utilisez Vérifier et reprendre : la reprise vérifie l’état enregistré et relit Azure DevOps avant les opérations restantes.
Vérifier le résultat
- Ouvrez le plan et la suite Authentification. Le test Se connecter avec un compte valide doit apparaître une seule fois.
- Ouvrez sa fiche : elle doit comporter deux étapes, dans le bon ordre, avec leurs résultats attendus.
- Ouvrez le chemin Commandes → Paiement sous le parent choisi. Le test Payer une commande doit s’y trouver.
- Comparez les IDs et les destinations au bilan JSON. La création de tests n’exécute aucun test et ne constitue pas une preuve de réussite.
Préparer votre propre fichier
La limite de fichier est 5 Mio, avec au maximum 10 000 lignes de données et 100 colonnes. Utilisez l’UTF-8, avec ou sans BOM. Les séparateurs virgule, point-virgule et tabulation sont pris en charge. Encadrez de guillemets une cellule contenant le séparateur, un guillemet ou un retour à la ligne ; doublez les guillemets internes selon les règles CSV. Un fichier Excel.xlsx doit d’abord être exporté en CSV.
Pour un nom de suite contenant lui-même
>, la valeur de Suite Path peut être un tableau JSON de segments, par exemple ["A > B", "Paiement"]. Dans un fichier CSV, ces guillemets doivent aussi être échappés. Préférez le modèle et vérifiez toujours le chemin affiché.
Les étapes partagées, les jeux de paramètres et les pièces jointes ne sont pas importés par ce parcours. Ne les convertissez pas silencieusement en étapes simples : conservez-les et traitez-les séparément dans Azure DevOps.
Choisir la zone des nouveaux cas
Suite Path organise les rattachements dans Test Plans. Area Path est le classement du work item, avec ses propres permissions : un chemin tel queCommandes > Paiement n’est pas une zone.
Dans Plan de test, contrôlez Zone des nouveaux cas de test et Itération des nouveaux cas de test (facultatif). Pour un plan existant, ses valeurs servent de point de départ. Modifiez-les si les nouveaux cas doivent utiliser un autre classement ; le plan existant n’est pas modifié. Vous pouvez effacer l’itération facultative.
- Une valeur Area Path ou Iteration Path renseignée dans le CSV est prioritaire pour ce cas.
- Sinon, la valeur choisie dans l’assistant est utilisée. Effacer l’itération facultative laisse ce champ non renseigné pour les cas sans valeur CSV.
- Chaque nouveau cas doit avoir une zone résolue avant préparation. Si le plan n’en fournit pas, saisissez une zone valide ; TestPulse ne choisit pas silencieusement la racine du projet.
- Contrôlez les champs résolus dans Aperçu. Création et reprise conservent ces valeurs même si celles du plan changent ensuite. Les cas réutilisés par ID ne sont pas reclassés.
Réutiliser un test existant
Renseignez son ID réel et vérifiez que l’aperçu retrouve le bon cas dans le projet. Le test est rattaché à la suite choisie ; son titre, ses étapes et ses champs ne sont pas modifiés par le CSV. Il n’existe pas de rapprochement automatique par titre. Pour placer un même nouveau test dans plusieurs groupes, conservez la même External Key avec des chemins de suite distincts et des données cohérentes. L’aperçu doit montrer un seul test à créer et plusieurs rattachements. Contrôlez ce point avant d’importer. La clé de fichier n’est pas un mécanisme de synchronisation permanent. Démarrer un nouvel import sans ID peut créer un nouveau cas, même si vous utilisez la même clé ou le même titre. Utilisez le journal pour reprendre l’import en cours et les IDs Azure DevOps pour des rattachements ultérieurs. Un tag technique commençant partestpulse-csv: est ajouté aux nouveaux cas afin de retrouver une création après une réponse perdue. Ne l’utilisez pas pour vos propres tags et ne le retirez pas tant que l’import n’est pas terminé. Les cas réutilisés par ID ne reçoivent pas ce tag.
Comprendre la reprise
Le journal de progression est stocké dans ce navigateur, dans le contexte de l’organisation, du projet et de l’utilisateur. Il contient les données nécessaires à la reprise ; il n’est pas partagé avec l’équipe ni automatiquement transféré sur un autre appareil. Le bilan JSON est une trace téléchargée, pas une commande d’annulation ni une sauvegarde réimportable du journal. L’exécution nécessite le stockage local et la fonction de verrouillage Web Locks du navigateur, qui empêche deux onglets d’exécuter le même import simultanément. Si ces fonctions sont indisponibles, l’assistant bloque l’écriture. Utilisez un navigateur récent et gardez un seul onglet actif pour l’import. Une coupure peut survenir après une création côté Azure DevOps mais avant sa confirmation dans le navigateur. Dans ce cas, l’absence de réponse ne signifie pas que rien n’a été créé. La reprise vérifie les objets et signale les résultats qui restent ambigus. Elle ne doit pas recréer aveuglément ces objets.Quand une opération incertaine n’a réellement pas abouti
- Téléchargez le bilan et examinez la ligne À vérifier : objet attendu, plan, suite, cas et destination. Contrôlez directement dans Azure DevOps que cette opération n’a pas abouti. Un chargement incomplet ou un accès refusé ne prouve pas l’absence d’un objet.
- Seulement après ce contrôle, utilisez sur cette ligne J’ai vérifié que cette opération n’a pas abouti. Relisez Autoriser une nouvelle tentative ? et cochez sa confirmation : vous autorisez la possibilité de recréer l’objet ou le rattachement lors de la prochaine reprise.
- Cliquez sur Confirmer l’absence et autoriser la reprise. TestPulse relit Azure DevOps. Si l’objet est retrouvé, si la cible ou sa configuration a changé, ou si un ID de plan ou de cas est déjà connu, la résolution par absence est refusée. Conservez le journal et vérifiez la situation ; ne contournez pas ce refus.
- Si l’absence est confirmée, l’opération passe à Échec, avec une résolution horodatée dans le journal. Aucune création n’est déclenchée par ce seul geste. Cliquez ensuite sur Vérifier et reprendre pour relancer les opérations restantes avec les contrôles habituels.
Dépannage
TF237111 : permission refusée sur une zone
Il s’agit d’un refus Azure DevOps sur les work items, distinct de l’ancien problème d’adresse de service décrit plus bas. Depuis 2.74.2, le message précise le cas, ses lignes source et la zone refusée.- Dans Plan de test, vérifiez Zone des nouveaux cas de test. Le chemin de la suite sélectionnée n’est pas une zone.
- Contrôlez une éventuelle valeur Area Path associée dans le CSV : une valeur remplie remplace celle de l’assistant. Corrigez la bonne valeur au lieu de modifier une suite sans rapport avec ce refus.
- Choisissez la zone voulue où votre compte peut créer des cas, ou faites vérifier Modifier les éléments de travail dans ce nœud (Edit work items in this node) par un administrateur. Sélectionner un plan ou une suite ne donne pas ce droit ; ce correctif ne demande aucun nouveau scope d’extension.
- Préparez à nouveau l’aperçu et contrôlez la zone résolue. Un refus pendant cette préparation ne crée aucun cas, suite ou plan.
Un ancien journal demande de contrôler les classements
Un journal créé avant ce correctif peut contenir de nouveaux cas en attente dont les valeurs de classement nécessaires à la création n’ont pas été figées. TestPulse le garde lisible et exportable, mais refuse toute nouvelle écriture tant que ces créations restent à faire. Il ne devine pas une autre zone à la reprise. Conservez le journal, téléchargez le bilan JSON et examinez les objets déjà présents dans Azure DevOps avant de décider comment traiter les cas restants. Ne réimportez pas tout le fichier avec des IDs vides : cela peut dupliquer les créations réussies. Ce contrôle ne reclasse pas les cas déjà créés. Si une création antérieure a un résultat incertain, TestPulse recherche d’abord son tag de reprise unique dans Azure DevOps, sans écriture. Si ce tag identifie sans ambiguïté un cas existant, ce cas peut être retrouvé et ses rattachements restants peuvent reprendre. Une correspondance absente ou ambiguë n’autorise pas la création d’un remplacement avec des classements non contrôlés.Erreur 403 pendant la préparation de l’aperçu en 2.74.0
La version 2.74.1 corrige un défaut de résolution de l’adresse de service : la demande de validation pouvait partir vers l’hébergement de l’extension au lieu du service Azure DevOps. Cette erreur intervenait avant toute création de cas ou de suite. Ajouter des droits ne corrige pas ce défaut de routage.- Après la mise à jour, rechargez l’onglet Azure DevOps et vérifiez que Documentation affiche 2.74.1 ou une version ultérieure.
- Sélectionnez à nouveau le CSV si nécessaire, contrôlez les correspondances et les cibles, puis cliquez sur Préparer l’aperçu.
- Si un import antérieur avait déjà effectué des écritures, conservez son journal et utilisez Vérifier et reprendre, au lieu de démarrer un nouvel import.
Autres situations
À suivre
Importer des résultats XML
Sauvegarder un rapport AUTO à partir de résultats automatisés.
Lectures et écritures
Distinguer les créations CSV, l’historique et les résultats d’exécution.