Partager via

Prise en charge des appareils

Si votre automatisation de test s’appuie sur la présence d’appareils ou de ressources de test, reportez-vous à l’exemple, TestResourceExample et suivez la procédure d’utilisation de la prise en charge des appareils ou de la prise en charge des ressources de test disponibles dans TAEF. Assurez-vous que vous êtes familiarisé avec la création de tests de base à l’aide de TAEF et de l’exécution de base de TAEF avant de continuer.

Rédaction pour la compatibilité des appareils - Fichier source

Te.Common.lib est requis en plus d’autres bibliothèques nécessaires pour créer un test dans TAEF.

Création pour la prise en charge des appareils - Définition de ressource de test

Les utilisateurs sont responsables de la création de leur propre définition de ressource de test (appareil). Pour ce faire, vous devez implémenter ITestResource. ITestResource est défini dans le fichier d’en-tête publié ITestResource.h et se présente comme suit :

namespace WEX { namespace TestExecution
{
    namespace TestResourceProperty
    {
        // the following are reserved and must have properties for any TestResource definition
        static const wchar_t c_szName[] = L"Name";
        static const wchar_t c_szId[] = L"Id";
        static const wchar_t c_szGuid[] = L"GUID";
        static const wchar_t c_szType[] = L"Type";
    }

    struct __declspec(novtable) __declspec(uuid("79098e4c-b78d-434b-854d-2b59f5c4acc5")) ITestResource : public IUnknown
    {
    public:
        virtual HRESULT STDMETHODCALLTYPE GetGuid(GUID* pGuid) = 0;
        virtual HRESULT STDMETHODCALLTYPE SetGuid(GUID guid) = 0;
        virtual HRESULT STDMETHODCALLTYPE GetValue(BSTR name, BSTR* pValue) = 0;
        virtual HRESULT STDMETHODCALLTYPE SetValue(BSTR name, BSTR value) = 0;
    };
} /*namespace TestExecution*/ } /*namespace WEX*/

Dans notre exemple, la classe MyTestResource implémente l’interface COM ITestResource. Dans ITestResource.h, vous trouverez également une liste de propriétés « must-have » définies. Il doit être possible d’obtenir le GUID de la ressource de test à l’aide de GetGuid(..) et du nom, de l’ID et du type de la ressource à l’aide de GetValue(...). Si l’une de ces informations est manquante dans un TestResource, TAEF considère qu’elle n’est pas valide et ne conserve pas ses informations. (Consultez la section « Génération de la liste des ressources » qui suit).

Création pour la prise en charge des appareils - Spécification des métadonnées dépendantes des ressources

Pour spécifier que le module de test possède des méthodes de test dépendantes des ressources de test, une propriété de métadonnées au niveau du module « TestResourceDependent » doit être définie sur « true ». La propriété est héritée par toutes les classes du module de test et par toutes les méthodes de test de ces classes. Si l’une des méthodes de test du module n’est pas dépendante de la ressource de test, elle doit définir explicitement la valeur de métadonnées sur false. Toutes les autres méthodes de test qui dépendent de la ressource de test doivent fournir une requête de sélection à l’aide de l'« ID » et/ou du « Type » de la ressource de test.

Voici un exemple rapide de « ResourceSelection » pour notre exemple de liste de ressources et ce que chacun d’eux implique :

  • « @Id='HD*' » : correspond à chaque ressource avec un ID commençant par « HD »
  • « @Type='PCI' » : correspond à chaque ressource de type « PCI »
  • « @Id='PCI*' OR @Id='HD*' » : correspond à chaque ressource commençant par « PCI » ou en commençant par « HD »
  • « @Type='PCI' et @id='*37' » : correspond à chaque ressource de type « PCI » avec un nom se terminant par « 37 »

Dans notre exemple de code, voici ce qui suit :

BEGIN_MODULE()
    MODULE_PROPERTY(L"TestResourceDependent", L"true")
END_MODULE()

    class TestResourceExample
    {
        TEST_CLASS(TestResourceExample);

        BEGIN_TEST_METHOD(NoTestResourceTest)
            TEST_METHOD_PROPERTY(L"TestResourceDependent", L"false")
        END_TEST_METHOD()

        BEGIN_TEST_METHOD(OneHDAudioTest)
            TEST_METHOD_PROPERTY(L"ResourceSelection", L"@Id='HD*'")
        END_TEST_METHOD()

        ...

        BEGIN_TEST_METHOD(HDorPCITest)
            TEST_METHOD_PROPERTY(L"ResourceSelection", L"@Id='PCI*' OR @Id='HD*'")
        END_TEST_METHOD()
        ...
    };

Dans l’exemple ci-dessus, vous verrez que le module est marqué comme « TestResourceDependent ». NoTestResourceTest est explicitement marqué comme ne dépendant d’aucune ressource de test en définissant les métadonnées « TestRssourceDependent » sur « false ». Toutes les autres méthodes de test spécifient des critères de sélection pour les ressources de test qu'elles souhaitent exécuter.

La grammaire des critères de sélection est très similaire à la grammaire de requête de sélection de ligne de commande disponible pour TAEF. Toutefois, dans le cas de la sélection de ressources, elle est limitée à l’utilisation des types et id de ressource. Étant donné que l’ID de ressource est une chaîne, il doit être placé entre guillemets simples. Vous pouvez utiliser les caractères génériques « * » ou « ? » dans la spécification de la valeur Id. Dans notre exemple ci-dessus, dans OneHDAudioTest, la sélection de ressources spécifie une correspondance avec n’importe quelle ressource à laquelle l’ID commence par « HD ». De même, dans le cas de HDorPCITest, la sélection de ressources correspond à n’importe quelle ressource où l’ID commence par « HD » ou commence par « PCI ». Il est important de noter que la sélection de ressources ne respecte pas la casse, c’est-à-dire « pci », « Pci » et « PCI » seront traitées de la même façon.

En fonction de la sélection de ressources, TAEF appelle à nouveau la méthode de test, ainsi que les méthodes de configuration et de nettoyage au niveau du test (si elles sont spécifiées) une fois pour chaque ressource de test qui correspond à la sélection. Les sections suivantes examinent les détails sur la façon de spécifier la liste des ressources et de les fournir à TAEF et comment la méthode de test peut récupérer les ressources dans la section suivante.

Élaboration pour la compatibilité des appareils - Établissement de la liste des ressources

Dès que TAEF rencontre un module de test TestResourceDependent, il recherche et appelle la méthode exportée par dll BuildResourceList. C'est lors de l'implémentation de BuildResourceList que les utilisateurs peuvent créer de nouvelles ressources de test et les ajouter à l'interface, qui est transmise comme paramètre à BuildResourceList. Examinons l’implémentation de cette méthode dans notre exemple :

using namespace WEX::TestExecution;
HRESULT __cdecl BuildResourceList(ResourceList& resourceList)
{
    Log::Comment(L"In BuildResourceList");

    GUID myGuid;
    VERIFY_SUCCEEDED(::CoCreateGuid(&myGuid));

    CComPtr<ITestResource> spTestResource;
    spTestResource.Attach(new MyTestResource(L"HDAudio1", L"HDAudio-deviceid-1", myGuid, L"HD"));
    resourceList.Add(spTestResource);

    spTestResource.Attach(new MyTestResource(L"HDAudio2", L"HDAudio-deviceid-2", myGuid, L"HD"));
    resourceList.Add(spTestResource);

    spTestResource.Attach(new MyTestResource(L"PCI1", L"PCI-deviceid-1", myGuid, L"PCI"));
    resourceList.Add(spTestResource);

    spTestResource.Attach(new MyTestResource(L"PCI2", L"PCI-deviceid-2", myGuid, L"PCI"));
    resourceList.Add(spTestResource);

    spTestResource.Attach(new MyTestResource(L"PCI3", L"PCI-deviceid-3", myGuid, L"PCI"));
    resourceList.Add(spTestResource);

    return S_OK;
}

BuildResourceList accepte une référence à WEX ::TestExecution ::ResourceList comme paramètre. ResourceList est défini dans le fichier d’en-tête publié ResourceList.h. À l’aide de la méthode Add(...) sur ResourceList, les utilisateurs peuvent ajouter toutes les ressources de test découvertes ou créées pour que TAEF gère et fonctionne avec. L’exemple ci-dessus a ajouté 5 ressources de test.

La méthode Add échoue si la ressource de test à ajouter ne retourne pas « Name », « Id », « Type » ou GUID pour la ressource.

ResourceList est conservé pendant toute la durée de vie du module de test, c’est-à-dire jusqu’à ce que toutes les méthodes de test et méthodes de nettoyage soient exécutées. Si BuildResourceList retourne une valeur HRESULT FAILED, toutes les méthodes de test dépendantes des ressources du module de test sont enregistrées comme bloquées sans exécution. Toutes les ressources non testées sont exécutées indépendamment.

BuildResourceList est appelé avant toute autre méthode dans le module de test. Une fois la liste de ressources générée (dans BuildResourceList), les métadonnées « ResourceSelection » sont utilisées pour faire correspondre les ressources disponibles dans la liste des ressources. Si une correspondance est trouvée, toutes les méthodes d’installation (module, classe, ordre de test) sont appelées suivie de la méthode de test elle-même. La méthode de nettoyage au niveau du test est appelée après chaque appel de test.

En arrière-plan, TAEF conserve le ResourceList sur lequel la sélection de ressources est appliquée. Par exemple, pour la méthode de test OneHDAudioTest, les ressources de test avec les ID « HDAudio-deviceid-1 » et « HDAudio-deviceid-2 » correspondent à « HD* » et pour chacune d’elles, la méthode de test sera réinvocée par TAEF (une fois pour chacun). Il y aura également un index implicite associé à chaque appel du test. Vous verrez donc le <qualificateur d’espace de noms> OneHDAudioTest#0 et le <qualificateur d’espace de noms> OneHDAudioTest#1 en tant que deux appels.

Création pour la prise en charge des appareils - Récupération de l’appareil dans une méthode de test

Les sections précédentes ont examiné comment ajouter les métadonnées nécessaires au niveau du module, de la classe et de la méthode de test. Ils ont également examiné comment définir des ressources de test personnalisées et comment les ajouter à ResourceList dans l’implémentation de BuildResourceList. La partie suivante consiste à récupérer les ressources dans la méthode de test. Examinons l’une des méthodes de test simples de notre exemple :

1   void TestResourceExample::OneHDAudioTest()
2   {
3       Log::Comment(L"In HD audio test");
4       size_t count = Resources::Count();
5       size_t index = 0;
6       VERIFY_ARE_EQUAL(count, (index + 1));
7
8       CComPtr<ITestResource> spTestResource;
9       VERIFY_SUCCEEDED(Resources::Item(index, &spTestResource));
10
11      // Get Resource Id
12      CComBSTR value;
13      VERIFY_SUCCEEDED(spTestResource->GetValue(CComBSTR(TestResourceProperty::c_szId), &value));
14      Log::Comment(L"Resource Id is " + String(value));
15  }

Dans OneHDAudioTest, la sélection de ressources sélectionne une ressource de test à la fois où l’ID de ressource commence par « HD ». Les ressources de classe statique définies dans ResourceList.h fournissent les API permettant de récupérer le nombre ainsi que la ressource réelle disponible pendant tout appel donné du test. Dans ce cas, comme vous pouvez le voir dans les lignes 4, 9 et 13 de l’exemple ci-dessus, Resources ::Count() donne le nombre de ressources de test disponibles pendant l’appel actuel de la méthode de test. Dans cette méthode de test, il doit s’agir de 1. Vous pouvez vérifier cette valeur à l’aide des macros VERIFY disponibles dans TAEF (Verify.h). Comme vous le savez, si l’un des appels de vérification échoue dans un test TAEF basé sur une exception, l’exécution se termine à ce stade et la méthode de test est marquée comme ayant échoué.

Ensuite, à l’aide de Resources ::Item(...) API et passage d’un index auquel récupérer la ressource (dans ce cas, car une seule ressource de test sera disponible pendant un appel, l’index sera toujours 0), vous pouvez récupérer la ressource de test. La méthode de test peut utiliser la ressource de test récupérée selon ses besoins pour les tests.

Le même principe de base est suivi dans toutes les méthodes de test. Examinez d’autres méthodes de test dans l’exemple pour mieux comprendre.

Exécution d’un module de test dépendant de la ressource de test

Avec les tests dépendants des ressources de test créés et générés, vous pouvez désormais l’exécuter à l’aide de TAEF. Le point clé à noter est que les tests TestResourceDependent ne peuvent être exécutés qu’enproc. Cela signifie que même si vous ne spécifiez pas explicitement le commutateur « /inproc », il est ajouté dès que TAEF découvre le module de test dépendant de la ressource de test. Comme vous le savez peut-être, les tests d’un seul module de test peuvent être exécutés dans une exécution TAEF donnée lorsque le commutateur « /inproc » est présent. Cela signifie que vous ne pouvez pas spécifier plusieurs modules de test au niveau de la ligne de commande si votre module de test dépend de la ressource.

Pour exécuter tous les tests dans notre module de test, vous pouvez simplement exécuter :

te Examples\Cpp.TestResource.Example.dll

Un moyen utile d’obtenir simplement une liste de tous les appels de méthode de test et les combinaisons de données et de métadonnées sans réellement exécuter les méthodes de test, consiste à utiliser le commutateur /listproperties au niveau de la ligne de commande. Examinons le résultat.

te Examples\Cpp.TestResource.Example.dll /listproperties

Test Authoring and Execution Framework v2.9.3k for x86
In BuildResourceList
Verify: SUCCEEDED(::CoCreateGuid(&myGuid))

        f:\toolsdev.binaries.x86chk\WexTest\CuE\TestExecution\Examples\Cpp.TestResource.Example.dll
                Property[TestResourceDependent] = true

            WEX::TestExecution::Examples::TestResourceExample
                WEX::TestExecution::Examples::TestResourceExample::NoTestResourceTest
                        Property[TestResourceDependent] = false

                WEX::TestExecution::Examples::TestResourceExample::OneHDAudioTest#0
                        Property[ResourceSelection] = @Id='HD*' 
                
                            Resource#0
                                Id = HDAudio-deviceid-1
                                Name = HDAudio1
                                Type = HD

                WEX::TestExecution::Examples::TestResourceExample::OneHDAudioTest#1
                        Property[ResourceSelection] = @Id='HD*'
                        
                            Resource#0
                                Id = HDAudio-deviceid-2
                                Name = HDAudio2
                                Type = HD

                WEX::TestExecution::Examples::TestResourceExample::OnePCIDeviceTest#0
                        Property[ResourceSelection] = @Id='PCI*'
                        
                            Resource#0
                                Id = PCI-deviceid-1
                                Name = PCI1
                                Type = PCI

                WEX::TestExecution::Examples::TestResourceExample::OnePCIDeviceTest#1
                        Property[ResourceSelection] = @Id='PCI*'
                        
                            Resource#0
                                Id = PCI-deviceid-2
                                Name = PCI2
                                Type = PCI

                WEX::TestExecution::Examples::TestResourceExample::OnePCIDeviceTest#2
                         Property[ResourceSelection] = @Id='PCI*'
                        
                            Resource#0
                                Id = PCI-deviceid-3
                                Name = PCI3
                                Type = PCI

                WEX::TestExecution::Examples::TestResourceExample::HDorPCITest#0
                        Property[ResourceSelection] = @Id='PCI*' OR @Id='HD*'
                        
                            Resource#0
                                Id = HDAudio-deviceid-1
                                Name = HDAudio1
                                Type = HD

                WEX::TestExecution::Examples::TestResourceExample::HDorPCITest#1
                         Property[ResourceSelection] = @Id='PCI*' OR @Id='HD*'
                        
                            Resource#0
                                Id = HDAudio-deviceid-2
                                Name = HDAudio2
                                Type = HD

                WEX::TestExecution::Examples::TestResourceExample::HDorPCITest#2
                         Property[ResourceSelection] = @Id='PCI*' OR @Id='HD*'
                        
                            Resource#0
                                Id = PCI-deviceid-1
                                Name = PCI1
                                Type = PCI

                WEX::TestExecution::Examples::TestResourceExample::HDorPCITest#3
                         Property[ResourceSelection] = @Id='PCI*' OR @Id='HD*'
                        
                            Resource#0
                                Id = PCI-deviceid-2
                                Name = PCI2
                                Type = PCI

                WEX::TestExecution::Examples::TestResourceExample::HDorPCITest#4
                         Property[ResourceSelection] = @Id='PCI*' OR @Id='HD*'
                        
                            Resource#0
                                Id = PCI-deviceid-3
                                Name = PCI3
                                Type = PCI

                WEX::TestExecution::Examples::TestResourceExample::PCI1AudioTest #0
                         Property[ResourceSelection] = @Id='PCI*' AND @Id='*1'
                        
                            Resource#0
                                Id = PCI-deviceid-1
                                Name = PCI1
                                Type = PCI

Notez l'indice implicite qui est ajouté au nom de la méthode de test lors de chaque invocation d'une méthode de test dépendante d'une ressource de test. La propriété ResourceSelection est affichée, suivie d’une liste de toutes les ressources qui seront disponibles pour la méthode de test dans l’ordre dans lequel elles seront disponibles. Par exemple, en cas de troisième appel de HDAudioHDAudioPCITest (HDAudioHDAudioPCITest#2), HDAudio-deviceid-1 sera la ressource disponible à l’index 0 dans Resources ::Item(...).

Vous pouvez être plus spécifique sur les appels de test qui vous intéressent à l’aide du langage de requête de sélection de ligne de commande disponible dans TAEF. Par exemple, pour sélectionner tous les appels de méthodes de test où les ressources de test « PCI-deviceid-3 » sont disponibles, vous pouvez utiliser les critères de sélection :

te Examples\Cpp.TestResource.Example.dll /list
          /select:"@Resource:Id='PCI-deviceid-3'"

Test Authoring and Execution Framework v2.9.3k for x86
In BuildResourceList
Verify: SUCCEEDED(::CoCreateGuid(&myGuid))

        f: \Examples\Cpp.TestResource.Example.dll
            WEX::TestExecution::Examples::TestResourceExample
                WEX::TestExecution::Examples::TestResourceExample::OnePCIDeviceTest#2
                WEX::TestExecution::Examples::TestResourceExample::HDorPCITest#4

De même, pour sélectionner une méthode de test particulière par nom (notez que les noms de méthode de test sont entièrement qualifiés avec l’index d'invocation ajouté à la fin), vous pouvez utiliser la requête de sélection suivante :

te Examples\Cpp.TestResource.Example.dll /name:*OneHDAudioTest#1
Test Authoring and Execution Framework v2.2 Build 6.1.7689.0 (release.091218-1251) for x86

Discovered a test resource dependent test module. Assuming /InProc execution.

In BuildResourceList
Verify: SUCCEEDED(::CoCreateGuid(&myGuid))

StartGroup: WEX::TestExecution::Examples::TestResourceExample::OneHDAudioTest#1
In HD audio test
Verify: AreEqual(count, (index + 1))
Verify: SUCCEEDED(Resources::Item(index, &spTestResource))
Verify: SUCCEEDED(spTestResource->GetValue(CComBSTR(TestResourceProperty::c_szId), &value))
Resource Id is HDAudio-deviceid-2
WEX::TestExecution::Examples::TestResourceExample::OneHDAudioTest#1 [Passed]

Summary: Total=1, Passed=1, Failed=0, Blocked=0, Not Run=0, Skipped=0

Notez l’avertissement implicite ajouté dans la troisième ligne de l’exemple ci-dessus. La requête de sélection ci-dessus a eu le même effet que la requête de sélection :/select :"@Name='*OneHDAudio*' Et @Resource:Index=1« . Il est également possible de sélectionner une ressource à l’aide de son nom ou de son type (ou id comme indiqué ci-dessus). Par exemple, /select :"@Name='*PCIHDAudioTest*' et @Resource:Name='PCI3' » sélectionnent les méthodes de test PCIHDAudioTest#4 et PCIHDAudioTest#5.

L’essai de ces requêtes et d’autres requêtes de sélection à l’invite de commandes est laissé comme exercice pour le lecteur.

  • Last updated on