Teste do Programa de Qualidade drawElements (deqp)

O AOSP inclui o conjunto de testes de GPU drawElements Quality Program (deqp) em https://android.googlesource.com/platform/external/deqp . Esta página detalha como implantar o conjunto de testes deqp em um novo ambiente.

Para trabalhar com o código enviado mais recente, use a deqp-dev . Para o código que corresponde a uma versão específica do Android CTS, use a ramificação release-code-name -release (por exemplo, para Android 6.0, use a ramificação marshmallow-release ).

Layout de origem

O layout do código-fonte para os módulos de teste deqp e as bibliotecas de suporte é mostrado na tabela abaixo (a listagem não é abrangente, mas destaca os diretórios mais importantes).

Componentes de código aberto

O deqp usa libpng e zlib , que podem ser obtidos usando o script platform/external/deqp/external/fetch_sources.py ou via git de platform/external/[libpng,zlib] .

Construindo programas de teste

A estrutura de teste foi projetada com a portabilidade em mente. Os únicos requisitos obrigatórios são suporte completo a C++ e bibliotecas de sistema padrão para E/S, threads e soquetes.

Sistema de compilação CMake

As fontes deqp possuem scripts de compilação para CMake, que é a ferramenta preferida para compilar os programas de teste.

O CMake é um sistema de compilação de código aberto que oferece suporte a várias plataformas e cadeias de ferramentas. O CMake gera makefiles nativos ou arquivos de projeto IDE a partir de arquivos de configuração independentes de destino. Para obter mais informações sobre o CMake, consulte a documentação do CMake .

O CMake suporta e recomenda compilações fora da árvore de origem, ou seja, você deve sempre criar makefiles ou arquivos de projeto em um diretório de compilação separado fora da árvore de origem. O CMake não possui nenhum tipo de destino "distclean", portanto, a remoção de qualquer arquivo gerado pelo CMake deve ser feita manualmente.

As opções de configuração são fornecidas ao CMake usando a sintaxe -D OPTION_NAME = VALUE . Algumas opções comumente usadas para deqp estão listadas abaixo.

Criando um arquivo de compilação de destino

O sistema de compilação deqp é configurado para novos destinos usando arquivos de compilação de destino. Um arquivo de compilação de destino define quais recursos a plataforma suporta e quais bibliotecas ou caminhos de inclusão adicionais são necessários. Os nomes dos arquivos de destino seguem o formato targets/ NAME / NAME .cmake e o destino é selecionado usando o parâmetro de construção DEQP_TARGET .

Os caminhos de arquivo nos arquivos de destino são relativos ao diretório deqp base, não ao diretório targets/ NAME . As seguintes variáveis ​​padrão podem ser definidas pelo arquivo de compilação de destino.

O arquivo de compilação de destino pode adicionar caminhos adicionais de inclusão ou link usando as funções CMake include_directories() e link_directories() .

Compilação do Win32

A maneira mais fácil de criar módulos deqp para Windows é usar o sistema de compilação CMake. Você precisará do CMake 2.6.12 ou mais recente e do compilador Microsoft Visual C/C++. O deqp foi testado com o Visual Studio 2013.

Os arquivos de projeto do Visual Studio podem ser gerados com o seguinte comando:

cmake path\to\src\deqp -G "Visual Studio 12"

Uma compilação de 64 bits pode ser feita selecionando "Visual Studio VERSION Win64" como o gerador de compilação:

cmake path\to\src\deqp -G "Visual Studio 12 Win64"

Você também pode gerar makefiles NMake com a opção -G "NMake Makefiles" , bem como o tipo de compilação ( -DCMAKE_BUILD_TYPE="Debug" ou "Release" ).

Criação de contexto de renderização

O contexto de renderização pode ser criado com WGL ou com EGL no Windows.

Suporte WGL

Todos os binários do Win32 suportam a criação de contexto GL com WGL, pois requer apenas bibliotecas padrão. O contexto WGL pode ser selecionado usando o argumento de linha de comando --deqp-gl-context-type=wgl . No modo WGL, o deqp usa a extensão WGL_EXT_create_context_es_profile para criar contextos OpenGL ES. Isso foi testado para funcionar com os drivers mais recentes da NVIDIA e Intel. Os drivers AMD não suportam a extensão necessária.

Suporte EGL

O deqp é construído com carregamento dinâmico para EGL no Windows se DEQP_SUPPORT_EGL estiver ON. Este é o padrão na maioria dos destinos. Então, se o host tiver bibliotecas EGL disponíveis, é possível executar testes com elas com o parâmetro de linha de comando: --deqp-gl-context-type=egl

Versão do Android

A compilação do Android usa scripts de compilação do CMake para compilar o código de teste nativo. Partes Java, ou seja, o Test Execution Server e o Test Application Stub, são compilados usando as ferramentas de compilação padrão do Android.

Para compilar programas de teste deqp para Android com os scripts de compilação fornecidos, você precisará:

• A versão mais recente do Android NDK ; o arquivo android/scripts/common.py lista a versão necessária
• SDK autônomo do Android com API 13, SDK Tools, SDK Platform-tools e pacotes SDK Build-tools instalados
• Apache Ant 1.9.4 (exigido pela compilação do código Java)
• CMake 2.8.12 ou mais recente
• Python 2.6 ou mais recente na série 2.x; Python 3.x não é compatível
• Para Windows: NMake ou JOM em PATH
  • JOM permite compilações mais rápidas
• Opcional: Ninja make também é compatível com Linux

Os binários Ant e SDK estão localizados com base na variável de ambiente PATH com certos padrões de substituição. A lógica é controlada por android/scripts/common.py .

O diretório do NDK deve ser ~/android-ndk- VERSION ou C:/android/android-ndk- VERSION ou definido por meio da variável de ambiente ANDROID_NDK_PATH .

Os componentes do Deqp no dispositivo, o serviço de execução de teste e os programas de teste são criados executando o android/scripts/build.py . O .apk final é criado em android/package/bin e pode ser instalado pelo script install.py . Se o executor de linha de comando for usado, o ExecService será iniciado com o script launch.py ​​no dispositivo via ADB. Os scripts podem ser executados de qualquer diretório.

Compilação do Linux

Binários de teste e utilitários de linha de comando podem ser criados para Linux gerando makefiles usando o CMake. Existem vários destinos de compilação predefinidos que são úteis ao compilar para Linux.

Sempre use -DCMAKE_BUILD_TYPE=<Debug|Release> para definir o tipo de compilação. Release é um bom padrão. Sem ele, uma compilação de versão padrão e não otimizada é feita.

Os argumentos de linha de comando -DCMAKE_C_FLAGS e -DCMAKE_CXX_FLAGS podem ser usados ​​para passar argumentos extras para o compilador. Por exemplo, a compilação de 32 bits ou 64 bits pode ser feita definindo -DCMAKE_C(XX)_FLAGS="-m32" ou "-m64" respectivamente. Se não for especificada, a arquitetura nativa da cadeia de ferramentas, normalmente de 64 bits na cadeia de ferramentas de 64 bits, será usada.

Os argumentos -DCMAKE_LIBRARY_PATH e -DCMAKE_INCLUDE_PATH podem ser usados ​​para que o CMake forneça ao CMake uma biblioteca adicional ou inclua caminhos de pesquisa.

Um exemplo de uma linha de comando completa usada para fazer uma compilação de depuração de 32 bits em relação a cabeçalhos de driver e bibliotecas em um local personalizado é o seguinte:

cmake <path to src>/deqp -DDEQP_TARGET=x11_egl -DCMAKE_C_FLAGS="-m32"
-DCMAKE_CXX_FLAGS="-m32" -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_LIBRARY_PATH="PATH_TO_DRIVER/lib"
-DCMAKE_INCLUDE_PATH="PATH_TO_DRIVER/inc"
make -j4

Compilação cruzada

A compilação cruzada pode ser obtida usando um arquivo de cadeia de ferramentas CMake. O arquivo de cadeia de ferramentas especifica o compilador a ser usado, juntamente com caminhos de pesquisa personalizados para bibliotecas e cabeçalhos. Vários arquivos de cadeia de ferramentas para cenários comuns estão incluídos no pacote de lançamento no diretório framework/delibs/cmake .

Além das variáveis ​​padrão do CMake, as seguintes variáveis ​​específicas do deqp podem ser definidas pelo arquivo de cadeia de ferramentas. O CMake geralmente pode detectar DE_OS , DE_COMPILER e DE_PTR_SIZE corretamente, mas DE_CPU deve ser definido pelo arquivo de cadeia de ferramentas.

O arquivo de cadeia de ferramentas pode ser selecionado usando o parâmetro de compilação CMAKE_TOOLCHAIN_FILE . Por exemplo, o seguinte criaria makefiles para uma compilação usando o compilador cruzado CodeSourcery para ARM/Linux:

cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release"
–DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake
–DARM_CC_BASE=PATH_TO_CC_DIRECTORY

Vinculação em tempo de execução de bibliotecas GLES e EGL

O deqp não precisa de pontos de entrada da API em teste durante a vinculação. O código de teste sempre acessa as APIs por meio de ponteiros de função. Os pontos de entrada podem ser carregados dinamicamente em tempo de execução ou a porta da plataforma pode fornecê-los em tempo de link.

Se o suporte para uma API estiver ativado nas configurações de compilação e as bibliotecas de links não forem fornecidas, o deqp carregará os pontos de entrada necessários em tempo de execução. Se a vinculação estática for desejada, forneça as bibliotecas de links necessárias na variável de configuração de construção DEQP_<API>_LIBRARIES .

Portando a estrutura de teste

A portabilidade do deqp envolve três etapas: adaptação de bibliotecas de portabilidade base, implementação de interfaces de integração de plataforma de estrutura de teste e portabilidade do serviço de execução.

A tabela abaixo lista os locais para prováveis ​​alterações de portabilidade. Qualquer coisa além deles provavelmente será exótica.

Bibliotecas básicas de portabilidade

As bibliotecas de portabilidade base já suportam Windows, a maioria das variantes do Linux, Mac OS, iOS e Android. Se o destino de teste for executado em um desses sistemas operacionais, provavelmente não será necessário tocar nas bibliotecas de portabilidade básicas.

Porta da plataforma da estrutura de teste

A porta da plataforma de estrutura de teste deqp requer dois componentes: um ponto de entrada de aplicativo e uma implementação de interface de plataforma.

O ponto de entrada do aplicativo é responsável por criar o objeto de plataforma, criar um objeto de linha de comando ( tcu::CommandLine ), abrir um log de teste ( tcu::TestLog ) e iterar o aplicativo de teste ( tcu::App ). Se o SO de destino suportar um ponto de entrada main() padrão, tcuMain.cpp pode ser usado como a implementação do ponto de entrada.

A API da plataforma deqp é descrita em detalhes nos arquivos a seguir.

A classe base para todas as portas da plataforma é tcu::Platform . A porta da plataforma pode, opcionalmente, suportar interfaces específicas de GL e EGL. Consulte a tabela a seguir para obter uma visão geral do que precisa ser implementado para executar os testes.

Instruções detalhadas para implementar portas de plataforma estão nos cabeçalhos da camada de portabilidade.

Serviço de execução de teste

Para usar a infraestrutura de execução de teste deqp ou o executor de linha de comando, o serviço de execução de teste deve estar disponível no destino. Uma implementação C++ portátil do serviço é fornecida no diretório execserver . O binário autônomo é construído como parte da construção do módulo de teste deqp para destinos de PC. Você pode modificar execserver/CMakeLists.txt para habilitar uma compilação em outros destinos.

A versão C++ do serviço de execução de teste aceita dois parâmetros de linha de comando:

• --port=<port> definirá a porta TCP na qual o servidor escuta. O padrão é 50016.
• --single encerrará o processo do servidor quando o cliente se desconectar. Por padrão, o processo do servidor permanecerá ativo para atender a outras solicitações de execução de teste.

Executando os testes

Esta página fornece instruções para executar testes deqp em ambientes Linux e Windows, usando argumentos de linha de comando e trabalhando com o pacote de aplicativos Android.

Ambientes Linux e Windows

Comece copiando os seguintes arquivos e diretórios para o destino.

Você pode implantar o serviço de execução e testar os binários em qualquer lugar no sistema de arquivos de destino; entretanto, os binários de teste esperam encontrar diretórios de dados no diretório de trabalho atual. Quando estiver pronto, inicie o Serviço de Execução de Teste no dispositivo de destino. Para obter detalhes sobre como iniciar o serviço, consulte Serviço de execução de teste .

Argumentos da linha de comando

A tabela a seguir lista os argumentos de linha de comando que afetam a execução de todos os programas de teste.

Argumentos específicos de GLES2 e GLES3

Formato da lista de casos de teste

A lista de casos de teste pode ser fornecida em dois formatos. A primeira opção é listar o nome completo de cada teste em uma linha separada em um arquivo ASCII padrão. À medida que os conjuntos de teste crescem, os prefixos repetitivos podem ser complicados. Para evitar repetir os prefixos, use uma sintaxe trie (também conhecida como árvore de prefixos) mostrada abaixo.

{nodeName{firstChild{…},…lastChild{…}}}

Por exemplo:

{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}

Traduz nos dois casos de teste a seguir:

dEQP-EGL.config_list
dEQP-EGL.create_context.rgb565_depth_stencil

Android

O pacote do aplicativo Android contém todos os componentes necessários, incluindo o serviço de execução de teste, binários de teste e arquivos de dados. A atividade de teste é uma NativeActivity que usa EGL (requer Android 3.2 ou superior).

O pacote do aplicativo pode ser instalado com o seguinte comando (nome mostrado é o nome do APK no pacote Android CTS; cujo nome depende da compilação):

adb –d install –r com.drawelements.deqp.apk

Para iniciar o serviço de execução de teste e configurar o encaminhamento de porta, use o seguinte:

adb –d forward tcp:50016 tcp:50016
adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter

As impressões de depuração podem ser habilitadas executando o seguinte antes de iniciar os testes:

adb –d shell setprop log.tag.dEQP DEBUG

Executando testes no Android sem Android CTS

Para iniciar manualmente a atividade de execução de teste, construa um intent do Android direcionado a android.app.NativeActivity . As atividades podem ser encontradas no pacote com.drawelements.deqp . A linha de comando deve ser fornecida como uma string extra com a chave "cmdLine" no Intent.

Um log de teste é gravado em /sdcard/dEQP-log.qpa . Se a execução de teste não iniciar normalmente, informações de depuração adicionais estarão disponíveis no log do dispositivo.

Você pode iniciar uma atividade a partir da linha de comando usando o utilitário am . Por exemplo, para executar testes dEQP-GLES2.info em uma plataforma com suporte para NativeActivity, use os comandos a seguir.

adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \
'cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa"'

Depuração no Android

Para executar os testes no depurador GDB no Android, primeiro compile e instale a compilação de depuração executando os dois scripts a seguir:

python android/scripts/build.py --native-build-type=Debug
python android/scripts/install.py

Depois que a compilação de depuração for instalada no dispositivo, para iniciar os testes no GDB em execução no host, execute o seguinte comando:

python android/scripts/debug.py \
--deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"

A linha de comando deqp depende dos casos de teste a serem executados e de outros parâmetros necessários. O script adiciona um ponto de interrupção padrão no início da execução do deqp ( tcu::App::App ).

O script debug.py aceita vários argumentos de linha de comando para ações como definir pontos de interrupção para depuração, parâmetros de conexão gdbserver e caminhos para binários adicionais para depuração (use debug.py --help para todos os argumentos e explicações). O script também copia algumas bibliotecas padrão do dispositivo de destino para obter listagens de símbolos.

Para percorrer o código do driver (como quando o GDB precisa saber os locais dos binários com informações completas de depuração), adicione mais bibliotecas por meio dos parâmetros de linha de comando debug.py . Este script grava um arquivo de configuração para o GDB a partir da linha 132 do arquivo de script. Você pode fornecer caminhos adicionais para binários, etc., mas fornecer parâmetros de linha de comando corretos deve ser suficiente.

Nota: No Windows, o binário GDB requer libpython2.7.dll . Antes de iniciar debug.py , adicione <path-to-ndk>/prebuilt/windows/bin à variável PATH.

Observação: a depuração de código nativo não funciona no Android 4.3; para soluções alternativas, consulte este bug público . O Android 4.4 e superior não contém esse bug.

Automatizando os testes

Os módulos de teste Deqp podem ser integrados a sistemas de teste automatizados de várias maneiras. A melhor abordagem depende da infraestrutura de teste existente e do ambiente de destino.

A saída principal de uma execução de teste é sempre o arquivo de log de teste, ou seja, o arquivo com um postfix .qpa . Os resultados completos do teste podem ser analisados ​​no log de teste. A saída do console é apenas para informações de depuração e pode não estar disponível em todas as plataformas.

Os binários de teste podem ser invocados diretamente de um sistema de automação de teste. O binário de teste pode ser iniciado para um caso específico, para um conjunto de teste ou para todos os testes disponíveis. Se ocorrer um erro fatal durante a execução (como certos erros de API ou uma falha), a execução do teste será abortada. Para testes de regressão, a melhor abordagem é invocar os binários de teste para casos individuais ou pequenos conjuntos de teste separadamente, para ter resultados parciais disponíveis mesmo em caso de falha grave.

O deqp vem com ferramentas de execução de teste de linha de comando que podem ser usadas em combinação com o serviço de execução para obter uma integração mais robusta. O executor detecta o término do processo de teste e retomará a execução do teste no próximo caso disponível. Um único arquivo de log é produzido a partir da sessão de teste completa. Essa configuração é ideal para sistemas de teste leves que não fornecem recursos de recuperação de falhas.

Ferramentas de execução de teste de linha de comando

O conjunto de ferramentas de linha de comando atual inclui uma ferramenta de execução de teste remoto, um gerador de comparação de log de teste para análise de regressão, um conversor de log de teste para CSV, um conversor de log de teste para XML e um conversor de log de teste para JUnit .

O código-fonte para essas ferramentas está no diretório executor e os binários estão embutidos no <builddir>/executor .

Executor de teste de linha de comando

A linha de comando Test Executor é uma ferramenta C++ portátil para iniciar uma execução de teste em um dispositivo e coletar os logs resultantes dele por meio de TCP/IP. O Executor se comunica com o serviço de execução (execserver) no dispositivo de destino. Juntos, eles fornecem funcionalidades como recuperação de falhas no processo de teste. Os exemplos a seguir demonstram como usar o Test Executor de linha de comando (use --help para obter mais detalhes):

Exemplo 1: execute testes funcionais GLES2 em um dispositivo Android:

executor --connect=127.0.0.1 --port=50016 --binaryname=
com.drawelements.deqp/android.app.NativeActivity
--caselistdir=caselists
--testset=dEQP-GLES2.* --out=BatchResult.qpa
--cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable
--deqp-gl-config-name=rgba8888d24s8"

Exemplo 2: Continuar um teste parcial do OpenGL ES 2 localmente:

executor --start-server=execserver/execserver --port=50016
--binaryname=deqp-gles2 --workdir=modules/opengl
--caselistdir=caselists
--testset=dEQP-GLES2.* --exclude=dEQP-GLES2.performance.* --in=BatchResult.qpa
--out=BatchResult.qpa

Teste a exportação de log CSV e compare

O deqp possui uma ferramenta para converter logs de teste (arquivos qpa ) em arquivos CSV. A saída CSV contém uma lista de casos de teste e seus resultados. A ferramenta também pode comparar dois ou mais resultados de lote e listar apenas os casos de teste que possuem códigos de status diferentes nos resultados de lote de entrada. A comparação também imprimirá o número de casos correspondentes.

A saída em formato CSV é muito prática para processamento posterior com utilitários de linha de comando padrão ou com um editor de planilhas. Um formato de texto simples adicional, legível por humanos, pode ser selecionado usando o seguinte argumento de linha de comando: --format=text

Exemplo 1: Exportar registro de teste no formato CSV

testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv

Exemplo 2: listar diferenças de resultados de teste entre dois logs de teste

testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

Observação: o argumento --value=code gera o código do resultado do teste, como "Aprovado" ou "Reprovado". O argumento --value=details seleciona a explicação adicional do resultado ou valor numérico produzido por um teste de desempenho, capacidade ou precisão.

Exportação XML de log de teste

Os arquivos de log de teste podem ser convertidos em documentos XML válidos usando o testlog-to-xml . Dois modos de saída são suportados:

• Modo de documentos separados, em que cada caso de teste e o documento de resumo caselist.xml são gravados em um diretório de destino
• Modo de arquivo único, em que todos os resultados no arquivo .qpa são gravados em um único documento XML.

Os arquivos de log de teste exportados podem ser visualizados em um navegador usando uma folha de estilo XML. Documentos de folha de estilo de amostra ( testlog.xsl e testlog.css ) são fornecidos no diretório doc/testlog-stylesheet . Para renderizar os arquivos de log em um navegador, copie os dois arquivos de folha de estilo no mesmo diretório em que os documentos XML exportados estão localizados.

Se você estiver usando o Google Chrome, os arquivos devem ser acessados ​​por HTTP, pois o Chrome limita o acesso local a arquivos por motivos de segurança. A instalação padrão do Python inclui um servidor HTTP básico que pode ser iniciado para servir o diretório atual com o comando python –m SimpleHTTPServer 8000 . Após iniciar o servidor, basta apontar o navegador Chrome para http://localhost:8000 para visualizar o log de teste.

Conversão para um log de teste JUnit

Muitos sistemas de automação de teste podem gerar relatórios de resultados de execução de teste a partir da saída JUnit. Os arquivos de log de teste deqp podem ser convertidos para o formato de saída JUnit usando a ferramenta testlog-to-junit.

Atualmente, a ferramenta suporta apenas a tradução do veredicto do caso de teste. Como JUnit suporta apenas resultados de "passagem" e "reprovação", um resultado de passagem do deqp é mapeado para "passagem de JUnit" e outros resultados são considerados falhas. O código de resultado do deqp original está disponível na saída JUnit. Outros dados, como mensagens de log e imagens de resultados, não são preservados na conversão.

Usando grupos de teste especiais

Alguns grupos de teste podem precisar ou oferecer suporte a opções de linha de comando especiais ou exigir cuidados especiais quando usados ​​em determinados sistemas.

Testes de estresse de alocação de memória

Os testes de estresse de alocação de memória exercitam condições de falta de memória alocando repetidamente determinados recursos até que o driver relate um erro de falta de memória.

Em determinadas plataformas, como o Android e a maioria das variantes do Linux, pode ocorrer o seguinte: O sistema operacional pode encerrar o processo de teste em vez de permitir que um driver manipule ou forneça um erro de falta de memória. Nessas plataformas, os testes projetados para causar erros de falta de memória são desabilitados por padrão e devem ser habilitados usando o argumento de linha de comando --deqp-test-oom=enable . É recomendável executar esses testes manualmente para verificar se o sistema se comporta corretamente sob pressão de recursos. No entanto, em tal situação, uma falha no processo de teste deve ser interpretada como uma aprovação.

Grupos de teste

dEQP-GLES2.stress.memory.*
dEQP-GLES3.stress.memory.*

Testes de estresse de renderização de longa duração

Os testes de estresse de renderização são projetados para revelar problemas de robustez sob carga de renderização sustentada. Por padrão, os testes executarão apenas algumas iterações, mas podem ser configurados para serem executados indefinidamente fornecendo o argumento de linha de comando --deqp-test-iteration-count=-1 . O watchdog de teste deve ser desabilitado ( --deqp-watchdog=disable ) ao executar esses testes por um longo período de tempo.

Grupos de teste

dEQP-GLES2.stress.long.*
dEQP-GLES3.stress.long.*