Exportando um trabalho HLK com falha

Agora você pode exportar um trabalho com falha para que ele possa ser executado em um computador fora do ambiente HLK completo. Para desenvolvedores de driver, esse recurso permite que a execução autônoma do teste simplifique o processo de reprodução de falhas.

Um ambiente de teste exportado simula de perto um ambiente HLK dedicado. No entanto, isso não garante a execução de teste idêntica. Um usuário pode precisar lidar com qualquer uma das seguintes circunstâncias:

• As reinicializações não são tratadas pela infraestrutura de teste. O usuário terá que reiniciar manualmente o sistema em muitos casos.
• Pode haver casos em que o teste reinicializa o sistema por meio da infraestrutura do cliente HLK em uma tarefa de teste. Por exemplo, essas reinicializações podem não ser capturadas no arquivo em lote como prompts ou reinicializações durante a execução autônoma.
• Arquivos de log não nomeados exclusivamente gravados no mesmo local por tarefas diferentes podem resultar na substituição de alguns desses arquivos.
• Os parâmetros gravados no arquivo em lote podem ser diferentes ao serem executados em sistemas diferentes. Por exemplo, as IDs de instância de hardware podem ser diferentes para o mesmo hardware e driver quando movidas para um sistema diferente, e o usuário precisará pesquisar o valor de destino correspondente (de Gerenciador de Dispositivos, por exemplo) e atualizar o arquivo em lote com o valor correto.
• Testes que dependem de um trabalho de configuração associado para configurar o sistema podem não estar preparados corretamente, pois o HLK exporta apenas o trabalho de teste em si.

Nem todos os resultados podem ser exportados. A lista a seguir descreve os limites nos testes e resultados de teste que são exportáveis:

• Os testes devem ter sido executados e concluídos com uma status aprovada, com falha ou cancelada.
• A execução do teste deve retornar com êxito os logs de infraestrutura do sistema cliente. Esses arquivos são necessários para exportar o teste.
• Somente testes de computador único podem ser exportados. Testes que exigem a execução de vários computadores não são exportáveis.
• Os testes devem ser executados usando o cliente da área de trabalho HLK. As execuções de teste nos sistemas Windows Core ou Proxy Mobile Client não são exportáveis.
• Testes marcados como não exportáveis devido a problemas de infraestrutura conhecidos ou outros motivos não são exportáveis.

1. Na guia Resultados no HLK Studio, clique com o botão direito do mouse no resultado com falha e selecione Exportar Execução de Teste.

2. Uma caixa de diálogo salvar é exibida. Salve o trabalho exportado em uma unidade flash ou em outro local externo para que você possa fazer o teste exportado para outro computador. O mesmo teste não pode ser exportado para o mesmo local mais de uma vez. Uma caixa de diálogo confirmará que a exportação foi concluída.

3. Os binários de teste e um arquivo em lote necessários para executar o teste em um sistema autônomo são exportados para o diretório especificado. O teste exportado é salvo em um subdiretório com o nome e a arquitetura do trabalho com falha. Os componentes de infraestrutura que devem ser instalados para executar o teste são salvos em um subdiretório chamado Infraestrutura , juntamente com o nome da arquitetura para a qual a infraestrutura é direcionada.

Observação

  Os componentes de infraestrutura devem ser instalados apenas uma vez no sistema de destino. Você não precisa reinstalar esses componentes para cada trabalho com falha.

Por exemplo, salvar um trabalho x64 com falha intitulado Definir Destino de Renderização na raiz da unidade E:\ exporta a pasta de trabalho e o instalador de infraestrutura usando a seguinte estrutura de pastas:

E:.
├───Infrastructure(X64)
└───Set_Render_Target(X64)
    ├───CoreClr
    ├───MinTe
    │   └───CoreClr
    ├───NetFx2.0
    ├───NetFx4.5
    ├───verifysupportfiles
    │   ├───CoreClr
    │   ├───MinTe
    │   │   └───CoreClr
    │   ├───NetFx2.0
    │   └───NetFx4.5
    └───[windir]
        └───system32 

O pacote de teste exportado contém vários arquivos e subpastas, incluindo o seguinte:

• readme1st.txt – contém informações sobre como executar o teste exportado
• run.cmd – arquivo em lote usado para executar o teste
• binários e outros arquivos necessários para executar o teste
• setup(architecture).exe – instalar executável usado para instalar a infraestrutura

4. Leve a pasta de teste exportada para o novo computador para teste. O caminho não deve conter espaços, pois isso fará com que alguns testes falhem.

5. Execute (salvar pasta)\Infrastructure(architecture)\setup(architecture).exe para instalar os componentes de infraestrutura antes de executar o teste. O instalador de infraestrutura exibirá uma caixa de diálogo que indica se a instalação dos componentes foi bem-sucedida.

Observação

Os componentes de infraestrutura devem ser instalados apenas uma vez no sistema de destino. Você não precisa reinstalar esses componentes para cada trabalho com falha.

Observação

A arquitetura do instalador e o trabalho devem corresponder à arquitetura do sistema de destino no qual ele está instalado.

6. Dentro do arquivo em lote na pasta (salvar pasta)(nome do trabalho)(arquitetura), você pode fazer as alterações necessárias no arquivo de lote a serem executadas no computador de teste. Como exemplos, você pode fazer as seguintes alterações:

• Comentando linhas que não contribuem para a falha no trabalho
• Alterando valores de parâmetro para corresponder ao computador no qual o teste exportado é executado. Por exemplo, a ID da instância do mesmo hardware geralmente difere em dois sistemas separados, portanto, isso precisaria ser atualizado antes de executar o teste exportado.
• Adicionar comandos para conectar um depurador

Observação

Se uma tarefa mostrar a mensagem de erro "Este teste não pode ser executado, pois pode reiniciar o computador.", você deve editar run.cmd e acrescentar /rebootstatefile=(some_file_name) à linha de comando da tarefa com falha, conforme mostrado no exemplo abaixo:

cmd /c TE.exe /inproc /enablewttlogging /appendwttlogging devfund_pcirootportsurpriseremovetest_wlk_certification.dll
/p:"MultiDeviceHardwareIdSdelQueryHardwareID=!MultiDeviceHardwareIdSdelQueryHardwareID!"
/p:"MultiDeviceInstanceIdSdelWDKDeviceID=!MultiDeviceInstanceIdSdelWDKDeviceID!" /p:"DQ=!DQ!"
/p:"TestCycles=!TestCycles!" /p:"IOPeriod=!IOPeriod!" /p:"WDTFREMOTESYSTEM=!WDTFREMOTESYSTEM!"
/p:"Wpa2PskAesSsid=!Wpa2PskAesSsid!"
/p:"DriverVerifierAdditionalDrivers=!DriverVerifierAdditionalDrivers!"
/p:"DriverVerifierExcludedFlags=!DriverVerifierExcludedFlags!"
/p:"DriverVerifierCustomizeConfiguration=!DriverVerifierCustomizeConfiguration!"
/rebootStateFile=rebootstatefile.xml

7. Depois de concluir as modificações, inicie um prompt de comando com privilégios administrativos, altere para o diretório de teste e execute run.cmd. Cada tarefa no arquivo em lote é associada a um número de tarefa que pode ser usado como ponto de partida ao executar o arquivo em lote. Por padrão, a execução é pausada entre as tarefas. Há suporte para os seguintes modos de execução:

• "Executar" sem parâmetros inicia a execução no início do arquivo em lote, com uma pausa entre cada tarefa.
• "Executar 5" iniciará o arquivo em lote e pulará para a tarefa 5.
• "Executar FAST" inicia o arquivo em lote no modo rápido (sem pausa entre as tarefas) no início.
• "Executar 5 FAST" iniciará o arquivo em lote no modo rápido (sem pausa entre as tarefas) na tarefa 5.
• "RebootResume" iniciará o arquivo em lote a partir da última reinicialização da última execução do script. Também há suporte para o sinalizador FAST.
• "RerunLast" iniciará o arquivo em lote do comando que estava em execução quando o arquivo em lote foi encerrado pela última vez. Esse comando pode ser usado para executar novamente uma tarefa várias vezes pressionando Control+C para sair do script durante a tarefa e executando rerunlast.cmd para executar novamente o comando anterior. Também há suporte para o sinalizador FAST.

8. Depois de identificar e corrigir o problema que está causando a falha do teste, você pode implantar a correção e verificar se o trabalho é bem-sucedido no ambiente HLK.

Observação

Não é possível importar resultados bem-sucedidos de volta para o ambiente HLK. Você deve executar novamente o trabalho de dentro do ambiente.