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.
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
- Klik på indstillingen "emailable-report.html"
- Klik på indstillingen webbrowser
Skærmbilledet nedenfor viser filen emailable-report.html, der åbnes fra mappen test-output.
Outputtet rapporterer i TestNG rapportering vil se ud som nedenfor, hvis begge klasser er bestået:
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:
På samme måde vil resultatet for Class DemoA se sådan ud:
Metode-2: index.html
- Højreklik på index.html fra projektbiblioteket.
- 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.
Resultatet vil se sådan ud:
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:
- Reporter.log(String s);
- Reporter.log(String s, Boolean logToStandardOut);
- Reporter.log(String s, int niveau);
- 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.
For klassedemoB:
- 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.
- I test-output-mappen skal du åbne emailable-report.html. Det vil se sådan ud:
På samme måde vil du også have et output til Demo B-projekt.
- I test-output-mappen skal du åbne index.html. Den vil se sådan ud:
Klik på reporteroutput. Det vil åbne logningsoplysninger, uanset hvad der er skrevet i 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.
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.












