O AOSP inclui o pacote de testes de GPU do programa de qualidade (deqp), na https://android.googlesource.com/platform/external/deqp Esta página detalha como implantar o pacote de testes deqp em um novo ambiente.
Para trabalhar com o código enviado mais recentemente, use a ramificação deqp-dev.
Para códigos que correspondam a uma versão específica do CTS do Android, 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 para os módulos de teste deqp e bibliotecas de suporte é mostrados na tabela abaixo (a listagem não está completa, mas destaca as mais importantes).
| Diretório | Descrição |
|---|---|
android |
Origens e scripts de build do Android Tester |
data |
Arquivos de dados de teste |
modules |
Origens dos módulos 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 do build específicos 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 |
Testar a biblioteca de integração do programa (C) |
framework/common |
Framework do Deqp (C++) |
framework/opengl, framework/egl |
Utilitários específicos da API |
execserver |
Origem do ExecServer no lado do dispositivo |
executor |
Ferramenta e utilitários do shell do executor de teste do lado do host |
external |
Diretório de stub de build para 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
A estrutura de teste foi projetada com foco na portabilidade. O único requisitos obrigatórios são compatibilidade total com C++ e bibliotecas padrão do sistema para E/S, linhas de execução e soquetes.
Sistema de build CMake
As origens do deqp têm scripts de build para o CMake, que é a ferramenta recomendada para e compilar os programas de teste.
O CMake é um sistema de build de código aberto compatível com várias plataformas e de última geração. O CMake gera makefiles nativos ou arquivos de projeto do ambiente de desenvolvimento integrado de de configuração independentes de destino. Para saber mais sobre o CMake, acesse documentação do CMake.
O CMake oferece suporte e recomenda builds de árvore de origem, ou seja, você precisa sempre 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 alvo, então a remoção de todos os arquivos gerados pelo CMake precisa ser feita manualmente.
As opções de configuração são fornecidas ao CMake usando -DOPTION_NAME=VALUE
. Algumas opções usadas com frequência para deqp estão listadas abaixo.
| Opção de configuração | Descrição |
|---|---|
DEQP_TARGET |
Nome do destino, por exemplo: "android" Os scripts do CMake no deqp incluirão 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 makefile. Os valores válidos são: "Debug" e "Liberar" A interpretação e o tipo padrão dependem do sistema de build de destino. Consulte a documentação do CMake para saber mais. |
Criar um arquivo de build de destino
O sistema de build deqp é configurado para novos destinos usando arquivos de build de destino.
Um arquivo de build de destino define com quais recursos a plataforma oferece suporte e quais bibliotecas ou
são necessários caminhos de inclusão adicionais. Os nomes dos arquivos de destino seguem a targets/NAME/NAME.cmake
e o destino é selecionado usando o parâmetro de build DEQP_TARGET.
Os caminhos nos arquivos de destino são relativos ao diretório base deqp, não ao
targets/NAME. As variáveis padrão a seguir 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 há suporte para GLES2 (padrão: DESATIVADO) |
DEQP_GLES2_LIBRARIES |
Bibliotecas GLES2 (deixe em branco se não for compatível ou se o carregamento dinâmico for usado) |
DEQP_SUPPORT_GLES3 |
Indica se o GLES3.x é compatível (padrão: DESATIVADO) |
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 |
Indica se OpenVG é compatível (padrão: DESATIVADO). |
DEQP_OPENVG_LIBRARIES |
Bibliotecas OpenVG (deixe em branco se não for compatível ou se o carregamento dinâmico for usado) |
DEQP_SUPPORT_EGL |
Se EGL é compatível (padrão: DESATIVADO) |
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 |
Outras bibliotecas 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 que são necessárias para a execução de testes, mas que não estão no padrão caminho de pesquisa. |
TCUTIL_PLATFORM_SRCS |
Lista de origens da porta da plataforma. As origens padrão são determinadas com base no e do SO. Observação:os caminhos são relativos a: |
O arquivo de build de destino pode adicionar outros caminhos de inclusão ou link usando o método
Funções do CMake include_directories() e link_directories().
Versão Win32
A maneira mais fácil de criar módulos deqp para Windows é usar o build do CMake sistema. Você vai precisar do CMake 2.6.12 ou mais recente e do pacote 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 build gerador:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Também é possível gerar makefiles NMake com a opção -G "NMake Makefiles".
como o tipo de build (-DCMAKE_BUILD_TYPE="Debug" ou "Release").
Criação do contexto de renderização
O contexto de renderização pode ser criado com WGL ou com EGL no Windows.
Compatibilidade com WGL
Todos os binários Win32 são compatíveis com a criação de contexto GL com WGL, pois ela exige apenas
bibliotecas padrão. O contexto WGL pode ser selecionado usando o --deqp-gl-context-type=wgl
argumento de linha de comando. No modo WGL, o deqp usa o WGL_EXT_create_context_es_profile
para criar contextos do OpenGL ES. Isso foi testado para funcionar com
os drivers mais recentes da NVIDIA e da Intel. Os drivers AMD não são compatíveis com os
.
Suporte a EGL
O deqp é criado com carregamento dinâmico para EGL no Windows se DEQP_SUPPORT_EGL
está ATIVADO. Esse é o padrão na maioria dos destinos. Então, se o host tiver bibliotecas EGL
é possível executar testes com eles usando a linha de comando
parâmetro: --deqp-gl-context-type=egl
Versão do Android
O build do Android usa scripts de build do CMake para gerar o código de teste nativo. As partes do Java, como o Test Execution Server e o Test Application Stub, são compilados usando as ferramentas de build padrão do Android.
Para compilar programas de teste de QP para Android com o build fornecido scripts, você precisará de:
- A versão mais recente do
Android NDK o arquivo
android/scripts/common.pylista a versão necessária - SDK independente do Android com API 13, Ferramentas do SDK, Ferramentas da plataforma SDK e SDK Pacotes de ferramentas de build instalados
- Apache Ant 1.9.4 (link em inglês) (exigido pelo build de 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
- Para Windows: NMake ou JOM em
PATH- O JOM permite builds mais rápidos
- Opcional: a marca do Ninja também é compatível com o Linux
Os binários do Ant e do SDK estão localizados na variável de ambiente PATH com
determinados padrões substitutos. 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 pelo ANDROID_NDK_PATH
variável de ambiente.
Os componentes do dispositivo, o serviço de execução de teste e os programas de teste estão
criado 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
command line executor é usado, o ExecService é iniciado
com o script launch.py no dispositivo pelo adb. Os scripts podem ser executados em qualquer diretório.
Build para Linux
Binários de teste e utilitários de linha de comando podem ser criados para Linux gerando makefiles usando CMake Há vários destinos de build predefinidos que são úteis na criação para Linux.
| Destino de build | Descrição |
|---|---|
default |
Destino padrão que usa 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 OpenGL (ES). |
x11_egl_glx |
Oferece suporte a GLX e EGL com X11. |
Sempre use -DCMAKE_BUILD_TYPE=<Debug|Release> para definir o tipo de build.
Release é um bom padrão. Sem isso, é criado um build de lançamento padrão e não otimizado.
Os argumentos de linha de comando -DCMAKE_C_FLAGS e -DCMAKE_CXX_FLAGS podem ser
usada para transmitir argumentos extras ao compilador. Por exemplo, a versão de 32 ou 64 bits pode ser feita
definindo -DCMAKE_C(XX)_FLAGS="-m32" ou "-m64", respectivamente. Caso contrário
especificada, é usada a arquitetura nativa do conjunto de ferramentas, normalmente de 64 bits em um conjunto de 64 bits.
Os argumentos -DCMAKE_LIBRARY_PATH e -DCMAKE_INCLUDE_PATH podem ser usados
do CMake para dar ao CMake uma biblioteca extra ou incluir caminhos de pesquisa.
Um exemplo de linha de comando completa usada para fazer um build de depuração de 32 bits no cabeçalhos e bibliotecas de drivers 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
É possível fazer a compilação cruzada usando um arquivo de conjunto de ferramentas do CMake. O conjunto de ferramentas
especifica o compilador a ser usado, juntamente com caminhos de pesquisa personalizados para
bibliotecas e cabeçalhos. Vários arquivos de conjunto de ferramentas para cenários comuns são
incluído no pacote de lançamento no diretório framework/delibs/cmake.
Além das variáveis padrão do CMake, as variáveis específicas do deqp a seguir
podem ser definidos pelo arquivo do conjunto de ferramentas. Geralmente, o CMake pode detectar 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 do conjunto de ferramentas pode ser selecionado usando o parâmetro de build CMAKE_TOOLCHAIN_FILE.
Por exemplo, o código a seguir criaria makefiles para um build usando o compilador cruzado do 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 do ambiente 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. A o código de teste sempre acessa as APIs usando ponteiros de função. Os pontos de entrada podem carregados dinamicamente em tempo de execução, ou a porta da plataforma pode fornecê-los a hora da vinculação.
Se o suporte para uma API estiver ativado nas configurações de compilação e as bibliotecas de links forem
não fornecido, o deqp carregará os pontos de entrada necessários no ambiente de execução. Se o
o link estático for desejado, informe as bibliotecas de links necessárias no arquivo DEQP_<API>_LIBRARIES
variável de configuração do build.
Fazer a portabilidade do framework de teste
A portabilidade do deqp envolve três etapas: adaptar as bibliotecas básicas de portabilidade, implementar interfaces de integração de plataforma de framework de teste e fazer a portabilidade serviço de execução.
A tabela abaixo lista locais para prováveis mudanças de portabilidade. Nada além é provável que sejam exóticas.
| 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 na |
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 base de portabilidade
As bibliotecas de portabilidade básicas já oferecem suporte ao Windows, à maioria das variantes do Linux, ao Mac OS, iOS e Android. Se o destino do teste for executado em um desses sistemas operacionais, provavelmente não será necessário mexer nas bibliotecas de portabilidade básicas.
Porta da plataforma do framework de teste
A porta da plataforma do framework de teste deqp requer dois componentes: um aplicativo um ponto de entrada e uma implementação de interface de plataforma.
O ponto de entrada do aplicativo é responsável por criar o objeto da plataforma,
criar um objeto de linha de comando (tcu::CommandLine), abrir um registro de teste
(tcu::TestLog) e iterar o aplicativo de teste (tcu::App). Se o
o SO de destino oferece suporte a um ponto de entrada main() padrão; tcuMain.cpp pode ser usado
como a implementação do ponto de entrada.
A API deqp platform é descrita em detalhes 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 de aplicativo padrão |
A classe de base de todas as portas da plataforma é tcu::Platform. A porta da plataforma pode
oferecer suporte 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.
| Module | Interface |
|---|---|
Módulos de teste OpenGL (ES) |
Interface da plataforma GL |
Módulo de teste de EGL |
Interface da plataforma EGL |
Instruções detalhadas para a implementação de portas de plataforma estão na e portabilidade de cabeçalhos de camada.
Serviço de execução de teste
Para usar a infraestrutura de execução do teste deqp ou o executor de linha de comando, o
o serviço de execução de teste precisa estar disponível no destino. Um C++ portátil
a implementação do serviço é fornecida no diretório execserver. Autônomo
O binário é criado como parte do módulo de teste deqp.
para destinos de PC. Você pode modificar execserver/CMakeLists.txt para ativar um build no
outros destinos.
A versão C++ do serviço de execução de teste aceita duas linhas de comando parâmetros:
-
--port=<port>definirá a porta TCP que o servidor escuta. O padrão é 50016. -
--singlevai encerrar o processo do servidor quando o cliente se desconectar. Por padrão, o do servidor de anúncios permanecerá ativo para atender outras solicitações de execução de teste.
Executar os testes
Esta página fornece instruções para executar testes deqp no Linux e no Windows ambientes, usando argumentos de linha de comando e trabalhando com a do pacote do aplicativo.
Ambientes Linux e Windows
Comece copiando os arquivos e diretórios a seguir para o destino.
| Module | 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 da rede de sistema de arquivos No entanto, os binários de teste esperam encontrar diretórios de dados no diretório de trabalho atual. Quando estiver pronto, inicie o serviço de execução de teste dispositivo de destino. Para mais detalhes sobre como iniciar o serviço, consulte Teste serviço de execução.
Argumentos de linha de comando
A tabela a seguir lista os argumentos de linha de comando que afetam a execução de todos para testar programas.
| Argumento | Descrição |
|---|---|
--deqp-case=<casename> |
Casos de execução que correspondam a um determinado padrão. O caractere curinga (*) é aceito. |
--deqp-log-filename=<filename> |
Grave os resultados do teste no arquivo com o nome informado. A execução do teste vai definir o nome do arquivo ao iniciar um teste. |
--deqp-stdin-caselist |
Lê a lista de casos a partir de stdin ou de um determinado argumento. A execução do teste serviço definirá o argumento de acordo com a solicitação de execução recebida. Consulte a próxima seção para uma descrição do formato da lista de casos. |
--deqp-test-iteration-count=<count> |
Modifique a contagem de iterações para testes compatíveis com um número variável de iterações. |
--deqp-base-seed=<seed> |
Sugestão de base para os casos de teste que usam randomização. |
Argumentos específicos de GLES2 e GLES3
A tabela a seguir lista os argumentos específicos de GLES2- e GLES3.| Argumento | Descrição |
|---|---|
--deqp-gl-context-type=<type> |
Tipo de contexto do OpenGL. Os tipos de contexto disponíveis dependem da plataforma. Ativado
plataformas compatíveis com EGL, o valor egl poderá ser usado para selecionar
no contexto de EGL. |
--deqp-gl-config-id=<id> |
Execute testes para o ID de configuração GL fornecido. A interpretação é dependente da plataforma. Na plataforma EGL, esse é o ID de configuração da EGL. |
--deqp-gl-config-name=<name> |
Execute testes para uma configuração GL nomeada. A interpretação é
dependente da plataforma. Para EGL, o formato é
rgb(a)<bits>d<bits>s<bits>: Por exemplo,
o valor de rgb888s8 selecionará a primeira configuração em que o
de cor é 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 determinado tamanho. O suporte para isso é opcional. |
--deqp-surface-type=<type> |
Use um determinado tipo de superfície como o principal destino da renderização de teste. Possível
são window, pixmap, pbuffer,
e fbo. |
--deqp-screen-rotation=<rotation> |
É a orientação da tela em incrementos de 90 graus para plataformas que apoiá-la. |
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. Conforme o se os conjuntos de teste crescem, os prefixos repetitivos podem ser complicados. Para evitar a repetição dos prefixos, use uma sintaxe de trie (também conhecida como árvore de prefixos) mostrada abaixo.
{nodeName{firstChild{…},…lastChild{…}}}
Exemplo:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
É traduzido para os dois casos de teste a seguir:
dEQP-EGL.config_list dEQP-EGL.create_context.rgb565_depth_stencil
Android
O pacote de aplicativo Android contém todos os componentes necessários, incluindo
o serviço de execução de teste, binários de teste e arquivos de dados. A atividade de teste é
Um NativeActivity que usa EGL (requer o Android 3.2 ou mais recente).
O pacote do aplicativo pode ser instalado com o seguinte comando (nome mostrado é o nome do APK no pacote do Android CTS. qual nome depende o 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 as impressões de depuração, execute o seguinte comando antes de iniciar a testes:
adb –d shell setprop log.tag.dEQP DEBUG
Executar testes no Android sem o Android CTS
Para iniciar manualmente a atividade de execução de teste, construa uma intent do Android
que segmenta android.app.NativeActivity. As atividades podem ser
no pacote com.drawelements.deqp. A linha de comando precisa
ser fornecido 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 inicia normalmente, há mais informações de depuração disponíveis no dispositivo
de registro.
É possível iniciar uma atividade na linha de comando usando o am
utilitário. Por exemplo, para executar testes dEQP-GLES2.info em uma plataforma
com suporte a NativeActivity,, use os comandos a seguir.
adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \ 'cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa"'
Depurar no Android
Para executar os testes com o depurador do GDB no Android, primeiro compile e instale o build de depuração executando estes dois scripts:
python android/scripts/build.py --native-build-type=Debugpython android/scripts/install.py
Depois de instalar o build de depuração no dispositivo, para iniciar os testes em GDB em execução no host, execute o seguinte comando:
python android/scripts/debug.py \ --deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"
A linha de comando deqp depende dos casos de teste que serão executados e de outras
parâmetros obrigatórios. O script adiciona um ponto de interrupção padrão no início do
a execução de deqp (tcu::App::App).
O script debug.py aceita vários argumentos de linha de comando para
ações como configurar pontos de interrupção para depuração, conexão gdbserver
parâmetros 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 alguns
bibliotecas padrão do dispositivo de destino para obter listagens de símbolos.
Para percorrer o código do driver (por exemplo, quando o GDB precisa saber os locais)
dos binários com informações de depuração completas), adicione mais bibliotecas via
Parâmetros de linha de comando debug.py. Esse script escreve um
de configuração do GDB a partir da linha 132 do arquivo de script. Você
pode fornecer caminhos adicionais para binários etc., mas fornecendo o comando correto
parâmetros de linha devem ser suficientes.
Observação:no Windows, o binário do GDB requer
libpython2.7.dll Antes de iniciar o debug.py, adicione
<path-to-ndk>/prebuilt/windows/bin à variável PATH.
Observação:a depuração do código nativo não funciona em estoca Android 4.3; para obter soluções alternativas, consulte este bug público. O Android 4.4 e versões mais recentes não apresentam esse bug.
Automatizar os testes
Os módulos de teste Deqp podem ser integrados a sistemas de teste automatizados de várias maneiras. A melhor abordagem depende da infraestrutura de teste atual e do objetivo de nuvem.
O resultado 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 do teste. A saída do console é
somente 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 teste O binário pode ser iniciado para um caso específico, para um conjunto de teste ou para todos disponíveis. Se um erro fatal ocorrer durante a execução (como determinadas APIs erros ou uma falha), a execução do teste será cancelada. Para testes de regressão, a melhor abordagem é invocar os binários de teste para casos individuais ou pequenos define separadamente para disponibilizar resultados parciais, mesmo que de falhas graves.
O deqp vem com ferramentas de execução de teste de linha de comando que podem ser usadas em com o serviço de execução para obter uma integração mais robusta. O executor detecta o encerramento do processo de teste e retoma a execução do teste em o próximo caso disponível. Um único arquivo de registro é produzido a partir do conjunto de dados sessão. Essa configuração é ideal para sistemas de teste leves que não oferecem instalações de recuperação de acidente.
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 para análise de regressão, um conversor de teste de registro para CSV, um conversor de teste de registro 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
integrado 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 coletando os registros resultantes dele por TCP/IP. Executor
se comunica com o serviço de execução (execserver) no dispositivo de destino.
Juntos, eles oferecem funcionalidades como a recuperação de falhas no processo de teste.
Os exemplos a seguir demonstram como usar o Executor de teste 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 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
Testar a exportação de CSV de registros e comparar
O deqp tem uma ferramenta para converter registros de teste (arquivos .qpa) em arquivos CSV. O arquivo CSV
saída contém uma lista de casos de teste e os
resultados. A ferramenta também pode comparar dois ou mais resultados em lote e listar somente os
casos de teste que têm códigos de status diferentes nos resultados do lote de entrada. A
comparação também mostra o número de casos correspondentes.
A saída em formato CSV é muito prática para processamento adicional com
utilitários de linha de comando ou com um editor de planilhas. Um pacote adicional, legível por humanos,
o formato de texto simples pode ser selecionado usando o seguinte argumento de linha de comando: --format=text
Exemplo 1: exportar registros 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 dos resultados do teste 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 teste
no código de resultado, como "Aprovado" ou "Falha". O argumento --value=details seleciona
explicação do resultado ou valor numérico produzido por um teste de desempenho, capacidade ou precisão.
Testar a exportação de XML do registro
Arquivos de registro de teste podem ser convertidos em documentos XML válidos usando o testlog-to-xml
utilitário. Há suporte para dois modos de saída:
- Modo de documentos separados, em que cada caso de teste e o resumo de
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 registro de teste exportados podem ser visualizados em um navegador usando uma folha de estilo XML.
São fornecidos exemplos de documentos da folha de estilo (testlog.xsl e testlog.css).
diretório doc/testlog-stylesheet. Para renderizar os arquivos de registro em um navegador, copie o
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 deverão ser acessados por HTTP como 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 atender à
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 do teste.
Conversão para um registro de teste do JUnit
Muitos sistemas de automação de testes podem gerar relatórios de resultados da execução de testes do JUnit saída. Os arquivos de registro do teste deqp podem ser convertidos para o formato de saída JUnit usando a ferramenta testlog-to-junit.
No momento, a ferramenta só oferece suporte à tradução do veredito do caso de teste. Como JUnit suporta apenas "cartão" e "falha" resultados, um resultado aprovado do deqp será mapeado para "JUnit pass" e outros resultados são considerados falhas. O deqp original o código de resultado é disponibilizado na saída do JUnit. Outros dados, como mensagens de registro e imagens de resultados não são preservadas na conversão.
Usar grupos de teste especiais
Alguns grupos de teste podem precisar ou oferecer suporte a opções de linha de comando especiais 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 ao alocar determinados recursos até que o driver informe um erro de falta de memória.
Em determinadas plataformas, como o Android e a maioria das variantes do Linux, os seguintes
pode ocorrer: o sistema operacional pode encerrar o processo de teste em vez de permitir uma
para processar ou fornecer um erro de falta de memória. Em tais
plataformas, os testes projetados para causar erros de falta de memória são desativados
por padrão e precisa ser ativado usando o argumento de linha de comando --deqp-test-oom=enable.
Recomendamos que você execute esses testes manualmente para
verifica se o sistema se comporta corretamente sob a pressão de recursos. No entanto, em
uma 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 foram projetados para revelar problemas de robustez em cargas de trabalho
carga de renderização. Por padrão, os testes vão executar apenas algumas iterações, mas
eles podem ser configurados para serem executados indefinidamente informando o --deqp-test-iteration-count=-1;
argumento de linha de comando. O watchdog de teste precisa ser desativado (--deqp-watchdog=disable).
quando os testes são executados
por um longo período.
Grupos de teste
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*