Exportation d’un travail HLK ayant échoué

Vous pouvez maintenant exporter un travail ayant échoué afin qu’il puisse être exécuté sur un ordinateur en dehors de l’environnement HLK complet. Pour les développeurs de pilotes, cette fonctionnalité permet l’exécution autonome du test afin de simplifier le processus de reproduction des échecs.

Un environnement de test exporté simule étroitement un environnement HLK dédié. Toutefois, cela ne garantit pas l’exécution identique des tests. Un utilisateur peut avoir besoin de gérer l’une des circonstances suivantes :

• Les redémarrages ne sont pas gérés par l’infrastructure de test. L’utilisateur doit redémarrer manuellement le système dans de nombreux cas.
• Il peut arriver que le test redémarre le système via l’infrastructure du client HLK au sein d’une tâche de test. Par exemple, ces redémarrages peuvent ne pas être capturés dans le fichier batch en tant qu’invites ou redémarrages pendant l’exécution autonome.
• Des fichiers journaux nommés de manière non unique écrits au même emplacement par des tâches différentes peuvent entraîner le remplacement de certains de ces fichiers.
• Les paramètres écrits dans le fichier batch peuvent différer lors de l’exécution sur des systèmes différents. Par exemple, les ID de matériel instance peuvent différer pour le même matériel et le même pilote lorsqu’ils sont déplacés vers un autre système, et l’utilisateur doit rechercher la valeur cible correspondante (à partir de Gestionnaire de périphériques, par exemple) et mettre à jour le fichier batch avec la valeur correcte.
• Les tests qui dépendent d’un travail de configuration associé pour configurer le système peuvent ne pas être préparés correctement, car HLK exporte uniquement le travail de test lui-même.

Tous les résultats ne peuvent pas être exportés. La liste suivante décrit les limites sur les tests et les résultats des tests qui sont exportables :

• Les tests doivent avoir été exécutés et terminés avec un status réussi, échoué ou annulé.
• La série de tests doit retourner avec succès les journaux d’infrastructure à partir du système client. Ces fichiers sont nécessaires pour exporter le test.
• Seuls les tests d’ordinateurs uniques peuvent être exportés. Les tests qui nécessitent l’exécution de plusieurs machines ne sont pas exportables.
• Les tests doivent être exécutés à l’aide du client de bureau HLK. Les exécutions de tests sur les systèmes Windows Core ou Proxy Mobile Client ne sont pas exportables.
• Les tests étiquetés comme non exportables en raison de problèmes d’infrastructure connus ou d’autres raisons ne sont pas exportables.

1. Sous l’onglet Résultats de HLK Studio, cliquez avec le bouton droit sur le résultat ayant échoué, puis sélectionnez Exporter l’exécution de test.

2. Une boîte de dialogue d’enregistrement s’affiche. Enregistrez le travail exporté sur un lecteur flash ou un autre emplacement externe afin de pouvoir effectuer le test exporté sur un autre ordinateur. Le même test ne peut pas être exporté vers le même emplacement plusieurs fois. Une boîte de dialogue confirme que l’exportation est terminée.

3. Les fichiers binaires de test et un fichier batch requis pour exécuter le test sur un système autonome sont exportés vers le répertoire spécifié. Le test exporté est enregistré dans un sous-répertoire avec le nom et l’architecture du travail ayant échoué. Les composants d’infrastructure qui doivent être installés pour exécuter le test sont enregistrés dans un sous-répertoire appelé Infrastructure avec le nom de l’architecture à laquelle l’infrastructure est ciblée.

Par exemple, l’enregistrement d’un travail x64 ayant échoué intitulé Définir la cible de rendu à la racine du lecteur E:\ exporte le dossier de travail et le programme d’installation de l’infrastructure à l’aide de la structure de dossiers suivante :

E:.
├───Infrastructure(X64)
└───Set_Render_Target(X64)
    ├───CoreClr
    ├───MinTe
    │   └───CoreClr
    ├───NetFx2.0
    ├───NetFx4.5
    ├───verifysupportfiles
    │   ├───CoreClr
    │   ├───MinTe
    │   │   └───CoreClr
    │   ├───NetFx2.0
    │   └───NetFx4.5
    └───[windir]
        └───system32 

Le package de test exporté contient plusieurs fichiers et sous-dossiers, notamment les suivants :

• readme1st.txt : contient des informations sur l’exécution du test exporté
• run.cmd : fichier batch utilisé pour exécuter le test
• fichiers binaires et autres fichiers requis pour exécuter le test
• setup(architecture).exe : installez l’exécutable utilisé pour installer l’infrastructure

4. Prenez le dossier de test exporté sur la nouvelle machine à des fins de test. Le chemin d’accès ne doit pas contenir d’espaces, car cela entraîne l’échec de certains tests.

5. Exécutez (enregistrer le dossier)\Infrastructure(architecture)\setup(architecture).exe pour installer les composants d’infrastructure avant d’exécuter le test. Le programme d’installation de l’infrastructure affiche une boîte de dialogue qui indique si l’installation des composants a réussi.

6. Dans le fichier batch du dossier (enregistrer le dossier)(nom du travail)(architecture), vous pouvez apporter toutes les modifications nécessaires au fichier batch à exécuter sur votre ordinateur de test. Par exemple, vous pouvez apporter les modifications suivantes :

• Commentaire de lignes qui ne contribuent pas à l’échec du travail
• Modification des valeurs de paramètre pour qu’elles correspondent à la machine sur laquelle le test exporté est exécuté. Par exemple, l’ID de instance du même matériel diffère souvent sur deux systèmes distincts. Il doit donc être mis à jour avant d’exécuter le test exporté.
• Ajout de commandes pour connecter un débogueur

cmd /c TE.exe /inproc /enablewttlogging /appendwttlogging devfund_pcirootportsurpriseremovetest_wlk_certification.dll
/p:"MultiDeviceHardwareIdSdelQueryHardwareID=!MultiDeviceHardwareIdSdelQueryHardwareID!"
/p:"MultiDeviceInstanceIdSdelWDKDeviceID=!MultiDeviceInstanceIdSdelWDKDeviceID!" /p:"DQ=!DQ!"
/p:"TestCycles=!TestCycles!" /p:"IOPeriod=!IOPeriod!" /p:"WDTFREMOTESYSTEM=!WDTFREMOTESYSTEM!"
/p:"Wpa2PskAesSsid=!Wpa2PskAesSsid!"
/p:"DriverVerifierAdditionalDrivers=!DriverVerifierAdditionalDrivers!"
/p:"DriverVerifierExcludedFlags=!DriverVerifierExcludedFlags!"
/p:"DriverVerifierCustomizeConfiguration=!DriverVerifierCustomizeConfiguration!"
/rebootStateFile=rebootstatefile.xml

7. Une fois les modifications terminées, démarrez une invite de commandes avec des privilèges d’administrateur, accédez au répertoire de test et exécutez run.cmd. Chaque tâche du fichier batch est associée à un numéro de tâche qui peut être utilisé comme point de départ lors de l’exécution du fichier batch. Par défaut, l’exécution s’interrompt entre les tâches. Les modes d’exécution suivants sont pris en charge :

• « Exécuter » sans paramètre démarre l’exécution au début du fichier batch, avec une pause entre chaque tâche.
• « Exécuter 5 » démarre le fichier batch et passe à la tâche 5.
• « Exécuter FAST » démarre le fichier batch en mode rapide (aucune pause entre les tâches) au début.
• « Exécuter 5 FAST » démarre le fichier batch en mode rapide (pas de pause entre les tâches) à la tâche 5.
• « RebootResume » démarre le fichier batch à partir du dernier redémarrage de la dernière exécution du script. L’indicateur FAST est également pris en charge.
• « RerunLast » démarre le fichier batch à partir de la commande qui était en cours d’exécution lorsque le fichier batch s’est arrêté pour la dernière fois. Cette commande peut être utilisée pour réexécuter une tâche plusieurs fois en appuyant sur Ctrl+C pour quitter le script pendant la tâche et en exécutant rerunlast.cmd pour réexécuter la commande précédente. L’indicateur FAST est également pris en charge.

8. Une fois que vous avez identifié et résolu le problème à l’origine de l’échec du test, vous pouvez déployer le correctif et vérifier que le travail réussit dans l’environnement HLK.