Titolo

Archivio dei tag

Test automatici per 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. =&0=& http://www.seleniumhq.org/ 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. =&1=&
  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
=&2=&
  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
=&3=& Framework per test angular end-to-end http://www.protractortest.org/#/ =&4=&
  1. specializzato su angular
  2. veloce
=&5=&
  1. i test vanno scritti a mano
  2. limitato ad applicativi angular
=&6=& https://www.katalon.com/ 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 =&7=&
  1. molto potente per la registrazione e gestione delle test suite
=&2=&
  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)

I test per lo sviluppo software

Nel paragrafo precedente è stato spiegato il meccanismo di passaggio tra gli ambienti e si è detto che la promozione del software è vincolata al superamento di test. Tali test sono suddivisi in più tipologie, per caratteristiche e scopo. Non c’è alcuna regola scritta per indicare quali test effettuare per ogni passaggio, come sempre dipende molto dal tipo di progetto, dalla sua criticità e dalla gestione dello stesso. In molti casi i test non sono formalizzati, ma ci si basa sul responso di qualcuno, quindi si rientra nel caso “User acceptance test”. Di seguito l’elenco della maggior parte di test attuabili, mentre nei paragrafi successivi saranno esaminati quelli più diffusi: read more