Supporto dispositivo
Se l'automazione dei test si basa sulla presenza di dispositivi o risorse di test, fare riferimento all'esempio TestResourceExample e seguire la procedura per sfruttare il supporto delle risorse di supporto per dispositivi o test disponibile in TAEF. Assicurarsi di avere familiarità con come creare test di base usando TAEF e l'esecuzione di base del TAEF prima di procedere.
Creazione per il supporto dei dispositivi - File di origini
Te.Common.lib è necessario oltre ad altre librerie necessarie per creare un test in TAEF.
Creazione per il supporto dei dispositivi - Definizione della risorsa di test
Gli utenti sono responsabili della creazione della propria definizione di risorsa di test (dispositivo). A tale scopo, è necessario implementare ITestResource. ITestResource viene definito nel file di intestazione pubblicato ITestResource.h e ha l'aspetto seguente:
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*/
Nell'esempio la classe MyTestResource implementa l'interfaccia COM ITestResource. In ITestResource.h troverai anche un elenco di proprietà "must-have" definite. Dovrebbe essere possibile ottenere il GUID per la risorsa di test usando GetGuid(..) e il nome, l'ID e il tipo della risorsa usando GetValue(...). Se una di queste informazioni non è presente in un oggetto TestResource, TAEF considererà non valida e non manterrà le informazioni. Vedere la sezione "Compilazione dell'elenco di risorse" riportata di seguito.
Creazione per il supporto dei dispositivi - Specifica dei metadati dipendenti dalle risorse
Per specificare che il modulo di test dispone di metodi di test dipendenti dalla risorsa di test, è necessario impostare su "true" una proprietà dei metadati a livello di modulo "TestResourceDependent". La proprietà viene ereditata da tutte le classi nel modulo di test e da tutti i metodi di test in queste classi. Se uno dei metodi di test nel modulo non è dipendente dalla risorsa di test, deve impostare in modo esplicito il valore dei metadati su false. Tutti gli altri metodi di test che dipendono dalla risorsa di test devono fornire una query di selezione usando l'ID della risorsa di test e/o "Type".
Ecco alcuni esempi rapidi di "ResourceSelection" per l'elenco di risorse di esempio e ciò che ognuno di essi implica:
- "@Id='HD*'": corrisponde a ogni risorsa con un ID che inizia con "HD"
- "@Type='PCI'": corrisponde a ogni risorsa di tipo "PCI"
- "@Id='PCI*' OR @Id='HD*'": corrisponde a ogni risorsa che inizia con "PCI" o a partire da "HD"
- "@Type='PCI' e @id='*37'": corrisponde a ogni risorsa di tipo "PCI" con un nome che termina in "37"
Nel codice di esempio, l'aspetto è il seguente:
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()
...
};
Nell'esempio precedente si noterà che il modulo è contrassegnato come "TestResourceDependent". NoTestResourceTest viene contrassegnato in modo esplicito come non dipendente da alcuna risorsa di test impostando i metadati "TestRssourceDependent" su "false". Tutti gli altri metodi di test specificano un criterio di selezione per le risorse di test a cui sono interessati l'esecuzione.
La grammatica dei criteri di selezione è molto simile alla grammatica della query di selezione della riga di comando disponibile per TAEF. Nel caso della selezione delle risorse, tuttavia, è limitato all'uso dei tipi e dell'ID risorsa. Poiché l'ID risorsa è una stringa, deve essere racchiuso tra virgolette singole. È possibile usare i caratteri jolly "*" o "?" nella specifica del valore ID. Nell'esempio precedente, in OneHDAudioTest, la selezione della risorsa specifica una corrispondenza con qualsiasi risorsa in cui ID inizia con "HD". Analogamente, nel caso di HDorPCITest, la selezione della risorsa corrisponderà a qualsiasi risorsa in cui ID inizia con "HD" o inizia con "PCI". È importante notare che la selezione delle risorse non fa distinzione tra maiuscole e minuscole, ovvero 'pci', 'Pci' e 'PCI' verranno trattate allo stesso modo.
In base alla selezione della risorsa, TAEF richiamerà nuovamente il metodo di test insieme ai metodi di installazione e pulizia a livello di test (se specificati) una volta per ogni risorsa di test corrispondente alla selezione. Le sezioni seguenti esamineranno i dettagli su come specificare l'elenco delle risorse e specificarlo al TAEF e sul modo in cui il metodo di test può recuperare le risorse nella sezione successiva.
Creazione per il supporto dei dispositivi - Compilazione dell'elenco di risorse
Non appena TAEF rileva un modulo di test TestResourceDependent, cercherà e richiamerà il metodo dll-export BuildResourceList. Si trova nell'implementazione di BuildResourceList in cui gli utenti possono creare nuove risorse di test e aggiungerle all'interfaccia passata come parametro a BuildResourceList. Di seguito viene illustrata l'implementazione di questo metodo nell'esempio seguente:
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 accetta un riferimento a WEX::TestExecution::ResourceList come parametro. ResourceList viene definito nel file di intestazione pubblicato ResourceList.h. Usando il metodo Add(...) in ResourceList, gli utenti possono aggiungere tutte le risorse di test individuate o create per gestire e usare il TAEF. Nell'esempio precedente sono state aggiunte 5 risorse di test di questo tipo.
Il metodo Add avrà esito negativo se la risorsa di test da aggiungere non restituisce "Name", "Id", "Type" o GUID per la risorsa.
ResourceList verrà mantenuto durante la durata del modulo di test, ovvero fino a quando non vengono eseguiti tutti i metodi di test e i metodi di pulizia. Se BuildResourceList restituisce un valore HRESULT FAILED, tutti i metodi di test dipendenti dalle risorse nel modulo di test vengono registrati come bloccati senza eseguire. Tutte le risorse non di test verranno eseguite indipendentemente.
BuildResourceList viene richiamato prima di qualsiasi altro metodo nel modulo di test. Dopo aver compilato l'elenco di risorse (in BuildResourceList), i metadati "ResourceSelection" vengono usati per trovare le corrispondenze con le risorse disponibili nell'elenco di risorse. Se viene trovata una corrispondenza, vengono richiamati tutti i metodi di installazione (modulo, classe, ordine di test) seguiti dal metodo di test stesso. Il metodo di pulizia a livello di test viene chiamato dopo ogni chiamata di test.
Dietro le quinte, TAEF mantiene l'oggetto ResourceList in cui viene applicata la selezione della risorsa. Ad esempio, per il metodo di test OneHDAudioTest, le risorse di test con ID "HDAudio-deviceid-1" e "HDAudio-deviceid-2" corrisponderanno a "HD*" e per ognuna di queste, il metodo di test verrà richiamato nuovamente da TAEF (una volta per ogni). Sarà presente anche un indice implicito associato a ogni chiamata del test. Verrà quindi visualizzato <il qualificatore>dello spazio dei nomi OneHDAudioTest#0 e <il qualificatore>dello spazio dei nomi OneHDAudioTest#1 come due chiamate.
Creazione per il supporto dei dispositivi - Recupero del dispositivo in un metodo di test
Nelle sezioni precedenti è stato illustrato come aggiungere i metadati necessari a livello di modulo, classe e metodo di test. Hanno anche esaminato come definire risorse di test personalizzate e come aggiungerle a ResourceList nell'implementazione di BuildResourceList. La parte successiva che segue sta recuperando le risorse nel metodo di test. Di seguito viene illustrato uno dei metodi di test semplici nell'esempio seguente:
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 }
In OneHDAudioTest la selezione della risorsa seleziona una risorsa di test alla volta in cui l'ID risorsa inizia con "HD". La classe statica Resources definita in ResourceList.h fornisce le API per il recupero del conteggio e la risorsa effettiva disponibile durante qualsiasi chiamata del test. In questo caso, come si può notare nelle righe 4, 9 e 13 nell'esempio precedente, Resources::Count() fornisce il numero di risorse di test disponibili durante la chiamata corrente del metodo di test. In questo metodo di test, deve essere 1. È possibile verificare questo valore usando le macro VERIFY disponibili in TAEF (Verify.h). Come si sa, se una delle chiamate di verifica ha esito negativo in un test TAEF basato su eccezioni, l'esecuzione terminerà a quel punto e il metodo di test verrà contrassegnato come Non riuscito.
Usare quindi Resources::Item(...) API e passaggio di un indice in corrispondenza del quale recuperare la risorsa (in questo caso, poiché durante una chiamata sarà disponibile una sola risorsa di test, l'indice sarà sempre 0), è possibile recuperare la risorsa di test. Il metodo di test può usare ulteriormente la risorsa di test recuperata in quanto necessaria per il test.
Lo stesso principio di base è seguito in tutti i metodi di test. Esaminare altri metodi di test nell'esempio per ottenere una migliore comprensione.
Esecuzione di un modulo di test dipendente dalla risorsa di test
Dopo aver creato e compilato i test dipendenti dalla risorsa di test, è ora possibile eseguirlo usando TAEF. Il punto chiave da notare è che i test TestResourceDependent possono essere eseguiti solo inproc. Ciò significa che, anche se non si specifica in modo esplicito l'opzione "/inproc", verrà aggiunta non appena TAEF individua il modulo di test dipendente dalla risorsa di test. Come si può notare, i test di un solo modulo di test possono essere eseguiti in una determinata esecuzione TAEF quando è presente l'opzione "/inproc". Ciò significa che non è possibile specificare più moduli di test nella riga di comando se il modulo di test dipende dalla risorsa.
Per eseguire effettivamente tutti i test nel modulo di test, è sufficiente eseguire:
te Examples\Cpp.TestResource.Example.dll
Un modo utile per ottenere solo un elenco di tutte le chiamate al metodo di test e le combinazioni di dati e metadati senza eseguire effettivamente i metodi di test, consiste nell'usare l'opzione /listproperties nella riga di comando. Esaminiamo ora l'output.
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
Si noti l'indice implicito che viene aggiunto al nome del metodo di test durante ogni chiamata di un metodo di test depent della risorsa di test. La proprietà ResourceSelection viene visualizzata seguito da un elenco di tutte le risorse che saranno disponibili per il metodo di test nell'ordine in cui saranno disponibili. Ad esempio, nel caso della terza chiamata di HDAudioHDAudioPCITest (HDAudioHDAudioPCITest#2), HDAudio-deviceid-1 sarà la risorsa disponibile nell'indice 0 in Resources::Item(...).
È possibile essere più specifici sulla chiamata di test a cui si è interessati usando il linguaggio di query di selezione della riga di comando disponibile in TAEF. Ad esempio, per selezionare tutte le chiamate dei metodi di test in cui sono disponibili le risorse di test "PCI-deviceid-3", è possibile usare i criteri di selezione:
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
Analogamente, per selezionare un metodo di test specifico in base al nome (si noti che i nomi dei metodi di test sono completi insieme all'indice di chiamata accodato alla fine), è possibile usare una query di selezione come indicato di seguito:
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
Si noti l'avviso inproc implicito aggiunto nella terza riga dell'esempio precedente. La query di selezione precedente ha lo stesso effetto della query di selezione:/select:"@Name='*OneHDAudio*' e @Resource:Index=1". È anche possibile selezionare una risorsa usando il nome o il tipo o l'ID, come illustrato in precedenza. Ad esempio, /select:"@Name='*PCIHDAudioTest*' e @Resource:Name='PCI3'" selezionerà i metodi di test PCIHDAudioTest#4 e PCIHDAudioTest#5.
Il tentativo di queste e altre query di selezione al prompt dei comandi viene lasciato come esercizio per il lettore.