Automatizando os testes de aplicativos do Windows 8

Blog do desenvolvedor de aplicativos do Windows 8

Ideias sobre a criação de aplicativos com o estilo Metro para o Windows 8, da equipe de engenharia do Windows 8

Automatizando os testes de aplicativos do Windows 8

  • Comments 0

Na postagem do blog para testes de aplicativos da Windows Store, abordamos principalmente quais testes realizar para seus aplicativos. Embora você possa executar manualmente as áreas de verificação que discutimos na postagem anterior, é mais eficiente automatizar algumas dessas áreas de verificação. Automatizar a verificação de seu aplicativo tem muitos benefícios. Os testes automatizados economizam tempo e dinheiro; sem eles, você desperdiçará tempo realizando testes manuais. Assim que forem criados os testes automatizados poderão ser executados quantas vezes forem necessárias, a um custo mínimo. Além disso, eles são muito mais rápidos do que os testes manuais. Isso ajuda a garantir que a qualidade de seus aplicativos permaneça elevada e o custo baixo com cada novo lançamento do aplicativo. Os testes automatizados também melhoram a precisão da verificação, pois até mesmo o responsável mais consciente por testes pode cometer erros durante testes manuais e entediantes.

Nesta postagem, fornecemos algumas dicas e técnicas sobre a automação dos testes de aplicativos do Windows 8. Lembre-se de que os testes automatizados são uma técnica poderosa que requer algum investimento inicial para se obter a recompensa total. As orientações e exemplos nesta postagem têm como objetivo ajudá-lo a iniciar, mas você precisará criar e manter sua própria infraestrutura com base nisso. Se você estiver procurando algumas técnicas de testes mais fáceis, verifique o blog recente sobre testes de aplicativos com o Visual Studio.

Um fluxo de trabalho característico de automação de testes de aplicativos envolve estas etapas:

  • Instalação: automatize a instalação do seu aplicativo.
  • Ativação: automatize a ativação do seu aplicativo.
  • Tempo de execução: automatize seu aplicativo quando ele estiver em execução.
  • Estado de ciclo de vida: automatize seu aplicativo sendo suspenso, retomado e encerrado.
  • Desinstalação: automatize a desinstalação do seu aplicativo.

Vamos abordar cada uma destas etapas em detalhes, bem como as ferramentas de automação/tecnologias para uso com cada uma delas.

Observação sobre testes no Windows RT

Antes de iniciarmos sobre os tópicos de automação, queremos fazer uma rápida observação sobre testes no Windows RT. Você não pode criar ou compatibilizar processos x86/64 para execução no Windows RT. Assim, todas as ferramentas e tecnologias discutidas no restante desta postagem não se aplicam para testes no Windows RT. Recomendamos que você use o Visual Studio para testes no Windows RT.

Automatizando a instalação do seu aplicativo

Para testar seu aplicativo, primeiro você precisa instalá-lo em sua máquina de teste. Usar o Visual Studio para compartilhar um pacote de aplicativo localmente é a abordagem recomendada para criar seu pacote de aplicativo e instalá-lo na máquina de teste. Nessa opção, o Visual Studio cria uma pasta que contém todos os arquivos pertinentes, junto com um script do PowerShell que instala a licença e o certificado apropriados, os pacotes de dependência e o pacote de aplicativo em si. Você precisa criar o pacote do seu aplicativo manualmente, mas a instalação é baseada no PowerShell e pode ser automatizada. Veja como será a instalação.

Etapa 1:

Habilite a execução de script do PowerShell. Por motivos de segurança, a política de execução do PowerShell padrão restringe a execução de scripts do PowerShell; portanto, você precisa substituir essa política. Essa etapa é manual pois requer manipulações do usuário. Felizmente, você precisa fazer isso uma vez por máquina. Execute esse comando de uma janela do PowerShell elevada para permitir a execução de script do PowerShell.

PS C:\> Set-ExecutionPolicy AllSigned
 Powershell_admin
Figura 1: Habilite a execução de script do PowerShell

Etapa 2:

Copie a pasta do pacote do aplicativo criada pelo Visual Studio na máquina de teste e execute o script do PowerShell Add-AppDevPackage de uma janela do PowerShell. Use este comando:

PS C:\JSGrid1_1.0.0.0_AnyCPU_Debug_Test> .\Add-AppDevPackage.ps1
Windows Powershell
Figura 2: Execute o script do PowerShell Add-AppDevPackage

Etapa 3:

Adquira uma licença de desenvolvedor. Essa etapa é manual pois requer manipulações do usuário. Mas você precisa fazer isso uma vez por máquina para o período de validade da licença. Se sua máquina de teste já tiver a licença de desenvolvedor, você poderá ignorar essa etapa.

Aceite o aviso de UAC e siga as instruções para adquirir uma licença de desenvolvedor. As capturas de tela a seguir ilustram o que você verá.

Esta primeira captura de tela requer que você concorde com os termos de licenciamento para instalar uma licença de desenvolvedor. Clique em I Agree (Aceito) se quiser continuar.

Powershell_devlic

Figura 3: aceite o aviso de aquisição da licença de desenvolvedor

Na caixa de diálogo Microsoft account (Conta da Microsoft), digite a sua conta da Microsoft. Se você não tiver uma, clique em Inscrever-se para criar uma.

msaccount_signin

Figura 4: entre com suas credenciais de conta da Microsoft

Você receberá uma confirmação de que sua licença de desenvolvedor foi criada e a data de expiração.

devlic_approve

Figura 5: licença de desenvolvedor adquirida com êxito

A próxima captura de tela indica que você obteve sua licença de desenvolvedor e seu pacote foi instalado com êxito.

PS_packagesuccess

Figura 6: instalação concluída

Automatizando a ativação do seu aplicativo

Seu pacote do aplicativo agora está instalado na máquina de teste e você está pronto para iniciar seu aplicativo. Você pode automatizar a ativação de seu aplicativo com a interface IApplicationActivationManager. Esta API está disponível como parte do SDK do Windows, que é instalado por padrão com o Visual Studio 2012. Use o método IApplicationActivationManager::ActivateApplication para iniciar seu aplicativo. O trecho de código aqui ilustra o uso desse método.

#include "stdafx.h"
#include <shlobj.h>
#include <stdio.h>
#include <shobjidl.h>
#include <objbase.h>
#include <atlbase.h>
#include <string>

/*++

Routine Description:

This routine launches your app using IApplicationActivationManager.

Arguments:

strAppUserModelID - AppUserModelID of the app to launch.
pdwProcessId - Output argument that receives the process id of the launched app.

Return value:

HRESULT indicating success/failure

--*/
HRESULT LaunchApp(const std::wstring& strAppUserModelId, PDWORD pdwProcessId)
{
CComPtr<IApplicationActivationManager> spAppActivationManager;
HRESULT hrResult = E_INVALIDARG;
if (!strAppUserModelId.empty())
{
// Instantiate IApplicationActivationManager
hrResult = CoCreateInstance(CLSID_ApplicationActivationManager, NULL, CLSCTX_LOCAL_SERVER, IID_IApplicationActivationManager, (LPVOID*)&spAppActivationManager);

if (SUCCEEDED(hrResult))
{
// This call ensures that the app is launched as the foreground window
hrResult = CoAllowSetForegroundWindow(spAppActivationManager, NULL);

// Launch the app
if (SUCCEEDED(hrResult))
{
hrResult = spAppActivationManager->ActivateApplication(strAppUserModelId.c_str(), NULL, AO_NONE, pdwProcessId);
}
}
}

return hrResult;
}

int _tmain(int argc, _TCHAR* argv[])
{
HRESULT hrResult = S_OK;
if (SUCCEEDED(CoInitializeEx(NULL, COINIT_APARTMENTTHREADED)))
{
if (argc == 2)
{
DWORD dwProcessId = 0;
++argv;
hrResult = LaunchApp(*argv, &dwProcessId);
}
else
{
hrResult = E_INVALIDARG;
}

CoUninitialize();
}

return hrResult;
}

 

Você pode compilar esse trecho e usá-lo da seguinte forma:

C:\>Win8AppLaunch.exe Microsoft.BingNews_8wekyb3d8bbwe!AppexNews

Nesse trecho de código, a chamada para CoAllowSetForegroundWindow é essencial. Sem essa chamada, o aplicativo será iniciado mas não será colocado em primeiro plano. A experiência mostra que isso fez com que inúmeras pessoas tentassem criar uma ferramenta de execução.

Por fim, uma observação rápida sobre AppUserModelId. Nessa abordagem, a entrada exigida para iniciar seu aplicativo é a AppUserModelId de seu aplicativo. A AppUserModelId funciona como um identificador exclusivo de seu aplicativo. Para recuperá-la, recomendamos que você use o PowerShell. Aqui está um script do PowerShell que ilustra como você pode recuperar a AppUserModelId para todos os aplicativos instalados em sua máquina.

$installedapps = get-AppxPackage
foreach ($app in $installedapps)
{
foreach ($id in (Get-AppxPackageManifest $app).package.applications.application.id)
{
$app.packagefamilyname + "!" + $id
}
}

Você também pode usar o IAppxManifestReader para enumerar os aplicativos no pacote e obter a AppUserModelId usando o método IAppxManifestApplication::GetAppUserModelId. Mas se seu foco principal for um único aplicativo que você está testando, usar o registro é muito mais simples do que gravar uma ferramenta que leia o manifesto do seu aplicativo.

Automatizando a funcionalidade principal do seu aplicativo

Seu aplicativo agora foi instalado na máquina de teste e sua automação pode iniciá-lo. A próxima etapa envolve automatizar o teste da funcionalidade principal de seu aplicativo. Você pode obter isso por uma combinação de testes de unidade e automação do aplicativo através de sua interface do usuário usando a automação de IU.

Os testes de unidade e automação de IU são técnicas complementares que, quando usadas juntas, podem resultar em um aplicativo de qualidade superior e amplamente testado. Os testes de unidade permitem que você automatize a lógica comercial principal em seu aplicativo. Os testes automatizados de IU permitem que você verifique a funcionalidade do seu aplicativo ao simular o uso de sua interface do usuário. Uma combinação dessas abordagens permite que você obtenha uma cobertura de teste mais ampla de seu aplicativo.

Vejamos algumas ferramentas e técnicas para cada uma dessas abordagens.

Testes de unidade

Os testes de unidade são uma técnica poderosa para verificar a funcionalidade principal de seu aplicativo. O Visual Studio 2012 é compatível com a criação de testes de unidade para aplicativos criados usando C# ou C++. Para obter mais informações sobre a criação e a execução de testes de unidade do Visual Studio 2012, consulte Criando e executando testes de unidade. Se você já estiver familiarizado com outras estruturas de testes de unidade, também poderá continuar usando os mesmos para testes de unidade de seu aplicativo da Windows Store.

Automação de IU

Os testes de unidade podem ser úteis para testar os trabalhos internos de seu aplicativo, mas não testam a interface do usuário de seu aplicativo. Recomendamos a automação de IU (AIU) para verificar a funcionalidade de um aplicativo através de sua interface do usuário.

No modelo de segurança do Windows 8, os aplicativos não têm os privilégios exigidos para ser um cliente de automação de IU. Mas você pode criar um aplicativo de desktop que atue como um cliente de automação com seu aplicativo como o destino. Para fazer isso, seu aplicativo cliente de automação de desktop precisa ser criado com permissões UIAccess, como descrito em Visão geral sobre segurança de automação da IU.

O SDK do Windows inclui algumas ferramentas que servem como bons exemplos de clientes de automação de IU: Inspect.exe e AccEvent.exe. O Inspect permite que você inspecione a árvore de automação de IU de ambos os tipos de aplicativos. O AccEvent realiza a escuta de eventos de AIU. Em uma máquina que tenha o SDK do Windows instalado, essas ferramentas geralmente estarão em %ProgramFiles(x86)%\Windows Kits\8.0\bin\<arquitetura>. Aqui você pode ver ambas as ferramentas em ação.

inspect.exe

Figura 7: a ferramenta Inspect em execução em relação ao aplicativo Bing News

accevent_tool

Figura 8: a ferramenta AccEvent em execução em relação ao aplicativo Bing Sports

Semelhante à abordagem usada por essas ferramentas, você pode usar a AIU para criar um aplicativo cliente de desktop que automatize seu aplicativo. A postagem Criando aplicativos cliente de automação de IU em C++ e C# do blog é um excelente ponto de partida para saber mais sobre como criar um cliente de AIU. Essa postagem do blog aborda a automação de IU tradicional, mas as mesmas técnicas funcionarão para qualquer aplicativo.

A amostra do cliente de conteúdo do documento de automação de IU ilustra como você pode usar os padrões de controle de AIU para recuperar vários tipos de conteúdo da janela do aplicativo de destino, como leitores, comentários ou a seleção atual. A amostra de Injeção de Toque ilustra como você pode usar as APIs de Injeção de Toque para simular o toque para verificação de seu aplicativo.

Como mencionado anteriormente, os testes de unidade e automação de IU são técnicas complementares que permitem que você automatize a lógica comercial principal em seu aplicativo e sua funcionalidade, quando testada da interface do usuário. Use ambas essas técnicas para depurar seu aplicativo.

Automatizando o estado do ciclo de vida do seu aplicativo

Como descrito na postagem de blog gerenciando o ciclo de vida do aplicativo, um aplicativo pode fazer a transição entre vários estados de tempo de execução. De uma perspectiva de testes, é importante verificar seu aplicativo em todos os estados. A automação da transição nesses estados é possível através do uso de uma ferramenta (PLMDebug) fornecida com as Ferramentas de depuração para Windows, uma ferramenta da linha de comando pronta para uso, que você pode usar para automatizar a transição de seu aplicativo entre estados do ciclo de vida.

Se a PLMDebug não for suficiente para suas necessidades, você poderá usar a interface IPackageDebugSettings para implementar sua própria ferramenta, que pode alterar o estado do ciclo de vida de seu aplicativo. Esta API está disponível como parte do SDK do Windows, que é instalado por padrão com o Visual Studio. O código ilustra como usar a API IPackageDebugSettings para alterar o estado do ciclo de vida de seu aplicativo, a fim de verificar se seu aplicativo funciona como esperado durante essas transições de estado.

#include "stdafx.h"
#include <stdio.h>
#include <shobjidl.h>
#include <objbase.h>
#include <atlbase.h>
#include <string>

/*++

Routine Description:

This routine changes the lifecycle state of a Windows Store app depending on the input argument.

Arguments:

strPackageFullName - Package Full Name of the Windows Store app
strOperation - Operation to take (/enabledebug, /suspend, /resume, /terminate, /cleanTerminate, /disabledebug)

Return Value:

HRESULT indicating success/failure

--*/
HRESULT ChangeLifecycleState(const std::wstring& strPackageFullName, const std::wstring& strOperation)
{
CComPtr<IPackageDebugSettings> spPackageDebugSettings;
HRESULT hrResult = E_INVALIDARG;

if (!strPackageFullName.empty() && !strOperation.empty())
{
// Instantiate IPackageDebugSettings
hrResult = CoCreateInstance(CLSID_PackageDebugSettings, NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&spPackageDebugSettings));

// Depending on the operation specified as the command line arg, change the lifecycle state of the app
if (SUCCEEDED(hrResult))
{
if (_wcsicmp(strOperation.c_str(), L"/enableDebug") == 0)
{
// Increment debug ref count on the app package - you must do this before you can suspend/resume/terminate
hrResult = spPackageDebugSettings->EnableDebugging(strPackageFullName.c_str(), NULL, NULL);
}
else if (_wcsicmp(strOperation.c_str(), L"/suspend") == 0)
{
// Asynchronously suspend the app
hrResult = spPackageDebugSettings->Suspend(strPackageFullName.c_str());
}
else if (_wcsicmp(strOperation.c_str(), L"/resume") == 0)
{
// Resume the app
hrResult = spPackageDebugSettings->Resume(strPackageFullName.c_str());
}
else if (_wcsicmp(strOperation.c_str(), L"/terminate") == 0)
{
// Terminate the app
hrResult = spPackageDebugSettings->TerminateAllProcesses(strPackageFullName.c_str());
}
else if (_wcsicmp(strOperation.c_str(), L"/cleanTerminate") == 0)
{
// Clean terminate the app - suspend, then terminate
hrResult = spPackageDebugSettings->StartServicing(strPackageFullName.c_str());
if (SUCCEEDED(hrResult))
{
hrResult = spPackageDebugSettings->StopServicing(strPackageFullName.c_str());
}
}
else if (_wcsicmp(strOperation.c_str(), L"/disableDebug") == 0)
{
// Decrement debug ref count on the app package
hrResult = spPackageDebugSettings->DisableDebugging(strPackageFullName.c_str());
}
else
{
hrResult = E_INVALIDARG;
}
}
}

return hrResult;
}

int _tmain(int argc, _TCHAR* argv[])
{
HRESULT hrResult = S_OK;
if (SUCCEEDED(CoInitializeEx(NULL, COINIT_APARTMENTTHREADED)))
{
if (argc == 3)
{
std::wstring strOperation(argv[1]);
std::wstring strPackageFullName(argv[2]);
hrResult = ChangeLifecycleState(strPackageFullName, strOperation);
}
else
{
hrResult = E_INVALIDARG;
}

CoUninitialize();
}

return hrResult;
}

 

Se você compilar esse trecho como LifecycleManager.exe, veja como usar:
C:\>Win8AppLifecycleManager.exe /enableDebug Microsoft.BingNews_1.2.0.98_x64__8wekyb3d8bbwe

C:\> Win8AppLifecycleManager.exe /suspend Microsoft.BingNews_1.2.0.98_x64__8wekyb3d8bbwe

C:\> Win8AppLifecycleManager.exe /resume Microsoft.BingNews_1.2.0.98_x64__8wekyb3d8bbwe

C:\> Win8AppLifecycleManager.exe /terminate Microsoft.BingNews_1.2.0.98_x64__8wekyb3d8bbwe

C:\> Win8AppLifecycleManager.exe /cleanTerminate Microsoft.BingNews_1.2.0.98_x64__8wekyb3d8bbwe

C:\> Win8AppLifecycleManager.exe /disableDebug Microsoft.BingNews_1.2.0.98_x64__8wekyb3d8bbwe
 

Por fim, uma observação rápida sobre PackageFullName. Todas as abordagens que analisamos para o gerenciamento do estado do ciclo de vida exigem o PackageFullName como o argumento de entrada pelo qual identificar o aplicativo. Para recuperar o PackageFullName, recomendamos que você use o cmdlet Get-AppxPackage PowerShell como o próximo exemplo demonstra (resultado reduzido para fins de melhor leitura).

PS C:\> Get-AppxPackage

Name : Microsoft.BingNews
Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture : X64
ResourceId :
Version : 1.2.0.98
PackageFullName : Microsoft.BingNews_1.2.0.98_x64__8wekyb3d8bbwe ←
InstallLocation : C:\Program Files\WindowsApps\Microsoft.BingNews_1.2.0.98_x64__8wekyb3d8bbwe
IsFramework : False
PackageFamilyName : Microsoft.BingNews_8wekyb3d8bbwe
PublisherId : 8wekyb3d8bbwe

Automatizando a desinstalação do seu aplicativo

Para desinstalar seu aplicativo, recomendamos que você use os cmdlets PowerShell, especificamente, Remove-AppxPackage. Aqui está um exemplo (resultado reduzido para fins de melhor leitura).

PS C:\> Get-AppxPackage

Name : Microsoft.SDKSamples.ListViewEssentials.JS
Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture : Neutral
ResourceId :
Version : 1.0.0.0
PackageFullName : Microsoft.SDKSamples.ListViewEssentials.JS_1.0.0.0_neutral__8wekyb3d8bbwe ←
InstallLocation : C:\Users\user1\Downloads\Samples\Controls_ListViewBasic\JS\bin\Debug\AppX
IsFramework : False
PackageFamilyName : Microsoft.SDKSamples.ListViewEssentials.JS_8wekyb3d8bbwe
PublisherId : 8wekyb3d8bbwe

PS C:\> Remove-AppxPackage Microsoft.SDKSamples.ListViewEssentials.JS_1.0.0.0_neutral__8wekyb3d8bbwe

Conclusão

Nesta postagem do blog, abordamos várias dicas, ferramentas e técnicas para a automação dos testes de seus aplicativos. Os testes automatizados podem ser uma forma econômica de aumentar o nível de verificação de seu aplicativo e garantir que a qualidade nunca caia. Tendo dito isso, é importante lembrar que os testes manuais também exercem uma função importante na verificação. Eles fornecem o elemento humano para a verificação de seu aplicativo. Como tal, uma combinação de testes automatizados e manuais fornecerá a você uma abordagem ideal para testar seu aplicativo.

-- Ashwin Needamangala, Líder de teste principal, Windows

Agradecimentos especiais a Mete Goktepe, J. Kalyana Sundaram, Ben Betz, Will Wei, Chris Edmonds, Craig Campbell e Jake Sabulsky por sua ajuda e contribuições a esta postagem.

  • Loading...
Leave a Comment
  • Please add 7 and 7 and type the answer here:
  • Post