AOSP inclui o conjunto de testes de GPU drawElements Quality Program (deqp) em https://android.googlesource.com/platform/external/deqp . Esta página detalha como implantar o conjunto de testes deqp em um novo ambiente.
Para trabalhar com o código enviado mais recente, use a ramificação deqp-dev . Para código que corresponda a uma versão específica do Android CTS, use o branch release-code-name -release (por exemplo, para Android 6.0, use o branch marshmallow-release ).
Layout de origem
O layout do código-fonte dos módulos de teste deqp e das bibliotecas de suporte é mostrado na tabela abaixo (a listagem não é abrangente, mas destaca os diretórios mais importantes).
| Diretório | Descrição |
|---|---|
android | Fontes de teste do Android e scripts de construção |
data | Arquivos de dados de teste |
modules | Fontes do módulo de teste |
modules/egl | Módulo EGL |
modules/gles2 | Módulo GLES2 |
modules/gles3 | Módulo GLES3 |
modules/gles31 | Módulo GLES3.1 |
modules/gles32 | Módulo GLES3.2 |
targets | Arquivos de configuração de compilação específicos do destino |
framework | estrutura e utilitários do módulo de teste deqp |
framework/delibs | Portabilidade básica e construção de bibliotecas |
framework/platform | Portas de plataforma |
framework/qphelper | Biblioteca de integração do programa de teste (C) |
framework/common | Estrutura Deqp (C++) |
framework/opengl, framework/egl | Utilitários específicos da API |
execserver | Fonte ExecServer do lado do dispositivo |
executor | Ferramenta e utilitários de shell do executor de teste do lado do host |
external | Construir diretório stub para bibliotecas externas libpng e zlib |
Componentes de código aberto
O deqp usa libpng e zlib , que podem ser obtidos usando o script platform/external/deqp/external/fetch_sources.py ou via git de platform/external/[libpng,zlib] .
Crie programas de teste
A estrutura de teste foi projetada tendo em mente a portabilidade. Os únicos requisitos obrigatórios são suporte completo a C++ e bibliotecas de sistema padrão para E/S, threads e soquetes.
Sistema de compilação CMake
As fontes deqp possuem scripts de construção para CMake, que é a ferramenta preferida para compilar os programas de teste.
CMake é um sistema de construção de código aberto que suporta múltiplas plataformas e conjuntos de ferramentas. CMake gera makefiles nativos ou arquivos de projeto IDE a partir de arquivos de configuração independentes de destino. Para obter mais informações sobre o CMake, consulte a documentação do CMake .
CMake suporta e recomenda compilações fora da árvore de origem, ou seja, você deve sempre criar makefiles ou arquivos de projeto em um diretório de compilação separado, fora da árvore de origem. O CMake não possui nenhum tipo de alvo "distclean", portanto a remoção de quaisquer arquivos gerados pelo CMake deve ser feita manualmente.
As opções de configuração são fornecidas ao CMake usando a sintaxe -D OPTION_NAME = VALUE . Algumas opções comumente usadas para deqp estão listadas abaixo.
| Opção de configuração | Descrição |
|---|---|
DEQP_TARGET | Nome de destino, por exemplo: "android" Os scripts deqp CMake incluirão o arquivo |
CMAKE_TOOLCHAIN_FILE | Caminho para o arquivo do conjunto de ferramentas do CMake. Usado para compilação cruzada. |
CMAKE_BUILD_TYPE | Tipo de compilação para destinos makefile. Os valores válidos são: "Debug" e "Release" Observe que a interpretação e o tipo padrão dependem do sistema de compilação de destino. Consulte a documentação do CMake para obter detalhes. |
Crie um arquivo de compilação de destino
O sistema de compilação deqp é configurado para novos destinos usando arquivos de compilação de destino. Um arquivo de construção de destino define quais recursos a plataforma suporta e quais bibliotecas ou caminhos de inclusão adicionais são necessários. Os nomes dos arquivos de destino seguem o formato targets/ NAME / NAME .cmake e o destino é selecionado usando o parâmetro de construção DEQP_TARGET .
Os caminhos de arquivo nos arquivos de destino são relativos ao diretório deqp base, não ao diretório targets/ NAME . As seguintes variáveis padrão podem ser definidas pelo arquivo de construção de destino.
| Variável | Descrição |
|---|---|
DEQP_TARGET_NAME | Nome do destino (será incluído nos logs de teste) |
DEQP_SUPPORT_GLES2 | Se GLES2 é compatível (padrão: OFF) |
DEQP_GLES2_LIBRARIES | Bibliotecas GLES2 (deixe em branco se não for compatível ou se for usado carregamento dinâmico) |
DEQP_SUPPORT_GLES3 | Se GLES3.x é compatível (padrão: OFF) |
DEQP_GLES3_LIBRARIES | Bibliotecas GLES3.x (deixe em branco se não for compatível ou se o carregamento dinâmico for usado) |
DEQP_SUPPORT_VG | Se o OpenVG é compatível (padrão: OFF) |
DEQP_OPENVG_LIBRARIES | Bibliotecas OpenVG (deixe em branco se não for compatível ou se for usado carregamento dinâmico) |
DEQP_SUPPORT_EGL | Se EGL é compatível (padrão: OFF) |
DEQP_EGL_LIBRARIES | Bibliotecas EGL (deixe em branco se não for compatível ou se o carregamento dinâmico for usado) |
DEQP_PLATFORM_LIBRARIES | Bibliotecas adicionais específicas da plataforma necessárias para vinculação |
DEQP_PLATFORM_COPY_LIBRARIES | Lista de bibliotecas que são copiadas para cada diretório de construção binário de teste. Pode ser usado para copiar bibliotecas necessárias para a execução de testes, mas que não estão no caminho de pesquisa padrão. |
TCUTIL_PLATFORM_SRCS | Lista de origem de portas da plataforma. As fontes padrão são determinadas com base nos recursos e no sistema operacional. Nota: Os caminhos são relativos a: |
O arquivo de compilação de destino pode adicionar caminhos de inclusão ou link adicionais usando as funções include_directories() e link_directories() do CMake.
Compilação Win32
A maneira mais fácil de construir módulos deqp para Windows é usar o sistema de compilação CMake. Você precisará do CMake 2.6.12 ou mais recente e do compilador Microsoft Visual C/C++. O deqp foi testado com Visual Studio 2013.
Os arquivos de projeto do Visual Studio podem ser gerados com o seguinte comando:
cmake path\to\src\deqp -G "Visual Studio 12"
Uma compilação de 64 bits pode ser feita selecionando "Visual Studio VERSION Win64" como gerador de compilação:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Você também pode gerar makefiles NMake com a opção -G "NMake Makefiles" bem como o tipo de compilação ( -DCMAKE_BUILD_TYPE="Debug" ou "Release" ).
Renderizar criação de contexto
O contexto de renderização pode ser criado com WGL ou com EGL no Windows.
Suporte WGL
Todos os binários Win32 suportam a criação de contexto GL com WGL, pois requer apenas bibliotecas padrão. O contexto WGL pode ser selecionado usando o argumento de linha de comando --deqp-gl-context-type=wgl . No modo WGL, o deqp usa a extensão WGL_EXT_create_context_es_profile para criar contextos OpenGL ES. Isso foi testado para funcionar com os drivers mais recentes da NVIDIA e Intel. Os drivers AMD não suportam a extensão necessária.
Suporte EGL
O deqp é construído com carregamento dinâmico para EGL no Windows se DEQP_SUPPORT_EGL estiver ativado. Este é o padrão na maioria dos destinos. Então, se o host tiver bibliotecas EGL disponíveis, é possível executar testes com elas com o parâmetro de linha de comando: --deqp-gl-context-type=egl
Versão Android
A compilação do Android usa scripts de compilação do CMake para criar o código de teste nativo. As partes Java, ou seja, o Test Execution Server e o Test Application Stub, são compiladas usando as ferramentas de construção padrão do Android.
Para compilar programas de teste deqp para Android com os scripts de construção fornecidos, você precisará de:
- A versão mais recente do Android NDK ; o arquivo
android/scripts/common.pylista a versão necessária - SDK autônomo do Android com API 13, SDK Tools, SDK Platform-tools e pacotes SDK Build-tools instalados
- Apache Ant 1.9.4 (exigido pela compilação do código Java)
- CMake 2.8.12 ou mais recente
- Python 2.6 ou mais recente na série 2.x; Python 3.x não é compatível
- Para Windows: NMake ou JOM em
PATH- JOM permite compilações mais rápidas
- Opcional: Ninja make também é compatível com Linux
Os binários Ant e SDK estão localizados com base na variável de ambiente PATH com determinados padrões de substituição. A lógica é controlada por android/scripts/common.py .
O diretório NDK deve ser ~/android-ndk- VERSION ou C:/android/android-ndk- VERSION ou definido por meio da variável de ambiente ANDROID_NDK_PATH .
Os componentes do dispositivo Deqp, o serviço de execução de teste e os programas de teste são criados executando o script android/scripts/build.py . O .apk final é criado em android/package/bin e pode ser instalado pelo script install.py . Se o executor de linha de comando for usado, o ExecService será iniciado com o script launch.py no dispositivo via ADB. Os scripts podem ser executados a partir de qualquer diretório.
Compilação Linux
Binários de teste e utilitários de linha de comando podem ser criados para Linux gerando makefiles usando CMake. Existem vários destinos de construção predefinidos que são úteis ao construir para Linux.
| Criar alvo | Descrição |
|---|---|
default | Destino padrão que usa a introspecção da plataforma CMake para determinar o suporte para várias APIs. |
x11_glx | Usa GLX para criar contextos OpenGL (ES). |
x11_egl | Usa EGL para criar contextos OpenGL (ES). |
x11_egl_glx | Suporta GLX e EGL com X11. |
Sempre use -DCMAKE_BUILD_TYPE=<Debug|Release> para definir o tipo de construção. Release é um bom padrão. Sem ele, é feita uma versão padrão e não otimizada.
Os argumentos de linha de comando -DCMAKE_C_FLAGS e -DCMAKE_CXX_FLAGS podem ser usados para passar argumentos extras para o compilador. Por exemplo, a compilação de 32 ou 64 bits pode ser feita definindo -DCMAKE_C(XX)_FLAGS="-m32" ou "-m64" respectivamente. Se não for especificado, a arquitetura nativa da cadeia de ferramentas, normalmente de 64 bits na cadeia de ferramentas de 64 bits, será usada.
Os argumentos -DCMAKE_LIBRARY_PATH e -DCMAKE_INCLUDE_PATH podem ser usados para o CMake fornecer biblioteca adicional ao CMake ou incluir caminhos de pesquisa.
Um exemplo de linha de comando completa usada para fazer uma compilação de depuração de 32 bits em cabeçalhos de driver e bibliotecas em um local personalizado é o seguinte:
cmake <path to src>/deqp -DDEQP_TARGET=x11_egl -DCMAKE_C_FLAGS="-m32" -DCMAKE_CXX_FLAGS="-m32" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_LIBRARY_PATH="PATH_TO_DRIVER/lib" -DCMAKE_INCLUDE_PATH="PATH_TO_DRIVER/inc"make -j4
Compilação cruzada
A compilação cruzada pode ser obtida usando um arquivo de conjunto de ferramentas CMake. O arquivo do conjunto de ferramentas especifica o compilador a ser usado, juntamente com caminhos de pesquisa customizados para bibliotecas e cabeçalhos. Vários arquivos do conjunto de ferramentas para cenários comuns estão incluídos no pacote de lançamento no diretório framework/delibs/cmake .
Além das variáveis padrão do CMake, as seguintes variáveis específicas do deqp podem ser configuradas pelo arquivo do conjunto de ferramentas. O CMake geralmente pode detectar DE_OS , DE_COMPILER e DE_PTR_SIZE corretamente, mas DE_CPU deve ser definido pelo arquivo do conjunto de ferramentas.
| Variável | Descrição |
|---|---|
DE_OS | Sistema operacional. Os valores suportados são: |
DE_COMPILER | Tipo de compilador. Os valores suportados são: |
DE_CPU | Tipo de CPU. Os valores suportados são: |
DE_PTR_SIZE | sizeof(void*) na plataforma. Os valores suportados são: 4 e 8 |
O arquivo da cadeia de ferramentas pode ser selecionado usando o parâmetro de construção CMAKE_TOOLCHAIN_FILE . Por exemplo, o seguinte criaria makefiles para uma compilação usando o compilador cruzado CodeSourcery para ARM/Linux:
cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release" –DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake –DARM_CC_BASE=PATH_TO_CC_DIRECTORY
Vinculação em tempo de execução de bibliotecas GLES e EGL
O deqp não precisa de pontos de entrada da API em teste durante a vinculação. O código de teste sempre acessa as APIs por meio de ponteiros de função. Os pontos de entrada podem então ser carregados dinamicamente em tempo de execução ou a porta da plataforma pode fornecê-los em tempo de link.
Se o suporte para uma API estiver ativado nas configurações de compilação e as bibliotecas de links não forem fornecidas, o deqp carregará os pontos de entrada necessários em tempo de execução. Se a vinculação estática for desejada, forneça as bibliotecas de links necessárias na variável de configuração de construção DEQP_<API>_LIBRARIES .
Portar a estrutura de teste
A portabilidade do deqp envolve três etapas: adaptação de bibliotecas de portabilidade básica, implementação de interfaces de integração de plataforma de estrutura de teste e portabilidade do serviço de execução.
A tabela abaixo lista os locais para prováveis alterações de portabilidade. Qualquer coisa além deles provavelmente será exótica.
| Localização | Descrição |
|---|---|
framework/delibs/debase | Quaisquer implementações necessárias de código específico do sistema operacional. |
framework/qphelper/qpCrashHandler.c | Opcional: Implementação para seu sistema operacional. |
framework/qphelper/qpWatchDog.c | Implementação para seu sistema operacional. O atual é baseado em |
framework/platform | A nova porta da plataforma e o stub do aplicativo podem ser implementados conforme descrito em Porta da plataforma da estrutura de teste . |
Bibliotecas de portabilidade básica
As bibliotecas básicas de portabilidade já suportam Windows, a maioria das variantes do Linux, Mac OS, iOS e Android. Se o alvo do teste for executado em um desses sistemas operacionais, provavelmente não haverá necessidade de mexer nas bibliotecas básicas de portabilidade.
Porta da plataforma da estrutura de teste
A porta da plataforma da estrutura de teste deqp requer dois componentes: um ponto de entrada do aplicativo e uma implementação de interface da plataforma.
O ponto de entrada do aplicativo é responsável por criar o objeto de plataforma, criar um objeto de linha de comando ( tcu::CommandLine ), abrir um log de teste ( tcu::TestLog ) e iterar o aplicativo de teste ( tcu::App ). Se o sistema operacional de destino suportar um ponto de entrada main() padrão, tcuMain.cpp poderá ser usado como implementação do ponto de entrada.
A API da plataforma deqp é descrita detalhadamente nos arquivos a seguir.
| Arquivo | Descrição |
|---|---|
framework/common/tcuPlatform.hpp | Classe base para todas as portas da plataforma |
framework/opengl/gluPlatform.hpp | Interface da plataforma OpenGL |
framework/egl/egluPlatform.hpp | Interface da plataforma EGL |
framework/platform/tcuMain.cpp | Ponto de entrada padrão do aplicativo |
A classe base para todas as portas da plataforma é tcu::Platform . A porta da plataforma pode suportar opcionalmente interfaces específicas de GL e EGL. Consulte a tabela a seguir para obter uma visão geral do que precisa ser implementado para executar os testes.
| Módulo | Interface |
|---|---|
Módulos de teste OpenGL (ES) | Interface da plataforma GL |
Módulo de teste EGL | Interface da plataforma EGL |
Instruções detalhadas para implementar portas de plataforma estão nos cabeçalhos da camada de portabilidade.
Serviço de execução de teste
Para usar a infraestrutura de execução de teste deqp ou o executor de linha de comando, o serviço de execução de teste deve estar disponível no destino. Uma implementação C++ portátil do serviço é fornecida no diretório execserver . O binário independente é construído como parte da construção do módulo de teste deqp para destinos de PC. Você pode modificar execserver/CMakeLists.txt para ativar uma compilação em outros destinos.
A versão C++ do serviço de execução de teste aceita dois parâmetros de linha de comando:
-
--port=<port>definirá a porta TCP na qual o servidor escuta. O padrão é 50016. -
--singleencerrará o processo do servidor quando o cliente se desconectar. Por padrão, o processo do servidor permanecerá ativo para atender outras solicitações de execução de teste.
Execute os testes
Esta página fornece instruções para executar testes deqp em ambientes Linux e Windows, usando argumentos de linha de comando e trabalhando com o pacote de aplicativos Android.
Ambientes Linux e Windows
Comece copiando os seguintes arquivos e diretórios para o destino.
| Módulo | Diretório | Alvo |
|---|---|---|
| Servidor de Execução | build/execserver/execserver | <dst>/execserver |
| Módulo EGL | build/modules/egl/deqp-egl | <dst>/deqp-egl |
| Módulo GLES2 | build/modules/gles2/deqp-gles2 | <dst>/deqp-gles2 |
data/gles2 | <dst>/gles2 | |
| Módulo GLES3 | build/modules/gles3/deqp-gles3 | <dst>/deqp-gles3 |
data/gles3 | <dst>/gles3 | |
| Módulo GLES3.1 | build/modules/gles31/deqp-gles31 | <dst>/deqp-gles31 |
data/gles31 | <dst>/gles31 | |
| Módulo GLES3.2 | build/modules/gles32/deqp-gles32 | <dst>/deqp-gles32 |
data/gles32 | <dst>/gles32 |
Você pode implementar o serviço de execução e testar binários em qualquer lugar do sistema de arquivos de destino; entretanto, os binários de teste esperam encontrar diretórios de dados no diretório de trabalho atual. Quando estiver pronto, inicie o Test Execution Service no dispositivo de destino. Para obter detalhes sobre como iniciar o serviço, consulte Serviço de execução de teste .
Argumentos de linha de comando
A tabela a seguir lista argumentos de linha de comando que afetam a execução de todos os programas de teste.
| Argumento | Descrição |
|---|---|
--deqp-case=<casename> | Execute casos que correspondam a um determinado padrão. Curinga (*) é suportado. |
--deqp-log-filename=<filename> | Grave os resultados do teste no arquivo cujo nome você fornece. O serviço de execução de teste definirá o nome do arquivo ao iniciar um teste. |
--deqp-stdin-caselist | Leia a lista de casos do stdin ou de um determinado argumento. O serviço de execução de teste definirá o argumento de acordo com a solicitação de execução recebida. Consulte a próxima seção para obter uma descrição do formato da lista de casos. |
--deqp-test-iteration-count=<count> | Substitua a contagem de iterações para testes que suportam um número variável de iterações. |
--deqp-base-seed=<seed> | Semente base para os casos de teste que usam randomização. |
Argumentos específicos do GLES2 e GLES3
A tabela a seguir lista os argumentos específicos do GLES2 e GLES3.| Argumento | Descrição |
|---|---|
--deqp-gl-context-type=<type> | Tipo de contexto OpenGL. Os tipos de contexto disponíveis dependem da plataforma. Em plataformas que suportam EGL, o valor egl pode ser usado para selecionar o contexto EGL. |
--deqp-gl-config-id=<id> | Execute testes para o ID de configuração GL fornecido. A interpretação depende da plataforma. Na plataforma EGL, este é o ID de configuração do EGL. |
--deqp-gl-config-name=<name> | Execute testes para uma configuração GL nomeada. A interpretação depende da plataforma. Para EGL, o formato é rgb(a)<bits>d<bits>s<bits> . Por exemplo, um valor rgb888s8 selecionará a primeira configuração onde o buffer de cores é RGB888 e o buffer de estêncil possui 8 bits. |
--deqp-gl-context-flags=<flags> | Cria um contexto. Especifique robust ou debug . |
--deqp-surface-width=<width> | Tente criar uma superfície com um determinado tamanho. O suporte para isso é opcional. |
--deqp-surface-type=<type> | Use um determinado tipo de superfície como principal alvo de renderização de teste. Os tipos possíveis são window , pixmap , pbuffer e fbo . |
--deqp-screen-rotation=<rotation> | Orientação da tela em incrementos de 90 graus para plataformas que a suportam. |
Formato da lista de casos de teste
A lista de casos de teste pode ser fornecida em dois formatos. A primeira opção é listar o nome completo de cada teste em uma linha separada em um arquivo ASCII padrão. À medida que os conjuntos de testes crescem, os prefixos repetitivos podem ser complicados. Para evitar a repetição dos prefixos, use uma sintaxe trie (também conhecida como árvore de prefixos) mostrada abaixo.
{nodeName{firstChild{…},…lastChild{…}}}
Por exemplo:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Traduz-se nos dois casos de teste a seguir:
dEQP-EGL.config_list dEQP-EGL.create_context.rgb565_depth_stencil
Android
O pacote de aplicativos Android contém todos os componentes necessários, incluindo o serviço de execução de teste, binários de teste e arquivos de dados. A atividade de teste é uma NativeActivity que usa EGL (requer Android 3.2 ou superior).
O pacote do aplicativo pode ser instalado com o seguinte comando (o nome mostrado é o nome do APK no pacote Android CTS; cujo nome depende da compilação):
adb –d install –r com.drawelements.deqp.apk
Para iniciar o serviço de execução de teste e configurar o encaminhamento de porta, use o seguinte:
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
As impressões de depuração podem ser habilitadas executando o seguinte antes de iniciar os testes:
adb –d shell setprop log.tag.dEQP DEBUG
Execute testes no Android sem Android CTS
Para iniciar manualmente a atividade de execução de teste, crie uma intent Android direcionada a android.app.NativeActivity . As atividades podem ser encontradas no pacote com.drawelements.deqp . A linha de comando deve ser fornecida como uma string extra com a chave "cmdLine" no Intent.
Um log de teste é gravado em /sdcard/dEQP-log.qpa . Se a execução do teste não iniciar normalmente, informações adicionais de depuração estarão disponíveis no log do dispositivo.
Você pode iniciar uma atividade a partir da linha de comando usando o utilitário am . Por exemplo, para executar testes dEQP-GLES2.info em uma plataforma que suporta NativeActivity, use os comandos a seguir.
adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \ 'cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa"'
Depurar no Android
Para executar os testes no depurador GDB no Android, primeiro compile e instale a compilação de depuração executando os dois scripts a seguir:
python android/scripts/build.py --native-build-type=Debugpython android/scripts/install.py
Depois que a compilação de depuração for instalada no dispositivo, para iniciar os testes no GDB em execução no host, execute o seguinte comando:
python android/scripts/debug.py \ --deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"
A linha de comando do deqp depende dos casos de teste a serem executados e de outros parâmetros necessários. O script adiciona um ponto de interrupção padrão no início da execução do deqp ( tcu::App::App ).
O script debug.py aceita vários argumentos de linha de comando para ações como definir pontos de interrupção para depuração, parâmetros de conexão gdbserver e caminhos para binários adicionais para depuração (use debug.py --help para todos os argumentos e explicações). O script também copia algumas bibliotecas padrão do dispositivo de destino para obter listagens de símbolos.
Para percorrer o código do driver (como quando o GDB precisa saber a localização dos binários com informações completas de depuração), adicione mais bibliotecas por meio dos parâmetros de linha de comando debug.py . Este script grava um arquivo de configuração para o GDB começando na linha 132 do arquivo de script. Você pode fornecer caminhos adicionais para binários, etc., mas fornecer parâmetros de linha de comando corretos deve ser suficiente.
Nota: No Windows, o binário GDB requer libpython2.7.dll . Antes de iniciar debug.py , adicione <path-to-ndk>/prebuilt/windows/bin à variável PATH.
Observação: a depuração de código nativo não funciona no Android 4.3 padrão; para soluções alternativas, consulte este bug público . O Android 4.4 e superior não contém esse bug.
Automatize os testes
Os módulos de teste Deqp podem ser integrados a sistemas de teste automatizados de diversas maneiras. A melhor abordagem depende da infraestrutura de teste existente e do ambiente de destino.
A saída principal de uma execução de teste é sempre o arquivo de log de teste, ou seja, o arquivo com um postfix .qpa . Os resultados completos do teste podem ser analisados no log de teste. A saída do console contém apenas informações de depuração e pode não estar disponível em todas as plataformas.
Os binários de teste podem ser invocados diretamente de um sistema de automação de teste. O binário de teste pode ser iniciado para um caso específico, para um conjunto de testes ou para todos os testes disponíveis. Se ocorrer um erro fatal durante a execução (como certos erros de API ou uma falha), a execução do teste será abortada. Para testes de regressão, a melhor abordagem é invocar os binários de teste para casos individuais ou pequenos conjuntos de testes separadamente, para ter resultados parciais disponíveis mesmo no caso de falha grave.
O deqp vem com ferramentas de execução de teste de linha de comando que podem ser usadas em combinação com o serviço de execução para obter uma integração mais robusta. O executor detecta o encerramento do processo de teste e retomará a execução do teste no próximo caso disponível. Um único arquivo de log é produzido a partir da sessão de teste completa. Essa configuração é ideal para sistemas de teste leves que não oferecem recursos de recuperação de falhas.
Ferramentas de execução de teste de linha de comando
O conjunto atual de ferramentas de linha de comando inclui uma ferramenta de execução remota de teste, um gerador de comparação de log de teste para análise de regressão, um conversor de log de teste para CSV, um conversor de log de teste para XML e um conversor de testlog para JUnit. .
O código-fonte dessas ferramentas está no diretório executor e os binários são criados no diretório <builddir>/executor .
Executor de teste de linha de comando
O executor de teste de linha de comando é uma ferramenta C++ portátil para iniciar uma execução de teste em um dispositivo e coletar os logs resultantes dele por meio de TCP/IP. O Executor se comunica com o serviço de execução (execserver) no dispositivo de destino. Juntos, eles fornecem funcionalidades como recuperação de falhas no processo de teste. Os exemplos a seguir demonstram como usar o Test Executor de linha de comando (use --help para obter mais detalhes):
Exemplo 1: execute testes funcionais do GLES2 em um dispositivo Android
executor --connect=127.0.0.1 --port=50016 --binaryname= com.drawelements.deqp/android.app.NativeActivity --caselistdir=caselists --testset=dEQP-GLES2.* --out=BatchResult.qpa --cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable --deqp-gl-config-name=rgba8888d24s8"
Exemplo 2: Continuar uma execução de teste parcial do OpenGL ES 2 localmente
executor --start-server=execserver/execserver --port=50016 --binaryname=deqp-gles2 --workdir=modules/opengl --caselistdir=caselists --testset=dEQP-GLES2.* --exclude=dEQP-GLES2.performance.* --in=BatchResult.qpa --out=BatchResult.qpa
Teste a exportação de log CSV e compare
O deqp possui uma ferramenta para converter logs de teste (arquivos qpa ) em arquivos CSV. A saída CSV contém uma lista de casos de teste e seus resultados. A ferramenta também pode comparar dois ou mais resultados de lote e listar apenas os casos de teste que possuem códigos de status diferentes nos resultados do lote de entrada. A comparação também imprimirá o número de casos correspondentes.
A saída em formato CSV é muito prática para processamento posterior com utilitários de linha de comando padrão ou com um editor de planilhas. Um formato de texto simples adicional, legível por humanos, pode ser selecionado usando o seguinte argumento de linha de comando: --format=text
Exemplo 1: Exportar log de teste em formato CSV
testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csvtestlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Exemplo 2: listar diferenças de resultados de teste entre dois logs de teste
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa
Nota: O argumento --value=code gera o código do resultado do teste, como "Aprovado" ou "Reprovado". O argumento --value=details seleciona a explicação adicional do resultado ou valor numérico produzido por um teste de desempenho, capacidade ou precisão.
Exportação XML do log de teste
Os arquivos de log de teste podem ser convertidos em documentos XML válidos usando o utilitário testlog-to-xml . Dois modos de saída são suportados:
- Modo de documentos separados, onde cada caso de teste e o documento de resumo
caselist.xmlsão gravados em um diretório de destino - Modo de arquivo único, onde 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. Documentos de folha de estilo de amostra ( testlog.xsl e testlog.css ) são fornecidos no diretório doc/testlog-stylesheet . Para renderizar os arquivos de log em um navegador, copie os dois arquivos de folha de estilo no mesmo diretório onde os documentos XML exportados estão localizados.
Se você estiver usando o Google Chrome, os arquivos deverão ser acessados por HTTP, pois o Chrome limita o acesso a arquivos locais por motivos de segurança. A instalação padrão do Python inclui um servidor HTTP básico que pode ser iniciado para servir o diretório atual com o comando python –m SimpleHTTPServer 8000 . Após iniciar o servidor, basta apontar o navegador Chrome para http://localhost:8000 para visualizar o log de teste.
Conversão para um log de teste JUnit
Muitos sistemas de automação de teste podem gerar relatórios de resultados de execução de teste a partir da saída JUnit. Os arquivos de log de teste deqp podem ser convertidos para o formato de saída JUnit usando a ferramenta testlog-to-junit.
A ferramenta atualmente oferece suporte à tradução apenas do veredicto do caso de teste. Como o JUnit suporta apenas resultados "aprovado" e "reprovado", um resultado aprovado do deqp é mapeado para "aprovado JUnit" e outros resultados são considerados falhas. O código de resultado deqp original está disponível na saída JUnit. Outros dados, como mensagens de log e imagens de resultados, não são preservados na conversão.
Use grupos de teste especiais
Alguns grupos de teste podem precisar ou suportar opções especiais de linha de comando ou exigir cuidados especiais quando usados em determinados sistemas.
Testes de estresse de alocação de memória
Os testes de estresse de alocação de memória exercitam condições de falta de memória alocando repetidamente determinados recursos até que o driver relate um erro de falta de memória.
Em determinadas plataformas, como Android e a maioria das variantes do Linux, pode ocorrer o seguinte: O sistema operacional pode encerrar o processo de teste em vez de permitir que um driver lide ou forneça um erro de falta de memória. Nessas plataformas, os testes projetados para causar erros de falta de memória são desabilitados por padrão e devem ser habilitados usando o argumento de linha de comando --deqp-test-oom=enable . É recomendável executar esses testes manualmente para verificar se o sistema se comporta corretamente sob pressão de recursos. No entanto, em tal situação, uma falha no processo de teste deve ser interpretada como uma aprovação.
Grupos de teste
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Testes de estresse de renderização de longa duração
Os testes de estresse de renderização são projetados para revelar problemas de robustez sob carga de renderização sustentada. Por padrão, os testes executarão apenas algumas iterações, mas podem ser configurados para serem executados indefinidamente, fornecendo o argumento de linha de comando --deqp-test-iteration-count=-1 . O watchdog de teste deve ser desabilitado ( --deqp-watchdog=disable ) ao executar esses testes por um longo período de tempo.
Grupos de teste
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2024-04-29 UTC.