Test automatici per interfacce web

Come effettuare test automatici su interfacce web

I test sull’interfaccia grafica sono il sistema più semplice e diffuso di testare un applicativo. Anche nei processi di sviluppo rudimentali dove non si fa testing in maniera esplicita, qualcuno prima o poi aprirà l’interfaccia grafica (magari un sito web…) e farà delle prove. Se prendiamo in considerazione processi di sviluppo realizzati con tutti i  livelli del “Test automation Pyramid” troviamo sempre in cima i test sull’interfaccia.
La bella notizia è che una buona parte di questi test possono essere automatizzati. Non voglio parlare qui di cosa ha senso automatizzare e cosa no. A tutti i livelli della piramide, ogni test automatico che aggiungiamo introduciamo un costo (per la realizzazione e la manutenzione). Occorre investire il giusto tempo nei test che garantiscono il funzionamento delle parti critiche e quelli che è conveniente fare, ma questo è un tema a parte.
Voglio elencare le principali alternative per l’automazione di test su interfaccia grafica. Non parlo di test end-to-end ma di una vera e propria automazione delle operazioni su browser. Quasi tutti avranno sentito parlare di Selenium: ecco, di questo stiamo parlando.
Il principio è molto semplice: si registra un test effettuando un percorso di navigazione con browser, si salva in una batteria di test e si esegue, possibilmente su tutti i browser, prima di ogni pubblicazione o ad ogni compilazione se il nostro sistema di CI lo supporta.
Vediamo alcune alternative open source o free.
Selenium
Registra la navigazione tramite tool visuale, e salva il progetto in modo da poterlo editare in seguito. La test suite è esportabile e trasformabile in unit test (junit, xunit,…). A me ha funzionato solo con junit.
Pro:
  1. permette di registrare un test da registrazione browser
  2. permette di lanciare un test su tutti i browser
  3. emulando le azioni sul browser dovrebbe essere “robusto” a fronte di applicativi angular (ma non l’ho provato…)
  4. può essere integrato nel processo di build \ release come unit test
Contro
  1. servono n tool
  2. possiamo personalizzare gli unit test ma esportandoli di nuovo si sovrascrivono (soluzione adottata)
  3. test di validazione non basilari
  4. emulando il browser i tempi sono più lunghi rispetto alle soluzioni end-to-end
Protractor
Framework per test angular end-to-end
Pro:
  1. specializzato su angular
  2. veloce
Contro:
  1. i test vanno scritti a mano
  2. limitato ad applicativi angular
Katalon
IDE eclipse based per test di carico e funzionali. La parte di registrazione è molto più evoluta rispetto a selenium. Il progetto può essere lanciato da console per integrarlo nel processo di build
Pro
  1. molto potente per la registrazione e gestione delle test suite
Contro
  1. il run a livello di integrazione non viene fatto a livello di unit test, quindi l’interpretazione dei risultati è limitata (es. al massimo posso avere un report via email)
danielefontani

Actually CTO in Sintra Consulting s.r.l, I'm senior developer and architect specialized on portals, intranets, and others business applications. Particularly interested in Agile developing and open source projects, I worked on some of this as project manager and developer. My experience include: Frameworks \Technlogies: .NET Framework (C# & VB), ASP.NET, Java, php, Spring Client languages: XML, HTML, CSS, JavaScript, Angular.js,Angular. jQuery Platforms: Sharepoint,Liferay, Drupal Databases: MSSQL, ORACLE, MYSQL, Postgres