Testes do programa de qualidade do drawElements

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O AOSP inclui o pacote de testes de GPU do 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 ramificação deqp-dev. Para um código que corresponde a uma versão específica do CTS do Android, use a filial release-code-name-release (por exemplo, para o Android 6.0, use a filial 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 lista não é abrangente, mas destaca os diretórios mais importantes.

Componentes de código aberto

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

Criar programas de teste

O framework de teste foi projetado pensando na portabilidade. 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 build do CMake

As origens deqp têm scripts de build para o CMake, que é a ferramenta preferida para compilar os programas de teste.

O CMake é um sistema de build de código aberto que oferece suporte a várias plataformas e toolchains. O CMake gera arquivos de makefiles nativos ou arquivos de projeto do IDE a partir de arquivos de configuração independentes da meta. Para mais informações sobre o CMake, consulte a documentação do CMake (link em inglês).

O CMake oferece suporte e recomenda builds fora da árvore de origem, ou seja, você precisa sempre criar arquivos de make ou de projeto em um diretório de build separado fora da árvore de origem. O CMake não tem nenhum tipo de destino "distclean". Portanto, a remoção de arquivos gerados pelo CMake precisa ser feita manualmente.

As opções de configuração são fornecidas ao CMake usando a sintaxe -DOPTION_NAME=VALUE. Confira abaixo algumas opções de deqp usadas com frequência.

Criar um arquivo de build de destino

O sistema de build deqp é configurado para novos destinos usando arquivos de build de destino. Um arquivo de build de destino define quais recursos a plataforma oferece suporte 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 build DEQP_TARGET.

Os caminhos dos arquivos de destino são relativos ao diretório deqp base, não ao diretório targets/NAME. As variáveis padrão a seguir podem ser definidas pelo arquivo de build de destino.

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

Build do Win32

A maneira mais fácil de criar módulos deqp para Windows é usar o sistema de build do CMake. Você vai 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"

Um build de 64 bits pode ser feito selecionando "Visual Studio VERSION Win64" como o gerador de build:

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

Também é possível gerar arquivos de make do NMake com a opção -G "NMake Makefiles", bem como o tipo de build (-DCMAKE_BUILD_TYPE="Debug" ou "Release").

Renderização da criação de contexto

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

Suporte a WGL

Todos os binários do Win32 oferecem suporte à criação de contexto GL com WGL, já que exigem 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 do OpenGL ES. Isso foi testado para funcionar com os drivers mais recentes da NVIDIA e da Intel. Os drivers AMD não são compatíveis com a extensão necessária.

Suporte ao EGL

O deqp é criado com o carregamento dinâmico para EGL no Windows se DEQP_SUPPORT_EGL estiver ATIVADO. Esse é o padrão na maioria dos destinos. Em seguida, se o host tiver bibliotecas EGL disponíveis, será possível executar testes com elas usando o parâmetro de linha de comando: --deqp-gl-context-type=egl

Versão do Android

O build do Android usa scripts de build do CMake para criar o código de teste nativo. As partes Java, ou seja, o servidor de execução de teste e o stub do aplicativo de teste, são compiladas usando as ferramentas de build padrão do Android.

Para compilar programas de teste deqp para Android com os scripts de build fornecidos, você vai precisar de:

• A versão mais recente do Android NDK. O arquivo android/scripts/common.py lista a versão necessária.
• SDK independente do Android com API 13, SDK Tools, SDK Platform-tools e SDK Build-tools pacotes instalados
• Apache Ant 1.9.4 (requerido pelo build de código Java)
• CMake 2.8.12 ou mais recente
• Python 2.6 ou mais recente na série 2.x. Não há suporte para Python 3.x
• No Windows: NMake ou JOM em PATH
  • O JOM permite builds mais rápidos
• Opcional: o Ninja make também tem suporte para Linux

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

O diretório do NDK precisa ser ~/android-ndk-VERSION ou C:/android/android-ndk-VERSION ou definido pela 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 script 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 pelo ADB. Os scripts podem ser executados em qualquer diretório.

Build do Linux

É possível criar binários de teste e utilitários de linha de comando para Linux gerando arquivos de make usando o CMake. Há vários destinos de build predefinidos que são úteis ao criar para Linux.

Sempre use -DCMAKE_BUILD_TYPE=<Debug|Release> para definir o tipo de build. Release é um bom padrão. Sem ele, um build de lançamento padrão não otimizado é criado.

Os argumentos de linha de comando -DCMAKE_C_FLAGS e -DCMAKE_CXX_FLAGS podem ser usados para transmitir argumentos extras ao compilador. Por exemplo, o build de 32 bits ou 64 bits pode ser feito definindo -DCMAKE_C(XX)_FLAGS="-m32" ou "-m64", respectivamente. Se não for especificado, a arquitetura nativa da cadeia de ferramentas, normalmente 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 uma biblioteca adicional ou inclua caminhos de pesquisa.

Um exemplo de uma linha de comando completa usada para fazer um build de depuração de 32 bits em cabeçalhos e bibliotecas de driver 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 feita usando um arquivo do conjunto de ferramentas do CMake. O arquivo de cadeia de ferramentas especifica o compilador a ser usado, além de caminhos de pesquisa personalizados para bibliotecas e cabeçalhos. Vários arquivos de toolchain para cenários comuns sã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 do conjunto de ferramentas. O CMake geralmente pode detectar DE_OS, DE_COMPILER e DE_PTR_SIZE corretamente, mas DE_CPU precisa ser definido pelo arquivo do conjunto de ferramentas.

O arquivo de toolchain pode ser selecionado usando o parâmetro de build CMAKE_TOOLCHAIN_FILE. Por exemplo, o comando a seguir criaria arquivos de make para um build 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 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 ponteiros de função. Os pontos de entrada podem ser carregados dinamicamente no momento da execução ou a porta da plataforma pode fornecê-los no momento da vinculação.

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

Portar o framework de teste

A portabilidade do deqp envolve três etapas: adaptar bibliotecas de portabilidade de base, implementar interfaces de integração de plataforma de framework de teste e migrar o serviço de execução.

A tabela abaixo lista os locais com mudanças de portabilidade prováveis. Qualquer coisa além disso provavelmente será exótica.

Bibliotecas de portabilidade básicas

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

Porta da plataforma do framework de teste

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

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

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

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

As 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 precisa estar disponível no destino. Uma implementação portátil do C++ do serviço é fornecida no diretório execserver. O binário independente é criado como parte do build do módulo de teste deqp para destinos de PC. É possível modificar execserver/CMakeLists.txt para ativar um build em outras metas.

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

• --port=<port> define a porta TCP em que o servidor detecta atividade. O padrão é 50016.
• --single encerrará o processo do servidor quando o cliente se desconectar. Por padrão, o processo do servidor permanece ativo para atender a outras solicitações de execução de teste.

Executar 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 aplicativo Android.

Ambientes Linux e Windows

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

É possível implantar o serviço de execução e testar binários em qualquer lugar no sistema de arquivos de destino. No entanto, os binários de teste esperam encontrar diretórios de dados no diretório de trabalho atual. Quando estiver tudo pronto, inicie o serviço de execução de teste no dispositivo de destino. Para saber mais sobre como iniciar o serviço, consulte Serviço de execução de teste.

Argumentos de linha de comando

A tabela a seguir lista os argumentos da 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 testes crescem, os prefixos repetitivos podem ser incômodos. Para evitar a repetição dos prefixos, use uma sintaxe de trie (também conhecida como árvore de prefixos) mostrada abaixo.

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

Exemplo:

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

Isso se traduz nos dois casos de teste a seguir:

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

Android

O pacote de 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 é um NativeActivity que usa EGL (requer o Android 3.2 ou mais recente).

O pacote do aplicativo pode ser instalado com o comando abaixo (o nome exibido é o nome do APK no pacote do Android CTS, que depende do build):

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

Para iniciar o serviço de execução de teste e configurar o encaminhamento de portas, 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 ativadas executando o seguinte antes de iniciar os testes:

adb –d shell setprop log.tag.dEQP DEBUG

Executar testes no Android sem o Android CTS

Para iniciar manualmente a atividade de execução do teste, crie uma intent do Android que tenha como destino android.app.NativeActivity. As atividades podem ser encontradas no pacote com.drawelements.deqp. A linha de comando precisa ser fornecida como uma string extra com a chave "cmdLine" na intent.

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

É possível iniciar uma atividade na linha de comando usando o utilitário am. Por exemplo, para executar testes dEQP-GLES2.info em uma plataforma que ofereça suporte a 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"'

Depurar no Android

Para executar os testes no depurador GDB no Android, primeiro compile e instale o build 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 o build de depuração for instalado 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 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 do gdbserver e caminhos para outros binários a serem depurados (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 receber listagens de símbolos.

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

Observação:no Windows, o binário do GDB requer libpython2.7.dll. Antes de iniciar o 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 padrão. Para soluções alternativas, consulte este bug público. O Android 4.4 e versões mais recentes não contêm esse bug.

Automatizar os testes

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

A saída principal de uma execução de teste é sempre o arquivo de registro de teste, ou seja, o arquivo com um sufixo .qpa. Os resultados completos do teste podem ser analisados no registro 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 testes. O binário de teste pode ser iniciado para um caso específico, para um conjunto de testes ou para todos os testes disponíveis. Se ocorrer um erro fatal durante a execução (como determinados erros de API ou uma falha), a execução do teste será interrompida. 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 no 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 conseguir uma integração mais robusta. O executor detecta o encerramento do processo de teste e retoma a execução do teste no próximo caso disponível. Um único arquivo de registro é produzido a partir da sessão de teste completa. Essa configuração é ideal para sistemas de teste leves que não oferecem facilidades de recuperação de falhas.

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

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

O código-fonte dessas ferramentas está no diretório executor, e os binários são criados no diretório <builddir>/executor.

Executor de teste de linha de comando

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

Exemplo 1: executar testes funcionais do 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 uma execução parcial de teste 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

Testar a exportação de CSV de registro e comparar

O deqp tem 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 os respectivos resultados. A ferramenta também pode comparar dois ou mais resultados de lote e listar apenas os casos de teste que têm códigos de status diferentes nos resultados de lote de entrada. A comparação também vai mostrar o número de casos correspondentes.

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

Exemplo 1: exportar o 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 as diferenças nos resultados de dois registros 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 "Pass" ou "Fail". O argumento --value=details seleciona a explicação adicional do resultado ou do valor numérico produzido por um teste de desempenho, capacidade ou precisão.

Testar a exportação de registro em XML

Os arquivos de registro de teste podem ser convertidos em documentos XML válidos usando o utilitário testlog-to-xml. Há dois modos de saída compatíveis:

• 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 registro de teste exportados podem ser visualizados em um navegador usando uma folha de estilo XML. Documentos de exemplo de folha de estilo (testlog.xsl e testlog.css) são fornecidos no diretório doc/testlog-stylesheet. Para renderizar os arquivos de registro em um navegador, copie os dois arquivos de folha de estilo para o mesmo diretório em que os documentos XML exportados estão localizados.

Se você estiver usando o Google Chrome, os arquivos precisarão ser acessados por HTTP, já que o Chrome limita o acesso a arquivos locais 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. Depois de iniciar o servidor, basta apontar o navegador Chrome para http://localhost:8000 para conferir o registro de teste.

Conversão em um registro de teste do JUnit

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

No momento, a ferramenta só oferece suporte à tradução do veredito do caso de teste. Como o JUnit oferece suporte apenas a resultados "pass" e "fail", um resultado de aprovação do deqp é mapeado para "JUnit pass", e outros resultados são considerados falhas. O código de resultado original do deqp está disponível na saída do JUnit. Outros dados, como mensagens de registro e imagens de resultados, não são preservados na conversão.

Usar 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 ao serem 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 informe um erro de falta de memória.

Em determinadas plataformas, como o Android e a maioria das variantes do Linux, o seguinte pode ocorrer: o sistema operacional pode encerrar o processo de teste em vez de permitir que um driver processe 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 desativados por padrão e precisam ser ativados 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 uma situação como essa, uma falha do processo de teste precisa 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 executam 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 precisa ser desativado (--deqp-watchdog=disable) ao executar esses testes por um longo período.

Grupos de teste

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