Source de données WMI

Assurez-vous que vous êtes familiarisé avec l’exécution de base de TAEF et savez comment créer des tests à l’aide de celui-ci, avant de passer à cette section.

Arrière-plan

« WMI » signifie « Windows Management Instrumentation ». Utilisation du Common Information Model (CIM), qui est la norme du secteur pour représenter les systèmes. Windows Management Instrumentation offre un moyen unifié d’accéder aux informations de gestion du système.

Comment cela aide-t-il mes tests ?

À l’aide de la prise en charge des requêtes WMI disponibles en tant que Source de données WMI dans TAEF, vous pouvez ajouter une condition préalable à votre test, ainsi que obtenir des informations sur les ressources sur l’ordinateur de test avant d’exécuter votre test. Voici quelques exemples du type de requête que vous pouvez effectuer à l’aide de WMI :

• Vérifiez si la machine sur laquelle le test s’exécute est un ordinateur portable et exécutez le test uniquement s’il s’agit d’un ordinateur portable.
• Vérifiez si un Service Pack a été installé sur la machine de test et exécutez le test uniquement s’il l’a été.
• Récupérez tous les lecteurs amovibles et disques durs locaux sur la machine de test et exécutez le test pour chacun des lecteurs qui correspondent à la requête.
• Exécutez le test uniquement si la machine de test n’est pas jointe au domaine OU
• Exécutez le test uniquement si la machine de test est jointe à un domaine et récupérez le nom de domaine.

Cela vous aurait donné une idée de l’endroit et de la façon dont vous pouvez tirer parti de WMI DataSource pour vos tests. Examinons comment ajouter cette prise en charge des requêtes WMI lors de la création d’un test TAEF.

Les seules métadonnées spéciales dont vous avez besoin pour effectuer votre test de source de données WMI sont les « DataSource ». La syntaxe DataSource doit se présenter comme suit :

[DataSource("WMI:<WQL query>")]

Ou dans le code natif :

TEST_METHOD_PROPERTY(L"DataSource", L"WMI:<WQL query>")]

Vous devez avoir remarqué que la valeur De Source de données commence par « WMI : », ce qui permet à TAEF de savoir qu’il s’agit en effet de la source de données d’un test qui dépend du résultat de la requête WMI et la distingue également du test piloté par les données. C'est une bonne occasion de mentionner qu'actuellement, TAEF ne prend pas en charge un test qui est à la fois piloté par les données et dépend du résultat de la requête WMI.

La question suivante est naturellement comment écrire des requêtes WQL pour ce que vous recherchez ? La syntaxe de requête WQL est très similaire aux requêtes SQL simplifiées. Il existe quelques exemples très bons de requêtes fournies dans les tâches WMI pour les scripts et les applications. Voici quelques exemples :

SELECT Description, DesktopInteract, ProcessId FROM Win32_Service WHERE Name='Themes'
Exécutez le test sur le service « Thèmes » après avoir trouvé les propriétés Description, DesktopInteract et ProcessId que vous envisagez d’utiliser dans vos tests.

Fonctionnalités SELECT, CapabilityDescriptions FROM Win32_Printe
Exécutez le test pour chaque imprimante connectée à cet ordinateur. Autorisez le test à accéder aux capacités et aux descriptions des capacités pour chaque imprimante.

SELECT Name, User, Location FROM Win32_StartupCommand
Exécutez le test pour chaque processus exécuté au démarrage de Windows. Pour chaque processus, indiquez le nom du processus, où il se trouve (emplacement) et l’utilisateur sous lequel le processus s’exécute.

Vous trouverez d’autres exemples dans la documentation mentionnée ci-dessus, ainsi que dans le fichier .cs et le fichier en-tête dans les exemples ouverts. La syntaxe générale et simplifiée est la suivante :

SELECT <comma separated properties> FROM <WMI Class name> [WHERE <add condition on some properties>]

Dans les exemples que vous venez de voir, Win32_Service, Win32_Printer et Win32_StartupCommand sont toutes les classes WMI. Vous pouvez rechercher les classes WMI dans les classes WMI.

TAEF ne prend pas en charge la récupération des propriétés système.

Derrière la scène, TAEF exécute la requête pour vous et confirme le résultat. Si au moins un objet est retourné à la suite de la requête, le test est exécuté pour chaque objet retourné. Si la requête WQL ne retourne aucun objet, le test est enregistré en tant que bloqué avec ces informations et l’exécution passe au test suivant.

Vérifier ou examiner votre requête avant de rédiger votre test semble être une bonne idée, et c'est un processus très simple :

• À partir de la boîte de dialogue d’exécution ou d’une invite de commandes, appelez «wbemtest.exe»
• Cliquez sur le bouton « Se connecter » dans le coin supérieur droit.
• Vérifiez que votre espace de noms est « root\cimv2 » avant de cliquer à nouveau sur « Se connecter » dans le coin supérieur droit.
• Sous « IWbemServices », cliquez sur « Requête »
• Entrez votre requête dans la zone d’édition qui s’affiche et cliquez sur « Appliquer »

REMARQUE : « IWbemService » dispose de plusieurs autres options qui peuvent vous aider à utiliser votre requête. Par exemple, l’utilisation de « classes énumérées » et la modification du bouton radio sur « récursive » vous aideront à voir toutes les classes WMI du système.

Récupération des propriétés interrogées à l’aide de la requête WMI

À présent, vous avez une idée de la façon d’obtenir une requête WMI pour une méthode de test et comment l’appliquer en tant que métadonnées lors de la création d’un test. Vous savez également comment vérifier que la requête est valide à l’aide de wbemtest.exe. Examinons maintenant comment récupérer les valeurs de propriété que vous recherchiez.

Les principes de base de la récupération de ces informations sont très similaires à la récupération de valeurs pour votre test piloté par les données. Par exemple, dans le code managé, cela se présente comme suit :

1 namespace WEX.Examples
2 {
3     using Microsoft.VisualStudio.TestTools.UnitTesting;
4     using System;
5     using System.Collections;
6     using System.Data;
7     using WEX.Logging.Interop;
8     using WEX.TestExecution;
9
10    [TestClass]
11    public class CSharpWmiDataSourceExample
12    {
13        [TestMethod]
14        [DataSource("WMI:SELECT Description, DesktopInteract, ProcessId FROM Win32_Service WHERE Name='Themes'")]
15        public void ThemesTest()
16        {
17            String description = (String)m_testContext.DataRow["Description"];
18            Boolean desktopInteract = (Boolean)m_testContext.DataRow["DesktopInteract"];
19            UInt32 processId = (UInt32)m_testContext.DataRow["ProcessId"];
20            Log.Comment("Themes service is running on process " + processId.ToString() + " with desktop interact set to "
                           + desktopInteract.ToString());
21            Log.Comment("Themes service description: " + description);
22        }
23        ...
24        public TestContext TestContext
25        {
26            get { return m_testContext; }
27            set { m_testContext = value; }
28        }
29
30        private TestContext m_testContext;
31    }
32}

Les lignes 24-30 de l’exemple ci-dessus sont exactement ce qui est requis pour un test piloté par les données managées. Vous avez défini une propriété TestContext privée et fourni un getter public et un setter sur celui-ci pour que TAEF définisse les valeurs appropriées. À l’aide de la propriété TestContext privée, vous pouvez récupérer la valeur actuelle de l’une des propriétés de l’objet résultant de la requête WMI que vous avez récupérées à partir de TAEF.

Le code natif pour récupérer les propriétés WMI est très similaire. Comme pour les tests natifs pilotés par les données, vous allez utiliser TestData pour obtenir les valeurs de propriété. Par exemple, prenons le test pour obtenir les propriétés de l’imprimante par défaut. Le fichier d’en-tête crée ce test comme suit :

1        // Test on the default printer and its driver name
2        BEGIN_TEST_METHOD(DefaultPrinterTest)
3            TEST_METHOD_PROPERTY(L"DataSource",
              L"WMI:SELECT DriverName, DeviceId, LanguagesSupported FROM Win32_Printer WHERE Default = True")
4        END_TEST_METHOD()

Pour cela, notre code de récupération, dans le fichier cpp se présente comme suit :

1     void WmiExample::DefaultPrinterTest()
2     {
3         String deviceId;
4         VERIFY_SUCCEEDED(TestData::TryGetValue(L"DeviceId", deviceId));
5
6         String driverName;
7         VERIFY_SUCCEEDED(TestData::TryGetValue(L"DriverName", driverName));
8
9         TestDataArray<unsigned int> languagesSupported;
10        VERIFY_SUCCEEDED(TestData::TryGetValue(L"LanguagesSupported", languagesSupported));
11
12        Log::Comment(L"The default driver is " + deviceId + L" which is a " + driverName);
13        size_t count = languagesSupported.GetSize();
14        for (size_t i = 0; i < count; i++)
15        {
16            Log::Comment(String().Format(L"Language supported: %d", languagesSupported[i]));
17        }
18    }

Comptabilité des valeurs de propriété NULL possibles

La partie à garder à l'esprit est que la requête WMI peut ne pas toujours retourner une propriété non nulle. Il peut arriver que la valeur de la propriété WMI retournée soit « null ». Si vous pensez que la propriété que vous recherchez peut être 'null' dans certains scénarios, vérifiez-le avant de la valider ou d’essayer de l’utiliser.

Dans le code de test managé par exemple, TestContext stocke les valeurs Null en tant qu’objet de type DBNull. Vous devez vérifier si l’objet est de type DBNull avant d’essayer de convertir la valeur résultante en type attendu. Examinons les points suivants :

1 namespace WEX.Examples
2 {
3     using Microsoft.VisualStudio.TestTools.UnitTesting;
4     using System;
5     using System.Collections;
6     using System.Data;
7     using WEX.Logging.Interop;
8     using WEX.TestExecution;
9
10    [TestClass]
11    public class CSharpWmiDataSourceExample
12    {
13        [TestMethod]
14        [DataSource("WMI:SELECT MaximumComponentLength, Availability, DeviceId, DriveType, Compressed
                         FROM Win32_LogicalDisk WHERE DriveType=2 Or DriveType=3")]
15        public void LogicalDiskTest()
16        {
17            UInt32 driveType = (UInt32)m_testContext.DataRow["DriveType"];
18            Log.Comment("DeviceId is " + m_testContext.DataRow["DeviceId"]);
19            Log.Comment("DriveType is " + driveType.ToString());
20
21            object nullCheckCompressed = m_testContext.DataRow["Compressed"];
22            Log.Comment("Compressed's type is: " + nullCheckCompressed.GetType().ToString());
23            if (nullCheckCompressed.GetType() == typeof(DBNull))
24            {
25                Log.Comment("Compressed is NULL");
26            }
27            else
28            {
29                Boolean compressed = (Boolean)nullCheckCompressed;
30                Log.Comment("Compressed is " + compressed.ToString());
31            }
32
33            object nullCheckMaxComponentLength = m_testContext.DataRow["MaximumComponentLength"];
34            if (nullCheckMaxComponentLength.GetType() == typeof(DBNull))
35            {
36                Log.Comment("MaxComponentLength is NULL");
37            }
38            else
39            {
40                UInt32 maxComponentLength = (UInt32)nullCheckMaxComponentLength;
41                Log.Comment("MaxComponentLength is " + maxComponentLength.ToString());
42            }
43
44            object nullCheckAvailability = m_testContext.DataRow["Availability"];
45            if (nullCheckAvailability.GetType() == typeof(DBNull))
46            {
47                Log.Comment("Availability is NULL");
48            }
49            else
50            {
51                UInt32 availability = (UInt32)nullCheckAvailability;
52                Log.Comment("Availability is " + availability.ToString());
53            }
54        }
55        ...
56        public TestContext TestContext
57        {
58            get { return m_testContext; }
59            set { m_testContext = value; }
60        }
61
62        private TestContext m_testContext;
63    }
64}

Par exemple, dans le test ci-dessus, « Compressé », « MaximumComponentLength » et « Availability » peuvent être null dans certains scénarios (lorsque la requête retourne des lecteurs amovibles comme des lecteurs de floppy). Vous souhaitez vous assurer que le test se comporte correctement dans de tels cas. À cette fin, récupérez la valeur de la propriété en tant qu’objet et vérifiez si elle est de type « DBNull ». Si c’est le cas, cela signifie que la valeur de propriété retournée était null. Si ce n’est pas le cas, la valeur retournée n’était pas null et donc valide. Par conséquent, cassez-la sur les types appropriés et utilisez-la pour le test.

Il en va de même avec les API de récupération native : la valeur de propriété retournée peut être NULL. Cela signifie que vous devez vérifier si TestData a bien récupéré la valeur sans utiliser un appel de vérification (puisque l'impossibilité de récupérer la valeur pourrait être due au fait que la valeur est null). Par exemple, vous pouvez avoir une méthode de test qui dépend d’une requête WMI :

1        // Test on only local (drive type = 3) or removable (drive type = 2) harddrive
2        BEGIN_TEST_METHOD(LocalOrRemovableHardDriveTest)
3            TEST_METHOD_PROPERTY(L"DataSource", L"WMI:SELECT DeviceId, DriveType, Availability,
                  MaximumComponentLength FROM Win32_LogicalDisk WHERE DriveType=2 OR DriveType=3")
4        END_TEST_METHOD()

Vous pouvez avoir « Disponibilité et « MaximumComponentLength » retournés en tant que valeurs NULL. Par conséquent, écrivez le test pour tenir compte de ce qui suit :

1     void WmiExample::LocalOrRemovableHardDriveTest()
2     {
3         String deviceId;
4         VERIFY_SUCCEEDED(TestData::TryGetValue(L"DeviceId", deviceId));
5         int driveType;
6         VERIFY_SUCCEEDED(TestData::TryGetValue(L"DriveType", driveType));
7
8         unsigned int maxComponentLength;
9         if (SUCCEEDED(TestData::TryGetValue(L"MaximumComponentLength", maxComponentLength)))
10        {
11            Log::Comment(String().Format(L"MaximumComponentLength: %d", maxComponentLength));
12        }
13
14        unsigned int availability;
15        if (SUCCEEDED(TestData::TryGetValue(L"Availability", availability)))
16        {
17            Log::Comment(String().Format(L"Availability: %d", availability));
18        }
19
20        Log::Comment(L"DeviceId: " + deviceId);
21        Log::Comment(String().Format(L"DriveType: %d", driveType));
22    }