Teste do programa de qualidade drawElements

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 ramificação deqp-dev . Para código que corresponda a uma versão específica do Android CTS, use o branch release-code-name -release (por exemplo, para Android 6.0, use o branch marshmallow-release ).

Layout de origem

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

Diretório Descrição
android

Fontes de teste do Android e scripts de construção

data

Arquivos de dados de teste

modules

Fontes do módulo de teste

modules/egl

Módulo EGL

modules/gles2

Módulo GLES2

modules/gles3

Módulo GLES3

modules/gles31

Módulo GLES3.1

modules/gles32

Módulo GLES3.2

targets

Arquivos de configuração de compilação específicos do destino

framework

estrutura e utilitários do módulo de teste deqp

framework/delibs

Portabilidade básica e construção de bibliotecas

framework/platform

Portas de plataforma

framework/qphelper

Biblioteca de integração do programa de teste (C)

framework/common

Estrutura Deqp (C++)

framework/opengl, framework/egl

Utilitários específicos da API

execserver

Fonte ExecServer do lado do dispositivo

executor

Ferramenta e utilitários de shell do executor de teste do lado do host

external

Construir diretório stub para bibliotecas externas libpng e zlib

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] .

Crie programas de teste

A estrutura de teste foi projetada tendo em mente a 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 compilação CMake

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

CMake é um sistema de construção de código aberto que suporta múltiplas plataformas e conjuntos de ferramentas. 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 .

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 alvo "distclean", portanto a remoção de quaisquer arquivos gerados 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.

Opção de configuração Descrição
DEQP_TARGET

Nome de destino, por exemplo: "android"

Os scripts deqp CMake incluirão o arquivo targets/ DEQP_TARGET / DEQP_TARGET .cmake e esperarão encontrar opções de construção específicas do destino a partir daí.

CMAKE_TOOLCHAIN_FILE

Caminho para o arquivo do conjunto de ferramentas do CMake. Usado para compilação cruzada.

CMAKE_BUILD_TYPE

Tipo de compilação para destinos makefile. Os valores válidos são: "Debug" e "Release"

Observe que a interpretação e o tipo padrão dependem do sistema de compilação de destino. Consulte a documentação do CMake para obter detalhes.

Crie 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 construçã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 construção de destino.

Variável Descrição
DEQP_TARGET_NAME

Nome do destino (será incluído nos logs de teste)

DEQP_SUPPORT_GLES2

Se GLES2 é compatível (padrão: OFF)

DEQP_GLES2_LIBRARIES

Bibliotecas GLES2 (deixe em branco se não for compatível ou se for usado carregamento dinâmico)

DEQP_SUPPORT_GLES3

Se GLES3.x é compatível (padrão: OFF)

DEQP_GLES3_LIBRARIES

Bibliotecas GLES3.x (deixe em branco se não for compatível ou se o carregamento dinâmico for usado)

DEQP_SUPPORT_VG

Se o OpenVG é compatível (padrão: OFF)

DEQP_OPENVG_LIBRARIES

Bibliotecas OpenVG (deixe em branco se não for compatível ou se for usado carregamento dinâmico)

DEQP_SUPPORT_EGL

Se EGL é compatível (padrão: OFF)

DEQP_EGL_LIBRARIES

Bibliotecas EGL (deixe em branco se não for compatível ou se o carregamento dinâmico for usado)

DEQP_PLATFORM_LIBRARIES

Bibliotecas adicionais específicas da plataforma necessárias para vinculação

DEQP_PLATFORM_COPY_LIBRARIES

Lista de bibliotecas que são copiadas para cada diretório de construção binário de teste. Pode ser usado para copiar bibliotecas necessárias para a execução de testes, mas que não estão no caminho de pesquisa padrão.

TCUTIL_PLATFORM_SRCS

Lista de origem de portas da plataforma. As fontes padrão são determinadas com base nos recursos e no sistema operacional.

Nota: Os caminhos são relativos a: framework/platform

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

Compilação Win32

A maneira mais fácil de construir 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 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 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" ).

Renderizar criação de contexto

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

Suporte WGL

Todos os binários 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 ativado. 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 Android

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

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

  • 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 determinados padrões de substituição. A lógica é controlada por android/scripts/common.py .

O diretório 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 dispositivo Deqp, 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 via ADB. Os scripts podem ser executados a partir de qualquer diretório.

Compilação Linux

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

Criar alvo Descrição
default

Destino padrão que usa a introspecção da plataforma CMake para determinar o suporte para várias APIs.

x11_glx

Usa GLX para criar contextos OpenGL (ES).

x11_egl

Usa EGL para criar contextos OpenGL (ES).

x11_egl_glx

Suporta GLX e EGL com X11.

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

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 ou 64 bits pode ser feita definindo -DCMAKE_C(XX)_FLAGS="-m32" ou "-m64" respectivamente. Se não for especificado, 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 o CMake fornecer biblioteca adicional ao CMake ou incluir caminhos de pesquisa.

Um exemplo de linha de comando completa usada para fazer uma compilação de depuração de 32 bits em 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 conjunto de ferramentas CMake. O arquivo do conjunto de ferramentas especifica o compilador a ser usado, juntamente com caminhos de pesquisa customizados para bibliotecas e cabeçalhos. Vários arquivos do conjunto 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 configuradas pelo arquivo do conjunto de ferramentas. O CMake geralmente pode detectar DE_OS , DE_COMPILER e DE_PTR_SIZE corretamente, mas DE_CPU deve ser definido pelo arquivo do conjunto de ferramentas.

Variável Descrição
DE_OS

Sistema operacional. Os valores suportados são: DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS

DE_COMPILER

Tipo de compilador. Os valores suportados são: DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG

DE_CPU

Tipo de CPU. Os valores suportados são: DE_CPU_ARM, DE_CPU_X86 .

DE_PTR_SIZE

sizeof(void*) na plataforma. Os valores suportados são: 4 e 8

O arquivo da cadeia de ferramentas pode ser selecionado usando o parâmetro de construçã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 então 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 .

Portar a estrutura de teste

A portabilidade do deqp envolve três etapas: adaptação de bibliotecas de portabilidade básica, 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.

Localização Descrição
framework/delibs/debase
framework/delibs/dethread
framework/delibs/deutil

Quaisquer implementações necessárias de código específico do sistema operacional.

framework/qphelper/qpCrashHandler.c

Opcional: Implementação para seu sistema operacional.

framework/qphelper/qpWatchDog.c

Implementação para seu sistema operacional. O atual é baseado em dethread e biblioteca C padrão.

framework/platform

A nova porta da plataforma e o stub do aplicativo podem ser implementados conforme descrito em Porta da plataforma da estrutura de teste .

Bibliotecas de portabilidade básica

As bibliotecas básicas de portabilidade já suportam Windows, a maioria das variantes do Linux, Mac OS, iOS e Android. Se o alvo do teste for executado em um desses sistemas operacionais, provavelmente não haverá necessidade de mexer nas bibliotecas básicas de portabilidade.

Porta da plataforma da estrutura de teste

A porta da plataforma da estrutura 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 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 sistema operacional de destino suportar um ponto de entrada main() padrão, tcuMain.cpp poderá ser usado como implementação do ponto de entrada.

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

Arquivo Descrição
framework/common/tcuPlatform.hpp

Classe base para todas as portas da plataforma

framework/opengl/gluPlatform.hpp

Interface da plataforma OpenGL

framework/egl/egluPlatform.hpp

Interface da plataforma EGL

framework/platform/tcuMain.cpp

Ponto de entrada padrão do aplicativo

A classe base para todas as portas da plataforma é tcu::Platform . A porta da plataforma pode suportar opcionalmente 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.

Módulo Interface

Módulos de teste OpenGL (ES)

Interface da plataforma GL

Módulo de teste EGL

Interface da plataforma EGL

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 independente é construído como parte da construção do módulo de teste deqp para destinos de PC. Você pode modificar execserver/CMakeLists.txt para ativar 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 outras solicitações de execução de teste.

Execute 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.

Módulo Diretório Alvo
Servidor de Execução build/execserver/execserver <dst>/execserver
Módulo EGL build/modules/egl/deqp-egl <dst>/deqp-egl
Módulo GLES2 build/modules/gles2/deqp-gles2 <dst>/deqp-gles2
data/gles2 <dst>/gles2
Módulo GLES3 build/modules/gles3/deqp-gles3 <dst>/deqp-gles3
data/gles3 <dst>/gles3
Módulo GLES3.1 build/modules/gles31/deqp-gles31 <dst>/deqp-gles31
data/gles31 <dst>/gles31
Módulo GLES3.2 build/modules/gles32/deqp-gles32 <dst>/deqp-gles32
data/gles32 <dst>/gles32

Você pode implementar o serviço de execução e testar binários em qualquer lugar do 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 Test Execution Service no dispositivo de destino. Para obter detalhes sobre como iniciar o serviço, consulte Serviço de execução de teste .

Argumentos de linha de comando

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

Argumento Descrição
--deqp-case=<casename> Execute casos que correspondam a um determinado padrão. Curinga (*) é suportado.
--deqp-log-filename=<filename> Grave os resultados do teste no arquivo cujo nome você fornece. O serviço de execução de teste definirá o nome do arquivo ao iniciar um teste.
--deqp-stdin-caselist
--deqp-caselist=<caselist>
--deqp-caselist-file=<filename>
Leia a lista de casos do stdin ou de um determinado argumento. O serviço de execução de teste definirá o argumento de acordo com a solicitação de execução recebida. Consulte a próxima seção para obter uma descrição do formato da lista de casos.
--deqp-test-iteration-count=<count> Substitua a contagem de iterações para testes que suportam um número variável de iterações.
--deqp-base-seed=<seed> Semente base para os casos de teste que usam randomização.

Argumentos específicos do GLES2 e GLES3

A tabela a seguir lista os argumentos específicos do GLES2 e GLES3.
Argumento Descrição
--deqp-gl-context-type=<type> Tipo de contexto OpenGL. Os tipos de contexto disponíveis dependem da plataforma. Em plataformas que suportam EGL, o valor egl pode ser usado para selecionar o contexto EGL.
--deqp-gl-config-id=<id> Execute testes para o ID de configuração GL fornecido. A interpretação depende da plataforma. Na plataforma EGL, este é o ID de configuração do EGL.
--deqp-gl-config-name=<name> Execute testes para uma configuração GL nomeada. A interpretação depende da plataforma. Para EGL, o formato é rgb(a)<bits>d<bits>s<bits> . Por exemplo, um valor rgb888s8 selecionará a primeira configuração onde o buffer de cores é RGB888 e o buffer de estêncil possui 8 bits.
--deqp-gl-context-flags=<flags> Cria um contexto. Especifique robust ou debug .
--deqp-surface-width=<width>
--deqp-surface-height=<height>
Tente criar uma superfície com um determinado tamanho. O suporte para isso é opcional.
--deqp-surface-type=<type> Use um determinado tipo de superfície como principal alvo de renderização de teste. Os tipos possíveis são window , pixmap , pbuffer e fbo .
--deqp-screen-rotation=<rotation> Orientação da tela em incrementos de 90 graus para plataformas que a suportam.

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 complicados. Para evitar a repetição dos 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-se nos dois casos de teste a seguir:

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

Android

O pacote de aplicativos 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 (o 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

Execute testes no Android sem Android CTS

Para iniciar manualmente a atividade de execução de teste, crie uma intent Android direcionada 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 do teste não iniciar normalmente, informações adicionais de depuração 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 que suporta 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 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 do 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 a localização 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 começando na 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 padrão; para soluções alternativas, consulte este bug público . O Android 4.4 e superior não contém esse bug.

Automatize os testes

Os módulos de teste Deqp podem ser integrados a sistemas de teste automatizados de diversas 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 contém apenas 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 testes 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 testes 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 obter uma integração mais robusta. O executor detecta o encerramento 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 oferecem recursos 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 remota de teste, 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 testlog 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 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 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 de 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 do 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 log de teste em 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

Nota: 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 do log de teste

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

  • Modo de documentos separados, onde cada caso de teste e o documento de resumo caselist.xml são gravados em um diretório de destino
  • Modo de arquivo único, onde 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 onde os documentos XML exportados estão localizados.

Se você estiver usando o Google Chrome, os arquivos deverão ser acessados ​​por HTTP, pois 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 . 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.

A ferramenta atualmente oferece suporte à tradução apenas do veredicto do caso de teste. Como o JUnit suporta apenas resultados "aprovado" e "reprovado", um resultado aprovado do deqp é mapeado para "aprovado JUnit" e outros resultados são considerados falhas. O código de resultado 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.

Use grupos de teste especiais

Alguns grupos de teste podem precisar ou suportar opções especiais de linha de comando 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 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 lide 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.*