TestNG Generazione di report in Selenium: Come generare?
⚡ Riepilogo intelligente
TestNG I report sono i file di risultati HTML predefiniti che TestNG Scrive nella cartella test-output dopo ogni esecuzione, mostrando quali casi di test sono stati superati, falliti o saltati, oltre a eventuali log di Reporter.
Che cosa sono TestNG Rapporti?
TestNG Report sono i report HTML predefiniti che vengono generati una volta eseguiti i casi di test utilizzando TestNG. Questi report aiutano a identificare le informazioni sui casi di test e sullo stato di un progetto. TestNG rapporti in Selenium Registra tre esiti per ogni metodo di test: superato, non superato e saltato, in modo da poter controllare i dati relativi ai casi di test a colpo d'occhio.
La generazione di report è molto importante quando si eseguono test di automazione e test manuali.
- Osservando il risultato, puoi facilmente identificare quanti casi di test sono stati superati, falliti e saltati.
- Osservando il rapporto, scoprirai qual è lo stato del progetto.
Selenium WebDriver viene utilizzato per automatizzare l'applicazione web, ma non genera autonomamente alcun report.
- Migliori TestNG genererà il rapporto predefinito.
- Quando esegui il file testng.xml e aggiorni il progetto, otterrai una cartella test-output, e tale cartella conterrà l'output di reporting da TestNG.
- Fai clic con il pulsante destro del mouse sul file emailable-report.html e seleziona l'opzione Apri con il browser web.
Nota: il comportamento qui descritto rimane invariato TestNG 7.x. Versioni da TestNG Dalla versione 7.6 in poi è richiesto JDK 11 o superiore, quindi un progetto più vecchio potrebbe necessitare di un aggiornamento del livello di JDK prima che i report vengano generati.
Tipi di TestNG Report nella cartella test-output
Prima di aprire un qualsiasi file, è utile sapere cosa contiene effettivamente la cartella di output dei test. TestNG Ad ogni esecuzione vengono creati diversi artefatti, ognuno dei quali risponde a una domanda diversa.
| File o cartella | Cosa contiene | Quando è utile |
| index.html | Il report di atterraggio che si collega ai risultati, ai gruppi, agli orari e alle visualizzazioni di output del reporter. | Analizzando nel dettaglio una singola esecuzione. |
| report-inviabile-via-email.html | Una singola pagina autonoma che riassume i metodi superati, non superati e saltati per ciascuna classe. | Condividere un risultato con persone che non aprono il progetto. |
| testng-results.xml | Il file XML leggibile dalla macchina, generato dal reporter XML integrato, con stato e durata per ciascun metodo. | Alimentazione di una dashboard o di un parser personalizzato. |
| junitreports | JUnit-file in formato XML, uno per ogni classe di test. | Qualsiasi plug-in CI che legge il JUnit formato del risultato. |
| testng-failed.xml | Un file di suite generato che elenca solo i metodi che hanno fallito. | Rieseguire solo i processi che hanno generato errori, anziché l'intera suite. |
I due file HTML sono quelli che questo tutorial aprirà successivamente, quindi la procedura descritta di seguito inizia con emailable-report.html.
Come generare report in Selenium
Metodo 1: emailable-report.html
- Fare clic sull'opzione "emailable-report.html"
- Fare clic sull'opzione browser web
Lo screenshot qui sotto mostra l'apertura del file emailable-report.html dalla cartella test-output.
L'output riporta in TestNG il reporting apparirà come di seguito se entrambe le classi vengono superate:
Considera lo scenario in cui stai intenzionalmente fallendo il test case, ad esempio la classe DemoB. Quindi converti entrambe le classi nel file della suite testng.xml ed eseguilo. Quindi il risultato sarà simile a questo. Mostrerà il casi di test falliti.
Questo è il risultato per la classe DemoB:
Allo stesso modo, il risultato per la Classe DemoA sarà simile al seguente:
Metodo-2: indice.html
- Fare clic con il tasto destro su index.html dalla directory del progetto.
- Seleziona l'opzione Apri con l'opzione del browser web. Verrà visualizzato il risultato nel seguente ordine.
Lo screenshot qui sotto mostra l'apertura del file index.html dalla directory del progetto.
Il risultato sarà simile a questo:
Metodo 3: Classe Reporter
Insieme a questi TestNG metodi generati dai report, è possibile utilizzare il file object.properties per archiviare i log generati dal sistema e dall'utente. Ma uno dei modi più semplici per archiviare le informazioni di registro nei test è l'utilizzo Classe Reporter.
Reporter.accedi Selenium è una classe presente in TestNG per Selenium segnalazione. Fornisce 4 diversi metodi per memorizzare le informazioni di registro che sono:
- Reporter.log(String s);
- Reporter.log(String s, booleano logToStandardOut);
- Reporter.log(String s, livello int);
- Reporter.log(String s, int level, booleano logToStandardOut);
Il secondo argomento decide se il messaggio viene visualizzato anche nella console oltre che nel report, mentre l'argomento level controlla il livello di dettaglio con cui il messaggio viene mantenuto.
Esempio:
Crea due classi, ad esempio DemoA e DemoB, e scrivi il seguente codice al loro interno.
Per la classe DemoA;
- Migliori Code per DemoA è già spiegato sopra. Qui stai usando log della classe Reporter. (Per implementare una classe di reporting personalizzata, la classe deve implementare l'interfaccia org.testng.IReporter.)
- Il metodo log è un metodo statico della classe Reporter. Quindi stai accedendo a quel metodo tramite la classe Reporter.
- Il metodo log viene utilizzato per archiviare le informazioni di registro scritte all'interno del programma. Osservando le informazioni di registro, scoprirai facilmente dove viene interrotta esattamente l'esecuzione del programma.
Lo screenshot qui sotto mostra le chiamate a Reporter.log inserite all'interno della classe DemoA.
Per la classe DemoB:
- Ora crea il file testng.xml selezionando queste due classi e
- Selezionare Esegui come e
- Fare clic su Converti in testing.
- Quindi esegui questo file testng.xml selezionando Esegui come e seleziona testng suite.
- Quindi aggiorna il progetto e apri la cartella test-output.
- Nella cartella test-output, apri emailable-report.html. Apparirà così:
Allo stesso modo, avrai anche un output per il progetto Demo B.
- Nella cartella test-output, apri il file index.html. Il contenuto sarà simile a questo:
Fare clic sull'output del reporter. Si apriranno le informazioni di registrazione scritte nei metodi di test.
Clicca sui tempi. Mostrerà quanto tempo è stato necessario per eseguire il metodo di test presente in classe utilizzando TestNG strumenti di segnalazione.
Come personalizzare TestNG Report con ITestListener e IReporter
I tre metodi sopra utilizzati sono tutti TestNG produce per impostazione predefinita. Quando un team ha bisogno di un layout diverso, campi aggiuntivi o una visualizzazione dello stato di avanzamento in tempo reale, TestNG espone due punti di estensione anziché richiedere di applicare una patch al report predefinito.
- ITest Listener Viene inviata una notifica in tempo reale all'inizio, al superamento, al fallimento o all'annullamento di ogni test. Utilizzatela quando è necessario acquisire le informazioni nel momento stesso in cui si verifica l'evento, ad esempio uno screenshot in caso di errore.
- Reporter Viene notificato una sola volta, al termine di ogni suite, e riceve oggetti che descrivono l'intera esecuzione. Utilizzalo quando l'output è un documento finale, come un PDF o una pagina HTML personalizzata.
Un listener che inserisce ciascun risultato nel report tramite la classe Reporter si presenta in questo modo.
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); } }
La registrazione del listener viene effettuata nello stesso file di suite testng.xml che hai già creato per DemoA e 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>
Due opzioni della riga di comando è utile da conoscere durante la sperimentazione. -d l'opzione modifica la directory in cui vengono scritti i report e -usedefaultlisteners false disattiva i reporter integrati in modo che venga eseguito solo il tuo listener. Entrambi sono descritti nel documento ufficiale. TestNG Registrazione e documentazione dei risultati, che documenta anche le proprietà accettate dal reporter XML integrato.
Un listener viene registrato una sola volta e poi si applica a ogni classe della suite, motivo per cui i team che gestiscono grandi test di automazione In genere, le suite di test preferiscono questa soluzione rispetto all'aggiunta manuale di righe di log a ciascun metodo di test.
TestNG Report predefiniti vs ExtentReports vs Allure
I report predefiniti sono sufficienti per una piccola suite, ma non contengono cronologia né grafici. Due librerie open-source vengono comunemente aggiunte quando una suite cresce, ed entrambe funzionano con TestNG.
| Capacità | TestNG difetto | Rapporti di estensione | Rapporto Allure |
| Sforzo di installazione | Nessuno — prodotto automaticamente | Aggiungi la libreria e scrivi il codice del reporter | Aggiungi l'adattatore, quindi genera il report dai risultati |
| Grafici e dashboard | Nodo | Si | Si |
| Screenshots | Solo tramite il markup Reporter.log | API per allegati integrata | API per allegati integrata |
| Storico delle corse e tendenze | Nodo | Tramite il componente server opzionale | Sì, dai risultati precedenti memorizzati |
| Copertura del quadro | TestNG esclusivamente | Java e .NET | Agnostico rispetto al framework |
Inizia con i report predefiniti finché la suite è piccola. Passa a Rapporti di estensione quando le parti interessate chiedono dashboard leggibili e per Rapporto Allure quando la cronologia dei test instabili tra le build diventa la questione che conta. Qualunque sia la tua scelta, il report viene normalmente pubblicato dal job di build, che è coperto nel Jenkins integrazione continua tutorial.












