Testes do programa de qualidade do drawElements

O AOSP inclui o pacote de testes de GPU do programa de qualidade drawElements (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 a ramificação release-code-name-release (por exemplo, para o Android 6.0, use a ramificação 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 lista não é abrangente, mas destaca os diretórios mais importantes.

Diretório Descrição
android

Fontes e scripts de build do testador do Android

data

Arquivos de dados de teste

modules

Testar origens de módulos

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 build específicos da plataforma de destino

framework

Framework e utilitários do módulo de teste deqp.

framework/delibs

Portabilidade de base e bibliotecas de build

framework/platform

Portas da plataforma

framework/qphelper

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

framework/common

Framework deqp (C++)

framework/opengl, framework/egl

Utilitários específicos da API

execserver

Fonte do ExecServer do lado do dispositivo

executor

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

external

Criar diretório stub para as bibliotecas externas libpng e zlib

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 via 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, linhas de execução e sockets.

Sistema de build do CMake

As fontes deqp têm scripts de build para 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 cadeias de ferramentas. O CMake gera makefiles nativos ou arquivos de projeto de IDE com base em arquivos de configuração independentes do destino. Para mais informações sobre o CMake, consulte a documentação do CMake (em inglês).

O CMake oferece suporte e recomenda builds fora da árvore de origem. Ou seja, você sempre deve criar makefiles ou arquivos de projeto em um diretório de build separado fora da árvore de origem. O CMake não tem nenhum tipo de destino "distclean", então 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 usadas com frequência para o deqp.

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

Nome do destino. Por exemplo: "android"

Os scripts CMake do deqp incluem o arquivo targets/DEQP_TARGET/DEQP_TARGET.cmake e esperam encontrar opções de build específicas do destino nele.

CMAKE_TOOLCHAIN_FILE

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

CMAKE_BUILD_TYPE

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

A interpretação e o tipo padrão dependem do sistema de build segmentado. Consulte a documentação do CMake para mais detalhes.

Criar um arquivo de build de destino

O sistema de build do 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 de arquivo nos arquivos de destino são relativos ao diretório base deqp, não ao diretório targets/NAME. As seguintes variáveis padrão podem ser definidas pelo arquivo de build de destino.

Variável Descrição
DEQP_TARGET_NAME

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

DEQP_SUPPORT_GLES2

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

DEQP_GLES2_LIBRARIES

Bibliotecas GLES2 (deixe em branco se não houver suporte ou se o carregamento dinâmico for usado)

DEQP_SUPPORT_GLES3

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

DEQP_GLES3_LIBRARIES

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

DEQP_SUPPORT_VG

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

DEQP_OPENVG_LIBRARIES

Bibliotecas OpenVG (deixe em branco se não houver suporte ou se o carregamento dinâmico for usado)

DEQP_SUPPORT_EGL

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

DEQP_EGL_LIBRARIES

Bibliotecas EGL (deixe em branco se não houver suporte 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 copiadas para cada diretório de build binário de teste. Pode ser usado para copiar bibliotecas necessárias para executar 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 nas capacidades e no SO.

Observação:os caminhos são relativos a: framework/platform

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

Build do Win32

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

Para criar um build de 64 bits, selecione "Visual Studio VERSION Win64" como o gerador de build:

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

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

Criação de contexto de renderização

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

Suporte ao WGL

Todos os binários Win32 são compatíveis com a criação de contexto GL com WGL, já que exigem apenas bibliotecas padrão. O contexto do 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 da AMD não são compatíveis com a extensão necessária.

Suporte ao EGL

O deqp é criado com carregamento dinâmico para EGL no Windows se DEQP_SUPPORT_EGL estiver ATIVADO. Essa é a opçã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

Build do Android

O build do Android usa scripts de build do CMake para criar o código de teste nativo. As partes em 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ê precisa do seguinte:

  • A versão mais recente do NDK do Android. 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 packages instalados
  • Apache Ant 1.9.4 (exigido pela build do código Java)
  • CMake 2.8.12 ou mais recente
  • Python 2.6 ou mais recente na série 2.x. O Python 3.x não é compatível.
  • No Windows: NMake ou JOM em PATH
    • O JOM permite builds mais rápidos
  • Opcional: o Ninja make também é compatível com o Linux.

Os binários do Ant e do SDK 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 no dispositivo do deqp, o serviço de execução de testes 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 em qualquer diretório.

Build do Linux

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

Destino de build Descrição
default

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

x11_glx

Usa GLX para criar contextos OpenGL (ES).

x11_egl

Usa EGL para criar contextos do OpenGL (ES).

x11_egl_glx

Compatível com GLX e EGL com X11.

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

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 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, geralmente 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 caminhos de pesquisa de inclusão ou biblioteca adicionais.

Confira a seguir um exemplo de uma linha de comando completa usada para fazer um build de depuração de 32 bits em relação a cabeçalhos e bibliotecas de driver em um local personalizado:

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 da 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 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 do conjunto de ferramentas. O CMake geralmente detecta DE_OS, DE_COMPILER e DE_PTR_SIZE corretamente, mas DE_CPU precisa ser definido pelo arquivo do conjunto de ferramentas.

Variável Descrição
DE_OS

Sistema operacional. Os valores aceitos 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 aceitos são: DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG

DE_CPU

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

DE_PTR_SIZE

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

O arquivo da cadeia de ferramentas pode ser selecionado usando o parâmetro de build CMAKE_TOOLCHAIN_FILE. Por exemplo, o comando a seguir criaria makefiles para um build usando o cross-compiler 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 das 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 tempo de execução ou a porta da plataforma pode fornecê-los no tempo de vinculação.

Se o suporte a uma API estiver ativado nas configurações de build e as bibliotecas de link não forem fornecidas, o deqp vai carregar os pontos de entrada necessários durante a execução. Se você quiser a vinculação estática, 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 básicas, implementar interfaces de integração de plataforma do framework de teste e portar o serviço de execução.

A tabela abaixo lista locais para possíveis mudanças de portabilidade. Qualquer coisa além disso provavelmente é exótica.

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

Todas as implementações necessárias de código específico do SO.

framework/qphelper/qpCrashHandler.c

Opcional: implementação para seu SO.

framework/qphelper/qpWatchDog.c

Implementação para seu SO. A atual é baseada em dethread e na 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 do framework de teste.

Bibliotecas de portabilidade de base

As bibliotecas de portabilidade básicas já são compatíveis com Windows, a maioria das variantes do Linux, Mac OS, iOS e 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 da interface da plataforma.

O ponto de entrada do aplicativo é responsável por criar o objeto da plataforma, 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, tcuMain.cpp poderá ser usado como a implementação do ponto de entrada.

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

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

Classe base para todas as portas de plataforma

framework/opengl/gluPlatform.hpp

Interface da plataforma OpenGL

framework/egl/egluPlatform.hpp

Interface de plataforma EGL

framework/platform/tcuMain.cpp

Ponto de entrada padrão do aplicativo

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

Módulo Interface

Módulos de teste do OpenGL (ES)

Interface da plataforma GL

Módulo de teste do EGL

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

A versão em 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.
  • O --single encerra o processo do servidor quando o cliente se desconecta. Por padrão, o processo do servidor vai continuar ativo para atender a mais solicitações de execução de teste.

Executar os testes

Nesta página, você encontra 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 Target
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

É possível implantar o serviço de execução e testar binários em qualquer lugar do 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 detalhes sobre como iniciar o serviço, consulte Serviço de execução de testes.

Argumentos de 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.

Argumento Descrição
--deqp-case=<casename> Executa casos que correspondem a um determinado padrão. O caractere curinga (*) é aceito.
--deqp-log-filename=<filename> Grava os resultados do teste no arquivo com o nome fornecido. O serviço de execução de testes define o nome do arquivo ao iniciar um teste.
--deqp-stdin-caselist
--deqp-caselist=<caselist>
--deqp-caselist-file=<filename>
Leia a lista de casos da entrada padrão ou de um argumento específico. O serviço de execução de teste vai definir o argumento de acordo com a solicitação de execução recebida. Consulte a próxima seção para ver uma descrição do formato da lista de casos.
--deqp-test-iteration-count=<count> Substitua a contagem de iterações para testes que aceitam um número variável de iterações.
--deqp-base-seed=<seed> Base de inicialização para os casos de teste que usam randomização.

Argumentos específicos do GLES2 e do GLES3

A tabela a seguir lista os argumentos específicos do GLES2 e do GLES3.
Argumento Descrição
--deqp-gl-context-type=<type> Tipo de contexto do OpenGL. Os tipos de contexto disponíveis dependem da plataforma. Em plataformas que oferecem suporte a EGL, o valor egl pode ser usado para selecionar o contexto EGL.
--deqp-gl-config-id=<id> Executa testes para o ID de configuração do GL fornecido. A interpretação depende da plataforma. Na plataforma EGL, esse é o ID da configuração EGL.
--deqp-gl-config-name=<name> Executa testes para uma configuração nomeada do GL. A interpretação depende da plataforma. Para EGL, o formato é rgb(a)<bits>d<bits>s<bits>. Por exemplo, um valor de rgb888s8 selecionará a primeira configuração em que o buffer de cores é RGB888 e o buffer de estêncil tem 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 tamanho específico. O suporte para isso é opcional.
--deqp-surface-type=<type> Use um determinado tipo de superfície como o principal destino 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 oferecem suporte a ela.

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 se tornar incômodos. Para evitar a repetição dos prefixos, use uma sintaxe de trie (também conhecida como árvore de prefixos), conforme mostrado 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 aplicativos Android contém todos os componentes necessários, incluindo o serviço de execução de testes, os binários de teste e os arquivos de dados. A atividade de teste é um NativeActivity que usa EGL (requer Android 3.2 ou mais recente).

O pacote do aplicativo pode ser instalado com o seguinte comando (o nome mostrado é o nome do APK no pacote CTS do Android, que depende da 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

Para ativar a impressão de depuração, execute o seguinte antes de iniciar os testes:

adb –d shell setprop log.tag.dEQP DEBUG

Executar testes no Android sem o CTS do Android

Para iniciar manualmente a atividade de execução de 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 começar normalmente, mais 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 compatível com 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 versão de depuração executando estes dois scripts:

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, execute o comando abaixo para iniciar os testes no GDB em execução no host:

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 obrigató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 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 listas 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 os parâmetros de linha de comando debug.py. Esse script grava um arquivo de configuração para o GDB a partir da 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 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 tê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 atuais.

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. 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, um conjunto de testes ou todos os testes disponíveis. Se um erro fatal ocorrer 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 testes separadamente, para ter resultados parciais disponíveis mesmo em caso de falha grave.

O deqp vem com ferramentas de execução de testes de linha de comando que podem ser usadas em combinação com o serviço de execução para alcançar 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 com base na 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 testes 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 registros 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 testes da linha de comando

O executor de testes 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 recuperação de falhas no processo de teste. Os exemplos a seguir mostram como usar o executor de testes da 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

Exportação e comparação de CSV de registros de teste

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

A saída no 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 adicional legível por humanos e em texto simples 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 diferenças nos resultados de testes entre 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 valor numérico produzido por um teste de performance, capacidade ou acurácia.

Exportação de XML de registros de teste

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

  • 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. Exemplos de documentos 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 disponibilizar 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 ver o registro de teste.

Conversão para um registro de teste do JUnit

Muitos sistemas de automação de testes podem gerar relatórios de resultados de execução de testes da saída do JUnit. Os arquivos de registro de teste do deqp podem ser convertidos para o formato de saída do 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 aceita apenas 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 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 exercem 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 Android e a maioria das variantes do Linux, o seguinte pode acontecer: 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. Recomendamos executar esses testes manualmente para verificar se o sistema se comporta corretamente sob pressão de recursos. No entanto, em uma situação assim, 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 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.*