O projeto AQAvit foi criado para "tornar a qualidade algo certo de acontecer." A verificação AQAvit é alcançada por meio do processo de executar e passar um conjunto prescrito e versionado de testes na suíte de testes AQAvit. A Eclipse Foundation Quality Verification Software License (QVSL) exige que aqueles que desejam verificar seu produto compartilhem um resumo dos resultados dos testes pelos quais a verificação foi alcançada. Este documento descreve como executar os testes de verificação AQAvit, verificar se a verificação foi aprovada e coletar os resultados dos testes necessários para publicação.
A verificação AQAvit é um dos critérios para listagem no Adoptium Marketplace. Aproveitar a suíte de testes AQAvit para garantir a qualidade dos binários listados no Adoptium Marketplace não só comunica aos consumidores o quanto levamos a qualidade a sério, mas também consolida as boas práticas de verificação dos membros do Adoptium Working Group sob um esforço centralizado. O AQAvit alinha os padrões da sua suíte de testes com os requisitos em constante mudança da base de usuários.
Visão Geral
A suíte de testes AQAvit é um grande conjunto de testes, muitos contribuídos ao projeto AQAvit e alguns extraídos de uma variedade de projetos de código aberto, que servem para verificar a qualidade dos binários OpenJDK. A suíte é adequada para testar Java SE 8 ou versões superiores em todas as plataformas suportadas. Para verificar binários, os testadores clonam uma versão especificada do repositório github aqa-tests (o último lançamento estável do repositório aqa-tests), configuram seu ambiente de teste, executam e passam os alvos de teste necessários contra cada binário que planejam verificar e disponibilizam os resultados dessas execuções de teste conforme o QVSL.
Alvos de Teste AQAvit para Executar
Os testes são divididos em diferentes grupos e esses grupos são divididos em 3 níveis. Esta categorização lógica dos testes oferece flexibilidade e granularidade e pode ser representada visualmente em uma grade.
Para a versão atual do AQAvit, o conjunto necessário de alvos de teste de nível superior a executar são [sanity.functional, extended.functional, special.functional, sanity.openjdk, extended.openjdk, sanity.system, extended.system, sanity.perf, extended.perf]. Em versões subsequentes do AQAvit, alvos serão adicionados para elevar ainda mais o nível de qualidade.
Detalhes sobre a Execução dos Testes
O AQAvit pode ser executado em vários ambientes de CI/CD, bem como diretamente via linha de comando em um contêiner ou em uma máquina de teste que tenha os pré-requisitos de teste instalados. Os passos básicos são os mesmos em qualquer ambiente.
git clone --depth 1 --branch v0.9.6-release https://github.com/adoptium/aqa-tests.git
export TEST_JDK_HOME=
export USE_TESTENV_PROPERTIES=true
export JDK_VERSION=17
export JDK_IMPL=hotspot
export BUILD_LIST=functional
cd aqa-tests
./get.sh
./compile.sh
cd TKG
make _sanity.functional
…
make _extended.system
Collect *.tap file and metadata file
Archive .zip
Publish .zip O projeto AQAvit criou uma action do Github que permite executar a suíte de testes AQAvit a partir de arquivos de workflow. A action run-aqa no repositório run-aqa permite que os usuários passem binários OpenJDK personalizados para verificação. Aqui está um exemplo de arquivo de workflow que pode executar alvos de nível sanity nas 3 plataformas suportadas disponíveis como runners do Github:
name: Run AQAvit
on:
workflow_dispatch: # Allows the job to be manually triggered
env: # Links to the JDK build under test and the native test libs
USE_TESTENV_PROPERTIES: true
BINARY_SDK: https://github.com/adoptium/temurin11-binaries/releases/download/jdk-11.0.14.1%2B1/OpenJDK11U-jdk_x64_linux_hotspot_11.0.14.1_1.tar.gz
NATIVE_LIBS: https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-linux-x64-hotspot/lastSuccessfulBuild/artifact/workspace/target/OpenJDK11U-testimage_x64_linux_hotspot_2022-02-12-17-06.tar.gz
jobs:
run_aqa:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
target: [sanity, extended]
suite: [functional, openjdk, system, perf]
include:
- target: special
suite: functional
steps:
- name: Run AQA Tests - ${{ matrix.target }}.${{ matrix.suite }}
uses: adoptium/run-aqa@v2
with:
version: '11'
jdksource: 'customized'
customizedSdkUrl: ${{ env.BINARY_SDK }} ${{ env.NATIVE_LIBS }}
aqa-testsRepo: 'adoptium/aqa-tests:v0.9.6-release' # Make sure this branch is set to the latest release branch
build_list: ${{ matrix.suite }}
target: _${{ matrix.target }}.${{ matrix.suite }}
- uses: actions/upload-artifact@v2
if: always() # Always run this step (even if the tests failed)
with:
name: test_output
path: ./**/output_*/*.tapSe você estiver usando o código do pipeline de testes Jenkins do AQAvit disponível no repositório aqa-tests e descrito na documentação na seção Jenkins Setup and Running, estes são os parâmetros adicionais que você definirá para executar os alvos de teste necessários.
# Set Jenkins job parameters
ADOPTOPENJDK_REPO=https://github.com/adoptium/aqa-tests.git
ADOPTOPENJDK_BRANCH=v0.9.6-release
USE_TESTENV_PROPERTIES=true
# Execute test targets
TARGET=sanity.functional and subsequently [extended.functional|special.functional|sanity.openjdk|extended.openjdk|sanity.system|extended.system|sanity.perf|extended.perf]
# Collect and publish results
Collect *.tap file and metadata file
Archive .zip
Publish .zip Os arquivos .tap e arquivos de metadados contêm timestamps e informações sobre o binário em teste. Essas informações são coletadas da saída java -version, informações do arquivo release e consultando algumas propriedades do sistema durante a execução do teste. Quando aplicável, as informações devem corresponder ao binário listado no marketplace.
Verificando os Resultados
A suíte de testes AQAvit produz arquivos de resultado de teste e arquivos de metadados ao final da execução dos testes. Após executar e passar cada um dos nove alvos de teste necessários, os arquivos de resultado e metadados devem ser coletados e compartilhados. Para alvos de teste que contêm falhas, a causa raiz da falha deve ser tratada e o alvo pode ser reexecutado e um arquivo de resultado de teste atualizado produzido e compartilhado.
Os arquivos de resultado de teste produzidos seguem uma certa convenção de nomenclatura e usam um protocolo TAP simples (Test Anything Protocol). Quando os alvos de nível superior são executados em série, um único arquivo .tap é produzido, por exemplo:
Test_openjdk11_hs_sanity.system_aarch64_linux.tap
contém informações de versão, impl/distribuição, alvo de teste e plataforma no nome, e seu conteúdo é assim:
# Timestamp: Wed Mar 2 10:51:55 2022 UTC
1..168
ok 1 - MachineInfo_0
---
duration_ms: 581
...
ok 2 - ClassLoadingTest_5m_0
---
duration_ms: 304339
...
ok 3 - ClassLoadingTest_5m_1
---
duration_ms: 303883
...
etc.
...
ok 168 - MauveMultiThrdLoad_5m_1
---
duration_ms: 304296
...Pode-se ver neste exemplo que o alvo de nível superior sanity.system contém 168 sub-alvos. Do conjunto de sub-alvos esperados, alguns podem ser 'ignorados' por serem filtrados como não aplicáveis para uma versão ou plataforma específica, mas não pode haver nenhum que tenha falhado. Dentro do arquivo tap, eles serão exibidos como 'not ok' se tiverem falhado. Sub-alvos com falha podem ser reexecutados individualmente e o arquivo tap produzido para essa execução individual pode ser incluído no arquivo <results>.zip para indicar que o binário em teste foi capaz de passar em todos os alvos esperados.
