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
|
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: |
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.pylista 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_COMPILER |
Tipo de compilador. Os valores aceitos são: |
DE_CPU |
Tipo de CPU. Os valores aceitos são: |
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 |
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 |
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
--singleencerra 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 |
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> |
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:50016adb –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=Debugpython 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.csvtestlog-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.xmlsão gravados em um diretório de destino. - Modo de arquivo único, em que todos os resultados no arquivo
.qpasã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.*