Lavoro su un team che sviluppa un sito Web con un numero elevato di pagine. Il ragazzo di QA del team esegue attualmente tutti i test manualmente. Sto pensando di fargli creare un mucchio di script di selenio. Non penso che possa automatizzare tutti i test, ma potrebbe automatizzarne molti.
Perché non ha un background di programmazione, quanto sarà difficile per lui creare e gestire un lotto di script Selenium? Con quali problemi avrà bisogno di aiuto?
Penso che il selenio come strumento indipendente di registrazione e riproduzione sia l'ideale per utenti non tecnici. L'idioma di registrare il mio percorso e poi riprodurlo è intuitivo, e l'interfaccia, anche se ovviamente orientata verso non-newb, non è troppo intimidatoria.
Selenium 2 / Selenium RC è ovviamente un ordine più elevato di complessità e non penso che si possa chiedere a un non programmatore di interfacciarlo con quello. (Sono stato frustrato dalla mancanza di un'interfaccia completa per i linguaggi non Java, in realtà. So che la versione attuale è di transizione, ma potrei davvero utilizzare una soluzione PHP completa in questo momento, non in qualche mitica release futura. cosa stai chiedendo.)
Penso che se il tuo tester non sa già del selenio, ti bacerà sulla bocca per parlargliene.
Selenium-IDE è progettato per essere utilizzato dai non programmatori. Ma la mia esperienza è che gli script che vengono prodotti in quel modo (usando XPath generato) sono molto fragili.
Quindi creare in essi non dovrebbe essere un problema. La gestione sarà non-così-cattiva se la vostra applicazione è abbastanza stabile. O quasi impossibile se la tua applicazione è in sviluppo e / o cambia frequentemente.
Selenium-RC è puramente uno strumento di sviluppo.
Consiglio vivamente di rivolgere questa domanda alla garanzia della qualità del software & Prova il sito beta o cerca domande simili che sono già state poste lì. Troverai una maggiore esperienza con l'uso del selenio per il QA di registrazione e riproduzione.
La risposta di Eric è l'esperienza della maggior parte degli ingegneri del controllo qualità che utilizzavano strumenti di registrazione e riproduzione: i test risultanti erano fragili e difficili da mantenere. Uno sviluppatore può utilizzare Page Objects con Selenium RC per creare una suite di test dell'interfaccia utente molto più manutenibile ed è un'opzione migliore quando è disponibile.
Questo non vuol dire che l'IDE Selenium non sarà utile per il tuo tester; tuttavia, l'utilità (e il potenziale di danneggiare gli sforzi di test piuttosto che l'aiuto) dipende strongmente da quanto è fissa l'interfaccia utente. Otterrete i migliori risultati con la registrazione e la riproduzione se l'interfaccia utente può essere bloccata all'inizio del ciclo di sviluppo. Potrebbe essere necessario insegnare al tester come ottenere nuovi XPath quando i vecchi XPath sono interrotti e come sapere se il test ha esito negativo a causa di una modifica dell'interfaccia utente (perché XPath non è più valido) oa causa di un bug di funzionalità. / p>
Penso che l'uso dell'XE Selenium sia migliore di nessuna automazione per qualsiasi progetto che abbia un'interfaccia utente generalmente stabile. Esecuzione di centinaia di test manuali sull'interfaccia utente stabile ogni volta che c'è un piccolo cambiamento è un vero e proprio spreco di tempo. Basta impostare le aspettative di conseguenza e rendersi conto che la modifica dell'interfaccia utente avrà un impatto significativamente maggiore sulla pianificazione del controllo di qualità una volta che si inizia a utilizzare l'automazione record-and-replay per quell'interfaccia utente. Il tuo tester potrebbe voler scegliere le aree che automatizza saggiamente.
Considera l'utilizzo di un framework di test guidato da parole chiave. L'idea è che gli sviluppatori sviluppano parole chiave di alto livello (o si utilizzano quelli che entrano in una libreria) e il tester raggruppa semplicemente queste parole chiave in casi di test di alto livello.
I team in cui sono stato negli ultimi anni hanno tratto molto chilometraggio da questo approccio. Utilizziamo framework robot ma ce ne sono altri come cetriolo (supportato da diverse lingue) e specflow (un'implementazione di cetriolo per .net)
Ad esempio, utilizzando questo approccio il tuo tester potrebbe scrivere un test che assomiglia a questo:
| Login with valid credentials
| | Go to page | LoginPage
| | Login as a normal user
| | The current page should be | DashboardPage
Queste parole chiave potrebbero essere scritte in python (o java o in un linguaggio .NET), ad esempio:
class LoginPage(PageObject):
def login_as_a_normal_user(self):
username = self.browser.find_element_by_id("username")
username.send_keys(DEFAULT_USER)
password = self.browser.find_element_by_id("password")
password.send_keys(DEFAULT_PASSWORD)
... and so on...
Esiste una libreria pre-creata per robot con parole chiave generiche basate sul selenio ("vai alla pagina", "la pagina dovrebbe contenere", "fare clic sul pulsante", ecc.) con cui il tester può diventare immediatamente produttivo con.
Abbastanza spesso queste parole chiave generiche sono sufficienti, ma usare il concetto di oggetti di pagina e parole chiave specifiche della pagina è un modo efficace per scrivere test. I tuoi sviluppatori possono creare una classe per ogni pagina della tua app e per ogni pagina possono scrivere parole chiave per scopi speciali in modo che il tester possa concentrarsi maggiormente sulla funzione logica della pagina piuttosto che sull'implementazione fisica.
Ecco un paio di post sul blog che ho scritto che si tuffano più in dettaglio nell'utilizzo di oggetti di pagina con framework robot:
Non ho avuto problemi ad addestrare gente non programmatrice a scrivere test di selenio con XPath relativi in Java / JUnit. Il programmatore lo imposta e scrive un modello di test di base, il tester sviluppa più test, registrandoli e quindi modificandoli. Se il tester ha bisogno di qualcosa di specifico, chiede al programmatore di scriverlo. Tester deve avere una conoscenza di base di HTML e XPath e un po 'di aiuto per selezionare l'API Selenium (oltre al plug-in Selenium per Firefox e Firebug).
La cosa divertente è che inizialmente pensavo a qualcosa di fantasioso come Cucumber o qualcosa di simile, ma questa combinazione Selenium / JUnit si è rivelata abbastanza buona e abbastanza semplice. Curiosamente, i tester senza precedente esperienza Java non hanno avuto problemi seri a scrivere test JUnit. L'unica cosa importante è che il programmatore esperto configuri il test, in modo che il tester abbia solo bisogno di produrre nuovi test e chiamare i metodi Selenium.
In realtà abbiamo avuto questa situazione in cui abbiamo avuto un membro del team non tecnico (in questo caso, un SQA senza background di programmazione). Questo purtroppo non è andato molto bene.
Prima il nostro team aveva provato gli strumenti di registrazione e riproduzione, ma come altri hanno detto, i test che genera sono molto fragili e difficili da mantenere. Il nostro SQA finì per cadere in un modello di registrazione di un test ogni volta che è cambiato, il che non era poi così efficiente, specialmente quando un cambiamento ha rotto la maggior parte dei nostri test (abbiamo avuto una modifica alla pagina principale del nostro sito che ha rotto circa 60 % dei nostri test).
Abbiamo scritto i nostri test sul selenio in Java e lo SQA non aveva mai usato Java prima, quindi lo stava imparando da solo. Abbiamo scoperto che i test si concludevano con alcune pratiche di programmazione davvero scadenti:
assertTrue(false) di righe per terminare un test Quando sono arrivato nel team, lo SQA originale era uscito e l'esecuzione di qualsiasi test ha comportato una serie di eccezioni console che ci è stato appena detto di ignorare. Dopodiché, abbiamo finito col coinvolgere gli sviluppatori e riscrivere in maniera massiccia gran parte del codice per farlo funzionare correttamente, essere manutenibile e facile da capire.
Penso che alcuni di questi problemi avrebbero potuto essere evitati se avessimo avuto qualcuno che fosse tecnico e li aiutasse. Se avessero spiegato perché le variabili statiche pubbliche dovrebbero invece essere variabili di istanze private, o come funziona JUnit, o come utilizzare WebDriverWait, o perché lo scattering di Thread.sleep () in giro ovunque sia cattivo, potremmo avere un codice migliore.
Ma, come è, siamo finiti con un codice che alla fine è stato irraggiungibile e, alla fine, abbiamo appena riscritto la maggior parte di esso, con un notevole spreco di tempo e denaro.