Test GUI automatizzati: incontrarci a metà strada

https://stackoverflow.com/questions/822275

03-07-2019
|

Domanda

Mi è stato assegnato il compito di sviluppare un sistema per i test automatizzati della GUI e potrei usare alcuni consigli. Per fortuna, siamo nel bel mezzo di una grande riprogettazione della nostra GUI e gli sviluppatori che fanno il lavoro sono aperti a rendere il loro codice più amichevole per l'automazione. Il mio problema è che non sono sicuro di cosa chiedere loro di aggiungere. Qualunque hook sia aggiunto non può influire sulla funzionalità, sull'aspetto o sulla sicurezza dell'interfaccia e non dovrebbe avere un impatto evidente sulle prestazioni. A parte questo, il cielo è il limite!

L'applicazione in questione è un'app Java basata sul web a cui si accede tramite AJAX. La maggior parte delle funzionalità esistenti sono codificate utilizzando jsp, Javascript e un po 'di Flash 8. La prossima ondata di funzionalità verrà eseguita utilizzando libreria Javascript YUI . Sono praticamente d'accordo su Selenium come strumento di test a causa della sua flessibilità e prezzo (gratuito). Punto importante: sto mirando alla riusabilità dei test e alla facilità di manutenzione. La mia preferenza è scrivere codice che rilevi, convalidi ed eserciti gli elementi della pagina piuttosto che utilizzare un sistema di registrazione e riproduzione per lo sviluppo di test.

Qualcuno può fornire una guida su quali hook possono essere inseriti nel codice o alcune best practice per rendere più semplice lo sviluppo dei test e i test stessi più robusti?

Soluzione

Principio guida di base: se vogliono che testiate qualcosa, i tester hanno bisogno di un modo per portare l'applicazione in quello stato e, una volta in quello stato, un modo per validare che lo stato sia corretto.

Quindi la prima cosa è assicurarsi che comprendano che l'automazione sta programmando e l'interfaccia utente è la tua API.

Accordo per non modificare arbitrariamente l'interfaccia utente - se il tester Bob vede che il componente è cambiato da un pulsante a un collegamento e corrisponde alla specifica, fa clic e continua. Mentre una modifica del codice relativamente semplice nell'automazione, è una modifica che potrebbe essere necessaria in più posizioni. (il tuo compito come tester è capire che il cambiamento avviene e minimizzare i costi di manutenzione; il loro compito è solo apportare modifiche importanti e comprendere l'impatto)
Un modo per determinare su quale pagina ti trovi .... Bob può dire la differenza tra login e immissione dell'ordine, ma come farà l'automazione? Se inserisci un campo con l'etichetta "Nome utente", la pagina di accesso. Se un campo di immissione con numero d'ordine, il campo dell'ordine.

Non buono - la migliore pratica è un elemento UI coerente per identificare la pagina - titolo della pagina, componente nascosto, ecc.

Un modo per identificare in modo univoco ogni elemento con cui devi interagire (fai clic, digita, verifica, ecc.) E non INPUT_42 ....
Chiedi agli sviluppatori quali informazioni possono essere fornite dai tester per accelerare il loro debug e chiedi loro di inserirli in un file di registro
Possibilità di scaricare lo stato del programma
Gestione coerente degli errori & amp; rapporti (anche solo una buona progettazione dell'interfaccia utente)

Altri suggerimenti

Come per la maggior parte delle domande, dipende. Principalmente su come appare il tuo sito e che tipo di controlli sono presenti nelle pagine - ci sono molti elementi ripetuti ecc?

Ho avuto molto successo usando Selenium RC e Selenium IDE. La cosa principale è abituarsi all'utilizzo del selenio e dei suoi comandi. È anche utile abituarsi a localizzare oggetti sulla pagina (selettori XPaths e CSS, oltre alla funzione 'contiene'). Quello che non vuoi sono molti elementi che hanno lo stesso percorso di selezione. Se le tabelle e i div sottostanti non hanno una parte unica, possono aggiungere ulteriore complessità ai tuoi test.

<html>
  <body>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
  </body>
</html>

Per testare le immagini, è bello poter verificare la loro esistenza in base a qualcosa di diverso dal nome del file di immagine, quindi non è necessario modificare i test quando l'immagine viene aggiornata. Se devi testare oggetti Flash, visita questo sito .

Oltre a ciò, non ho notato molte cose che possono essere incorporate nel lato dello sviluppo. Una volta che inizi a configurare i test e a individuare gli elementi sulla pagina, probabilmente vedrai abbastanza rapidamente cosa devono fare gli sviluppatori per aiutarti.

Un consiglio: mantieni il tuo codice di prova in almeno due livelli di astrazione :

livello superiore : questa dovrebbe essere una sorta di facciata orientata verso la terminologia / le azioni specifiche dell'applicazione, ecc. Questo livello non utilizza direttamente la libreria RC Selenium . Sullo sfondo usa il ...
... livello inferiore : una libreria con alcuni schemi di test comuni (esempio: " asserisce che è stato scelto il valore X del controllo pulsante di opzione ") , che utilizza la libreria Selenium RC.

In questo modo i tuoi test saranno più puliti da mantenere e più comprensibili in termini di ciò che viene testato. Abbiamo anche provato un approccio a tre livelli, il terzo strato (in alto) essendo i test specificati usando XML . Questo per consentire ai nostri tester non programmatori di essere in grado di specificare i test di accettazione senza approfondire il codice C #.

Aggiungendo ai commenti di McWafflestix e s_hewitt, gli elementi gui devono essere adeguatamente etichettati, unici e prevedibili per il successo con l'automazione gui. Se gli ID elemento non sono prevedibili, si verificheranno problemi. Prevedibile non significa necessariamente statico. Per elementi di pagina statici come un campo nome utente o un pulsante di accesso, mi aspetterei che il nome / ID per questi siano statici dalla compilazione alla compilazione e all'esecuzione. Per le caselle di controllo, i pulsanti di opzione, i contenuti dinamici, mi aspetto che siano dinamici, ma prevedibili. Ad esempio, potresti avere un div con class = " contentdetail " e un id = "12345". Finché puoi creare il tuo xpath per trovare l'oggetto con cui devi interagire in modo affidabile, dovresti essere bravo.

EDIT: un ottimo modo per gli sviluppatori di supportare l'automazione del test è con la configurazione del test. A seconda dell'applicazione, la configurazione e lo smontaggio del test automatico possono essere problematici. Ad esempio, in un'applicazione del flusso di lavoro del magazzino, i test all'inizio del flusso di lavoro (accetta articoli nel magazzino) sono facili da configurare, ma i test alla fine del flusso di lavoro (spedisci un articolo dal magazzino al cliente) hanno molte dipendenze (l'articolo deve essere in magazzino, con quantità sufficiente, nella posizione corretta dell'inventario, ecc ...) che la maggior parte del codice di automazione può gestire semplicemente navigando e immettendosi attraverso l'app per arrivare al punto in cui è possibile eseguire un test. In questi casi, può essere utile disporre di un qualche tipo di utilità esterna (al di fuori dell'app, quindi la GUI principale non è interessata) per iniettare dipendenze o ripristinare il database su uno stato noto. Nel mio esempio di magazzino, la tua utility potrebbe impostare lo scenario attraverso il livello API, in modo che il test gui automatizzato possa riprendere nel punto pertinente.

C'è molto poco che gli sviluppatori possono aggiungere al codice per aiutare.

Il problema è che se si desidera testare l'esecuzione di percorsi di codice e la validità di tali percorsi di codice, ciò dovrebbe essere fatto in Test unità e questi dovrebbero essere completamente separati dalla propria GUI. Ma se vuoi davvero testare la tua GUI, devi solo simulare l'input dell'utente. L'unica cosa che può aiutare in questo è avere i tuoi oggetti e controlli adeguatamente taggati in modo che possano essere correttamente rilevati dal tuo framework di test ed essere esercitati. A parte questo, non c'è molto che si possa fare (sebbene ciò possa aiutare un po 'di per sé).

Sono abbastanza propenso al (corretto) test unitario, ma ho riscontrato alcune menzioni che dovresti provare ad evitare di testare la tua GUI. Di solito omettono ragioni specifiche, quindi non posso davvero eseguirne il backup.

L'approccio che seguo (e penso che l'approccio suggerito da Juval Lowy in "Programmazione di componenti .NET") è quello di provare a sottrarre il codice effettivo dalla GUI tramite un'interfaccia, che mi consente di scrivere test unitari per tutti i logica aziendale attivata dalla GUI senza effettivamente testare la GUI stessa.

Funziona abbastanza bene e ha portato a un codice molto più pulito con una grande separazione della logica aziendale dalla GUI e rende anche le modifiche della GUI molto meno stressanti.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow