I test della GUI automatizzati richiedono troppo tempo a causa degli stessi passaggi prima che la "azione di test principale" possa procedere

1

Stiamo sviluppando un'applicazione desktop e sono responsabile per i test della GUI. Attualmente abbiamo circa 500 test che richiedono 8 ore.

I test stanno testando quasi tutti i pulsanti / menu / campi ecc. nell'applicazione. Alcune funzioni impiegano 3 - 15 minuti perché l'applicazione sta effettivamente misurando qualcosa, ma la maggior parte dei test richiede circa 2 minuti.

Il problema più grande che vedo è che molti test stanno eseguendo gli stessi passaggi prima che l'azione di test principale possa procedere, ad esempio iniziare con l'importazione di documenti da utilizzare per il test, che richiede diversi secondi.

Come ridurre questa volta?

Il test parallelo o un ambiente di esecuzione di fantasia non è probabilmente una soluzione o ciò che chiedo. Sono più interessato alla progettazione del test o ad alcuni suggerimenti per ridurre la ripetizione del lavoro.

    
posta ne2dmar 26.03.2014 - 14:55
fonte

3 risposte

4

Ci sono diversi approcci per attaccare il tempo in cui i test automatici sono in aumento. Alcuni degli approcci, come l'esecuzione di più ambienti virtuali e l'esecuzione parallela dei test, e la riduzione della portata di ciò che è effettivamente testato potrebbero non essere adatti al carico di lavoro, ma vale la pena menzionarli come possibili strategie per altri lettori in futuro.

Una delle aree in cui i test automatizzati possono impiegare molto tempo, consiste nell'eseguire il test nello "stato di test".

Una soluzione non ottimale è raggruppare i test in modo che sia sufficiente entrare in quello stato di test una sola volta e quindi eseguire tutti i test in questo stato come parte di un test di gruppo. Ciò è difettoso, perché puoi avere situazioni in cui i test passano solo a causa di artefatti lasciati da una sequenza precedente nell'esecuzione del test.

Una soluzione più completa è trovare un meccanismo per ricreare rapidamente l'ambiente di partenza. Hanno molto sull'effetto sistemico dell'importazione di questi documenti. Sono elaborati in diversi file di configurazione? stanno aggiornando più tabelle di database? e quindi trovare un meccanismo più efficiente per l'iniezione di queste informazioni di stato nell'ambiente di test. Tuttavia, questo approccio può essere problematico se il formato delle informazioni sullo stato cambia durante lo sviluppo del prodotto, è un lavoro sostanziale da ricreare.

La soluzione che probabilmente utilizzerei è quella di utilizzare un meccanismo che consenta il rollback. Potrebbe essere un ambiente virtuale in grado di eseguire il rollback a un'istantanea, o magari usare LVM sotto il file system e quindi all'inizio di ogni test, torniamo indietro al punto di partenza, perdendo gli artefatti della corsa precedente.

    
risposta data 26.03.2014 - 15:41
fonte
0

Una strategia che vedo utilizzata è raggruppare i test per durata. Diciamo che hai 300 test. 100 di loro corrono in 30 secondi o meno. 100 di essi eseguono 30 secondi - 60 secondi e 100 di essi corrono più a lungo di quello (forse fanno un po 'di analisi statistica per dividerli in 3 o 4 gruppi).

Se strutturi il processo di esecuzione del test (ad esempio, usando tag in Cucumber) in modo che siano raggruppati per quanto tempo impiegano tipicamente, puoi eseguire le tue cose veloci forse ogni giorno, le tue cose medie ogni altro giorno, e il tuo roba da corsa una volta alla settimana.

Non è l'ideale, ma "ideale" costa (elaborazione parallela contro una grande griglia virtuale, ad esempio), e non tutti i negozi possono permettersi la spesa.

    
risposta data 26.03.2014 - 23:12
fonte
-1

Quale strumento di test automatico stai usando? Ciò influenzerà significativamente le risposte.

Per quanto riguarda i collegamenti sì puoi ridurre alcuni dei tuoi test.

es. Se i tuoi primi passi sono sempre in fase di avvio, accedi, naviga al modulo X ... esegui l'interrogazione di "thing-a-ma-bobs", quindi esegui 12 script che fanno qualcosa con uno. puoi dividere i tuoi test in modo da avere l'opzione di eseguirli da un capo all'altro, o se la parte iniziale di avvio / login / navigazione è terminata, basta eseguire il resto di ciascuno dei tuoi test da quel punto.

Ognuno dei tuoi test dovrebbe essere effettivamente registrato / scritto in un formato abbastanza modulare in modo che tu possa combinarne molti di loro insieme secondo necessità e / o scambiare uno che necessiti di un tweaking.

es. per un'applicazione desktop mi aspetterei un po 'come:

  • Avvia l'app
  • Accedi all'App (se applicabile)
  • Passa alla schermata X (una per tutte le parti principali della tua app)
  • Seleziona / Visualizza un $ {Oggetto} (qualunque sia il tuo oggetto)
    • Rinomina
    • Modifica
    • Assegnalo
    • Annulla l'assegnazione
    • ...

Spero (se necessario) di saltare i primi passi una volta che sei "in" e di eseguire solo le singole attività.

    
risposta data 26.03.2014 - 15:30
fonte

Leggi altre domande sui tag