Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Thema werden Sie durch eine Reihe von skriptgestützten Schritten geführt, um Windows HLK-Treiber-, System- und Softwaregerätetests zu automatisieren. Auf diese Weise können Sie die Windows HLK-Tests ausführen, ohne die Windows HLK-Benutzeroberfläche (UI) zu verwenden.
Hinweis
Es gibt ein bekanntes Problem mit dem Windows HLK-Ausführungsmodul. Wenn ein Test angehalten wurde oder das System einen Computer beendet hat und das Windows HLK-Objektmodell den Test als noch ausgeführt interpretiert, erkennt das Windows HLK-Ausführungsmodul die Bedingung nicht und kann die Testausführung auf unbestimmte Zeit überwachen (oder bis der Timeoutwert des Projekts erreicht ist). Die Ursache für dieses Problem besteht darin, dass das Windows HLK-Ausführungsmodul das Testergebnis aus dem Windows HLK-Objektmodell abruft. In diesem Fall ist es daher der Ansicht, dass der Test noch ausgeführt wird und der Computermonitor nicht gestartet wird, um auf die Wiederherstellung zu warten.
Es wird empfohlen, den Auftrag manuell abzubrechen und den Computer neu zu starten, um ObjectModel zu benachrichtigen. Möglicherweise müssen Sie den fehlgeschlagenen/abgebrochenen Test mithilfe einer kurzen Testsammlungsdatei erneut ausführen oder manuell mithilfe von Windows HLK Studio ausführen. Dieses Problem wird in zukünftigen Versionen behoben.
Der Prozess zum Ausführen der Windows HLK-Tests in einer Reihe skriptbasierter Schritte folgt einem Workflow, der dem Guide Erste Schritte mit dem Windows HLK ähnelt.
Die einzelnen Schritte sind wie folgt:
Schritt 1: Installieren von Controller und unterstützenden Programmen auf dem Testserver
Schritt 3: Erstellen einer Testprojektdefinitionsdatei auf dem Controller oder Testserver
Schritt 5: Filtern der vollständigen Liste der Tests auf dem Controller
Schritt 6: Hinzufügen gefilterter Tests zur Projektdefinitionsdatei auf dem Controller
Voraussetzungen für Windows HLK-Automatisierungstools
Bevor Sie mit dem Testen beginnen, stellen Sie sicher, dass Sie mit den Windows HLK-Automatisierungskonzepten und Hardwareanforderungen vertraut sind. Siehe Voraussetzungen für Windows HLK.
Schritt 1: Installieren von Controller und unterstützenden Programmen auf dem Testserver
Der Testservercomputer sollte mit einem Betriebssystem installiert und wie unter Windows HLK-Voraussetzungen beschrieben konfiguriert werden. Anschließend können Sie die folgenden Programme installieren:
Windows HLK. Ausführliche Anweisungen zum Installieren von Windows HLK finden Sie unter Schritt 1: Installieren von Controller und Studio auf dem Testserver.
Windows PowerShell 3.0. Siehe KB2506143.
Microsoft Excel (Excel 2007, Excel 2010 oder Excel 2013).
Primäre Interop-Assemblys für Office für Windows XP.
Wichtig
Diese bestimmte Version ist zum Exportieren von Excel erforderlich.
Laden Sie office.dll und Microsoft.Office.Interop.Excel.dll herunter und kopieren Sie sie nach %WTTSTDIO%. Verwenden Sie diese Programme zur Unterstützung von Schritt 8: Analysieren der Testergebnisse in Excel.
Um die erfolgreiche Installation der Windows HLK Controller-Software zu überprüfen, überprüfen Sie die folgenden Programme in C:\Program Files (x86)\Windows Kits\8.1\Hardware Certification Kit\Studio auf dem Testserver:
hlkexecutionengine.exe
Microsoft.Windows.Kits.Hardware.Certification.Management.dll
Microsoft.Windows.Kits.Hardware.Certification.Project.dll
Microsoft.Windows.Kits.Hardware.Certification.Testcollection.dll
Gehen Sie wie folgt vor, um die erfolgreiche Installation von Windows PowerShell 3.0 zu überprüfen:
Windows PowerShell 3.0 verifizieren
Zum Öffnen einer Windows PowerShell 3.0-Sitzung, x86-Version auf einem Computer mit Windows 7, klicken Sie auf Start, klicken Sie auf Alle Programme, klicken Sie auf Zubehör, klicken Sie auf Windows PowerShell, klicken Sie mit der rechten Maustaste auf Windows PowerShell (x86), und klicken Sie dann auf Als Administrator ausführen.
Um eine Windows PowerShell 3.0-Sitzung der x86-Version zu öffnen, befolgen Sie die Anweisungen unter Erste Schritte mit PowerShell auf einem Computer, auf dem Windows 8 oder Windows Server 2012 ausgeführt wird.
Geben Sie
Get-Command -Module HardwareCertificationein, um folgende Liste der Windows HLK-Automatisierungs-Cmdlets zu sehen:Export-HwCertTestCollectionToXml
Import-HwCertTestCollectionFromXml
Merge-HwCertTestCollectionFromPackage
Merge-HwCertTestCollectionFromXm
New-HwCertTestCollectionExcelReport
New-HwCertTestCollection
New-HwCertProjectDefinitionFile
Sie können optional die Debugnachrichtenausgabe mit automatischer Fortsetzung festlegen, indem Sie den folgenden Befehl verwenden:
$DebugPreference = "Continue";
Schritt 2: Installieren des Clients auf Testsystemen
Um den HLK-Client auf einem Testsystem zu installieren, folgen Sie den Anweisungen in Schritt 2: Installieren des Clients auf Testsystemen.
Hinweis
Wenn Sie Windows HLK-Clientsoftware auf einem Computer installieren, wird der Computer automatisch in den Windows HLK-Controller-Standardpool hinzugefügt. Der Standardpool wird nur in der Projektdefinitionsdatei unterstützt, die Sie in den nächsten Schritten definieren.
Informationen zum Suchen der Hardware-ID oder Geräteklasse des Testgeräts über die Geräte-Manager jedes Testcomputers finden Sie unter Ermitteln von Hardware-IDs und Geräteeinrichtungsklassen für Ihre Geräte.
Schritt 3: Erstellen einer Testprojektdefinitionsdatei auf dem Controller oder Testserver
Project Definition File (auch als PDEF bezeichnet) definiert den Ziel- und computerspezifischen Teil des Testprojekts. Der Test- und ergebnisspezifische Teil wird in der Testsammlungsdatei definiert. Zusammen beschreiben diese Dateien die Projektkonfiguration, den Umfang und die Ergebnisse vollständig.
Eine Beschreibung des PDEF-Dateiformats und unterstützende PDEF-Informationen finden Sie unter PDEF-Referenz.
Eine Beispiel-Project-Definition-Datei zum Testen, genannt C:\Temp\DefinitionFile\device-win8client-x64-auto.xml, wird hier gezeigt:
<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>
In den folgenden Tabellen werden untergeordnete Elemente und die Attribute definiert, gruppiert durch den XML-Knoten, in dem sie festgelegt werden sollen.
Projekt
| Xml | Name | BESCHREIBUNG |
|---|---|---|
attribute |
Name |
Benutzerspezifischer Anzeigename des Projekts. |
attribute |
Controller |
Der Name des Controllers. |
attribute |
Datenbank |
Fester Name der Controllerdatenbank (z. B. HLKJobs). |
attribute |
Timeout |
Die Zeit, über die das Ausführungstool für Aktivitäten überwacht, ausgedrückt in Stunden. Wenn der Testdurchlauf länger als dieser Wert ausgeführt wird, beendet das Tool alle Tests. |
Element |
SchedulerType |
Optionaler Enumerationswert, der für Planungstests verwendet wird, um den Planungsmodus für das Ausführungsmodul zu definieren. Folgende Werte sind gültig:
|
Element |
MultiDeviceTestGroup |
Boolesche Kennzeichnung, auf TRUE festgelegt, um Multigerätetests zu ermöglichen. |
Element |
TestStatusToSkip |
Optionaler Enumerationswert, der verwendet wird, um den Übersprungmodus für das Ausführungsmodul beim Planen von Tests zu definieren. Gültige Werte sind Pass, Fail oder NoData. |
Element |
Produkt |
Das Produkt für dieses Projekt. Es sollte nur ein Eintrag vorhanden sein. |
Element |
Paket |
Der Pfad, zu dem das HLKX-Paket für dieses Projekt gespeichert werden soll. |
Produkt
| Xml | Name | BESCHREIBUNG |
|---|---|---|
attribute |
Name |
Anzeigename des Produkts, das Sie testen. |
attribute |
OSPlatform |
Version von Windows für das Produkt. Alle Computer, die für dieses Produkt angegeben sind, die andere Versionen von Windows ausführen, werden ignoriert. |
attribute |
MachinePool |
Computerpool, der die Testcomputer enthält, die für das Produkt unter Test angegeben sind. Dies ist ein optionaler Parameter. Wenn er nicht angegeben ist, wird der Standardcomputerpool verwendet. Wenn ein Computerpool angegeben ist, muss er auf einen vorhandenen Computerpool verweisen. Dieser Parameter funktioniert zusammen mit dem Parameter Machine. Wenn der Parameter MachinePool angegeben, aber kein Machine-Parameter angegeben wird, wird der Test auf allen Computern im angegebenen Computerpool ausgeführt. |
Element |
Familie |
Eine Reihe von Zielfamilien, die zu diesem Produkt gehören. |
Element |
Machine |
Mindestens ein Computer, der zum Testen verwendet wird. Wenn dieser Parameter leer ist, werden alle Computer im angegebenen Pool abgeglichen und zum Testen verwendet. |
Familie
| Xml | Name | BESCHREIBUNG |
|---|---|---|
attribute |
Name |
Anzeigename der Zielfamilie von Zielen, die Sie im Projekt testen. |
Element |
Ziel |
Eine Reihe von Zielen, die zu dieser Familie gehören. Ziel ist das Gerät oder der Treiber, der zum Testen ausgewählt werden kann. |
Target
| Xml | Name | BESCHREIBUNG |
|---|---|---|
attribute |
TargetType |
Der Typ des Ziels. Gültige Werte sind „Device“, „System“ und „TargetCollection“. |
attribute |
Id |
Eindeutiger Bezeichner des Ziels. Wenn beispielsweise der Parameter TargetType auf den Wert Device festgelegt wird, wird die Id auf Hardware-ID, HWID festgelegt. Wenn TargetType auf den Wert System festgelegt ist, wird der Wert für Id ignoriert. |
Element |
ManualSelectFeature |
Gibt ein manuell hinzugefügtes Feature an. |
Computer
| Xml | Name | BESCHREIBUNG |
|---|---|---|
attribute |
Name |
Name des Testcomputers. Dies ist ein optionaler Parameter. Wenn der Computername angegeben ist:
|
attribute |
Role |
Wenn der Computer ein System unter Test (SUT) ist, sollte dieses Attribut als SUT angegeben werden. Wenn der Computer ein sekundärer Client ist, der für Multicomputertests verwendet wird, sollte das Attribut als CLIENT angegeben werden. Dieses Attribut wird standardmäßig auf diesem Computer als System unter Test (SUT) angegeben. |
Paket
| Xml | Name | BESCHREIBUNG |
|---|---|---|
attribute |
Pfad |
Ordner für die Übermittlungspakete, die bei der Projektausführung generiert werden. |
Generieren der Projektdefinitionsdatei
Sie können die PDEF mithilfe eines beliebigen XML- oder Text-Editors oder mithilfe des Verwaltungstool-Cmdlet New-HwCertProjectDefinitionFile erstellen. Wenn Sie das Verwaltungstool-Cmdlet verwenden, können Sie ein PDEF generieren, das die unten aufgeführten Einschränkungen enthält. Sie können die generierte PDEF-XML manuell oder programmgesteuert aktualisieren, indem Sie alle Änderungen verwenden, die für das PDEF-Dateischema gültig sind.
Das generierte PDEF kann nur über ein einzelnes <Projekt>-Element und ein einzelnes <Produkt>-Element für das Projekt verfügen.
Das <Pfad>-Attribut des <Paket>-Elements muss leer oder auf das [PACKAGES]-Token festgelegt sein.
Das Attribut <TestCollectionStatusLocation> des <Projekt>-Elements muss auf eine leere Zeichenfolge festgelegt werden.
Das <SchedulerType>-Element muss auf AdaptiveResourceOptimized festgelegt werden.
Das Attribut<OsPlatform> des <Product>-Elements muss auf den OSPlatform-Wert festgelegt werden, der vom ersten Computer im angegebenen Pool für dieses Projekt abgeleitet wird.
Parameter des Cmdlets New- HwCertProjectDefinitionFile werden unten beschrieben:
OutputAutomatedPdef – eine boolesche Flag, die die automatische Generierung der folgenden PDEF-XML-Attribute behandelt:
<Controller> = "[MACHINE]
<TestCollectionReadLocation> = "[FILTERED_TEST_COLLECTION]
<Pfad> = "[PACKAGES]"
TestCollectionFilePath – der vollständige Pfad zur XML-Datei der Testsammlung, die im Attribut<TestCollectionReadLocation> des <Projekt>-Elements in der PDEF-XML gespeichert ist. Wenn dieser Wert und OutputAutomatedPdef nicht bereitgestellt werden, wird der Pfad auf eine leere Zeichenfolge festgelegt.
ControllerName – der Name des Controllers, der im Attribut <Controller> des <ProjectDefinitionData>-Elements der PDEF-XML gespeichert ist. Wenn dieser Wert und OutputAutomatedPdef nicht angegeben werden, wird der Controllername auf den Namen des aktuellen Computers festgelegt.
PdefFilePath – der Name der PDEF-Ausgabe-XML-Datei. Falls nicht angegeben, wird der Pfad automatisch mit dem folgenden Format generiert:
%userprofile%\\desktop\\PDEF_Files\\PDEF_{time_date}\\PDEF_{os_platform_name}_{time_date}.xmlProjectName- der Name des Projekts, das im Attribut <Name> des <Project>-Elements in der PDEF-XML gespeichert ist. Falls nicht angegeben, wird der Name automatisch mithilfe des aktuellen Datumszeitstempelwerts generiert.
EnableMultiDeviceTest – eine boolesche Flag, die die Mehrgeräteplanung für das Projekt verarbeitet, gespeichert im <MultiDeviceTestGroup>-Element in der PDEF-XML. Wenn nicht angegeben, ist die Planung für mehrere Geräte nicht aktiviert.
SkipTestStatus – der Übersprungmodus für Planungstests, gespeichert im <TestStatusToSkip>-Element in der PDEF-XML. Gültige Werte sind Pass, Fail und NoData. Falls nicht angegeben, ist der Standard-Übersprungmodus Pass.
EnableIsolateTargets – eine boolesche Flag, die die Erstellung einer einzelnen Gerätefamilie für jedes ermittelte Ziel ermöglicht. Wenn nicht angegeben, werden Ziele nach Geräteklassen in die Familien gruppiert.
Die folgenden beiden Parameter geben den Computerpool für das Projekt an. Sie müssen nur einen Parameter angeben. Wenn Sie keinen Parameter angeben oder beide Parameter angeben, wird ein Fehler angezeigt.
MachineList – Geben Sie Computernamen in einer durch Kommas getrennten Liste an. Alle angegebenen Computer müssen sich im gleichen vorhandenen Pool oder im Standardpool befinden.
MachinePool – der Name des vorhandenen Computerpools.
Die folgenden sechs Parameter geben den Typ der Ziele für das Projekt an. Sie müssen nur einen Parameter angeben. Wenn Sie keinen Parameter angeben oder mehrere Parameter angeben, wird ein Fehler angezeigt.
RunSystemTest – das Projekt dient zum Testen des gesamten Systems. Eine Zielfamilie mit einem einzelnen TargetType = System wird generiert.
TestAllDevices – das Projekt dient zum Testen aller auf den angegebenen Computern ermittelten Ziele.
HwIdList – Geben Sie Zielhardware-IDs in einer durch Kommas getrennten Liste an. Jede Hardware-ID in der Liste kann teilweise angegeben werden. In diesem Fall werden die übereinstimmenden Hardware-IDs mithilfe des teilweise angegebenen Werts als Unterzeichenfolge im Hinblick auf das Hardware-ID-Format identifiziert. Zeichenfolgen werden als ASCII mit Groß-/Kleinschreibung verglichen.
DriverList – Geben Sie Namen von Zieltreibern in einer durch Kommas getrennten Liste an. UMDF-Treiber (.DLL) werden derzeit nicht unterstützt. Diese Geräte können weiterhin mithilfe ihrer HWID, als Teil der Windows Device Class GUID oder aller Ziele ermittelt werden.
ContainerIdList – Geben Sie Container-ID-Werte in einer durch Kommas getrennten Liste an. Jeder Container-ID-Wert muss im GUID-Format enthalten sein.
ClassIdList – Geben Sie Klassen-ID-Werte in einer durch Kommas getrennten Liste an. Jeder Klassen-ID-Wert muss im GUID-Format enthalten sein.
Schritt 4: Generieren der vollständigen Liste der Tests basierend auf der Projektdefinitionsdatei auf dem Controller oder Testserver
Sie können das Verwaltungstool-Cmdlet New-HwCertTestCollection verwenden, um die vollständige Liste der Tests zu generieren, die für Testziele im Projekt erforderlich sind. Ein Beispiel für die Verwendung des Verwaltungstool-Cmdlets in der Windows Powershell-Sitzung finden Sie unten. (Dieser Schritt ist optional.)
New-HwCertTestCollection -ProjectDefinitionFile C:\Temp\DefinitionFile\device-win8client-x64-auto.xml | Export-HwCertTestCollectionToXml -Output c:\temp\master.xml -TestPassIdentifier "TP001"
Wenn ein Ziel, das in der Projektdefinitionsdatei angegeben ist, nicht mehr verfügbar ist, erhalten Sie eine Warnung, und die Testsammlungsgenerierung wird fortgesetzt. In diesem Fall empfehlen wir Folgendes, um die vollständige Liste der Tests zu erhalten:
Erstellen Sie eine Hilfskopie der Projektdefinitionsdatei, die nur diese Ziele enthält, die nicht verfügbar waren. Da die Testlistengenerierungszeit von der Anzahl der angegebenen Ziele abhängt, empfehlen wir dringend, dass Sie nur jene Ziele beibehalten, die in der vorherigen Ausführung in der Hilfskopie nicht verfügbar waren.
Beheben Sie das Problem, das dazu führte, dass die Ziele nicht verfügbar sind; Beispielsweise befinden sich bestimmte Computer im Pool nicht im READY-Zustand.
Generieren Sie eine Hilfsliste mit Tests mithilfe der Hilfskopie der Projektdefinitionsdatei.
Führen Sie die Anfangs- und Hilfslisten von Tests zusammen. Sie können dies manuell ausführen, indem Sie <testCollectionRecord>-Elemente aus der Hilfsliste zur ursprünglichen Liste hinzufügen.
Ein Beispiel für die generierte Xml-Ausgabedatei (c:\temp\master.xml) wird unten angegeben.
<?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>
Dabei sind die Attribute definiert als:
TargetId – Hardware-ID des Ziels auf dem Testcomputer
TargetName – Anzeigename des Ziels auf dem Testcomputer
OSPlatform – Windows-Version auf dem Testcomputer für das angegebene Ziel
Guid – für das Testen des Ziels erkannte Auftrags-ID
Name – Anzeigename des Auftrags, der für das Testen des Ziels erkannt wurde
TestPassIdentifier – Zeichenfolgenwert, identifiziert den Testdurchlauf.
TargetType – Typ des im Projekt getesteten Produkts (Gerät, System oder Filter)
Feature zugeordnet – Feature, das den erkannten Auftrag für das Ziel testet
ContentLevelSet - Kategorien des Auftrags, der für das Testen des Ziels erkannt wurde
ScheduleOptionSet – Optionen für die Testplanung. Gültige Werte sind:
Manuell – Test erfordert manuelle Aktionen zur Ausführungszeit
Verteilungsfähig – Test kann für mehrere Computer geplant und auf dem ersten verfügbaren Computer ausgeführt werden.
MultipleDevices – Test kann auf mehreren Geräten gleichzeitig auf demselben Computer ausgeführt werden
MultipleMachines – Test kann für die Ausführung auf mehreren Computern mit unterschiedlichen Rollen geplant werden
SpecialConfiguration – Test erfordert spezielle Computerkonfiguration, um den Test auszuführen
HLKBuildVersion – Version von HLK, die zum Generieren der Testsammlung verwendet wurde
Schritt 5: Filtern der vollständigen Liste der Tests auf dem Controller
Sie können das Verwaltungstool-PowerShell-Cmdlet Import-HwCertTestCollectionFromXml verwenden, um die vollständige Liste der Tests nach einem angegebenen Attributwert zu filtern. (Dieser Schritt ist optional.) Jedes Attribut der generierten Ausgabe-XML-Datei, wie in Schritt 4 aufgeführt, kann zum Filtern der Liste verwendet werden. Die Testsammlungstestdatensätze der Ausgabe sollten in der erforderlichen Reihenfolge für die Planung angeordnet werden. Im folgenden Beispiel wird die Standardtestkategorie zum Filtern und Sortieren der Masterliste verwendet. Geben Sie in einem Windows PowerShell-Fenster folgende Befehle ein:
Import-HwCertTestCollectionFromXml -Input C:\Temp\master.xml | ? { $_.ContentLevelSet.Contains("Basic") } | sort -Property GUID | Export-HwCertTestCollectionToXml -Output c:\temp\basic.xml
Schritt 6: Hinzufügen gefilterter Tests zur Projektdefinitionsdatei auf dem Controller
Verwenden Sie einen beliebigen Text- oder XML-Editor, um das PDEF zu aktualisieren, um den Speicherort für die XML-Datei der Testsammlung und den Speicherort für die Ausgabetestergebnisse hinzuzufügen. Ein Beispiel für das aktualisierte PDEF, C:\Temp\DefinitionFile\device-win8client-x64-auto-basic.xml, wird unten angegeben.
<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>
Dabei sind die Attribute definiert als:
TestCollectionReadLocation – Pfad zur gefilterten XML-Datei der Testsammlung
TestCollectionStatusLocation – Pfad zur Xml-Ausgabedatei mit Testergebnissen
Schritt 7: Ausführen des Testprojekts auf dem Controller
Führen Sie den folgenden Befehl von einer Befehlszeile aus:
hlkexecutionengine.exe /Project "C:\Temp\DefinitionFile\device-win10client-x64-auto-basic.xml" /RunCollection
Nach Abschluss des Befehls werden die folgenden Dateien erstellt:
Ein Paketdateiname.hlkx wird für jede Testausführung an dem Speicherort erstellt, der im PackagePath-Attribut wie im PDEF definiert ist (siehe Schritt 3: Erstellen einer Testprojektdefinitionsdatei auf dem Controller oder Testserver). Der Name der Paketdatei besteht aus dem Anzeigenamen des Projekts und den Daten und der Uhrzeit der Projektausführung.
Die Ergebnisse werden in einer XML-Datei angezeigt. Eine Beispielergebnisdatei (C:\temp\basic_collection_status.xml) wird unten angegeben.
<?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>Dabei sind die Attribute definiert als:
StartTime – Datum und Zeit, zu der die Testausführung gestartet wurde
Status – Entweder bestanden oder fehlgeschlagen
FiltersAppliedCount – Anzahl der Filter, die auf das Ergebnisprotokoll angewendet wurden
SourcePath – Dateipfad zur hlkx-Paketdatei, die für die Projektausführung generiert wurde
InstanceID – Geräteinstanz-ID des Ziels auf dem Testcomputer
FeatureDetected – Features, die für das getestete Ziel erkannt wurden
Beenden/Neustarten der Testausführung
Sie können Testläufe jederzeit beenden und neu starten. Tests, die derzeit auf Clientcomputern ausgeführt werden, werden weiterhin ausgeführt, aber keine weiteren Tests werden geplant. Die Anzahl der ausgeführten Tests entspricht der Anzahl der verfügbaren Computer, da die Planungslogik nicht mehr Tests in die Warteschlange stellt als verfügbare Computer. Während die Ausführung von Tests weiterhin ausgeführt wird (und Testergebnisse zurück an das Windows HLK-Projekt zurückgeben können), enthält die Status-XML-Datei, die vom Windows HLK-Ausführungsmodul generiert wird, nicht den Pass/Fail-Wert für diese Tests, die zum Zeitpunkt des Beendens des Prozesses ausgeführt wurden. Daher kann das Neustarten eines Projekts zu einer Reihe von Tests führen – einmal nach dem Beenden des Automatisierungstools und einmal, wenn der Prozess neu gestartet wird. Da die frühzeitige Beendigung des Prozesses im Allgemeinen bedeutet, dass Computerzustandsprobleme untersucht werden müssen, ist dieses erneute Ausführungsverhalten des letzten Batches der zuvor geplanten Tests geplant und wird im Allgemeinen gewünscht.
Endmechanismus
Sie können den Testvorgang beenden, indem Sie im Konsolenfenster einen Befehl Strg-C eingeben. Das Windows HLK-Ausführungsmodul beendet die Ausführung neuer Tests und beginnt einen kurzen Bereinigungsprozess, z. B. das Schreiben des endgültigen Status in die Zusammenfassungs-XML-Datei und das Ausführungsmodulprotokoll.
Neustartmechanismus
Eine grundlegende Übersicht über den Prozess ist wie folgt:
Erstellen Sie mithilfe von Windows HLK Studio ein hlkx-Paket des Projekts, das ausgeführt wurde, bevor Sie den Testvorgang beendet haben.
Bearbeiten Sie die XML-Datei für die Projektdefinition des Windows HLK-Ausführungsmoduls, um eine neue Eingabe- und Ausgabestatusdatei zu liefern.
Starten Sie HlkExecutionEngine.exe mithilfe der Projektdefinitionsdatei neu.
Verwenden Sie Windows HLK Studio, um die beiden HLK-Teilprojekte in eine neue, vollständige HLKX-Datei zusammenzuführen.
Führt die Phase „Analysieren“ in der wettbewerbsfähigen HLKX-Datei aus, wie im Abschnitt „Nachfolgende Analyseoptionen“ in diesem Dokument beschrieben.
Im Einzelnen läuft dieser Prozess wie folgt ab:
Um ein HLKX-Paket der Ergebnisse zu erstellen, die vor dem Beenden der Testausführung abgeschlossen wurden, starten Sie Windows HLK Studio.
Doppelklicken Sie in Windows HLK Studio auf den Projektnamen des Projekts, das beendet wurde. Der Projektname entspricht dem Namen in der Projekt-XML-Datei. (Die Projekt-XML-Datei finden Sie unter C:\Users\LocalAdminUser\Desktop\PDEF_Files in einem Ordner mit Zeitstempel.)
Klicken Sie in Windows HLK Studio auf der Registerkarte Paket auf Paket erstellen und speichern Sie das Paket.
Hinweis
Der folgende Schritt muss nur ausgeführt werden, wenn der anfängliche Testlauf ausgeführt wurde, indem die Clientcomputer im Standardpool gestartet werden.
Da Tests nur ausgeführt werden können, wenn Computer sich in einem nicht standardmäßigen Pool befinden, und da das Windows HLK-Ausführungsmodul nicht darauf wartet, dass alle derzeit ausgeführten Tests vor Abschluss eines STRG-C-Vorgangs abgeschlossen werden, bleiben alle Computer im vorhandenen Computerpool, nachdem das Windows HLK-Ausführungsmodul beendet wurde. Wenn die ursprüngliche Xml-Datei des Projekts im Standardpool angegeben ist, müssen Sie die Clientcomputer wieder in den Standardpool verschieben. Dazu können Sie das Menü Konfiguration verwenden, das sich oben auf der Windows HLK Studio-Benutzeroberfläche befindet, oder die Windows HLK Manager-Anwendung.
Nachdem das partielle HLKX-Paket generiert wurde, müssen Sie die Windows HLK-Ausführungsmodul-Projektdatei aktualisieren, um die restliche Ausführung vorzubereiten. Navigieren Sie zu C:\Users\LocalAdminUser\Desktop\PDEF_Files und suchen Sie den richtigen Zeitstempelordner aus der Testausführung. In der Gruppe von XML-Dateien im Ordner ist die Projekt-XML-Datei jene Date, der nicht „Status_“, „FTC_“ oder „TC_“ vorangestellte ist. Bearbeiten Sie diese Datei im Editor oder einem anderen Text-Editor wie folgt:
In der Projekt-XML-Datei müssen zwei Felder bearbeitet werden: TestCollectionReadLocation und TestCollectionStatusLocation. Damit das Windows HLK-Ausführungsmodul weiß, wo es fortsetzen soll, muss der vorherige TestCollectionStatusLocation-Wert (die XML-Ausgabedatei der Ergebnisse) zur Eingabedatei werden. Kopieren Sie den Wert von TestCollectionStatusLocation in den Wert TestCollectionReadLocation. Legen Sie dann einen neuen Wert TestCollectionStatusLocation fest. Der Wert TestCollectionStatusLocation kann ein beliebiger Wert sein; Beispielsweise „C:\Users\LocalAdminUser\Desktop\PDEF_Files\Rerun.xml“.
Ändern Sie optional den Wert Name des Projektknotens, um das Projekt später in HLK Studio einfacher zu finden. (Da der aktuelle Wert Name bereits verwendet wurde, erstellt Windows HLK-Ausführungsmodul einen neuen Projektnamen.)
Um das Tool neu zu starten, öffnen Sie ein neues Eingabeaufforderungsfenster mithilfe von Administratorrechten. Navigieren Sie zum Windows HLK Studio-Verzeichnis (%wttstdio%). Geben Sie folgenden Befehl ein:
HlkExecutionEngine.exe /Project <project xml file location> /RunCollectionDieser Befehl startet das Windows HLK-Ausführungsmodul, das mithilfe der vorherigen Gruppe von Tests fortgesetzt wird, die ausgeführt wurden, bevor das Tool beendet wurde. Die Ausführung kann fortgesetzt werden, bis alle Tests abgeschlossen sind.
Nachdem der zweite Testsatz abgeschlossen ist, müssen Sie die beiden Projekte zusammenführen. Öffnen Sie dazu Windows HLK Studio. Sehen Sie sich die neuesten Projekte an, die erstellt wurden – in der Regel ist das neueste Projekt jenes aus der zweiten Ausführung (es sei denn, andere Benutzer erstellen auch Projekte während dieser Zeit). Oder wenn Sie den Wert Name des Projekts in der Projekt-XML-Datei geändert haben, können Sie das Projekt durch den neuen Namen identifizieren.
Doppelklicken Sie auf das neue Projekt, das aus der zweiten Ausführung erstellt wurde. Klicken Sie auf der Registerkarte Paket auf Paket zusammenführen. Klicken Sie im Dialogfeld Zusammenzuführendes Paket auf Hinzufügen und navigieren Sie zum ersten HLKX-Teilpaket, das aus der ersten Ausführung des HLK-Ausführungsmoduls erstellt wurde. Klicken Sie auf Speichern und klicken Sie im Hauptfenster auf Paket erstellen.
Schritt 8: Analysieren der Testergebnisse in Excel
Sie können einen Management Tool PowerShell-Befehl verwenden, um die aggregierte Liste der Testergebnisse für das Projekt zu generieren. Anschließend können Sie die aggregierten Ergebnisse in Excel analysieren.
Es gibt zwei Möglichkeiten, die Liste der Testergebnisse für ein Projekt zusammenzufassen.
Verwenden der XML-basierten Ausgabedateien. Hier wird ein Beispiel dafür gezeigt, wie Sie XML-basierte Testergebnisse aus der Windows PowerShell-Sitzung zusammenführen können, die auf Ihrem Controller oder Testserver geöffnet ist:
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"Verwenden der .hlkx-Ausgabedateien des Projekts. Hier wird ein Beispiel dafür gezeigt, wie Sie .hlkx-Ausgabedateien aus der Windows PowerShell-Sitzung zusammenführen können, die auf Ihrem Controller oder Testserver geöffnet ist:
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"
Wenn ValidationXmlPath als Parameter für das Cmdlet Merge-HwCertTestCollectionFromXml oder Merge-HwCertTestCollectionFromPackage angegeben wird, überprüft der Aggregationsalgorithmus, ob alle in der Mastertestsammlung aufgeführten Tests mindestens ein Ergebnis haben, das für die Aggregation in einer der Testsammlungsdateien angegeben ist. Diese Bedingung wird nur für die Testsammlungen überprüft, die den gleichen TestPassIdentifier-Wert haben wie im Cmdlet-Parameter TestPassIdentifier angegeben. Wenn diese Bedingung nicht wahr ist, wird die Aggregation abgebrochen und ein Fehler tritt auf.
Um zu ermitteln, welche Tests für den Testlauf nicht ausgeführt werden, fügen Sie die Mastertestsammlung in die Liste der Testsammlungsdateien ein, die für die Aggregation angegeben sind, geben Sie jedoch nicht die ValidationXmlPath an. In diesem Fall wird die aggregierte Testsammlung generiert. Die Auflistung enthält alle Tests, die in der Mastersammlung aufgeführt sind, obwohl einige von ihnen möglicherweise keine Ergebnisse haben.
Die aggregierte Liste der Testergebnisse (C:\temp\merged.xml) enthält Informationen für die vollständige Liste der Tests. Wurde ein erforderlicher Test nicht ausgeführt, zeigt die aggregierte Liste der Testergebnisse, dass einer der erforderlichen Tests nie ausgeführt wurde. Da alle Testergebnisse zusammengeführt werden, kann das Ausführen mehrerer Testläufe mit demselben TestPassIdentifier-Attributnamenswert zu inkonsistenten Ergebnisberichten führen. Es wird empfohlen, einen anderen Namen für jeden Testlauf zu verwenden.
Nachdem Sie eine aggregierte Liste von Testergebnissen erstellt haben, können Sie mithilfe von Befehlen in der Windows PowerShell-Sitzung auf dem Controller oder Testserver eine Excel-Tabelle generieren. Ein Beispiel für die Befehle, die den Excel-Tabellenbericht erstellen, ist hier angegeben:
New-HwCertTestCollectionExcelReport ("C:\Temp\merged_1.xml", "C:\Temp\merged_2.xml" ) -ExcelPath 'c:\temp\report.xls' -ResultCount 1
Dabei ist ResultCount definiert als die maximale Anzahl der neuesten Ergebnisse, die im Excel-Bericht für jeden Test gespeichert werden.
Ein Beispiel für die Ausgabe, die nach dem Ausführen der Befehle zum Erstellen eines Excel-Tabellenberichts erstellt wurde, ist unten dargestellt.
Der resultierende Excel-Bericht enthält die folgenden Überschriften:
Gesamttest – Die Gesamtzahl der Tests in diesem Testdurchlauf.
Total Pass – Die Gesamtzahl der Ergebnisse in diesem Testdurchlauf
Gesamtbestanden mit Filter – Die Gesamtzahl der Durchgänge mit einem auf den Test angewendeten Errata-Filter.
Total Pass Percentage – Prozentsatz der bestandenen Tests (Total Pass / Total Test).
Total Fail – Die Gesamtzahl der Fehler in diesem Testdurchlauf (Total Test – Total Pass).
N-1-Verbesserung - Zwischen diesem Testdurchlauf und dem vorherigen Testdurchlauf (Spalte links), wie viele neue Durchgänge erzielt wurden.
N-1 Regression – Wie viele neue Fehler wurden zwischen diesem Testdurchlauf und dem vorherigen Testdurchlauf (Spalte links) festgestellt.
N-1 Nicht geändert – Zwischen diesem Testdurchlauf und dem vorherigen Testdurchlauf (Spalte links), bei wie vielen Tests gab es keine Änderung des Ergebnisergebnisses.
N-1 nicht verglichen – Zwischen diesem Testdurchlauf und dem vorherigen Testdurchlauf (Spalte links), wie viele Tests nicht verglichen wurden, weil der Test nur in einem der Testdurchläufe verfügbar war.
PDEF-Referenz
Hilfsinformationen, die im PDEF angegeben sind
Einige Projekte erfordern testspezifische Informationen zum Ermitteln und Ausführen von Tests. Folgende Informationen werden erfasst:
Testparameter, die keine Standardwerte in der Testdefinition haben. Optionale <Parameter/>-Elemente können an mehreren Stellen angegeben werden (siehe PDEF-Schema):
Unter dem <Test>-Element. In diesem Fall wird der Parameterwert für den bestimmten Test angegeben.
Unter dem <Familie>-Element. In diesem Fall wird der Parameterwert für alle Tests für alle Ziele in der Familie angewendet, es sei denn, es wird vom Wert desselben Parameters überschrieben, der für den Test angegeben ist
Unter dem <Product>-Element. In diesem Fall wird der Parameterwert für alle Tests für alle Ziele im Produkt angewendet, es sei denn, es wird vom Wert desselben Parameters überschrieben, der für die Familie oder den Test angegeben ist
Zielfeatures, die nicht automatisch erkannt werden können. Optionale <ManualSelectedFeature>-Elemente können unter dem <Target>-Element angegeben werden. Wenn angegeben, beteiligen sich diese Features zusammen mit automatisch erkannten Features an der Testermittlungs- und Testsammlungsgenerierung.
Schema der Projektdefinitionsdatei
<?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>