Test end-to-end e test di integrazione: cosa coglie ciascuno (con esempi)
Test end-to-end e test di integrazione: cosa vede ciascuno, il bug del checkout che solo un test dello schermo coglie, la piramide dei test, e quanti test end-to-end servono.
10 min di letturaDi Ait Nohaila, Business Development Representative
Test end-to-end e test di integrazione: la differenza in una riga
Definizione
Il test di integrazione controlla che due o più parti di un'applicazione lavorino insieme alla loro giunzione, attraverso il codice o un'API, mentre il test end-to-end controlla l'intera applicazione attraverso il suo schermo, nel modo in cui la percorre un utente.
- Un test di integrazione fa una domanda al codice: il servizio del carrello ha restituito il totale che il checkout si aspetta?
- Un test end-to-end fa una domanda allo schermo: l'utente vede il totale giusto dove se lo aspetta?
- Servono entrambi, e nessuno dei due può rispondere alla domanda dell'altro.
I due vengono confusi perché entrambi testano più di un pezzo alla volta.La differenza sta in dove si trova il test.Un test di integrazione sta alla giunzione tra due parti e osserva ciò che la attraversa.Un test end-to-end sta dove sta l'utente, davanti allo schermo, e osserva il risultato di tutto ciò che c'è dietro.
I test di integrazione controllano la giunzione.Un test end-to-end controlla ciò che viene disegnato.
Test E2E e test di integrazione a confronto
Ecco come i due si confrontano sulle domande che un team si pone quando decide cosa automatizzare.
| Domanda | Test di integrazione | Test end-to-end |
|---|---|---|
| Ambito | Due o più parti dell'applicazione, insieme: un servizio e il suo database, l'API e il modulo che la chiama. | L'intera applicazione come la incontra l'utente, con ogni parte da cui dipende: lo schermo, i servizi dietro di esso, spesso altri sistemi come un fornitore di pagamenti. |
| Punto di ingresso | Il codice o un'API: il test chiama una funzione o invia una richiesta e legge la risposta. | Lo schermo: il test fa clic, digita e legge ciò che viene disegnato, come farebbe una persona. |
| Cosa trova | Una parte che non risponde più come si aspetta la parte successiva: un campo rinominato, uno stato sbagliato, un record mancante. | Un percorso che non dà più all'utente il risultato giusto: un totale sbagliato sullo schermo, un pulsante che non fa nulla, una pagina che non si apre. |
| Velocità | Da millisecondi a secondi per test.Se ne possono eseguire centinaia a ogni commit. | Da secondi a minuti per percorso.Una suite di qualche decina viene eseguita a ogni build o ogni notte. |
| Costo | Economico da scrivere per lo sviluppatore che conosce la giunzione, ed economico da eseguire. | Costoso quando è codice: ogni restyling rompe i selettori.Economico quando è registrato dallo schermo e mantenuto senza codice. |
| Chi lo scrive | Gli sviluppatori, man mano che costruiscono ogni giunzione. | Tester, ingegneri QA e product owner che sanno cosa si aspetta l'utente; anche gli sviluppatori. |
| Quando viene eseguito | A ogni commit, nella build, prima che qualcosa venga integrato. | A ogni build o pull request per pochi percorsi critici, ogni notte per l'intera suite, su ogni browser e dispositivo prima di un rilascio. |
Il bug che un test di integrazione non può vedere
Prendete un checkout.Il servizio del carrello somma gli articoli, il servizio dei prezzi applica la tariffa di spedizione, e la pagina del checkout disegna il risultato in tre righe: Subtotale, Spedizione e Totale.Un giorno uno sviluppatore riordina il modello del checkout.Una riga si sposta.Il codice dietro di essa è intatto.
Il test di integrazione chiede all'API il totale del carrello e lo confronta con il numero che si aspetta.Ottiene 48.90, esattamente giusto, e passa.Ogni servizio ha fatto il suo lavoro, e la giunzione tra loro è solida.
Il test end-to-end fa ciò che fa un cliente: aggiunge due articoli, apre il checkout e legge il totale prima di pagare.Sullo schermo, la riga Totale è vuota, e 48.90 ora sta accanto a Spedizione.Un cliente legge che la spedizione costa 48.90 e che non c'è nulla da pagare.È un bug su cui nessuno discuterebbe, e nessun test di integrazione può vederlo, perché un test di integrazione non guarda mai la pagina.
Lo stesso schema nasconde molti dei bug che arrivano agli utenti.
- Un totale calcolato in dollari e disegnato con il simbolo dell'euro.
- Un pulsante Paga spinto sotto il bordo visibile da un nuovo banner.
- Un messaggio di conferma che compare dietro la finestra.
- Un'etichetta troppo lunga per il suo campo dopo una traduzione.
- In ogni caso, i dati sono giusti e lo schermo è sbagliato.
È la stessa lacuna che i bug visivi che i vostri test automatici non vedono descrive dall'altro lato: un controllo che chiede se un elemento esiste non può dire se una persona può vederlo, leggerlo o farci clic.
La piramide dei test: dove ogni livello si guadagna il suo posto
La piramide dei test è la rappresentazione consueta di come dimensionare una suite.La sua forma riguarda il costo, non l'importanza: un test unitario gira in un millisecondo e si può scrivere per ogni caso, un test end-to-end avvia l'applicazione reale e segue un percorso, quindi ce ne sono meno.
La piramide dei test: quanti test, e cosa vede ogni livello
Test unitari
Un test unitario si guadagna il suo posto cogliendo un calcolo sbagliato nel momento in cui viene scritto, nella funzione che lo ha fatto.
Test di integrazione
Un test di integrazione si guadagna il suo posto cogliendo una giunzione che si è rotta: un campo rinominato in un servizio e ancora atteso da un altro.
Test end-to-end
Un test end-to-end si guadagna il suo posto cogliendo ciò che solo lo schermo mostra: il numero giusto nel campo sbagliato, il pulsante su cui non si può fare clic, la pagina che non si apre mai.
Il test di sistema sta accanto alla punta della piramide, e molti team usano i due nomi per la stessa cosa.La distinzione utile: il test di sistema controlla l'applicazione assemblata rispetto ai suoi requisiti, il test end-to-end segue il percorso di un utente attraverso tutto ciò che quel percorso tocca.Cos'è il test end-to-end ripercorre il quadro completo.
Test di integrazione o test end-to-end: quando usare l'uno e quando l'altro
La scelta è raramente l'uno o l'altro.Ogni livello è il più economico per un tipo diverso di domanda, e un team che sa quale domanda sta ponendo mette il test nel posto giusto.
Usate un test di integrazione quando la domanda riguarda una giunzione.
- L'API risponde ancora nella forma che il modulo si aspetta?
- L'ordine arriva al database con ogni campo?
- Il rifiuto del fornitore di pagamenti torna come l'errore che il codice gestisce?
- Sono tanti piccoli casi, meglio controllati in fretta, a ogni commit, dallo sviluppatore che ha costruito la giunzione.
Usate un test end-to-end quando la domanda riguarda il risultato per l'utente.
- Un cliente può accedere, trovare un prodotto, pagare e vedere la conferma con il numero d'ordine giusto?
- Il report che il team finanziario esporta ogni lunedì si apre ancora con le colonne giuste?
- Sono pochi percorsi completi, controllati dove li controllerebbe l'utente, a ogni build.
Usate entrambi dove sono in gioco denaro, dati o accesso.
- Il checkout qui sopra ha bisogno dei suoi test di integrazione, così un totale sbagliato viene colto alla giunzione che lo ha prodotto, e del suo test end-to-end, così viene colto anche un totale giusto disegnato nel posto sbagliato.
- Quel giorno nessuno dei due avrebbe potuto sostituire l'altro.
Entrambi i livelli sono test di regressione: vengono eseguiti di nuovo dopo ogni modifica per dimostrare che nulla di ciò che funzionava si è rotto.Cos'è il test di regressione spiega quando eseguire ciascuno e perché le suite vengono abbandonate quando costano più di quanto colgono.
Quanti test end-to-end servono?
Meno di quanto pensiate, e scelti meglio.La punta della piramide non è un posto in cui elencare ogni schermata.È un posto per i percorsi che farebbero più male se si rompessero, ciascuno seguito dal primo clic al risultato per cui l'utente è venuto, e ciascuno che verifica quel risultato.
La maggior parte delle applicazioni è coperta da un elenco breve.
- 1Registrazione e accesso, compreso l'errore quando la password è sbagliata.
- 2Il compito principale per cui l'applicazione esiste: fare un ordine, prenotare uno slot, creare un cliente, inviare una richiesta.
- 3Il pagamento, fino alla conferma e al suo numero d'ordine.
- 4La ricerca o l'elenco da cui un utente parte ogni giorno.
- 5L'esportazione o il report su cui un cliente fa affidamento.
- 6Ogni percorso che si è rotto una volta ed è arrivato agli utenti.
Da cinque a quindici percorsi come questi, eseguiti a ogni build, colgono la maggior parte di ciò che una suite di integrazione lascia passare.Ognuno termina con un controllo di ciò che mostra lo schermo: il totale, la conferma, il file esportato.Un test che attraversa un percorso a colpi di clic e non verifica nulla dimostra poco.
Cosa verificare a ogni passaggio è una scelta che vale la pena fare di proposito: un'immagine dell'elemento, le sue parole, o ciò che è comparso sullo schermo.Scegliere cosa verifica un test lo spiega passo dopo passo.
Automatizzare il livello end-to-end senza codice
Il livello end-to-end è quello che la maggior parte dei team lascia sottile, perché è stato il più costoso da mantenere: i test in codice trovano gli elementi tramite selettori, e ogni restyling li rompe.GUI Test Studio toglie il codice da quel livello.Testa app web, app desktop Windows, telefoni Android e giochi attraverso il loro schermo, come fa un utente.
Registratelo, o descrivetelo
Fate clic su Registra e seguite il percorso nella vostra applicazione reale: aggiungete gli articoli, aprite il checkout, leggete il totale.I clic, la digitazione e i controlli di ciò che è comparso diventano un test, senza codice da scrivere.Potete anche descrivere il percorso in un prompt al vostro assistente IA, e il test viene creato per voi.Il vostro primo test, passo dopo passo richiede circa dieci minuti.
Il test controlla ciò che mostra lo schermo, non il codice dietro di esso.
- Un'asserzione visiva confronta l'immagine di un elemento, un'asserzione testuale legge le sue parole, e un controllo di ciò che è comparso coglie la finestra di dialogo o il messaggio che il passaggio ha aperto.
- Il GTS Engine + AI trova ogni elemento prima attraverso le informazioni di accessibilità dell'applicazione, e a vista quando l'applicazione non dice nulla.
Eseguitelo a ogni build
gtr-cli esegue la suite end-to-end su una macchina di build Windows e risponde come si aspetta una pipeline: un percorso non riuscito fa fallire la build, un file JUnit riempie la scheda dei test, e ogni immagine di ciò che non è riuscito viene conservata accanto ai risultati di integrazione.
gtr-cli run tests\journeys --countdown 0 --junit results\junit.xml --artifacts results\artifactsFunziona in TeamCity, Jenkins, GitHub Actions, GitLab e Azure DevOps: vedete Eseguire i test nella pipeline.
Il report di affidabilità dice cosa è cambiato
Ogni esecuzione termina con un report di affidabilità.Per ogni controllo, dice se l'elemento è stato trovato e se ha ancora l'aspetto con cui è stato registrato, con l'immagine attesa e quella trovata affiancate e la differenza evidenziata.Per il checkout qui sopra, mostra la riga Totale vuota e 48.90 una riga più in alto: esattamente ciò che un tester avrebbe scritto nella segnalazione di bug.
Il rumore viene ignorato e le regressioni vengono colte.
- Le lievi differenze di rendering che nessuna persona noterebbe non vengono contate, mentre una parola cambiata, un badge mancante o un numero nella riga sbagliata fanno fallire il controllo.
- Quando un'immagine è diversa, l'analisi intelligente con IA può dare una seconda occhiata e dire cosa è cambiato in parole semplici, nel cloud con la vostra chiave o sul vostro computer con un modello di IA locale, uno dei nostri o uno vostro.
Una modifica viene inviata
Il modello del checkout viene riordinato
La build viene eseguita
Test di integrazione, poi gtr-cli
Report di affidabilità
Il totale è nella riga sbagliata
Corretto prima dell'integrazione
L'utente non l'ha mai visto
Punti chiave
- 1I test di integrazione controllano la giunzione tra le parti; un test end-to-end controlla ciò che viene disegnato per l'utente.
- 2Lo stesso bug può essere verde e rosso allo stesso tempo: l'API restituisce il totale giusto, lo schermo lo mostra nel campo sbagliato.
- 3La forma della piramide riguarda il costo, non l'importanza: molti test veloci sotto, pochi percorsi completi in cima, ciascuno coglie ciò che gli altri non possono.
- 4Usate entrambi dove sono in gioco denaro, dati o accesso, e scegliete il livello in base a chi scriverebbe la segnalazione di bug: un utente o uno sviluppatore.
- 5Da cinque a quindici percorsi, ciascuno che verifica il suo risultato, coprono la maggior parte di ciò che la suite di integrazione lascia passare, e si possono registrare senza codice.
Domande
Qual è la differenza tra test end-to-end e test di integrazione?
Il test di integrazione controlla che due o più parti di un'applicazione lavorino insieme alla loro giunzione, di solito attraverso il codice o un'API.Il test end-to-end controlla l'intera applicazione attraverso il suo schermo, nel modo in cui la percorre un utente.Un test di integrazione può passare mentre lo schermo mostra la cosa sbagliata.
Il test end-to-end è la stessa cosa del test di sistema?
Si sovrappongono, e molti team usano le due parole per la stessa cosa.Il test di sistema controlla l'applicazione completa e assemblata rispetto ai suoi requisiti.Il test end-to-end segue il percorso di un utente dal primo clic al risultato, attraverso ogni parte che il percorso tocca, altri sistemi compresi.
I test di integrazione possono sostituire i test end-to-end?
No.I test di integrazione dimostrano che le parti sono d'accordo tra loro, non che un utente ottenga il risultato giusto sullo schermo.Un totale può essere calcolato correttamente da ogni servizio ed essere comunque disegnato nel campo sbagliato o nascosto dietro un banner, e solo un test che guarda lo schermo lo vede.
Cosa scrivere per primi, i test di integrazione o i test end-to-end?
Gli sviluppatori scrivono i test di integrazione man mano che costruiscono ogni giunzione, quindi di solito arrivano per primi.I primi test end-to-end spettano ai percorsi che farebbero più male se si rompessero, come l'accesso e il checkout, e si possono registrare non appena quei percorsi funzionano.
Quanti test end-to-end dovrebbe avere un progetto?
Meno di quanto pensiate, e scelti meglio.Da cinque a quindici percorsi coprono ciò che la maggior parte delle applicazioni non può permettersi di rompere: registrazione, accesso, il compito principale, il pagamento, l'esportazione su cui i clienti fanno affidamento.Ognuno segue un percorso fino al risultato per cui l'utente è venuto, e verifica quel risultato.
Perché i test end-to-end sono più lenti dei test di integrazione?
Un test end-to-end avvia l'applicazione reale, ne guida le schermate e aspetta che ognuna risponda, quindi un percorso richiede da secondi a minuti dove un test di integrazione richiede millisecondi.Ecco perché i test end-to-end coprono pochi percorsi importanti, e i test di integrazione coprono molti casi.
Cos'è la piramide dei test?
La piramide dei test è un modo di dimensionare una suite di test: molti test unitari veloci alla base, meno test di integrazione al centro, e un piccolo numero di test end-to-end in cima.Ogni livello coglie ciò che i livelli sottostanti non possono, e il livello in cima è l'unico che vede ciò che vede l'utente.
Chi scrive i test end-to-end?
Chiunque sappia cosa si aspetta l'utente può farlo, quando lo strumento non ha bisogno di codice.Con GUI Test Studio, un tester o un product owner registra un percorso usando l'applicazione, o lo descrive in un prompt, e il test viene eseguito a ogni build con gtr-cli.
TeamCity, Jenkins, GitHub, GitLab e Azure DevOps sono marchi dei rispettivi proprietari.
Pronti a registrare il vostro primo test?
Tutte le funzionalità, per 15 giorni.
Preferite vederlo sul tipo di app che testate?Prenotate una chiamata gratuita di 30 minuti con il nostro team.