Quale problema risolve il test automatico dell'interfaccia utente?

Stiamo attualmente esaminando i test automatizzati dell'interfaccia utente (attualmente eseguiamo test automatizzati di unità e integrazione).

Abbiamo esaminato Selenium e Telerik e abbiamo optato per quest'ultimo come strumento di scelta grazie al suo registratore molto più flessibile - e non vogliamo davvero che i tester scrivano troppo codice.

Tuttavia, sto cercando di capire il vantaggio complessivo. Quali sono le opinioni delle persone e che tipo di cose funzionano bene e cosa no?

Il nostro sistema è in costante sviluppo e rilasciamo regolarmente nuove versioni della nostra piattaforma (basata sul web).

Finora il vantaggio principale che possiamo vedere è per i test di regressione, in particolare su più implementazioni client della nostra piattaforma.

Cerca davvero le opinioni degli altri. "Pensiamo" che sia la cosa giusta da fare, ma in un programma già occupato stiamo cercando ulteriori approfondimenti.

Quando il mio team ha implementato i test UI automatizzati sono successe molte cose straordinarie.

In primo luogo, il team addetto al controllo qualità è diventato molto più efficiente nel testare l'applicazione, nonché più competente con l'applicazione. Il responsabile del controllo qualità ha affermato di essere stato in grado di accelerare rapidamente i nuovi membri del controllo qualità introducendoli nelle suite di test per l'interfaccia utente.

In secondo luogo, la qualità dei biglietti QA restituiti al team Dev era migliore. Invece di "Pagina interrotta quando ho fatto clic sul pulsante Invia" abbiamo ottenuto il caso esatto che non è riuscito in modo da poter vedere cosa è stato inserito nel modulo. Il team addetto al controllo qualità ha anche fatto un ulteriore passo in avanti controllando tutti i casi che hanno fallito e testato altri scenari in quella pagina per darci una visione migliore di ciò che è successo.

Terzo, il team addetto al controllo qualità ha avuto più tempo. Con questo tempo extra, sono stati in grado di partecipare a più riunioni di design. Questo a sua volta ha permesso loro di scrivere i nuovi casi della suite di test mentre i Dev stavano codificando queste nuove funzionalità.

Inoltre, lo stress test che la suite di test che abbiamo usato valeva il suo peso in oro. Onestamente mi ha aiutato a dormire meglio la notte sapendo che la nostra app poteva sopportare praticamente qualsiasi cosa. Abbiamo trovato alcune pagine contratte sotto pressione che siamo riusciti a correggere prima di andare in diretta. Semplicemente perfetto.

L'ultima cosa che abbiamo scoperto è che con alcune modifiche da parte del team addetto al controllo qualità, abbiamo potuto anche eseguire alcuni test di iniezione SQL sulla nostra app. Abbiamo riscontrato alcune vulnerabilità che siamo stati in grado di risolvere rapidamente.

L'installazione della suite di test dell'interfaccia utente ha richiesto molto tempo. Ma una volta che è stato lì è diventato una parte centrale del nostro processo di sviluppo.

I test automatizzati dell'interfaccia utente sono i veri test di integrazione. Testano l'intero sistema nel modo in cui viene effettivamente utilizzato quando è attivo. Questo li rende i test più significativi. Tuttavia, tendono anche ad essere i più fragili e i più lenti da eseguire.

Tieni d'occhio il rapporto costi / benefici (con la fragilità che fa parte del costo) e non esitare ad avere alcune cose che vengono testate solo manualmente (ma assicurati che siano testate). E, se possibile, consentire agli sviluppatori di eseguire parti specifiche della suite di test dell'interfaccia utente rispetto alla versione dell'app localmente in esecuzione, in modo che possano beneficiare dei test durante lo sviluppo.

Avere i test eseguiti automaticamente su un server di build (almeno una volta al giorno) è un must assoluto, ovviamente.

non vogliamo davvero che i tester scrivano troppo codice.

IMO questo è un sogno irrealizzabile. La creazione di test automatizzati sta scrivendo codice. Funzionalità di registrazione può aiutare a scrivere un po 'di quel codice più veloce e iniziare in modo più rapido con la scrittura manualmente (e rallentare terribilmente se si perde il punto in cui la scrittura di codice diventa manualmente più veloce), ma alla fine il codice di scrittura manuale è quello che si finirà per facendo molto. Spero meglio che il tuo framework di test lo supporti bene e che il suo sviluppo non sia stato troppo focalizzato sul sogno (molto vendibile) della pipa di consentire alle persone che non sono in grado di scrivere codice di produrre test automatici.

e non vogliamo davvero che i tester scrivano troppo codice

Abbiamo adottato l'approccio opposto. Volevamo che i tester scrivessero il codice.

Ecco il flusso di lavoro che abbiamo iniziato ad adottare. Non è facile farlo perché la gestione non dipende assolutamente dai test automatizzati del front-end. Sono disposti ad accontentarsi di "abbastanza vicini".

1. Storie degli utenti.

2. Concetto operativo. Come probabilmente la storia funzionerebbe. Revisione del progetto.

3. Schizzo dello schermo: progettazione dell'interfaccia utente. Come sarebbe.

4. Script di selenio. Se tutti gli script funzionano, abbiamo terminato il rilascio.

5. Codifica e test fino a quando lo script funziona.

I test automatici sono l' unico modo per dimostrare l'esistenza della funzionalità.

I test manuali sono soggetti a errori e soggetti a modifiche da parte della direzione: "è abbastanza buono, quei test falliti non contano tanto quanto rilasciarli in tempo."

"Qualsiasi funzione di programma senza un test automatizzato semplicemente non esiste."

La presentazione visiva è un'altra storia. Il test manuale di un layout visivo è un caso eccezionale perché può comportare un giudizio estetico o esaminare problemi specifici (piccoli) su una schermata di pixel molto ampia e complessa.

Finora il vantaggio principale che possiamo vedere è per i test di regressione, in particolare su più implementazioni client della nostra piattaforma.

L'automazione dei test di regressione è una buona cosa. Ciò consente ai tester di svolgere attività più interessanti, ad esempio aggiungendo ulteriori test automatizzati, stress test dell'applicazione o qualsiasi altra cosa.

Inoltre, rendendolo automatizzato, puoi far sì che i tuoi sviluppatori eseguano i test e quindi prevenire problemi che verranno scoperti solo più avanti nel processo.

Abbiamo esaminato Selenium e Telerik e abbiamo scelto quest'ultimo come strumento di scelta grazie al suo registratore molto più flessibile

Non sono sicuro di quanto ci hai guardato dentro. Certamente ci sono anche altre opzioni. Hai mai guardato Watir , WatiN , Sikuli per citarne alcuni?

e non vogliamo davvero che i tester scrivano troppo codice.

Mi sento male per le persone che devono mantenere questi script. Molto spesso, senza un codice che può essere facilmente modificato, gli script diventano fragili e inizia a impiegare più tempo a modificarlo che a registrarlo nuovamente, il che fa perdere ancora più tempo.

Tuttavia, sto cercando di capire il vantaggio complessivo. Quali sono le opinioni delle persone e che tipo di cose funzionano bene e cosa no?

L'automazione del test è una cosa meravigliosa se eseguita correttamente. Risparmia tempo sui test / controlli di regressione in modo da dare ai tuoi tester più tempo per fare ciò che fanno meglio, test. Non credere per un momento però che sia un proiettile d'argento. Gli script di automazione richiedono tempo significativo per lo sviluppo se l'applicazione esiste già ma i test no e richiedono un aggiornamento costante con ogni versione. I test automatizzati sono anche un ottimo modo per le nuove persone del team per vedere come dovrebbe comportarsi il sistema. Inoltre, assicurati che i tester possano decidere cosa deve essere automatizzato. Se è un piccolo controllo che non richiede molto da controllare, è molto monotono e facile da automatizzare, inizia da quello. Inizia sempre con i controlli che ottengono il massimo attraverso l'automazione e lavora da lì.

Finora il vantaggio principale che possiamo vedere è per i test di regressione, in particolare su più implementazioni client della nostra piattaforma.

È il vantaggio principale e, se impostato correttamente, può testare la maggior parte dei browser necessari con una piccola modifica della configurazione.

"Pensiamo" che sia la cosa giusta da fare, ma in un programma già occupato stiamo cercando ulteriori approfondimenti.

Come ho affermato in precedenza, l'automazione dei test richiede notevoli sforzi, tuttavia, se eseguita correttamente, non ho ancora incontrato un team che ha affermato "Vorrei che non avessimo impostato l'automazione dei test".

Hai ragione che la regressione è enorme. Anche -

• se i tuoi test sono scritti in modo modulare, puoi ottenere più risultati con il mixare e abbinare i set di test

• abbiamo riutilizzato gli script di test automatizzati per il caricamento dei dati in modo da non dover creare un database per eseguire test di grandi dimensioni

• test della prestazione

• test multi thread

• sui sistemi Web: scambio tra browser e scambio tra sistemi operativi. Con problemi di coerenza del browser, colpire una base il più ampia possibile è una cosa enorme.

Le cose da saltare - specialmente nei sistemi web, fai attenzione ai casi in cui elementi del tuo display sono creati con ID dinamici e mutevoli - spesso gli script di test automatizzati non gestiscono così bene e potresti aver bisogno di una riprogettazione seria per aggiornare questo.

Solo un esempio: misurare accuratamente la durata del rendering della pagina Web

Utilizzando i test di automazione, è molto più semplice testare le prestazioni del browser web. Per misurare il tempo di risposta massimo che è probabile che accetti, basta impostare una costante negli script di test e / o passarla come parametro di funzione, ad esempio in questo pseudocodice: $ sel-> wait_for_page_to_load ($ mypage, $ maxtime).

Fare test cross-browser con valori bassi può essere abbastanza illuminante.

L'alternativa sarebbe che i dipendenti effettuino misurazioni di temporizzazione con un cronometro.

Il test automatizzato dell'interfaccia utente risolve la possibilità di:

• ripetere rapidamente i test di un gran numero di componenti
• ricordati di provare ogni volta un gran numero di funzioni
• confrontare esecuzioni e tempi di esecuzione delle suite di test man mano che l'applicazione cresce
• la configurazione viene eseguita con centinaia di input e condizioni variabili diversi
• consentire alle persone che non hanno scritto il test di eseguirlo e vedere eventuali problemi visivi
• consentire agli utenti finali di vedere l'applicazione utilizzata in modo rapido e semplice
• distribuire l'interfaccia utente del test viene eseguita su una rete, un server remoto o un servizio
• avviare i test del volume utilizzando macchine parallele.

Tuttavia, come altri hanno notato:

Telerik ...

lo strumento preferito grazie al suo registratore molto più flessibile

è una bandiera rossa per molti di noi.

Gli script registrati in questo modo tendono a non essere una soluzione a lungo termine perché:

• l'ID database / oggetto tende a cambiare da caso a caso
• gli script registrati manualmente spesso si basano su tag di layout di pagina che cambiano spesso
• azioni comuni dovranno essere riscritte più e più volte invece di consentire il riutilizzo (vedi approccio SitePrism & PageObject)
• a volte è necessario utilizzare strumenti come xpath per acquisire informazioni aggiuntive in base alle informazioni della pagina corrente. Una semplice sceneggiatura registrata non lo farà.
• gli sviluppatori e i tester che scrivono codice non saranno incoraggiati a utilizzare classi CSS, ID e attributi di dati HTML5, che sono pratiche che porteranno a test più solidi e sostenibili.

Telerik ha alcuni vantaggi che dovrebbero essere considerati però:

• rivolto ai clienti mobili
• strumenti integrati per gestire la crescita
• gestisce Android, iOS e Windows Phone

Un approccio che può aiutare a colmare le lacune è quello di registrare lo script iniziale utilizzando il registratore di pagine degli strumenti, ma quindi modificare lo script per utilizzare ID, classi e attributi dei dati in modo che duri nel tempo. Questo è un approccio che ho effettivamente utilizzato con il plug-in selenio di Firefox.

Rende "Esperto Test" (simile al "Test esplorativo", ma eseguito da utenti finali o membri del team con una grande conoscenza del business) più facile da eseguire, registrare risultati, misurare e automatizzare.

Vengo a questo da uno sfondo diverso. Presso i miei ex datori di lavoro, abbiamo sviluppato strumenti di test automatizzati commerciali (QALoad, QARun, TestPartner, SilkTest, SilkPerfomer).

Abbiamo visto i test automatizzati dell'interfaccia utente come due ruoli:

1. Test di regressione completo

2. Installazione automatizzata di ambienti di test

Ci siamo fortemente appoggiati agli strumenti per eseguire i test di regressione su base notturna. Semplicemente non avevamo il potere umano di testare tutti i pulsanti e le finestre di dialogo per verificare che non avessimo interrotto nulla tra l'interfaccia utente e la logica aziendale.

Per test più importanti, abbiamo scoperto che una sola persona poteva far girare diverse macchine virtuali e usare gli script per arrivare al punto di un vero test. Ciò consente loro di concentrarsi sui bit importanti e di non provare a seguire un caso di test in 24 passaggi.

L'unico problema con i test automatizzati era l'abitudine di scaricare troppi test sulla scatola senza alcun tipo di supervisione per eliminare test duplicati o non necessari. Di tanto in tanto dovremmo entrare e potare le cose per poter completare la suite in meno di 12 ore.

Test automatici, di qualsiasi tipo, prevedono test di regressione; eseguendo il test che una volta funzionava, si verifica che funzioni ancora (o non funziona) indipendentemente da qualsiasi altra cosa sia stata aggiunta. Questo è vero indipendentemente dal fatto che il test sia un test di integrazione (che di solito non tocca l'interfaccia utente) o un AAT (che di solito richiede l'interfaccia utente).

Il test automatico dell'interfaccia utente consente di testare il sistema come se un utente stesse facendo clic sui pulsanti. Tali test possono quindi essere utilizzati per verificare la navigazione attraverso il sistema, la correttezza delle etichette e / o dei messaggi, le prestazioni e / o i tempi di caricamento in un particolare ambiente di test, ecc. Ecc. L'obiettivo principale è ridurre il tempo impiegato dal QA facendo clic sui pulsanti, proprio come l'integrazione e i test unitari fanno per il programmatore. Può impostare un test una volta (di solito registrando i propri clic del mouse e le voci di dati in uno script) e, una volta che il test funziona correttamente, tutto ciò che dovrebbe fare per verificare la correttezza del sistema sottoposto a test viene eseguito di nuovo. Alcuni framework, come Selenium, consentono la migrazione dei test tra i browser, consentendo di testare diversi ambienti in cui il sito dovrebbe funzionare correttamente.

Senza test automatici, sei limitato dal numero e dalla velocità dei tuoi tester di controllo qualità; devono letteralmente avere il sistema pratico, testando che la tua nuova funzionalità soddisfa i requisiti e (altrettanto importante) che non hai rotto nulla di già esistente.

Il test determina molte cose diverse. Molti di questi test possono essere automatizzati, per consentire la rimozione della fatica e per fare di più. Per determinare se i tuoi test possono essere automatizzati, devi prima vedere se la domanda che pongono è appropriata per questo.

• Stai determinando se un componente funziona secondo le specifiche?
• Vuoi testare tutti i diversi ingressi e uscite possibili?
• stress test del componente?
• O stai cercando di provare che "funziona"?

La maggior parte di questi può essere automatizzata, perché di natura meccanica. La nuova funzione accetta input, quindi cosa succede quando ci lanciamo dati casuali? Ma alcuni, come testare se il sistema funziona, richiede che qualcuno lo usi effettivamente . In caso contrario, non saprai mai se le aspettative dei tuoi utenti sono le stesse di quelle del programma. Fino a quando il sistema non si "rompe".

Nella mia esperienza, il test automatico dell'interfaccia utente copre molte lacune, tra cui:

• Mancanza di documentazione (esempio: utilizzo del test runner automatizzato per dimostrare la funzionalità esistente)
• Requisiti obsoleti dovuti allo scorrimento dell'ambito (esempio: identificazione del divario tra requisiti e codice acquisendo lo schermo durante le prove)
• Elevato turnover di sviluppatori e tester (esempio: JavaScript dell'ingegneria inversa acquisendo lo schermo durante le prove con lo strumento di sviluppo aperto)
• Identificazione delle violazioni delle convenzioni di denominazione standard tramite test di regressione XPath (esempio: ricerca di tutti i nodi degli attributi DOM per i nomi dei cammelli)
• Riconoscere le falle di sicurezza che solo un computer può scoprire (esempio: disconnettersi da una scheda e contemporaneamente inviare un modulo nell'altra)

Vorrei condividere l'esperienza del nostro team. Abbiamo utilizzato il nostro strumento di test dell'interfaccia utente, Screenster, per testare le nostre app Web e quelle dei nostri clienti. Si è dimostrato un'alternativa utile al selenio per le attività di test visivi / CSS. Screenster è uno strumento di automazione di test che esegue un confronto basato su screenshot di diverse versioni delle tue pagine Web. Innanzitutto crea una linea di base visiva per una pagina, facendo uno screenshot per ogni azione dell'utente. Durante la prossima corsa prende un nuovo screenshot ad ogni passaggio, lo confronta con quello della linea di base ed evidenzia le differenze.

Riassumendo, Screenster presenta i seguenti vantaggi: Linea di base visiva: le schermate vengono catturate per ogni passaggio dell'utente durante la registrazione di prova Confronto basato su schermate: Lo schermo confronta le immagini catturate durante una riproduzione con quelle della linea di base ed evidenzia tutte le differenze Selettori Smart CSS: il tester può selezionare Elementi CSS sugli screenshot ed eseguire azioni con essi, ad esempio contrassegnarli come ignorare le regioni da escludere da ulteriori confronti