Quale problema risolve il test dell'interfaccia utente automatizzato?

Quando il mio team ha implementato il test dell'interfaccia utente automatizzato, sono successe molte cose grandiose.

In primo luogo, il team addetto al controllo qualità è diventato molto più efficiente nel test dell'applicazione e più competente nell'applicazione. Il responsabile del controllo qualità ha detto che è stato in grado di portare rapidamente nuovi membri del controllo qualità introducendoli alle suite di test per l'interfaccia utente.

In secondo luogo, la qualità dei biglietti di QA che tornavano al team Dev era migliore. Invece di "Pagina si è rotta quando ho fatto clic sul pulsante Invia", abbiamo ottenuto il caso esatto che ha avuto esito negativo, così abbiamo potuto vedere cosa è stato inserito nel modulo. Il team addetto al controllo qualità ha anche compiuto un ulteriore passo avanti controllando tutti i casi che hanno fallito e testato altri scenari intorno a quella pagina per darci una visione migliore di ciò che è accaduto.

In terzo luogo, il team addetto al controllo qualità ha avuto più tempo. Con questo tempo extra, sono stati in grado di partecipare a più riunioni di progettazione. Ciò a sua volta ha permesso loro di scrivere i nuovi casi della suite di test nello stesso momento in cui i Devs stavano codificando quelle nuove funzionalità.

Inoltre, lo stress test che la suite di test che abbiamo usato valeva il suo peso in oro. Sinceramente mi ha aiutato a dormire meglio di notte sapendo che la nostra app poteva prendere praticamente tutto ciò che veniva lanciato. Abbiamo trovato un bel po 'di pagine che non funzionavano sotto pressione che siamo stati in grado di risolvere prima di andare in diretta. Semplicemente perfetto.

L'ultima cosa che abbiamo scoperto è stata che con alcune modifiche apportate dal team addetto al controllo qualità, abbiamo potuto eseguire alcuni test di SQL injection 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 una buona quantità di tempo. Ma, una volta lì, è diventato una parte centrale del nostro processo di sviluppo.

I test dell'interfaccia utente automatici sono i test di integrazione reali . Testano l'intero sistema nel modo in cui viene effettivamente utilizzato quando è in diretta. Questo li rende i test più significativi. Tuttavia, tendono anche ad essere il più fragile e il più lento da eseguire.

Tieni d'occhio il rapporto costi / benefici (considerando che la fragilità è una parte del costo) e non esitare ad avere alcune cose che vengono testate solo manualmente (ma assicurati che siano testate ). E se possibile, consente agli sviluppatori di eseguire parti specifiche della suite di test dell'interfaccia utente contro la loro versione locale dell'applicazione, 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) è assolutamente necessario, naturalmente.

we don't really want testers writing too much code.

IMO questo è un sogno irrealizzabile. Creare test automatici è scrivere codice. La funzionalità di registrazione può aiutarti a scrivere un po 'di quel codice più velocemente e iniziare più rapidamente con la scrittura manuale (e rallentarti terribilmente se ti perdi il punto in cui scrivere codice diventa più veloce manualmente), ma alla fine scrivere codice manualmente è ciò che finirà per fare molto. Meglio sperare che il tuo framework di testing lo supporti bene e non abbia avuto il suo sviluppo focalizzato troppo sul sogno (molto vendibile) di permettere a chi non può scrivere codice di produrre test automatici.

and we don't really want testers writing too much code

Abbiamo scelto l'approccio opposto. volevamo i tester che scrivevano il codice.

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

1. Storie degli utenti.

2. Concetto operativo. Come potrebbe funzionare la storia. Revisione del progetto.

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

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

5. Codifica e verifica fino a quando lo script non funziona.

Il test automatico è il modo solo per dimostrare che la funzionalità esiste.

Il test manuale è soggetto a errori e soggetto a override di gestione: "è abbastanza buono, i test non validi non contano tanto quanto rilasciandoli in tempo."

"Qualsiasi funzione del programma senza un test automatico semplicemente non esiste."

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

So far the main benefit we can see is for regression testing, especially across multiple client deployments of our platform.

Automatizzare i test di regressione è una buona cosa. In questo modo i tuoi tester possono svolgere un lavoro più interessante, ad esempio aggiungendo più test automatici, stress test della tua applicazione o un numero qualsiasi di altre cose.

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

We've looked at Selenium and Telerik and have settled on the latter as the tool of choice due to its much more flexible recorder

Non sono sicuro di quanto hai esaminato. Ci sono certamente anche altre opzioni. Hai esaminato Watir , WatiN , Sikuli per citarne alcuni?

and we don't really want testers writing too much code.

Mi sento male per le persone che devono mantenere questi script. Molto spesso, senza codice che può essere facilmente modificato, gli script diventano fragili e inizia a richiedere più tempo per modificare lo script piuttosto che per ri-registrarlo, il che fa sprecare ancora più tempo.

However, I am trying to understand the overall benefit. What are peoples' views and what sort of things work well and what doesn't?

L'automazione dei test è una cosa bellissima se eseguita correttamente. Consente di risparmiare tempo sui test di regressione / controlli in modo da dare ai tuoi tester più tempo per fare ciò che sanno fare meglio, testare. Non credere neanche per un momento che sia un proiettile d'argento. Gli script di automazione richiedono un tempo significativo per svilupparsi se l'applicazione esiste già ma i test non lo fanno e richiedono un aggiornamento costante ad ogni release. I test automatici sono anche un ottimo modo per le nuove persone nel team di vedere come si suppone che il sistema si comporti. Inoltre, assicurati che i tuoi tester decidano cosa deve essere automatizzato. Se è un piccolo assegno che non richiede molto controllo, è molto monotono e facile da automatizzare, inizia da quello. Inizia sempre con i controlli che ottengono il massimo tramite l'automazione e lavora da lì.

So far the main benefit we can see is for regression testing, especially across multiple client deployments of our platform.

È il vantaggio principale, e se impostato correttamente, puoi testare la maggior parte dei browser che ti occorrono con una piccola modifica alla configurazione.

We "think" it is the right thing to do but in an already busy schedule are looking for some additional insight.

Come ho detto prima, l'automazione dei test richiede notevoli sforzi, tuttavia, se eseguita correttamente, non ho ancora incontrato una squadra che abbia detto "Vorrei non aver impostato la nostra automazione di test."

Hai ragione che la regressione è enorme. Inoltre -

• se i tuoi test sono scritti in modo modulare, puoi ottenere più botte grazie al mixaggio e alla corrispondenza dei set di test

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

• test delle prestazioni

• test multi-thread

• sui sistemi web - scambio tra i browser e scambio tra i sistemi operativi. Con i problemi di coerenza del browser, colpire la base più ampia possibile è una cosa enorme.

Cose da saltare  - specialmente nei sistemi web, fai attenzione ai casi in cui gli elementi del tuo display sono creati con id dinamici e mutevoli - spesso gli script di test automatici non gestiscono bene questo aspetto e potresti dover riprovare seriamente per aggiornarlo.

Un solo esempio: misurazione accurata della durata del rendering della pagina web

Utilizzando i test di automazione, è molto più facile testare le prestazioni del browser web. Per misurare il tempo di risposta massimo che è probabile accettare, 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).

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

L'alternativa sarebbe avere dipendenti che misurano i tempi con un cronometro.

I test dell'interfaccia utente automatizzati risolvono la capacità di:

• ripetere rapidamente il test su un gran numero di componenti
• ricorda di testare un numero elevato di funzioni ogni volta
• confronta le corse e i tempi di esecuzione delle suite di test man mano che l'applicazione cresce
• imposta esecuzioni con centinaia di input diversi e condizioni variabili
• abilita le persone che non hanno scritto il test per eseguirlo e vedere eventuali problemi visivi
• consentire agli utenti finali di vedere l'applicazione utilizzata in modo facile e veloce
• distribuisci le UI di test eseguite su una rete, un server remoto o un servizio
• avvia il test del volume usando macchine parallele.

Tuttavia, come altri hanno notato:

Telerik...

the tool of choice due to its much more flexible recorder

è una bandiera rossa per molti di noi.

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

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

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 poi modificare lo script per utilizzare ID, classi e attributi dei dati in modo che duri nel tempo. Questo è un approccio che ho effettivamente usato con il plugin per il selenio firefox.

Rende "Expert Testing" (simile ai "test esplorativi", ma realizzato dagli utenti finali o membri del team con una grande quantità di conoscenze aziendali) 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 automatici commerciali (QALoad, QARun, TestPartner, SilkTest, SilkPerfomer).

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

1. Test di regressione completa

2. Impostazione automatica degli ambienti di test

Abbiamo pesantemente appoggiato gli strumenti per eseguire test di regressione su base notturna. Semplicemente non avevamo il potere dell'uomo di testare tutti i pulsanti e le finestre di dialogo per verificare che non avessimo infranto nulla tra l'interfaccia utente e la logica di business.

Per test più importanti, abbiamo scoperto che una singola persona poteva far girare diverse macchine virtuali e utilizzare gli script per arrivare al punto di un vero test. Permette loro di concentrarsi sui bit importanti e non tentare di seguire un test case in 24 fasi.

L'unico problema con i test automatici era l'abitudine di scaricare troppi test sulla confezione senza alcun tipo di supervisione per eliminare test duplicati o non necessari. Ogni tanto dovevamo entrare e potare le cose in modo che la suite potesse completare in meno di 12 ore.

I test automatici, di qualsiasi tipo, prevedono test di regressione; eseguendo il test che funzionava, verificate che funzioni (o non lo faccia) indipendentemente da qualsiasi altra cosa abbiate aggiunto. Questo è vero indipendentemente dal fatto che il test sia un test di integrazione (che di solito non tocchi 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 è quello di ridurre il tempo impiegato dai pulsanti di selezione, molto come integrazione e unit test per il programmatore. Può impostare un test una volta (solitamente 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 è eseguirlo di nuovo. Alcuni framework, come Selenium, consentono la migrazione dei test tra i browser, consentendo il test di diversi ambienti in cui il sito dovrebbe funzionare correttamente.

Senza test automatizzati, sei limitato dal numero e dalla velocità dei tuoi tester QA; devono letteralmente avere a portata di mano il sistema, testando che la nuova funzione soddisfi i requisiti e (altrettanto importante) che non abbia violato nulla che era già presente.

I test determinano molte cose diverse. Molti di questi test possono essere automatizzati, per consentire la rimozione del lavoro ingrato e per fare di più. Per determinare se i tuoi test possono essere automatizzati, devi prima vedere se la domanda che chiedono è appropriata per questo.

• Stai determinando se un componente funziona secondo le specifiche?
• Vuoi testare tutti i diversi ingressi e uscite possibili?
• stress test il componente?
• O stai provando a testare che "funziona"?

La maggior parte di questi può essere automatizzata, perché sono di natura meccanica. La nuova funzione accetta input, quindi cosa succede quando lanciamo dati casuali su di esso? Ma alcuni, come testare se il sistema funziona, richiedono a qualcuno di usarlo in realtà. Se non lo fanno, non saprai mai se le aspettative dei tuoi utenti sono le stesse di quelle del programma. Finché, cioè, il sistema si "spezza".

Nella mia esperienza, i test dell'interfaccia utente automatizzati coprono molte lacune tra cui:

• Mancanza di documentazione (esempio: utilizzo del test runner automatizzato per la dimostrazione della funzionalità esistente)
• Requisiti obsoleti a causa di creep dell'ambito (esempio: identificazione del divario tra requisiti e codice acquisendo lo schermo durante le esecuzioni di test)
• Alto turnover di sviluppatori e tester (esempio: reverse engineering legacy JavaScript acquisendo lo schermo durante le esecuzioni di test con lo strumento di sviluppo aperto)
• Identificazione delle violazioni delle convenzioni di denominazione standard tramite test di regressione XPath (ad esempio: ricerca di tutti i nodi dell'attributo DOM per i nomi cased del cammello)
• Riconoscimento dei buchi di sicurezza che solo un computer può scoprire (esempio: disconnessione da una scheda e contemporaneamente invio di un modulo nell'altra)

Mi piacerebbe condividere l'esperienza del nostro team. Abbiamo utilizzato il nostro strumento di test dell'interfaccia utente, Screenster, per testare le nostre applicazioni web dei nostri clienti. Ha dimostrato di essere un utile alternativa al Selenium per le attività di test visuali / CSS. Screenster è un strumento di automazione dei test che esegue il confronto basato su screenshot di diverse versioni delle tue pagine web. Prima crea una linea di base visiva per una pagina, catturando uno screenshot per ogni azione dell'utente. Durante la prossima esecuzione prende una nuova schermata ad ogni passo, la confronta con quella della linea di base e mette in risalto le differenze.

Riassumendo, Screenster presenta i seguenti vantaggi: Linea di base visiva: gli screenshot vengono catturati per ogni fase dell'utente durante la registrazione del test Confronto basato su screenshot: lo screenster confronta le immagini catturate durante una riproduzione con quelle della linea di base e evidenzia tutte le differenze Selettori CSS intelligenti: il tester può selezionare elementi CSS negli screenshot ed eseguire azioni con essi - ad es. contrassegnali come ignorano le regioni da escludere da ulteriori confronti