Test cross-browser: un solo test per ogni browser e dispositivo

Che cos'è il test cross-browser?

Il test cross-browser consiste nel controllare che un sito o un'app web funzioni e si presenti correttamente in ogni browser dei vostri utenti.Il test cross-device fa lo stesso su schermi e metodi di input diversi: telefoni, tablet e dimensioni desktop, touch e mouse, verticale e orizzontale.Insieme rispondono a una sola domanda.La pagina che il vostro team ha costruito funziona per la persona che la apre su un telefono, in un altro browser, in un'altra lingua?

La domanda conta perché una pagina web non è un'immagine fissa.Ogni browser disegna lo stesso HTML, CSS e JavaScript con il proprio motore.Ogni dispositivo dà alla pagina uno schermo diverso a cui adattarsi.Un checkout che funziona su un monitor largo in Chrome può spingere il suo pulsante Paga sotto la parte visibile su un telefono piccolo.

Il test web mobile è la parte che guarda un sito su telefoni e tablet.Il test responsive è la parte che controlla che un layout si adatti a ogni dimensione dello schermo.

Cosa cambia tra browser e dispositivi

Un test superato in un browser su uno schermo dimostra poco sugli altri.Queste sono le differenze che rompono più spesso le pagine.

Il solo test della viewport copre unicamente la seconda riga.Un vero controllo cross-device richiede insieme la dimensione dello schermo, l'input touch e la densità dei pixel.

Come affrontano di solito i team il test cross-browser?

Prima vengono i controlli manuali.Un tester apre la pagina in ogni browser e ridimensiona la finestra.Funziona per un rilascio e non è sostenibile a ogni build.

Poi vengono le suite automatizzate.La loro forma è simile in ogni framework: un test scritto in codice, poi una configurazione che lo esegue di nuovo per ogni browser o dispositivo.

Progetti e dispositivi di Playwright

Playwright raggruppa i test in progetti.Un progetto è un gruppo di test eseguito con una sola configurazione, come un browser o un dispositivo emulato.Playwright esegue tutti i progetti per impostazione predefinita.Il suo registro dei dispositivi descrive telefoni, tablet e desktop, con la dimensione dello schermo, lo user agent e il supporto del touch.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'Mobile Chrome', use: { ...devices['Pixel 5'] } },
    { name: 'Mobile Safari', use: { ...devices['iPhone 12'] } },
  ],
});

Browser e viewport di Cypress

Cypress supporta i browser della famiglia Chrome, Firefox e WebKit, scelti con l'opzione --browser.Il suo comando cy.viewport imposta la dimensione e l'orientamento dello schermo, con preimpostazioni come iphone-6 e ipad-2.La sua documentazione precisa che il rapporto di pixel del dispositivo non viene simulato.Suggerisce inoltre di eseguire alcuni browser meno spesso, ad esempio Firefox ogni notte anziché a ogni commit, per risparmiare tempo e costi di CI.

Selenium Grid

Selenium Grid esegue script WebDriver su macchine remote, in parallelo, su diverse versioni di browser e piattaforme.È il modo classico di fare test multipiattaforma con Selenium.Il vostro team configura quelle macchine e mantiene aggiornati i loro browser.

Cloud di dispositivi

I cloud di dispositivi come BrowserStack, TestMu AI (in precedenza LambdaTest) e Sauce Labs ospitano per voi i browser e i dispositivi.BrowserStack e TestMu AI elencano ciascuno migliaia di combinazioni di browser e sistema operativo.Sauce Labs offre emulatori, simulatori e dispositivi reali.I vostri test in codice vengono eseguiti sulle loro macchine, e BrowserStack Automate calcola i suoi piani in base ai test paralleli.

Per uno sguardo più ampio su questi strumenti, vedete lo studio comparativo.

Quanto costa una suite cross-device in codice

La configurazione è la parte facile.Il costo è tutto ciò che ogni test deve sapere di ogni schermo.

test('open the checkout', async ({ page, isMobile }) => {
  if (isMobile)
    await page.getByRole('button', { name: 'Menu' }).click();
  await page.getByRole('link', { name: 'Checkout' }).click();
});

Moltiplicatelo per ogni elemento che si sposta su uno schermo piccolo.La parte cross-device di una suite diventa presto una seconda suite, con una manutenzione tutta sua.

Test cross-browser da una sola registrazione

GUI Test Studio, che automatizza i test end-to-end su Windows, segue un'altra strada.Registrate un test web una sola volta, svolgendo voi stessi il flusso di lavoro nel browser che usate ogni giorno.Spuntate i browser, i dispositivi e le condizioni che deve coprire.GUI Test Runner-Recorder genera poi una versione del test per ciascuno, chiamata ramo.

Quando registrate un'app web, spuntate Genera questo test anche per altri browser e dispositivi sotto il suo indirizzo.I browser sono quelli installati sul vostro computer: Chrome, Edge e Firefox.I dispositivi sono più di 80 tra telefoni, tablet e dimensioni dello schermo desktop, raggruppati per produttore.Ogni telefono e tablet può essere tenuto in verticale, in orizzontale o in entrambi i modi.

Ingrandisci

La finestra indica quanti test risultano dalla vostra scelta, quanto tempo serve per generarli e quanto spazio su disco occupano.Una volta salvato il test, i rami vengono generati in background.Nulla viene fissato al momento della registrazione: potete aggiungere browser e dispositivi in seguito.

Siete alle prime registrazioni?Registrare un test mostra tutto il percorso.Potete anche descrivere il test in un prompt e indicare i browser e i dispositivi nella stessa frase: vedete Creare un test da un prompt.

Cosa fa ogni versione per browser e dispositivo

Un ramo non è la registrazione riprodotta alle stesse coordinate.Viene creato riproducendo il test su quel browser e quel dispositivo, passaggio per passaggio, attraverso gli elementi della pagina stessa.

È la parte che una suite in codice scrive a mano.Qui viene dalla pagina stessa: il menu, lo scorrimento e la nuova posizione di ogni elemento.

Ogni controllo di un ramo viene ritagliato da ciò che quel dispositivo mostra davvero, quindi il layout specifico di un telefono non risulta mai un errore, mentre una vera regressione su quel telefono continua a risultarlo.

Quando un passaggio non può essere eseguito su un dispositivo, il ramo lo segnala.Richiede la vostra attenzione, e GUI Test Studio contrassegna il passaggio e spiega perché.

Test responsive, di localizzazione e su rete lenta

Browser e schermi sono metà di ciò che portano gli utenti.L'altra metà è come è configurato il loro browser.Un ramo può essere eseguito in determinate condizioni, e ogni condizione che spuntate viene combinata con i browser e i dispositivi che avete scelto.

Ingrandisci

Senza finestra (headless) e affiancati

Un ramo può essere eseguito senza finestra (headless): il browser lavora senza una finestra, quindi il vostro schermo e il vostro computer restano a vostra disposizione.Telefoni, tablet e rami con una condizione vengono sempre eseguiti così.Lo fanno anche i rami desktop quando il test lo consente, come avviene per impostazione predefinita.Il test registrato stesso viene eseguito in una finestra, come è stato registrato.

Il test con browser headless rende semplice anche il test in parallelo.I rami che non hanno bisogno di una finestra vengono eseguiti affiancati, fino a quattro alla volta a seconda del vostro computer.

Fate clic su Esegui test in un test di questo tipo, e GUI Test Runner-Recorder chiede quali versioni copre questa esecuzione.Ogni ramo generato è spuntato, e il tempo previsto si trova sotto l'elenco.Deriva da quanto è durata ciascuna l'ultima volta: un valore tipico, non un limite.

Ingrandisci

Alla fine, una finestra elenca l'esito di ogni esecuzione, ciascuna con il suo report.Vedete Eseguire un test per l'esecuzione stessa.

Test cross-browser in CI/CD

gtr-cli, la riga di comando di GUI Test Studio, esegue gli stessi rami in qualsiasi pipeline.--branch all esegue il test registrato e ogni ramo, ciascuno con la propria voce nel file JUnit e la propria cronologia.gtr-cli generate crea i rami mancanti o non aggiornati.

gtr-cli generate Checkout.GTS --branch missing
gtr-cli run Checkout.GTS --branch all --junit results\junit.xml

Eseguire i test nella pipeline elenca ogni opzione.L'esempio con TeamCity percorre una vera pipeline, passo dopo passo, e funziona allo stesso modo con qualsiasi strumento CI/CD.

Un report per ogni browser e dispositivo

Ogni ramo è un test a sé per quanto riguarda i risultati: il suo report di affidabilità, la sua cronologia delle esecuzioni e il suo video.Così un errore dice sempre dove è avvenuto: in Firefox, su un telefono tenuto in orizzontale, o in francese.

Nel report di affidabilità, il pulsante Browser & Dispositivi elenca la registrazione e ogni ramo con il suo ultimo esito.Apre il report di quello che scegliete.

Le modifiche seguono la stessa idea.Quando salvate un ramo dopo aver cambiato ciò che fa un passaggio, GUI Test Studio chiede se la modifica vale per ogni browser e dispositivo, o solo per questo.Quando modificate il test registrato, propone di aggiornare da esso ogni browser e dispositivo.

Cosa sapere prima di iniziare

Alcuni limiti, perché possiate scegliere a occhi aperti.

Volete il quadro completo di ciò che GUI Test Studio copre oltre il browser?Vedete la pagina Test end-to-end.

Domande

Selenium, Playwright, Cypress, BrowserStack, TestMu AI, LambdaTest, Sauce Labs, Chrome, Edge, Firefox, Safari e iPhone sono marchi dei rispettivi proprietari.