Qual è il punto di selenio?

Question

Ok, forse mi manca qualcosa, ma davvero non vedo il punto del Selenio. Qual è lo scopo di aprire il browser usando il codice, fare clic sui pulsanti usando il codice e controllare il testo usando il codice? Ho letto il sito Web e vedo come in teoria sarebbe utile testare automaticamente le tue applicazioni web, ma alla fine non ci vuole solo molto più tempo per scrivere tutto questo codice piuttosto che semplicemente fare clic e verificare visivamente che le cose funzionino ?

Non capisco ...

Answer 1

Ti consente di scrivere test funzionali nella tua " unità " framework di test (il problema è la denominazione del successivo).

Quando si esegue il test dell'applicazione tramite il browser, di solito si esegue il test del sistema completamente integrato. Considera che devi già testare le tue modifiche prima di eseguirle (test del fumo), non vuoi testarle ripetutamente manualmente.

Qualcosa di veramente bello, è che puoi automatizzare i tuoi test del fumo e il QA può aumentare quelli. Abbastanza efficace, in quanto riduce la duplicazione degli sforzi e avvicina l'intera squadra.

Ps come qualsiasi pratica che stai usando la prima volta che ha una curva di apprendimento, quindi di solito impiega più tempo le prime volte. Ti suggerisco anche di guardare il oggetto pagina , aiuta a mantenere i test pulito.

Aggiornamento 1: Nota che i test eseguiranno anche javascript sulle pagine, il che aiuta a testare pagine altamente dinamiche. Si noti inoltre che è possibile eseguirlo con browser diversi, in modo da poter verificare i problemi tra browser (almeno sul lato funzionale, poiché è ancora necessario controllare l'aspetto visivo).

Si noti inoltre che man mano che aumenta la quantità di pagine coperte dai test, è possibile creare rapidamente test con cicli completi di interazioni. Usando il modello Oggetto pagina sembrano:

   LastPage aPage = somePage
      .SomeAction()
      .AnotherActionWithParams("somevalue")
      //... other actions
      .AnotherOneThatKeepsYouOnthePage(); 
  // add some asserts using methods that give you info
  // on LastPage (or that check the info is there).
  // you can of course break the statements to add additional 
  // asserts on the multi-steps story.

È importante capire che vai gradualmente su questo. Se si tratta di un sistema già integrato, si aggiungono test per le funzionalità / modifiche su cui si sta lavorando. Aggiungendo sempre più copertura lungo la strada. Andando invece al manuale, di solito si nasconde ciò che si è perso nel test, quindi se si è apportata una modifica che ha effetto su ogni singola pagina e si controllerà un sottoinsieme (poiché il tempo non lo consente), si sa quali sono stati effettivamente testati e il QA può funzionare lì (si spera aggiungendo ancora più test).

Answer 2

Questa è una cosa comune che si dice sui test unitari in generale. " Devo scrivere il doppio del codice per il test? " Gli stessi principi si applicano qui. Il vantaggio è la possibilità di modificare il codice e sapere che non stai rompendo nulla.

Answer 3

Perché puoi ripetere ripetutamente il STESSO test.

Answer 4

Se la tua applicazione ha anche più di 50 pagine e devi fare build frequenti e testarla su un numero X di browser principali, ha molto senso.

Answer 5

Immagina di avere 50 pagine, tutte con 10 collegamenti ciascuna, e alcune con moduli multi-stage che richiedono di passare attraverso i moduli, inserendo circa 100 diversi set di informazioni per verificare che funzionino correttamente con tutti i numeri di carta di credito , tutti gli indirizzi in tutti i paesi, ecc.

È praticamente impossibile testarlo manualmente. Diventa così soggetto all'errore umano che non puoi garantire che i test siano stati eseguiti correttamente, non importa cosa provino i test sulla cosa testata.

Inoltre, se segui un modello di sviluppo moderno, con molti sviluppatori che lavorano tutti sullo stesso sito in modo disconnesso e distribuito (alcuni lavorano sul sito dal loro laptop mentre su un aereo, per esempio), allora i tester umani non sarà nemmeno in grado di accedervi, tanto meno avere la pazienza di riprovare ogni volta che un singolo sviluppatore prova qualcosa di nuovo.

Su qualsiasi sito Web di dimensioni adeguate, i test DEVONO essere automatizzati.

Answer 6

Il punto è lo stesso di qualsiasi tipo di test automatizzato: scrivere il codice potrebbe richiedere più tempo di "fare clic e verificare visivamente che le cose funzionino", forse 10 o anche 50 volte di più.

Ma ogni applicazione non banale dovrà essere testata molto più di 50 volte alla fine, e i test manuali sono un fastidioso lavoro che sarà probabilmente omesso o fatto debolmente sotto pressione, il che si tradurrà in bug che resteranno da scoprire fino a poco prima (o dopo) scadenze importanti, che si traducono in sessioni di codifica stressanti per tutta la notte o persino in perdite monetarie definitive dovute a sanzioni contrattuali.

Answer 7

Il selenio (insieme a strumenti simili, come Watir) ti consente di eseguire test sull'interfaccia utente dell'app Web in modi in cui i computer sono bravi: migliaia di volte durante la notte o entro pochi secondi dopo ogni check-in alla fonte. (Nota che ci sono molti altri pezzi di test dell'interfaccia utente in cui gli umani sono molto più bravi, come notare che qualche cosa strana non direttamente correlata al test è sbagliata.)

Esistono altri modi per coinvolgere l'intero stack della tua app guardando l'HTML generato invece di avviare un browser per renderlo, come Webrat e Mechanize . La maggior parte di questi non ha modo di interagire con le UI pesanti di JavaScript; Il selenio ti copre in qualche modo qui.

Answer 8

Selenium registra ed esegue nuovamente tutto il manuale facendo clic e digitando per testare la tua applicazione web. Ancora e ancora.

Nel corso del tempo gli studi di me stesso mi hanno dimostrato che tendo a fare meno test e iniziare a saltarne alcuni o a dimenticarmene.

Il selenio eseguirà invece ogni test, lo eseguirà, se non restituisce ciò che ti aspetti, può farti sapere.

C'è un costo iniziale di tempo per registrare tutti questi test. Lo raccomanderei come test unitari - se non lo hai già, inizia a usarlo con le parti più complesse, permalose o più aggiornate del tuo codice.

Answer 9

E se salvi quei test come classi JUnit puoi eseguirli di nuovo a tuo piacimento, come parte della tua build automatizzata o nel test di carico di un uomo povero usando JMeter.

Answer 10

In un lavoro precedente abbiamo usato per testare la nostra web-app. Se l'app Web cambia aspetto, i test non devono essere riscritti. Tutti i test di tipo record and replay dovrebbero essere ripetuti.

Answer 11

Perché hai bisogno del selenio? Perché i tester sono esseri umani. Vanno a casa tutti i giorni, non possono sempre lavorare nei fine settimana, prendere i malati, fare le festività, andare di tanto in tanto in vacanza, annoiarsi facendo compiti ripetitivi e non possono sempre fare affidamento sul fatto che sono in giro quando ne hai bisogno.

Non sto dicendo che dovresti sbarazzarti dei tester, ma uno strumento di test UI automatizzato completa i tester di sistema.

Answer 12

Il punto è la capacità di automatizzare ciò che era prima di un test manuale e che richiede tempo. Sì, ci vuole tempo per scrivere i test, ma una volta scritti, possono essere eseguiti tutte le volte che il team desidera. Ogni volta che vengono eseguiti, verificano che il comportamento dell'applicazione Web sia coerente. Il selenio non è un prodotto perfetto, ma è molto bravo ad automatizzare l'interazione realistica dell'utente con un browser.

Answer 13

Se non ti piace l'approccio al selenio, puoi provare HtmlUnit , lo trovo più utile e facile da integrare nei test unitari esistenti.

Answer 14

Per applicazioni con interfacce Web avanzate (come molti progetti GWT) Selenium / Windmill / WebDriver / etc è il modo per creare test di accettazione. Nel caso di GWT / GXT, il codice dell'interfaccia utente finale è in JavaScript, quindi la creazione di test di accettazione utilizzando normali casi di test junit è sostanzialmente fuori discussione. Con Selenium è possibile creare scenari di test corrispondenti alle azioni dell'utente reale e ai risultati previsti.

In base alla mia esperienza con Selenium, può rivelare bug nella logica dell'applicazione e nell'interfaccia utente (nel caso in cui i casi di test siano ben scritti). Trattare con i front-end AJAX richiede uno sforzo extra ma è ancora fattibile.

Answer 15

Lo uso per testare moduli multipagina in quanto ciò comporta l'onere di digitare più volte la stessa cosa. E avere la capacità di verificare se alcuni elementi sono presenti è grandioso. Ancora una volta, usando il modulo come esempio il test finale del selenio potrebbe verificare se qualcosa come dire "Grazie Mr. Rogers per aver ordinato ..." appare alla fine del processo di ordinazione.