Allure Reports: Aussagekräftige Testberichte erstellen

1. Warum ein dediziertes Reporting-Werkzeug sinnvoll ist

Die native Konsolenausgabe der meisten Test-Frameworks eignet sich gut für die unmittelbare Rückmeldung während der Entwicklung, versagt aber, sobald mehrere Personen im Team regelmäßig einen Überblick über den Zustand der gesamten Testsuite benötigen, ohne selbst jeden einzelnen Testlauf lokal auszuführen. Ohne ein aufbereitetes, geteiltes Dashboard bleibt der tatsächliche Zustand der Testsuite für alle außer der Person, die den letzten CI-Lauf gestartet hat, weitgehend unsichtbar.

Allure Report adressiert dieses Problem, indem es aus einem maschinenlesbaren, framework-unabhängigen JSON-Zwischenformat ein vollständiges, statisches HTML-Dashboard generiert, das sich problemlos als CI-Artefakt veröffentlichen und im gesamten Team teilen lässt, ohne dass jemand ein spezielles Werkzeug lokal installieren muss, um den Bericht anzusehen. Der entscheidende architektonische Vorteil dieses Zwischenformats ist, dass praktisch jedes gängige Test-Framework, von Cypress über Playwright bis zu PHPUnit, dasselbe Format erzeugen kann, wodurch Allure als gemeinsame, framework-übergreifende Reporting-Schicht für ein heterogenes Testökosystem dient.

Gerade in einem gewachsenen Magento-Projekt, in dem parallel Frontend-E2E-Tests mit Playwright und Backend-Integrationstests mit PHPUnit laufen, zahlt sich diese Framework-Übergreifendheit besonders aus, da beide Testarten am Ende im selben, einheitlichen Dashboard erscheinen, statt zwei getrennte, inkonsistent aussehende Berichte in unterschiedlichen Werkzeugen pflegen zu müssen, die jeweils eigene Lernkurven für alle Beteiligten mit sich bringen und den Gesamtüberblick über die tatsächliche Testabdeckung des Projekts erschweren.

2. Setup für Playwright

Die Integration von Allure in ein bestehendes Playwright-Projekt beschränkt sich im Kern auf die Installation eines zusätzlichen Reporter-Pakets und dessen Eintragung in der Playwright-Konfiguration, wonach jeder Testlauf automatisch die für Allure benötigten JSON-Ergebnisdateien in einem eigenen Ausgabeverzeichnis erzeugt.

npm install --save-dev allure-playwright allure-commandline

3. Konfiguration und Report-Generierung im Detail

Nach der Installation muss der Reporter in der Playwright-Konfigurationsdatei registriert werden, wobei sich mehrere Reporter parallel eintragen lassen, etwa der native `list`-Reporter für die Konsole zusätzlich zum `allure-playwright`-Reporter für die spätere HTML-Generierung. Nach jedem Testlauf erzeugt der Befehl `allure generate` aus den gesammelten Rohdaten das vollständige, interaktive HTML-Dashboard. Dieser Generierungsschritt lässt sich problemlos als letzter Schritt in die CI-Pipeline einbauen, sodass der fertige Bericht ohne manuellen Zusatzaufwand nach jedem Lauf automatisch vorliegt.

// playwright.config.js
module.exports = {
  reporter: [
    ['list'],
    ['allure-playwright', { resultsDir: 'allure-results' }],
  ],
  use: {
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: 'retain-on-failure',
  },
};

4. Screenshots und Videos aussagekräftig einbinden

Damit ein Screenshot im Allure-Bericht tatsächlich Kontext liefert, sollte er nicht nur beim finalen Fehlschlag, sondern idealerweise auch nach jedem einzelnen relevanten Testschritt aufgenommen werden, wofür sich ein benutzerdefinierter Attachment-Aufruf innerhalb des Testcodes eignet. Playwright unterstützt zusätzlich das Aufzeichnen eines vollständigen Traces, der neben Screenshots auch den DOM-Zustand, Netzwerkanfragen und Konsolen-Logs zu jedem Zeitpunkt des Testlaufs enthält und sich direkt im Trace-Viewer öffnen lässt, ohne den Test lokal erneut ausführen zu müssen.

Videos eignen sich besonders für Testfälle mit komplexen, mehrstufigen Benutzerinteraktionen, bei denen ein einzelner Screenshot den zeitlichen Ablauf nicht ausreichend erfasst, etwa bei einem mehrschrittigen Checkout-Prozess mit mehreren Formularfeldern, während für einfache, kurze Testfälle ein aussagekräftiger Screenshot meist ausreicht und Speicherplatz spart.

import { test } from '@playwright/test';
import { allure } from 'allure-playwright';

test('Warenkorb zeigt korrekte Zwischensumme', async ({ page }) => {
  await page.goto('/checkout/cart');
  await allure.step('Screenshot vor Preisberechnung', async () => {
    await page.screenshot({ path: 'vor-berechnung.png' });
  });
  await page.click('[data-testid="apply-coupon"]');
  await allure.attachment('Warenkorb-Zustand', await page.screenshot(), 'image/png');
});

5. Trend-Ansicht über mehrere Testläufe hinweg

Der eigentliche Mehrwert von Allure gegenüber einem simplen, einmaligen HTML-Bericht liegt in der History-Funktion, die frühere Ergebnisse mit dem aktuellen Lauf zusammenführt und daraus automatisch Trend-Grafiken erzeugt, etwa zur Entwicklung der Erfolgsquote, der durchschnittlichen Ausführungsdauer und der Anzahl instabiler, wiederholt fehlschlagender Tests über die letzten Läufe hinweg.

Damit diese History-Funktion überhaupt greift, muss das `history`-Verzeichnis des vorangegangenen Berichts vor jedem neuen Lauf in das aktuelle Ergebnisverzeichnis kopiert werden, was in einer CI-Pipeline üblicherweise bedeutet, dieses Verzeichnis als eigenes, persistentes Artefakt zwischen aufeinanderfolgenden Pipeline-Läufen zu übertragen, statt es bei jedem Lauf verloren gehen zu lassen. Ohne diesen zusätzlichen Schritt beginnt die Trend-Historie bei jedem CI-Lauf wieder bei null, was den größten Nutzen der Funktion praktisch zunichtemacht. In den meisten CI-Systemen lässt sich dieses Verhalten über einen einfachen Cache- oder Artefakt-Mechanismus abbilden, der ohnehin schon für andere, wiederkehrende Build-Bestandteile genutzt wird.

6. Ein Team-Dashboard aus dem Allure-Bericht aufbauen

Für ein Team, das den generierten HTML-Bericht dauerhaft und zentral einsehen möchte, empfiehlt sich das Hosten über den Allure-Server-Modus oder das automatische Veröffentlichen als statische Seite nach jedem CI-Lauf, etwa auf GitLab Pages oder einem vergleichbaren internen Hosting-Dienst, statt den Bericht nur als flüchtiges, herunterladbares CI-Artefakt bereitzustellen.

Ein zusätzlicher, praktischer Baustein ist die Integration eines Status-Badges oder eines kurzen Zusammenfassungskommentars direkt im Pull Request, der die wichtigsten Kennzahlen des zugehörigen Testlaufs, etwa Erfolgsquote und Anzahl neu aufgetretener Fehlschläge, bereits ohne einen Klick auf den vollständigen Bericht sichtbar macht und so die Einstiegshürde für ein regelmäßiges Betrachten der Testergebnisse im gesamten Team senkt.

7. Kategorien, Labels und Severity sinnvoll einsetzen

Allure erlaubt es, Tests mit strukturierten Metadaten wie Severity-Stufe, Feature-Bereich oder Epic anzureichern, wodurch sich der Bericht im Nachhinein gezielt filtern und gruppieren lässt, etwa um ausschließlich Tests mit der Severity `critical` zu betrachten oder alle Tests eines bestimmten Feature-Bereichs auf einen Blick zusammenzufassen, statt die gesamte, oft mehrere hundert Testfälle umfassende Liste manuell zu durchsuchen.

Zusätzlich lassen sich über benutzerdefinierte Kategorien Fehlschläge nach Ursachenklasse gruppieren, etwa "Bekannter, noch nicht behobener Bug" gegenüber "Neuer, echter Regressions-Fehler", was bei der täglichen Durchsicht der CI-Ergebnisse hilft, tatsächlich neue Probleme von bereits bekannten und akzeptierten Einschränkungen zu unterscheiden, ohne bei jedem Durchlauf erneut dieselbe manuelle Einordnung vornehmen zu müssen. Diese Konsequenz bei der Pflege der Metadaten zahlt sich besonders bei einer wachsenden Testsuite aus, da ein sauber kategorisierter Bericht mit mehreren hundert Testfällen weiterhin in wenigen Sekunden durchsuchbar bleibt, während eine unkategorisierte, gleich große Liste schnell unübersichtlich wird.

8. Abgrenzung zu anderen Reporting-Werkzeugen

Neben Allure existieren weitere verbreitete Reporting-Werkzeuge wie Mochawesome für Mocha-basierte Projekte oder die nativen Cucumber-HTML-Reports, die ebenfalls aus rohen Testergebnissen einen lesbaren Bericht erzeugen, sich aber meist auf ein einzelnes Test-Framework beschränken und in der Regel keine eingebaute History-Funktion über mehrere Läufe hinweg mitbringen, wodurch die Trend-Betrachtung dort selbst gebaut werden müsste, statt sie sofort einsatzbereit zu erhalten.

Auch reine JUnit-XML-Ausgaben, wie sie viele CI-Systeme direkt in ihrer eigenen Oberfläche darstellen können, liefern zwar eine gewisse Grundfunktionalität für Erfolg und Fehlschlag, bleiben dabei aber auf die textuelle Fehlermeldung beschränkt und bieten weder Screenshots noch Videos noch eine strukturierte Kategorisierung nach Ursache, was sie für ein Team, das regelmäßig tiefergehende Fehleranalyse betreiben möchte, deutlich weniger praktikabel macht als ein dediziertes Werkzeug wie Allure. Der entscheidende Vorteil von Allure gegenüber diesen Alternativen liegt somit weniger in der reinen HTML-Darstellung selbst, sondern in der Kombination aus Framework-Übergreifendheit, eingebauter History und reichhaltigen Anhängen an einem einzigen, konsistenten Ort, statt diese drei Aspekte über mehrere, getrennt gepflegte Werkzeuge zusammensuchen zu müssen.

9. Allure-Funktionen im Überblick

Die folgende Tabelle fasst die vorgestellten Allure-Funktionen zusammen.

10. Zusammenfassung

11. FAQ: Allure Reports: Das Wichtigste auf einen Blick