Partager via

Outil d’automatisation HLK

Cette rubrique vous guide à travers une série d’étapes basées sur des scripts pour automatiser les tests de pilotes, de systèmes et de périphériques logiciels Windows HLK. Cela vous permet d’exécuter les tests Windows HLK sans utiliser l’interface utilisateur Windows HLK.

Remarque

Il existe un problème connu avec le moteur d’exécution Windows HLK. Lorsqu’un test est interrompu ou si le système a arrêté une machine et que le modèle objet Windows HLK interprète le test comme étant toujours en cours d’exécution, le moteur d’exécution Windows HLK ne détecte pas le problème et peut continuer à surveiller indéfiniment l’exécution du test (ou jusqu’à ce que la valeur de délai d’expiration du projet soit atteinte). La cause racine de ce problème est que le moteur d’exécution Windows HLK obtient le résultat de test depuis ObjectModel Windows HLK. Le moteur estime alors que le test est toujours en cours d’exécution et ne démarre pas le moniteur de l’ordinateur pour attendre la récupération.

Nous vous recommandons d’annuler manuellement le travail et de redémarrer l’ordinateur pour alerter ObjectModel. Il se peut que vous deviez réexécuter le test échoué/annulé à l'aide d’un fichier de collection de tests raccourci ou l’exécuter manuellement à l’aide de Windows HLK Studio. Ce problème sera résolu dans les prochaines versions.

Le processus d’exécution des tests Windows HLK sous forme d'une série de scripts par étapes suit un workflow similaire à celui du guide de prise en main de Windows HLK.

processus de test des outils d’automatisation hlk

Voici les différentes étapes :

Prérequis pour les outils d’automatisation Windows HLK

Avant de commencer les tests, familiarisez-vous avec les concepts d’automatisation Windows HLK et la configuration matérielle requise. Consultez Prérequis pour Windows HLK.

Étape 1 : installer un contrôleur et des programmes de prise en charge sur le serveur de test

L’ordinateur serveur de test doit être doté d'un système d’exploitation et configuré comme décrit dans les prérequis pour Windows HLK. Vous pouvez ensuite installer les programmes suivants :

  1. HLK Windows. Pour obtenir des instructions détaillées sur l’installation de Windows HLK, consultez Étape 1 : installer Controller et Studio sur le serveur de test.

  2. Windows PowerShell 3.0. Consultez KB2506143.

  3. Microsoft Excel (Excel 2007, Excel 2010 ou Excel 2013).

  4. Assemblies PIA (Primary Interop Assembly) d’Office pour Windows XP.

    Important

    Cette version spécifique est requise pour les exports avec Excel.

  5. Téléchargez et copiez office.dll et Microsoft.Office.Interop.Excel.dll vers %WTTSTDIO%. Utilisez ces programmes pour prendre en charge l'étape 8 : analyser les résultats des tests dans Excel.

Pour vérifier que l'installation du logiciel Windows HLK Controller s'est déroulée correctement, recherchez les programmes suivants dans C:\Program Files (x86)\Windows Kits\8.1\Hardware Certification Kit\Studio sur le serveur de test :

  • hlkexecutionengine.exe

  • Microsoft.Windows.Kits.Hardware.Certification.Management.dll

  • Microsoft.Windows.Kits.Hardware.Certification.Project.dll

  • Microsoft.Windows.Kits.Hardware.Certification.Testcollection.dll

Pour vérifier que l'installation du logiciel Windows PowerShell 3.0 s'est déroulée correctement, procédez comme suit :

Vérifier Windows PowerShell 3.0

  1. Pour ouvrir une session Windows PowerShell 3.0 version x86 sur un ordinateur exécutant Windows 7, cliquez sur Démarrer, puis sur Tous les programmes. Cliquez ensuite sur Accessoires, puis sur Windows PowerShell. Cliquez avec le bouton droit sur Windows PowerShell (x86), puis cliquez sur Exécuter en tant qu’administrateur.

    Pour ouvrir une session Windows PowerShell 3.0 version x86 sur un ordinateur exécutant Windows 8 ou Windows Server 2012, suivez les instructions de prise en main de PowerShell.

  2. Tapez Get-Command -Module HardwareCertification pour consulter la liste suivante des applets de commande d’automatisation Windows HLK :

    Export-HwCertTestCollectionToXml

    Import-HwCertTestCollectionFromXml

    Merge-HwCertTestCollectionFromPackage

    Merge-HwCertTestCollectionFromXm

    New-HwCertTestCollectionExcelReport

    New-HwCertTestCollection

    New-HwCertProjectDefinitionFile

  3. Vous pouvez, si vous le souhaitez, configurer la génération des messages de débogage de sorte qu'elle se poursuive automatiquement sans interruption en utilisant la commande suivante :

    $DebugPreference = "Continue";

Étape 2 : installer le client HLK sur le ou les systèmes de test

Pour installer le client HLK sur un système de test, suivez les instructions décrites à l’étape 2 : installer le client sur le ou les systèmes de test.

Remarque

Lorsque vous installez le logiciel client Windows HLK sur un ordinateur, l’ordinateur est automatiquement ajouté au pool par défaut du contrôleur Windows HLK. Le pool par défaut est uniquement pris en charge dans le fichier de définition de projet que vous définissez dans les étapes suivantes.

Pour localiser l’ID matériel ou la classe d’appareil de l’appareil de test à partir du gestionnaire de périphériques de chaque ordinateur de test, consultez Découverte des ID matériels et des classes de configuration d’appareil pour vos appareils.

Étape 3 : créer un fichier de définition de projet de test sur le contrôleur ou le serveur de test

Le fichier de définition de projet (également appelé PDEF) définit la partie du projet de test spécifique à la cible et à la machine. La partie spécifique au test et au résultat est définie dans le fichier de collection de tests. Ensemble, ces fichiers décrivent entièrement la configuration, l’étendue et les résultats du projet.

Pour obtenir une description du format de fichier PDEF et des informations PDEF auxiliaires, consultez les références PDEF.

Voici un exemple de fichier de définition de projet de test appelé C:\Temp\DefinitionFile\device-win8client-x64-auto.xml :

<ProjectDefinitionData Controller="controllername" Database="HLKJobs" Timeout="120" User="user">
    <Project Name="Project-win8client-x64">
        <SchedulerType>AdaptiveOrderOptimized</SchedulerType>
        <MultiDeviceTestGroup>true</MultiDeviceTestGroup>
        <TestStatusToSkip>Pass</TestStatusToSkip>
        <Product Name="Product-win8client-x64" OsPlatform="Windows 8 Client x64" MachinePool="Test">
            <Family Name="Family-win8client-x64">
                <Target TargetType="Device" Id="HWID"/>
            </Family>
            <Machine Name="TEST-CLIENT-A" Role="SUT"/>
            <Machine Name="TEST-CLIENT-B" Role="SUT"/>
        </Product>
        <Packages Path="C:\temp"/>
    </Project>
</ProjectDefinitionData>

Les tableaux suivants présentent les éléments enfants et les attributs, regroupés en fonction du nœud XML dans lequel ils doivent être définis.

Projet

Xml Nom Description

Attribut

Nom

Nom convivial du projet spécifié par l’utilisateur.

Attribut

Contrôleur

Nom du contrôleur.

Attribut

Base de données

Nom fixe de la base de données du contrôleur (par exemple, HLKJobs).

Attribut

Délai d'expiration

Durée pendant laquelle l'outil d'exécution surveille l'activité, exprimée en heures. Si la durée du test dépasse cette valeur, l'outil interrompt tous les tests.

Élément

SchedulerType

Valeur d’énumération facultative utilisée lors de la planification des tests, pour définir le mode de planification du moteur d’exécution. Les valeurs suivantes sont valides :

  • AdaptiveOrderOptimized : les tests sont planifiés exactement dans l’ordre dans lequel ils sont définis dans le fichier xml de la collection de tests.

  • AdaptiveResourceOptimized : les tests sont planifiés dans l’ordre dans lequel ils sont définis dans le fichier xml de la collection de tests, en fonction de la disponibilité des machines pour la cible de test de planification.

Élément

MultiDeviceTestGroup

Indicateur booléen, défini sur TRUE pour activer les tests multi-appareils.

Élément

TestStatusToSkip

Valeur d’énumération facultative utilisée pour définir le mode d'évitement pour le moteur d’exécution lors de la planification des tests. Les valeurs valides sont Pass, Fail ou NoData.

Élément

Produit

Produit de ce projet. Il n'y doit avoir qu’une entrée.

Élément

Package

Chemin d’accès du dossier dans lequel le package .hlkx pour ce projet doit être enregistré.

Produit

Xml Nom Description

Attribut

Nom

Nom convivial du produit que vous testez.

Attribut

OSPlatform

Version de Windows pour le produit. Tous les ordinateurs spécifiés pour ce produit qui exécutent différentes versions de Windows seront ignorés.

Attribut

MachinePool

Pool de machines qui contient les ordinateurs de test spécifiés pour le produit testé. Il s'agit d'un paramètre facultatif. S’il n’est pas spécifié, le pool de machines par défaut est utilisé.

Si un pool de machines est spécifié, il doit faire référence à un pool de machines existant. Ce paramètre fonctionne avec le paramètre Machine. Si le paramètre MachinePool est spécifié, mais qu’aucun paramètre Machine n’est spécifié, le test s’exécute sur tous les ordinateurs du pool de machines spécifié.

Élément

Famille

Ensemble de familles cibles appartenant à ce produit.

Élément

Machine

Un ou plusieurs ordinateurs qui seront utilisés pour les tests. Si ce paramètre est vide, toutes les machines du pool spécifié sont mises en correspondance et utilisées pour les tests.

Famille

Xml Nom Description

Attribut

Nom

Nom convivial de la famille cible des cibles que vous testez dans le projet.

Élément

Cible

Ensemble de cibles appartenant à cette famille. La cible est un périphérique ou un pilote qui peut être sélectionné pour les tests.

Cible

Xml Nom Description

Attribut

TargetType

Type de cible. Les valeurs valides sont Device, System et TargetCollection.

Attribut

Id

Identificateur unique de la Cible. Par exemple, avec le paramètre TargetType défini sur la valeur Device, l’Id est défini sur Id matériel, HWID. Si TargetType est défini sur la valeur Système, la valeur de l’Id est ignorée.

Élément

ManualSelectFeature

Spécifie une fonctionnalité ajoutée manuellement.

Machine

Xml Nom Description

Attribut

Nom

Nom de l'ordinateur de test. Il s'agit d'un paramètre facultatif. Si le nom de l’ordinateur est spécifié :

  • Le nom spécifié doit exister dans le MachinePool désigné.

  • Seuls les ordinateurs spécifiés par le paramètre Name sont utilisés pour tester le produit.

  • Seuls les ordinateurs spécifiés par Name qui exécutent le système d’exploitation désigné par OSPlatform sont utilisés pour tester le produit.

Attribut

Rôle

Si l’ordinateur est un système testé (SUT), cet attribut doit être spécifié en tant que SUT. Si l’ordinateur est un client secondaire utilisé pour les tests multi-ordinateurs, l’attribut doit être spécifié en tant que CLIENT. Si vous ne spécifiez pas cet attribut, cet ordinateur est considéré par défaut comme un système testé (SUT).

Package

Xml Nom Description

Attribut

Chemin d’accès

Dossier des packages de soumission générés lors de l’exécution du projet.

Génération du fichier de définition de projet

Vous pouvez créer le PDEF à l’aide de n’importe quel éditeur xml ou éditeur de texte, ou à l’aide de l’applet de commande New-HwCertProjectDefinitionFile. Si vous utilisez l’applet de commande de l’outil de gestion, vous pouvez générer un PDEF dont les restrictions sont répertoriées ci-dessous. Vous pouvez mettre à jour manuellement ou programmatiquement le PDEF xml généré à l’aide des modifications valides par rapport au schéma de fichier PDEF.

  • Le PDEF généré ne peut avoir qu’un seul élément <Project> et un seul élément <Product> pour le projet.

  • L’attribut <Path> de l’élément <Packages> doit être vide ou défini sur le jeton [PACKAGES].

  • L’attribut <TestCollectionStatusLocation> de l’élément <Project> doit être défini sur une chaîne vide.

  • L’élément <SchedulerType> doit être défini sur AdaptiveResourceOptimized.

  • L’attribut <OsPlatform> de l’élément <Product> doit être défini sur la valeur OSPlatform dérivée de la première machine du pool spécifié pour ce projet.

Les paramètres de l’applet de commande New- HwCertProjectDefinitionFile sont décrits ci-dessous :

  • OutputAutomatedPdef : indicateur booléen qui gère la génération automatique des attributs PDEF xml suivants :

    • <Controller> = "[MACHINE]

    • <TestCollectionReadLocation> = "[FILTERED_TEST_COLLECTION]

    • <Path> = « [PACKAGES] »

  • TestCollectionFilePath : chemin d’accès complet au fichier xml de collection de tests stocké dans l’attribut <TestCollectionReadLocation> de l’élément <Project> dans le fichier PDEF xml. Si cette valeur et OutputAutomatedPdef ne sont pas fournis, le chemin d’accès est défini sur une chaîne vide.

  • ControllerName : nom du contrôleur stocké dans l’attribut <Controller> de l’élément <ProjectDefinitionData> du PDEF xml. Si cette valeur et OutputAutomatedPdef ne sont pas fournis, le nom du contrôleur est défini sur le nom de l’ordinateur actuel.

  • PdefFilePath : nom du fichier PDEF xml de sortie. S’il n’est pas fourni, le chemin d’accès est généré automatiquement selon le format suivant :

    %userprofile%\\desktop\\PDEF_Files\\PDEF_{time_date}\\PDEF_{os_platform_name}_{time_date}.xml

  • ProjectName : nom du projet stocké dans l’attribut <Name> de l’élément <Project> dans le PDEF xml. S’il n’est pas fourni, le nom est généré automatiquement à l’aide de la valeur d’horodatage de la date actuelle.

  • EnableMultiDeviceTest : indicateur booléen qui gère la planification multi-appareils pour le projet, stocké dans l’élément <MultiDeviceTestGroup> dans le PDEF xml. S'il n’est pas spécifié, la planification multi-appareils n’est pas activée.

  • SkipTestStatus : mode d'évitement pour la planification des tests, stocké dans l’élément <TestStatusToSkip> dans le PDEF xml. Les valeurs valides sont Pass, Fail et NoData. S’il n’est pas fourni, le mode d'évitement par défaut est Pass.

  • EnableIsolateTargets : indicateur booléen qui permet la création d’une famille d’appareils individuelle pour chaque cible découverte. S’il n’est pas spécifié, les cibles sont regroupées dans les familles par classes d’appareils.

Les deux paramètres suivants spécifient le pool de machines pour le projet. Vous devez fournir un seul paramètre. Si vous ne fournissez pas de paramètre ou si vous renseignez les deux paramètres, vous obtiendrez une erreur.

  • MachineList : spécifiez les noms d’ordinateurs sous la forme d'une liste délimitée par des virgules. Toutes les machines spécifiées doivent se trouver dans le même pool existant ou dans le pool par défaut.

  • MachinePool : nom du pool de machines existant.

Les six paramètres suivants spécifient le type des cibles du projet. Vous devez fournir un seul paramètre. Si vous ne fournissez pas de paramètre ou si vous en fournissez plusieurs, vous obtiendrez une erreur.

  • RunSystemTest : le projet est destiné à tester l’ensemble du système. Une famille cible disposant d'un seul TargetType = System est générée.

  • TestAllDevices : le projet consiste à tester toutes les cibles découvertes sur les machines spécifiées.

  • HwIdList : spécifiez les ID matériels cibles dans une liste délimitée par des virgules. Chaque ID matériel de la liste peut être spécifié partiellement. Dans ce cas, les ID matériels correspondants sont identifiés en utilisant la valeur partielle comme sous-chaîne par rapport au format d'ID matériel. Les chaînes sont comparées au format ASCII, sans tenir compte de la casse.

  • DriverList : spécifiez les noms des pilotes cibles dans une liste délimitée par des virgules. Les pilotes UMDF (.DLL) ne sont actuellement pas pris en charge. Ces appareils peuvent toujours être détectés à l’aide de leur HWID, dans le cadre du GUID de la classe d’appareil Windows ou de toutes les cibles.

  • ContainerIdList : spécifiez des valeurs d’ID de conteneur dans une liste délimitée par des virgules. Chaque valeur d'ID de conteneur doit être au format GUID.

  • ClassIdList : spécifiez des valeurs d’ID de classe dans une liste délimitée par des virgules. Chaque valeur d'ID de classe doit être au format GUID.

Étape 4 : générer la liste complète des tests en fonction du fichier de définition de projet sur le contrôleur ou le serveur de test

Vous pouvez utiliser l’applet de commande Outil de gestion, New-HwCertTestCollection, pour générer la liste complète des tests requis pour tester les cibles dans le projet. Voici un exemple d’utilisation de l’applet de commande Outil de gestion dans la session Windows PowerShell. (Cette étape est facultative.)

New-HwCertTestCollection -ProjectDefinitionFile C:\Temp\DefinitionFile\device-win8client-x64-auto.xml | Export-HwCertTestCollectionToXml -Output c:\temp\master.xml -TestPassIdentifier "TP001"

Si une cible spécifiée dans le fichier de définition de projet n’est plus disponible, vous recevrez un avertissement et la génération de la collection de tests se poursuit. Dans un tel cas, nous vous recommandons d’obtenir la liste complète des tests :

  1. Créez une copie auxiliaire du fichier de définition de projet contenant uniquement les cibles non disponibles. Étant donné que le temps nécessaire à la génération de la liste de tests dépend du nombre de cibles spécifiées, nous vous recommandons vivement de conserver uniquement les cibles qui n’étaient pas disponibles lors de l’exécution précédente dans la copie auxiliaire.

  2. Corrigez le problème ayant provoqué l’indisponibilité des cibles ; par exemple, certaines machines du pool ne sont pas à l’état READY.

  3. Générez une liste auxiliaire de tests à l’aide de la copie auxiliaire du fichier de définition du projet.

  4. Fusionnez les listes de tests initiale et auxiliaire. Pour ce faire, ajoutez manuellement les éléments <TestCollectionRecord> de la liste auxiliaire à la liste initiale.

Vous trouverez ci-dessous un exemple du fichier xml de sortie généré (c:\temp\master.xml).

<?xml version="1.0" ?> 
<ArrayOfTestCollectionRecord 
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
               mlns:xsd="http://www.w3.org/2001/XMLSchema">
               <TestCollectionRecord 
                               Name="Disk Stress (LOGO)" 
                               Guid="738735f7-245a-4b39-9d81-20339ce31fd4" 
                               TargetName="Disk" 
                               TargetId="DiskId" 
                               TargetType="Device" 
                               HlkBuildVersion="10.000.10020.10020"
                               TestPassIdentifier="TP001"
                               OsPlatform="Windows 10 Client x64">
                               <ContentLevelSet>Reliability</ContentLevelSet>
                               <ContentLevelSet>Certification</ContentLevelSet>
                               <ScheduleOptionSet>Distributable</ScheduleOptionSet>
                               <ScheduleOptionSet>MultipleDEvices</ScheduleOptionSet>
                               <FeatureMapped>Device.Storage.Hd</FeatureMapped>
               </TestCollectionRecord>
</ArrayOfTestCollectionRecord>

Voici la définition des attributs :

  • TargetId : ID matériel de la cible sur l’ordinateur de test

  • TargetName : nom convivial de la cible sur l’ordinateur de test

  • OSPlatform : version de Windows installée sur l'ordinateur de test pour la cible spécifiée

  • Guid : ID tâche détecté pour le test de la cible

  • Name : nom convivial de la tâche détecté pour le test de la cible

  • TestPassIdentifier : valeur de chaîne qui identifie la passe de test

  • TargetType : type de produit testé dans le projet (appareil, système ou filtre)

  • Feature Mapped : fonctionnalité pour laquelle la tâche de test détectée sera effectué sur la cible

  • ContentLevelSet : catégories associées à la tâche détectée pour le test de la cible

  • ScheduleOptionSet : options pour la planification des tests. Les valeurs valides sont :

    • Manual : le test nécessite des actions manuelles au moment de l’exécution

    • Distributable : le test peut être planifié pour plusieurs ordinateurs et s’exécuter sur le premier ordinateur disponible.

    • MultipleDevices : le test peut être exécuté simultanément sur plusieurs appareils sur le même ordinateur

    • MultipleMachines : le test peut être planifié pour s’exécuter sur plusieurs ordinateurs ayant des rôles différents

    • SpecialConfiguration : le test nécessite une configuration spéciale de l'ordinateur pour pouvoir s'exécuter

  • HLKBuildVersion : version de HLK utilisée pour générer la collection de tests

Étape 5 : filtrer la liste complète des tests sur le contrôleur

Vous pouvez utiliser l’applet de commande PowerShell de l’outil de gestion, Import-HwCertTestCollectionFromXml, pour filtrer la liste complète des tests en fonction d'une valeur d’attribut spécifiée. (Cette étape est facultative.) Tous les attributs du fichier xml de sortie généré, tel que listés à l’étape 4, peuvent être utilisés pour filtrer la liste. Les enregistrements de test de collecte de tests de sortie doivent être organisés dans l’ordre requis pour la planification. Dans l’exemple suivant, la catégorie de test Basic est utilisée pour filtrer et trier la liste principale. Saisissez la commande suivante dans une session Windows PowerShell :

Import-HwCertTestCollectionFromXml -Input C:\Temp\master.xml | ? { $_.ContentLevelSet.Contains("Basic") } | sort -Property GUID | Export-HwCertTestCollectionToXml -Output c:\temp\basic.xml

Étape 6 : ajouter la liste filtrée de tests au fichier de définition de projet sur le contrôleur

Utilisez n’importe quel éditeur de texte ou xml pour mettre à jour le PDEF afin d’ajouter l’emplacement du fichier xml d’entrée contenant la collection de tests, ainsi que l’emplacement du fichier de sortie où les résultats des tests seront stockés. Vous trouverez ci-dessous un exemple de PDEF mis à jour, C:\Temp\DefinitionFile\device-win8client-x64-auto-basic.xml.

<ProjectDefinitionData Controller="controllername" Database="HLKJobs" Timeout="120" User="user">
    <Project Name="Project-win8client-x64" TestCollectionReadLocation="C:\temp\basic.xml" TestCollectionStatusLocation="basic_collection_status.xml">
        <MultiDeviceTestGroup>true</MultiDeviceTestGroup>
        <TestStatusToSkip>Pass</TestStatusToSkip>
        <Product Name="Product-win8client-x64" OsPlatform="Windows 8 Client x64" MachinePool="Test">
            <Family Name="Family-win8client-x64">
                <Target TargetType="Device" Id="HWID"/>
            </Family>
            <Machine Name="TEST-CLIENT-A" Role="SUT"/>
            <Machine Name="TEST-CLIENT-B" Role="SUT"/>
        </Product>
        <Packages Path="C:\temp"/>
    </Project>
</ProjectDefinitionData>

Voici la définition des attributs :

  • TestCollectionReadLocation : chemin d’accès au fichier xml contenant la collection de tests filtrés

  • TestCollectionStatusLocation : chemin d’accès au fichier xml de sortie contenant les résultats des tests

Étape 7 : exécuter le projet de test sur le contrôleur

Exécutez ce qui suit à partir d'une ligne de commande :

hlkexecutionengine.exe /Project "C:\Temp\DefinitionFile\device-win10client-x64-auto-basic.xml" /RunCollection

Une fois la commande terminée, les fichiers suivants sont créés :

  • Un fichier nom du fichier de package.hlkx est créé pour chaque exécution de test à l’emplacement spécifié par l’attribut PackagePath dans le PDEF (voir Étape 3 : créer un fichier de définition de projet de test sur le contrôleur ou le serveur de test). Le nom du fichier de package est composé du nom convivial du projet et de la date et l’heure de l’exécution du projet.

  • Les résultats des tests sont présentés dans un fichier XML. Voici un exemple de fichier de résultats (C:\temp\basic_collection_status.xml).

    <?xml version="1.0" ?> 
<ArrayOfTestCollectionRecord 
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
               mlns:xsd="http://www.w3.org/2001/XMLSchema">
               <TestCollectionRecord 
                               Name="Disk Stress (LOGO)" 
                               Guid="738735f7-245a-4b39-9d81-20339ce31fd4" 
                               TargetName="Disk" 
                               TargetId="DiskId" 
                               TargetType="Device" 
                               HlkBuildVersion="10.000.10020.10020"
                               TestPassIdentifier="TP001"
                               OsPlatform="Windows 8 Client x64">
                               <ContentLevelSet>Reliability</ContentLevelSet>
                               <ContentLevelSet>Certification</ContentLevelSet>
                               <ScheduleOptionSet>Distributable</ScheduleOptionSet>
                               <ScheduleOptionSet>MultipleDEvices</ScheduleOptionSet>
                               <FeatureMapped>Device.Storage.Hd</FeatureMapped>
                               <Result 
                                              StartTime="2013-03-14T17:59:45.117-07:00" 
                                              Status="Passed" 
                                              FiltersAppliedCount="0" 
                                              SourcePath="TEST-MACHINE-2A" 
                                              InstanceId="67" 
                                              FeatureDetected="Device.DevFund.CDA Device.DevFund.DriverFramework.AllDrivers Device.DevFund.DriverFramework.KMDF Device.DevFund.INF Device.DevFund.Memory Device.DevFund.Reliability.Interrupts Device.DevFund.Reliability Device.DevFund.ReliabilityDisk Device.DevFund.Security Device.DevFund.Server Device.Storage.Hd.Iscsi Device.Storage.Hd.MultipleAccess.PersistentReservation Device.Storage.Hd.PersistentReservation Device.Storage.Hd.ScsiProtocol Device.Storage.Hd" />
               </TestCollectionRecord>
</ArrayOfTestCollectionRecord>

    Voici la définition des attributs :

    • StartTime : date et heure du démarrage de l’exécution du test

    • Status : indique si le test a réussi ou échoué

    • FiltersAppliedCount : nombre de filtres appliqués au journal des résultats

    • SourcePath : chemin du fichier .hlkx du package généré pour l’exécution du projet

    • InstanceID : ID d’instance de l’appareil testé sur l’ordinateur de test

    • FeatureDetected : fonctionnalités détectées pour la cible testée

Arrêt/redémarrage de l’exécution des tests

Vous pouvez arrêter et redémarrer l'exécution des tests à tout moment. Les tests en cours d’exécution sur les ordinateurs clients continueront à s’exécuter, mais aucun nouveau test n'est programmé. Le nombre de tests en cours d’exécution ne peut pas dépasser le nombre d’ordinateurs disponibles. En effet, la logique de planification ne met pas en file d’attente plus de tests qu'il n'y a de machines disponibles. Bien que les tests en cours d'exécution continuent de s'exécuter (et peuvent renvoyer les résultats des tests au projet Windows HLK), le fichier xml de statut généré par l'outil Windows HLK Execution Engine ne contiendra pas les résultats (succès/échec) des tests qui étaient en cours d'exécution au moment où le processus a été arrêté. Par conséquent, le redémarrage d’un projet peut entraîner l’exécution d’un ensemble de tests deux fois : une fois après la fermeture de l’outil d'automatisation et une fois lors du redémarrage du processus. Étant donné qu'un arrêt anticipé du processus implique généralement que les problèmes liés à l'état de la machine doivent être examinés, ce comportement de réexécution du dernier batch de tests précédemment programmés est prévu et généralement souhaité.

Mécanisme d’arrêt

Vous pouvez arrêter le processus de test en tapant une commande Ctrl-C dans la fenêtre de console. Le moteur d'exécution Windows HLK cessera d'exécuter de nouveaux tests et entamera un bref processus de nettoyage, tel que l'écriture de l'état final dans le fichier xml de résumé et dans le journal du moteur d'exécution.

Mécanisme de redémarrage

Voici une brève vue d’ensemble du processus :

  1. À l’aide de Windows HLK Studio, créez un package .hlkx du projet en cours d’exécution avant l’arrêt du processus de test.

  2. Modifiez le fichier xml de définition de projet du moteur d’exécution Windows HLK pour fournir un nouveau fichier d’état d’entrée et de sortie.

  3. Redémarrez HlkExecutionEngine.exe à l’aide du fichier de définition de projet.

  4. Utilisez Windows HLK Studio pour fusionner les deux projets HLK partiels en un nouveau fichier .hlkx complet.

  5. Exécutez la phase d’analyse sur le fichier .hlkx concurrent, comme indiqué dans la section « Options d’analyse suivantes » de ce document.

Les étapes détaillées de ce processus sont les suivantes :

  1. Pour créer un package .hlkx des résultats obtenus avant l’arrêt de l’exécution du test, démarrez Windows HLK Studio.

  2. Dans Windows HLK Studio, double-cliquez sur le nom du projet qui a été arrêté. Le nom du projet est le même que celui du fichier xml du projet. (Le fichier xml du projet se trouve sous C:\Users\LocalAdminUser\Desktop\PDEF_Files, dans un dossier horodaté.)

  3. Dans Windows HLK Studio, sous l’onglet Package, cliquez sur Créer un package et enregistrez le package.

    Remarque

    L'étape suivante ne doit être effectuée que si la passe de test initiale a été exécutée en faisant démarrer les machines clientes dans le pool par défaut.

  4. Étant donné que les tests ne peuvent s’exécuter que lorsque les machines se trouvent dans un pool autre que celui par défaut, et que le moteur d’exécution Windows HLK n’attend pas que tous les tests en cours d’exécution se terminent avant d’effectuer une opération Ctrl-C, toutes les machines resteront dans leur pool d’ordinateurs existant après l’arrêt du moteur d’exécution Windows HLK. Si le fichier xml du projet d’origine indiquait des machines dans le pool par défaut, vous devez ramener les machines clientes dans le pool par défaut. Pour ce faire, utilisez le menu Configuration situé en haut de l’interface utilisateur de Windows HLK Studio ou l’application Windows HLK Manager.

  5. Une fois le package .hlkx partiel généré, vous devez mettre à jour le fichier de projet du moteur d’exécution HLK Windows pour préparer l’exécution restante. Accédez à C:\Users\LocalAdminUser\Desktop\PDEF_Files, puis recherchez le dossier horodaté approprié à partir de la série de tests. Dans l’ensemble des fichiers xml du dossier, le fichier xml du projet est celui qui n’est pas précédé de « Status_ », « FTC_ » ou « TC_ ». Dans le Bloc-notes ou un autre éditeur de texte, modifiez ce fichier comme suit :

    Dans le fichier xml du projet, deux champs doivent être modifiés : TestCollectionReadLocation et TestCollectionStatusLocation. Pour que l’outil Windows HLK Execution Engine sache où reprendre, la valeur précédente de TestCollectionStatusLocation (le fichier de sortie xml des résultats) doit devenir le fichier d’entrée. Copiez la valeur de TestCollectionStatusLocation dans la valeur TestCollectionReadLocation. Ensuite, définissez une nouvelle valeur TestCollectionStatusLocation. La valeur de TestCollectionStatusLocation peut être n’importe quelle valeur ; par exemple, « C:\Users\LocalAdminUser\Desktop\PDEF_Files\Rerun.xml ».

    Modifiez éventuellement la valeur Name du nœud de projet pour faciliter par la suite la recherche du projet dans HLK Studio. (La valeur actuelle de Name ayant déjà été utilisée, le moteur d’exécution Windows HLK créera un nouveau nom de projet)

  6. Pour redémarrer l’outil, ouvrez une nouvelle fenêtre d’invite de commandes à l’aide des privilèges d’administrateur. Accédez au répertoire Windows HLK Studio (%wttstdio%). Tapez la commande suivante :

    HlkExecutionEngine.exe /Project <project xml file location> /RunCollection

    Cette commande démarre le moteur d’exécution Windows HLK, qui reprend en utilisant l’ensemble des tests qui étaient en cours d’exécution avant l’arrêt de l’outil. L’exécution peut se poursuivre jusqu’à ce que tous les tests soient terminés.

  7. Une fois le deuxième ensemble de tests terminé, vous devez fusionner les deux projets. Pour ce faire, ouvrez Windows HLK Studio. Examinez les projets les plus récents qui ont été créés : généralement, le projet le plus récent est celui de la seconde série d’exécutions (sauf si d'autres utilisateurs créent également des projets pendant ce temps). Si vous avez modifié la valeur Name du projet dans le fichier xml du projet, vous pouvez identifier le projet par son nouveau nom.

  8. Double-cliquez sur le nouveau projet créé à partir de la seconde exécution. Sous l’onglet Package, cliquez sur Fusionner le package. Dans la boîte de dialogue Package à fusionner, cliquez sur Ajouter et accédez au premier package .hlkx partiel créé à partir de la première exécution du moteur d’exécution HLK. Cliquez sur Enregistrer et cliquez sur Créer un package dans la fenêtre principale.

Étape 8 : analyser les résultats des tests dans Excel

Vous pouvez utiliser une commande PowerShell de l’outil de gestion pour générer la liste agrégée des résultats des tests pour le projet. Vous pouvez ensuite analyser les résultats agrégés dans Excel.

Il existe deux façons d’agréger la liste des résultats de test pour un projet.

  1. Utiliser les fichiers de sortie XML. Voici un exemple de la façon dont vous pouvez fusionner les résultats de test XML à partir de la session Windows PowerShell ouverte sur votre contrôleur ou serveur de test :

    dir -s "c:\temp\*.xml" | Merge-HwCertTestCollectionFromXml -ValidationXmlPath "C:\temp\master.xml" | Export-HwCertTestCollectionToXml -Output "C:\Temp\merged_1.xml"  -TestPassIdentifier "TP003"
dir -s "c:\temp\*.xml" | Merge-HwCertTestCollectionFromXml -ValidationXmlPath "C:\temp\master.xml" | Export-HwCertTestCollectionToXml -Output "C:\Temp\merged_2.xml"  -TestPassIdentifier "TP004"

  2. Utiliser les fichiers de sortie .hlkx du projet. Voici un exemple de la façon dont vous pouvez fusionner les fichiers de sortie .hlkx à partir de la session Windows PowerShell ouverte sur votre contrôleur ou votre serveur de test :

    dir -s "c:\temp\*.hlkx" | Merge-HwCertTestCollectionFromPackage -ValidationXmlPath "C:\temp\master.xml" | Export-HwCertTestCollectionToXml -Output "C:\Temp\merged_1.xml" -TestPassIdentifier "TP003"
dir -s "c:\temp\*.hlkx" | Merge-HwCertTestCollectionFromPackage -ValidationXmlPath "C:\temp\master.xml" | Export-HwCertTestCollectionToXml -Output "C:\Temp\merged_2.xml" -TestPassIdentifier "TP004"

Lorsque ValidationXmlPath est spécifié comme paramètre de l’applet de commande Merge-HwCertTestCollectionFromXml ou Merge-HwCertTestCollectionFromPackage, l’algorithme d’agrégation vérifie si tous les tests répertoriés dans la collection de tests principale ont au moins un résultat spécifié pour l'agrégation dans l'un des fichiers de la collection de tests. Cette condition n'est vérifiée que pour les collections de tests qui ont la même valeur TestPassIdentifier que celle spécifiée dans le paramètre d’applet de commande TestPassIdentifier. Si cette condition n’est pas vraie, l’agrégation est annulée et une erreur se produit.Si cette condition n'est pas remplie, l'agrégation est annulée et une erreur se produit.

Pour déterminer quels tests ne sont pas exécutés au cours de l'ensemble de tests, il convient d'inclure la collection de tests principaux dans la liste des fichiers de collection de tests spécifiés pour l’agrégation, mais sans spécifier ValidationXmlPath. Dans ce cas, la collection de tests agrégée de sortie est générée. La collection contient tous les tests répertoriés dans la collection principale, bien que certains d’entre eux n’aient peut-être pas de résultats.

La liste agrégée des résultats des tests (C:\temp\merged.xml) inclut des informations concernant la liste complète des tests. Si l’un des tests requis n’a jamais été exécuté, la liste agrégée des résultats des tests indique qu’un test requis n’a pas été exécuté. Étant donné que tous les résultats des tests sont fusionnés, l’exécution de plusieurs séries de test à l’aide de la même valeur de nom d’attribut TestPassIdentifier peut créer des rapports de résultats incohérents. Nous vous recommandons d’utiliser un nom différent pour chaque ensemble de tests.

Une fois que vous avez créé une liste agrégée de résultats de test, vous pouvez générer une feuille de calcul Excel à l’aide de commandes dans la session Windows PowerShell sur le contrôleur ou le serveur de test. Voici un exemple des commandes qui génèrent le rapport sous la forme d'une feuille de calcul Excel :

New-HwCertTestCollectionExcelReport ("C:\Temp\merged_1.xml", "C:\Temp\merged_2.xml" ) -ExcelPath 'c:\temp\report.xls' -ResultCount 1

Où ResultCount est défini comme le nombre maximal de résultats les plus récents, qui est stocké dans le rapport Excel pour chaque test.

Voici un exemple de sortie obtenue après avoir exécuté les commandes de création d'un rapport sous la forme d'une feuille de calcul Excel.

exemple d’outil d’automatisation hlk des résultats excel

Le rapport Excel obtenu contient les en-têtes suivants :

  • Total Test : nombre total de tests dans cette phase de test.

  • Total Pass : Nombre total de résultats dans cet ensemble de tests

  • Total Pass With Filter : nombre total d'itérations avec un filtre errata appliqué au test.

  • Total Pass Percentage : pourcentage de réussite de tests (Total Pass / Total Test).

  • Total Fail : nombre total d’échecs dans cette phase de test (Total Test - Total Pass).

  • N-1 Improvement : entre cette phase de test et la phase de test précédente (colonne à gauche), nombre de nouvelles itérations ont abouti positivement.

  • N-1 Regression : entre cette phase de test et la phase de test précédente (colonne à gauche), nombre de nouveaux échecs rencontrés.

  • N-1 Not Changed : entre cette phase de test et la phase de test précédente (colonne à gauche), nombre de tests dont le résultat n'a pas changé.

  • N-1 Not Compared : entre cette phase de test et la phase de test précédente (colonne à gauche), combien de tests n’ont pas été comparés parce que le test n’était disponible que dans un seul des ensembles de tests.

Référence PDEF

Informations auxiliaires spécifiées dans le PDEF

Certains projets nécessitent des informations spécifiques aux tests pour la découverte et l’exécution de tests. Ces informations comprennent :

  • Les paramètres de test qui n’ont pas de valeurs par défaut dans la définition des tests. Les éléments <Parameter> facultatifs peuvent être spécifiés à plusieurs emplacements (voir schéma PDEF) :

    • Sous l’élément <Test>. Dans ce cas, la valeur du paramètre est spécifiée pour le test particulier.

    • Sous l’élément <Family> . Dans ce cas, la valeur du paramètre est appliquée à chaque élément Tests pour tous les éléments Targets de Family, sauf si elle est remplacée par la valeur du même paramètre spécifié pour le test

    • Sous l’élément <Product>. Dans ce cas, la valeur du paramètre est appliquée à chaque élément Tests pour tous les éléments Targets de Product, sauf si elle est remplacée par la valeur du même paramètre spécifié pour Family ou pour Test.

  • Les fonctionnalités cibles, qui ne peuvent pas être détectées automatiquement. Les éléments <ManualSelectedFeature> facultatifs peuvent être spécifiés sous l’élément <Target>. Si elles sont spécifiées, ces fonctionnalités, ainsi que les fonctionnalités détectées automatiquement, participent à la découverte de tests et à la génération de collection de tests.

Schéma du fichier de définition de projet

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:attribute name="User" type="xsd:string"/>
<xsd:attribute name="Controller" type="xsd:string"/>
<xsd:attribute name="Timeout" type="xsd:nonNegativeInteger"/>
<xsd:attribute name="Database" type="xsd:string"/>
<xsd:attribute name="Name" type="xsd:string"/>
<xsd:attribute name="Value" type="xsd:string"/>
<xsd:attribute name="TestCollectionReadLocation" type="xsd:string"/>
<xsd:attribute name="TestCollectionStatusLocation" type="xsd:string"/>
<xsd:attribute name="OsPlatform" type="xsd:string"/>
<xsd:attribute name="MachinePool" type="xsd:string"/>
<xsd:attribute name="Path" type="xsd:string"/>
<xsd:attribute name="Role" type="xsd:string"/>
<xsd:attribute name="TargetType">
<xsd:simpleType>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="((S|s)(Y|y)(S|s)(T|t)(E|e)(M|m))|((D|d)(E|e)(V|v)(I|i)(C|c)(E|e))|((T|t)(A|a)(R|r)(G|g)(E|e)(T|t)(C|c)(O|o)(L|l)(L|l)(E|e)(C|c)(T|t)(I|i)(O|o)(N|n))"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="Id" type="xsd:string"/>
<xsd:attribute name="CrashDumpCopyBack">
<xsd:simpleType>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="((D|d)(I|i)(S|s)(A|a)(B|b)(L|l)(E|e)|(M|m)(I|i)(N|n)(I|i))|(K|k)(E|e)(R|r)(N|n)(E|e)(L|l)|((F|f)(U|u)(L|l)(L|l))"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:element name="ProjectDefinitionData">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Project" minOccurs="1"  maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute ref="User" use="optional"/>
<xsd:attribute ref="Controller" use="required"/>
<xsd:attribute ref="Timeout" use="optional" default="120"/>
<xsd:attribute ref="Database" use="optional" default="HLKJobs"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Project">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="MultiDeviceTestGroup" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="TestStatusToSkip" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="Product" minOccurs="1" maxOccurs="unbounded"/>
<xsd:element ref="Packages" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute ref="Name" use="required"/>
<xsd:attribute ref="TestCollectionReadLocation" use="optional"/>
<xsd:attribute ref="TestCollectionStatusLocation" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="MultiDeviceTestGroup" type="xsd:Boolean"/>
<xsd:element name="TestStatusToSkip">
<xsd:simpleType>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="((P|p)(A|a)(S|s)(S|s))|((F|f)(A|a)(I|i)(L|l))|((N|n)(O|o)(D|d)(A|a)(T|t)(A|a))"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="Product">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Family" minOccurs="1" maxOccurs="unbounded"/>
<xsd:element ref="Machine" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="Parameter" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute ref="Name" use="required"/>
<xsd:attribute ref="OsPlatform" use="required"/>
<xsd:attribute ref="CrashDumpCopyBack" use="optional"/>
<xsd:attribute ref="MachinePool" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Family">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Target" minOccurs="1" maxOccurs="unbounded"/>
<xsd:element ref="Parameter" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute ref="Name" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="ManualSelectFeature" type="xsd:string"/>
<xsd:element name="Target">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ManualSelectFeature" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="Test" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute ref="TargetType" use="required"/>
<xsd:attribute ref="Id" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Test">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Parameter" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute ref="Id" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Parameter">
<xsd:complexType>
<xsd:attribute ref="Name" use="required"/>
<xsd:attribute ref="Value" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Machine">
<xsd:complexType>
<xsd:attribute ref="Name" use="required"/>
<xsd:attribute ref="Role" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Packages">
<xsd:complexType>
<xsd:attribute ref="Path" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>

Informations techniques de référence sur les outils HLK