Das AQAvit-Projekt wurde gegründet, um „Qualität zur Gewissheit zu machen." Die AQAvit-Verifizierung erfolgt durch das Ausführen und erfolgreiche Bestehen eines festgelegten und versionierten Satzes von Tests in der AQAvit-Testsuite. Die Eclipse Foundation Quality Verification Software License (QVSL) verpflichtet diejenigen, die ihr Produkt verifizieren möchten, eine Zusammenfassung der Testergebnisse zu veröffentlichen, mit denen die Verifizierung erreicht wurde. Dieses Dokument beschreibt, wie die AQAvit-Verifizierungstests ausgeführt werden, wie überprüft wird, ob die Verifizierung bestanden wurde, und wie die erforderlichen Testergebnisse für die Veröffentlichung gesammelt werden.
Die AQAvit-Verifizierung ist eines der Kriterien für die Aufnahme in den Adoptium Marketplace. Die Nutzung der AQAvit-Testsuite zur Sicherstellung der Qualität der im Adoptium Marketplace aufgeführten Binärdateien zeigt nicht nur, wie ernst wir Qualität nehmen, sondern bündelt auch die guten Verifizierungspraktiken der Mitglieder der Adoptium Working Group unter einem zentralen Ansatz. AQAvit richtet die Standards seiner Testsuite an den sich ändernden Anforderungen der Nutzerbasis aus.
Überblick
Die AQAvit-Testsuite ist eine umfangreiche Sammlung von Tests – viele davon zum AQAvit-Projekt beigesteuert und einige aus einer Vielzahl von Open-Source-Projekten entnommen –, die dazu dienen, die Qualität von OpenJDK-Binärdateien zu verifizieren. Die Suite eignet sich zum Testen von Java SE 8 oder höher auf allen unterstützten Plattformen. Um Binärdateien zu verifizieren, klonen Tester einen festgelegten Release des aqa-tests-GitHub-Repositorys (den neuesten stabilen Release des aqa-tests-Repositorys), konfigurieren ihre Testumgebung, führen die erforderlichen Test-Targets gegen jede zu verifizierende Binärdatei aus und bestehen diese, und stellen die Ergebnisse dieser Testläufe gemäß der QVSL zur Verfügung.
Auszuführende AQAvit-Test-Targets
Die Tests sind in verschiedene Gruppen aufgeteilt, und diese Gruppen sind in 3 Ebenen untergliedert. Diese logische Kategorisierung der Tests bietet Flexibilität und Granularität und lässt sich visuell in einem Raster darstellen.
Für den aktuellen AQAvit-Release sind folgende erforderliche übergeordnete Test-Targets auszuführen: [sanity.functional, extended.functional, special.functional, sanity.openjdk, extended.openjdk, sanity.system, extended.system, sanity.perf, extended.perf]. In nachfolgenden AQAvit-Releases werden weitere Targets hinzugefügt, um die Qualitätsanforderungen weiter zu erhöhen.
Details zur Testausführung
AQAvit kann in verschiedenen CI/CD-Umgebungen sowie direkt über die Kommandozeile in einem Container oder auf einem Testrechner ausgeführt werden, auf dem die Testvoraussetzungen installiert sind. Die grundlegenden Schritte sind in jeder Umgebung gleich.
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 Das AQAvit-Projekt hat eine Github-Action erstellt, die das Ausführen der AQAvit-Testsuite aus Workflow-Dateien ermöglicht. Die run-aqa-Action im run-aqa-Repository erlaubt es Benutzern, eigene OpenJDK-Binärdateien zur Verifizierung zu übergeben. Hier ist eine Beispiel-Workflow-Datei, die Sanity-Level-Targets auf den 3 unterstützten Plattformen ausführen kann, die als Github-Runner verfügbar sind:
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_*/*.tapWenn Sie den AQAvit-Jenkins-Testpipeline-Code verwenden, der im aqa-tests-Repository verfügbar und im Abschnitt Jenkins Setup and Running der Dokumentation beschrieben ist, sind dies die zusätzlichen Parameter, die Sie setzen müssen, um die erforderlichen Test-Targets auszuführen.
# 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 Die .tap-Dateien und Metadaten-Dateien enthalten Zeitstempel und Informationen über die getestete Binärdatei. Diese Informationen werden aus der Ausgabe von java -version, Informationen aus der Release-Datei sowie durch Abfragen einiger Systemeigenschaften während des Testlaufs gesammelt. Soweit zutreffend, sollten die Informationen mit der im Marketplace aufgeführten Binärdatei übereinstimmen.
Ergebnisse überprüfen
Die AQAvit-Testsuite erzeugt am Ende der Testausführung Testergebnis- und Metadaten-Dateien. Nach dem Ausführen und erfolgreichen Bestehen jedes der neun erforderlichen Test-Targets sind die Ergebnis- und Metadaten-Dateien zu sammeln und zu teilen. Bei Test-Targets, die Fehler enthalten, sollte die Ursache des Fehlers behoben werden; anschließend kann das Target erneut ausgeführt und eine aktualisierte Testergebnis-Datei erstellt und geteilt werden.
Die erzeugten Testergebnis-Dateien folgen einer bestimmten Namenskonvention und verwenden ein einfaches TAP-Format (Test Anything Protocol). Wenn übergeordnete Targets seriell ausgeführt werden, wird eine einzelne .tap-Datei erzeugt, zum Beispiel:
Test_openjdk11_hs_sanity.system_aarch64_linux.tap
enthält Version, Implementierung/Distribution, Test-Target und Plattforminformationen im Namen, und ihr Inhalt sieht wie folgt aus:
# 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
...Man kann in diesem Beispiel sehen, dass das übergeordnete Target sanity.system 168 Sub-Targets enthält. Von der Menge der erwarteten Sub-Targets können einige als „übersprungen" markiert sein, weil sie für eine bestimmte Version oder Plattform herausgefiltert wurden – es darf jedoch kein fehlgeschlagenes Sub-Target geben. In der tap-Datei erscheinen fehlgeschlagene Sub-Targets als „not ok". Fehlgeschlagene Sub-Targets können einzeln erneut ausgeführt werden, und die für diesen einzelnen Lauf erzeugte tap-Datei kann in die <results>.zip-Datei aufgenommen werden, um nachzuweisen, dass die getestete Binärdatei alle erwarteten Targets bestehen konnte.
