TestNG Rapportgenerering i Selenium: Hvordan genererer man?

⚡ Smart opsummering

TestNG Rapporter er standard HTML-resultatfilerne, der TestNG skriver til test-output-mappen efter hver kørsel og viser hvilke testcases der bestod, mislykkedes eller blev sprunget over, plus eventuelle Reporter-logfiler.

  • 🔘 Standardoutput: Hver TestNG `run` opretter en test-output-mappe uden ekstra kode.
  • ☑️ To HTML-visninger: emailable-report.html opsummerer resultater, index.html linker til de detaljerede visninger.
  • ✅ Reporterlogfiler: Reporter.log() skriver brugerdefinerede beskeder direkte ind i den genererede rapport.
  • 🧪 Suiten kører: Kørsel af testng.xml grupperer flere klasser i én samlet rapport.
  • 🛠️ Tilpasning: ITestListener og iReporter lader et team opbygge sit eget rapportformat.
  • 📊 Ud over standardindstillinger: ExtentReports og Allure tilføjer diagrammer, historik og vedhæftede skærmbilleder.

TestNG generering af rapporter i Selenium

Hvad er TestNG Rapporter?

TestNG Rapporter er standard HTML-rapporter, som genereres, når testcaserne er udført vha TestNG. Disse rapporter hjælper dig med at identificere oplysningerne om testcases og status for et projekt. TestNG rapporterer i Selenium Registrer tre resultater for hver testmetode – bestået, ikke bestået og spring over – så du kan tjekke dataene om testcases med et hurtigt blik.

Rapportgenerering er meget vigtig, når du laver automationstestning såvel som for manuel test.

  • Ved at se på resultatet kan du nemt identificere, hvor mange testsager der er bestået, ikke bestået og sprunget over.
  • Ved at se på rapporten får du at vide, hvad status på projektet er.

Selenium WebDriver bruges til at automatisere webapplikationen, men den genererer ikke nogen rapporter i sig selv.

  • TestNG vil generere standardrapporten.
  • Når du udfører testng.xml-filen og opdaterer projektet, får du en test-output-mappe, og den mappe indeholder rapporteringsoutputtet fra TestNG.
  • Højreklik på emailable-report.html og vælg indstillingen Åbn med webbrowseren.

Bemærk: Den her beskrevne adfærd er uændret i TestNG 7.x. Udgivelser fra TestNG 7.6 og nyere kræver JDK 11 eller højere, så et ældre projekt skal muligvis have sit JDK-niveau hævet, før rapporterne produceres.

Typer af TestNG Rapporter i test-output-mappen

Før du åbner en enkelt fil, er det nyttigt at vide, hvad test-output-mappen rent faktisk indeholder. TestNG skriver adskillige artefakter på hver kørsel, og hver enkelt besvarer et forskelligt spørgsmål.

Fil eller mappe Hvad den indeholder Når det er nyttigt
index.html Landingsrapporten, der linker til resultater, grupper, tidspunkter og visninger af rapporterens output. Dykker ned i ét løb i detaljer.
emailable-rapport.html En enkelt selvstændig side, der opsummerer beståede, mislykkede og oversprungne metoder pr. klasse. Deling af et resultat med personer, der ikke åbner projektet.
testng-resultater.xml Den maskinlæsbare XML skrevet af den indbyggede XML-reporter, med status og varighed pr. metode. Fodring af et dashboard eller en brugerdefineret parser.
junireports JUnit-format XML-filer, én pr. testklasse. Ethvert CI-plugin, der læser JUnit resultatformat.
testng-failed.xml En genereret suite-fil, der kun viser de metoder, der mislykkedes. Genkører kun fejlene i stedet for hele pakken.

De to HTML-filer er dem, som denne vejledning åbner herefter, så gennemgangen nedenfor starter med emailable-report.html.

Sådan genererer du rapporter i Selenium

Metode-1: emailable-report.html

  1. Klik på indstillingen "emailable-report.html"
  2. Klik på indstillingen webbrowser

Skærmbilledet nedenfor viser filen emailable-report.html, der åbnes fra mappen test-output.

Valg af emailable-report.html i TestNG test-output-mappe

Outputtet rapporterer i TestNG rapportering vil se ud som nedenfor, hvis begge klasser er bestået:

TestNG E-mailbar rapport, der viser beståede DemoA- og DemoB-testklasser

Overvej scenariet, hvor du bevidst fejler testsagen, dvs. DemoB-klassen. Konverter derefter begge klasser til testng.xml suite-filen og kør den. Så vil resultatet se sådan ud. Det vil vise mislykkede testsager.

Dette er resultatet for DemoB-klassen:

E-mailbar rapport, der fremhæver den bevidst mislykkede DemoB-testcase

På samme måde vil resultatet for Class DemoA se sådan ud:

Rapportoversigtsrække, der kan sendes via e-mail, for den beståede DemoA-klasse

Metode-2: index.html

  1. Højreklik på index.html fra projektbiblioteket.
  2. Vælg mulighed åben med webbrowser mulighed. Det vil vise resultatet i følgende rækkefølge.

Skærmbilledet nedenfor viser index.html, der åbnes fra projektmappen.

Åbning af index.html fra projektmappen i en webbrowser

Resultatet vil se sådan ud:

TestNG index.html-rapportens landingsside med en liste over visninger af kørselsresultater

Metode-3: Reporterklasse

Sammen med disse TestNG rapportgenererede metoder, kan du bruge filen object.properties til at gemme de systemgenererede logfiler såvel som brugergenererede logfiler. Men en af ​​de enkleste måder at gemme logoplysninger på i test er at bruge Reporter klasse.

Reporter.log ind Selenium er en klasse til stede i TestNG forum Selenium rapportering. Det giver 4 forskellige metoder til at gemme logoplysninger, de er:

  1. Reporter.log(String s);
  2. Reporter.log(String s, Boolean logToStandardOut);
  3. Reporter.log(String s, int niveau);
  4. Reporter.log(String s, int niveau, boolesk logToStandardOut);

Det andet argument afgør, om beskeden sendes via ekko til konsollen såvel som rapporten, og argumentet "level" styrer den ordgrænsning, som beskeden holdes ved.

Eksempel:

Opret to klasser såsom DemoA og DemoB og skriv følgende kode inde i klasserne.

For klasse DemoA;

  • Code for DemoA er allerede forklaret ovenfor. Her bruger du logmetode for Reporter-klassen. (For at implementere din egen rapporteringsklasse skal klassen implementere org.testng.IReporter-grænsefladen.)
  • Logmetoden er en statisk metode af Reporter-klassen. Så du får adgang til den metode gennem Reporter-klassen.
  • Logmetoden bruges til at gemme logoplysninger, der er skrevet inde i programmet. Ved at se på logoplysningerne, vil du nemt komme til at vide, hvor nøjagtigt udførelsen af ​​programmet stoppes.

Skærmbilledet nedenfor viser Reporter.log-kaldene, der er placeret i DemoA-klassen.

Reporter.log-sætninger skrevet i DemoA-testklassen

For klassedemoB:

Reporter.log-sætninger skrevet i DemoB-testklassen

  • Opret nu testng.xml fil ved at vælge disse to klasser og
  • Vælg kør som og
  • Klik på konverter til testng.
  • Kør derefter denne testng.xml fil ved at vælge kør som og vælg testng suite.
  • Opdater derefter projektet, åbn test-output-mappen.
  1. I test-output-mappen skal du åbne emailable-report.html. Det vil se sådan ud:

    E-mail-rapport produceret efter kørsel af DemoA- og DemoB-testng.xml-pakken

    På samme måde vil du også have et output til Demo B-projekt.

  2. I test-output-mappen skal du åbne index.html. Den vil se sådan ud:

    index.html-rapport produceret efter kørsel af testng.xml-pakken

Klik på reporteroutput. Det vil åbne logningsoplysninger, uanset hvad der er skrevet i testmetoderne.

TestNG Reporter outputvisning, der viser de meddelelser, der er logget af testmetoderne

Klik på Tiderne. Det vil vise, hvor meget tid det tog at køre testmetoden, der er til stede i klassen ved hjælp af TestNG rapporteringsværktøjer.

TestNG Tidsvisning, der viser, hvor lang tid hver testmetode tog at køre

Sådan tilpasses TestNG Rapporter med ITestListener og iReporter

De tre ovenstående metoder bruger hvad som helst TestNG producerer som standard. Når et team har brug for et andet layout, ekstra felter eller en live statusvisning, TestNG eksponerer to udvidelsespunkter i stedet for at bede dig om at opdatere standardrapporten.

  • ITestListener får besked i realtid, når hver test starter, består, fejler eller springes over. Brug den, når oplysningerne skal registreres i det øjeblik, hændelsen sker – f.eks. et skærmbillede ved fejl.
  • IR-rapporter får besked én gang, efter hver suite er færdig, og modtager objekter, der beskriver hele kørslen. Brug den, når outputtet er et færdigt dokument, f.eks. en PDF eller en brugerdefineret HTML-side.

En lytter, der skubber hvert resultat ind i rapporten via Reporter-klassen, ser sådan ud.

import org.testng.ITestListener;
import org.testng.ITestResult;
import org.testng.Reporter;

public class ReportListener implements ITestListener {

    @Override
    public void onTestSuccess(ITestResult result) {
        Reporter.log("PASSED: " + result.getName(), true);
    }

    @Override
    public void onTestFailure(ITestResult result) {
        Reporter.log("FAILED: " + result.getName(), true);
    }

    @Override
    public void onTestSkipped(ITestResult result) {
        Reporter.log("SKIPPED: " + result.getName(), true);
    }
}

Registrering af lytteren udføres i den samme testng.xml-suitefil, som du allerede har oprettet til DemoA og DemoB.

<suite name="Demo Suite">
  <listeners>
    <listener class-name="ReportListener" />
  </listeners>
  <test name="Demo Test">
    <classes>
      <class name="DemoA" />
      <class name="DemoB" />
    </classes>
  </test>
</suite>

To kommandolinjeparametere er værd at kende, mens du eksperimenterer. -d indstillingen ændrer den mappe, som rapporterne skrives til, og -usedefaultlisteners falsk slår de indbyggede reportere fra, så kun din egen lytter kører. Begge er beskrevet i den officielle TestNG logføring og resultatdokumentation, som også dokumenterer de egenskaber, der accepteres af den indbyggede XML-reporter.

En lytter registreres én gang og ansøger derefter om hver klasse i pakken, hvilket er grunden til, at teams, der kører store automatiseringstest Suiter foretrækker det normalt frem for at tilføje loglinjer til hver testmetode manuelt.

TestNG Standardrapporter vs. ExtentReports vs. Allure

Standardrapporterne er nok til en lille pakke, men de indeholder ingen historik og ingen diagrammer. To open source-biblioteker tilføjes normalt, når en pakke vokser, og begge fungerer med TestNG.

Capability TestNG standard Omfangsrapporter Allure-rapport
Opsætningsindsats Ingen — produceres automatisk Tilføj biblioteket og skriv reporterkoden Tilføj adapteren, og generer derefter rapporten ud fra resultaterne
Diagrammer og dashboards Ingen Ja Ja
Screenshots Kun via Reporter.log-markup Indbygget API til vedhæftede filer Indbygget API til vedhæftede filer
Kørselshistorik og tendenser Ingen Gennem den valgfri serverkomponent Ja, fra gemte tidligere resultater
Rammedækning TestNG kun Java og .NET Framework-agnostisk

Start med standardrapporterne, mens pakken er lille. Flyt til Omfangsrapporter når interessenter beder om læsbare dashboards, og til Allure-rapport når ustabil testhistorik på tværs af builds bliver det spørgsmål, der betyder noget. Uanset hvad du vælger, udgives rapporten normalt af buildjobbet, som er dækket i Jenkins kontinuerlig integration tutorial.

Ofte Stillede Spørgsmål

Mappen vises først efter TestNG afslutter en kørsel, og projektet opdateres i IDE'en. En tom mappe betyder normalt, at klassen blev startet som en almindelig Java applikation, eller standardlytterne var slået fra, så ingen reporter kørte nogensinde.

Ja. TestNG skriver som standard til test-output. Send -d-indstillingen på kommandolinjen, eller angiv outputmappen i IDE-kørselskonfigurationen eller i Maven Surefire-indstillingerne, der starter pakken.

Optag billedet i en lyttermetode, f.eks. onTestFailure, gem filen ved siden af ​​rapporten, og skriv derefter et HTML-billedtag via Reporter.log. Rapporten gengiver markup'en, så billedet vises ved siden af ​​den mislykkede metode.

TestNG sender ikke selv mail. Teams vedhæfter normalt emailable-report.html fra et byggejob, for eksempel en Jenkins trin efter opbygning af e-mail, eller tilføj en lille mailrutine i en iReporter-implementering.

AI-modeller grupperer fejl efter stak-tracligheden, adskille ægte defekter fra miljø- eller timingfejl, og rangordne hvilke fejlende metoder, der skal inspiceres først. En lang liste med rapporter, der kan sendes via e-mail, bliver en kort prioriteret kø for teamet.

GitHub Copilot kan scaffolde lytterklasser, Reporter.log-sætninger og testng.xml-poster fra en kort kommentar. Revse alle forslag, fordi genererede lyttere ofte overser de præcise grænseflademetoder TestNG forventer.

Når en IRetryAnalyzer er tilsluttet, registreres hvert nyt forsøg sammen med det endelige resultat. Standardrapporten viser derfor hvert forsøg, så en ustabil test kan fremstå som både en fiasko og en bestået test i samme kørsel.

Send -usedefaultlisteners false på kommandolinjen, eller indstil useDefaultListeners til false i Maven Surefire- eller Ant-konfigurationen. Kun de reportere, du registrerer eksplicit, køres derefter, hvilket forkorter kørslen for meget store suiter.

Opsummer dette indlæg med: