2010-04-27 17 views
8

Voglio iniziare a implementare l'automazione. Non so se questo sarebbe un buon uso delle risorse. L'applicazione sta crescendo ad un tasso esponenziale, ma non so a che punto i test di benefici dell'automazione.Quando deve iniziare l'automazione?

Puoi darmi dei motivi per automatizzare anche se hai tester manuali?

+0

Sembra che si stia tentando di creare un framework di test che automatizzi ciò che fanno i tester del QA (test della GUI). Hai già test di livello inferiore (unità/integrazione)? È importante averli prima di avere l'automazione della GUI. –

+0

Grazie a tutti per le vostre risposte. Erano tutti molto utili. In questo momento sto guardando in Selenium e Ruby. Sono sicuro che mi vedrete presto altre domande. – onesith

+0

Dopo aver esaminato la mia ultima domanda, ho fottuto. Dovrebbe essere "Quando" invece del perché. grazie ancora. – onesith

risposta

2

penso che dipende dalle persone che lavorano in azienda . Alcune persone amano l'automazione, altre lo amano meno. Se la tua azienda non ce l'ha ora, provare a implementarla potrebbe essere difficile.

Preferisco l'automazione, a causa delle ore (già menzionate) e perché per la maggior parte si sa cosa si otterrà con esso.

Si dovrebbe avere entrambi, ma per andare senza automazione e test diventerà molto difficile come prodotto cresce.

+0

Mi ha risposto quando avrei dovuto automatizzarlo. Tutti gli altri mi hanno dato una grande ragione per usare l'automazione. – onesith

0

Effettuare test più efficienti - anche se si dispone di tester manuali, se (o voi) è possibile implementare test automatizzati, è possibile esplorare molti altri casi. Scrivere i tuoi test automatici potrebbe anche darti un'idea del tuo codice.

4

È possibile eseguire l'automazione perché premendo "vai" e aspettando 10 minuti per i risultati si intende che il tester può eseguire altri lavori utili durante quei 10 minuti invece di fare da baby-sitter all'applicazione.

Ricordare che un test automatico può essere eseguito ogni notte mentre si dorme. I tester possono quindi utilizzare il loro orario di lavoro per scrivere nuovi test utili invece di ripetere gli stessi vecchi test più e più volte.

La ragione principale è che quando hai cambiato qualcosa poco prima della spedizione, con i test automatici non esiterai a eseguire i test anche se "il cambiamento è stato semplice e non avrebbe dovuto essere danneggiato" - e poi tu tira un sospiro di sollievo quando i test automatici catturano l'errore che avevi introdotto e stavano per essere spediti.

5

L'automazione è quasi sempre un buon modo per testare. Il test manuale è ancora importante, ma è molto più soggetto a errori e se il processo di test manuale inizia a richiedere giorni o settimane per essere completato, diventa difficile distribuire gli aggiornamenti a una velocità elevata. Di solito è più semplice impostare l'automazione all'inizio di un progetto, perché ci saranno meno cose da automatizzare e, una volta ottenuto il framework di automazione, dovrebbe essere facile espandersi man mano che il progetto cresce.

Provare ad automatizzare i test su un progetto già completamente implementato richiederà probabilmente più lavoro che l'automazione fin dall'inizio, quindi consiglierei di immergerti il ​​prima possibile.

1

I test ripetuti sono dolorosi e soggetti a errori con test manuali e, se l'applicazione viene modificata, è necessario ripetere i test.

0

test automatico può benchmark e identificare problemi con l'interfaccia utente ... che manualmente non poteva anche essere cliccata thaaat veloce :)

0

Immaginiamo che la dimensione del programma e il numero di test aumenta linearmente con tempo, e che tu voglia fare continui (giornalieri) test di integrazione e regressione. In questo caso, il primo giorno testerai una cosa, il secondo giorno ne effettuerai il test due, il terzo giorno ne verificherai tre, ecc.

Lo sforzo di test totale per i test manuali aumenterà con il quadrato della dimensione del programma: a causa del nuovo test e del re-test.

Se non si automatizza, non si eseguiranno regolarmente test di regressione completi.

2

La ragione per cui ho automatizzato i test è che significa ottenere un riscontro coerente, ripetibile e tempestivo che ciò che ho appena fatto è corretto.

Anche il test manuale ha il suo posto, ma è difficile essere convinti di coprire tutto correttamente, e certamente non lo fa altrettanto rapidamente quanto i test automatici.

Ad esempio, parte di uno dei miei progetti è un algoritmo di ottimizzazione che utilizza una certa euristica per aggirare lo spazio di ricerca alla ricerca di buone soluzioni. Ora ci sono circa 40 euristiche diverse che possono essere utilizzate individualmente o in varie combinazioni, e ogni incontro con un cliente sembra implicare l'aggiunta di una nuova euristica o l'estensione di una esistente. Devo essere assolutamente certo che nessuno di questi lavori per un cliente causerà una regressione per un altro cliente, il che implica l'esecuzione dell'algoritmo su poche centinaia di casi diversi e la verifica che l'output sia (non peggiore di) di un tempo.

Non sarebbe pratico chiedere a un tester manuale di eseguire tutti questi casi di test caricando la GUI, aprendo il file di input e facendo clic su "Esegui", almeno non abbastanza spesso per essere un meccanismo di feedback utile. I test sono generalmente eseguiti decine di volte al giorno per i test brevi e ogni notte per i test più pesanti. Con un processo manuale, il feedback completo richiederebbe probabilmente un paio di giorni e correggere un bug introdotto un paio di giorni fa è molto più difficile che correggere un bug introdotto nell'ultima mezz'ora.

Sarebbe anche molto difficile garantire che qualsiasi controllo "a occhio" dei risultati sia buono come una volta, quindi i controlli dei risultati devono essere automatizzati. Ma se hai intenzione di automatizzarlo, puoi anche automatizzare il tutto. Non è difficile.

Un ulteriore vantaggio dei test automatici, dall'esperienza di lavorare con un progetto che non ne aveva, è che se si hanno test manuali che non sono ampiamente documentati, allora quando il progetto giace dormiente (in "modalità manutenzione" apparentemente) per un anno e poi riavvia lo sviluppo attivo nessuno può ricordare come eseguire i test o quali sono stati i risultati attesi, e si finisce per introdurre un intero mucchio di regressioni sciocche che impiegano anni a rimbalzare. D'altra parte, se hai intenzione di documentare i tuoi test in modo sufficientemente dettagliato da poter essere raccolti un anno dopo l'altro, in pratica li hai già automatizzati: hai solo bisogno di rendere la documentazione eseguibile.

Nella mia esperienza, è necessario iniziare a testare circa 2 ore prima del punto in cui ci si rende conto improvvisamente che si dovrebbe avere iniziato a testare 2 ore fa :)

2

Puoi darmi dei motivi per automatizzare anche se hai tester manuali?

Vorrei automatizzare tutto ciò che può essere automatizzato. Qual è il valore aggiunto dell'uso di un cervello umano per qualcosa che può essere fatto da una macchina in modo ripetibile? E lo sviluppo personale? Preferisco usare un cervello umano per qualcosa che possono fare meglio delle macchine: pensa.

0

È necessario automatizzare il prima possibile. Molti studi hanno dimostrato che più tardi si trova un difetto nel ciclo di sviluppo più è costoso da risolvere. L'automazione generalmente consente di trovare i difetti il ​​più presto possibile (presumendo che tu esegua effettivamente quei test automatici il prima possibile).

Prima si inizia a scrivere test automatici, prima gli sviluppatori possono iniziare a eseguire quei test automatici e/o possono essere eseguiti in un ambiente di integrazione continua. E una volta che ciò accade, prima trovi i difetti che risparmiano i soldi dell'azienda e rendono felici gli sviluppatori perché consentono loro di rilasciare un codice di qualità superiore. Inoltre dà loro la sicurezza di apportare modifiche perché possono vedere rapidamente se provoca una regressione.

Inoltre, fa sì che i tecnici di qualità facciano molto più parte del processo complessivo piuttosto che sentirsi come se il loro impegno sia stato risolto fino alla fine, dopo che gran parte del lavoro è già stato fatto.

0

Ci sono alcune regole empiriche prima di avviare l'automazione, come assicurati che la tua applicazione sia abbastanza stabile, in secondo luogo prova ad avviare l'automazione con ad es. creare una sceneggiatura di prova del fumo, che inizialmente tocca parti principali (solo parti critiche della funzionalità). Ad esempio, se si tratta di un'applicazione bancaria, inizialmente è sufficiente automatizzare tale operazione se l'utente è in grado di accedere e verificare il proprio saldo del conto ecc. E nulla più o meno. In questo modo, prova ad aumentare il repository di script man mano che l'applicazione diventa più stabile nel tempo. Ma la cosa più importante è chiedersi quale sia esattamente lo scopo che si vuole risolvere con l'automazione.

Di seguito link può anche aiutare:

Pre-requisites to start automation testing

How to plan test automation

0
  1. ogni azienda dovrebbe automatizzare i casi di test.
  2. Automatizza i test di regressione.
  3. Seguire la metodologia BDD e POM.
  4. Il codice deve essere riutilizzabile.
  5. codice deve essere sempre indipendente dalla macchina.
  6. il metodo di segnalazione dovrebbe essere abbastanza semplice da consentire ai proprietari del progetto di conoscerlo facilmente.
  7. integrare CI attraverso JENKINS/cron.
  8. L'automazione richiede il costo dell'hardware e il tempo per l'automazione.
Problemi correlati