Test dell'applicazione Web utilizzando FitNesse e soapUI: qualsiasi procedura ottimale per la gestione e la manutenzione dei test?

Question

Per tutti gli esperti di automazione di test :-)! Mi piacerebbe sentire le vostre opinioni sul seguente scenario:

C'è un'applicazione web che ho bisogno di testare. Devo eseguire test di back-end sul server e test front-end sul client. Devo anche eseguire test end-to-end, coinvolgendo sia il back-end che il front-end.

Il server espone i servizi Web (SOAP) e il client front-end utilizza i dati da questi servizi. Ci sono anche clienti di terze parti che consumano dati dai servizi web. A volte, uno scenario di test richiede che eseguo test end-to-end, cioè apportando alcune modifiche alla GUI front-end e quindi utilizzo un servizio Web sul back-end per scoprire se le modifiche hanno avuto esito positivo o meno.

Mi piace FitNesse - a mio parere, la separazione di COSA e PERCHE da HOW è essenziale per la progettazione di buoni test. C'è il modulo Selenesse, che rende possibile l'integrazione dei test Selenium con le pagine wiki di FitNesse. Ciò semplifica la descrizione di cosa e perché ho bisogno di testare qualcosa (testo wiki) da come voglio testarlo (tabelle degli scenari e tabelle di script) che è il modo in cui voglio che le cose siano.

Il problema con FitNesse è che è piuttosto complicato testare i servizi Web SOAP. In entrambi i casi, ho bisogno di sviluppare un dispositivo Java per client SOAP appositamente creato, o devo scrivere dispositivi Java che estendono la classe ServiceFixture, scritta per FIT. In entrambi i casi, lo sforzo di sviluppo è significativamente maggiore rispetto a quando implemento questi test in soapUI.

A mio parere, lo svantaggio di soapUI è che non esiste un modo semplice per spiegare WHAT e WHY di un test (almeno non in modo intuitivo).

Quindi, supponendo che voglio uno sforzo di sviluppo ragionevole per il test end-to-end, ho optato per l'approccio di scrivere i test della GUI in FitNesse/Selenesse e test back-end in soapUI. Ora ho la scelta di provare a eseguire i test soapUI di FitNesse, gestirli tutti i test o eseguire i test FitNesse da soapUI ...

Ho alcune preoccupazioni riguardo la gestione dei test (non è facile vedere i risultati del test in una vista) e la sostenibilità (due strumenti con diversi laguaggi) di questo approccio. Hai qualche idea per la migliore/buona pratica in merito? Suggeriresti un terzo strumento per gestire gli altri due?

Answer 1

Dou usi qualche strumento di integrazione continuo come hudson, bamboo?

Sto facendo questa domanda perché ti suggerisco di preferire l'approccio all'integrazione continua in modo da avere la possibilità di testare automaticamente le applicazioni dopo ogni commit/build.

Voglio dire che se usi hudson o bambù puoi avere la possibilità di eseguire i tuoi test dopo che uno sviluppatore ha commesso qualcosa. Inoltre, è possibile eseguire il test in modo pianificato.

Un altro vantaggio è che questi strumenti (hudson/bamboo) possono registrare gli script di test e possono inviare una e-mail in caso di errore/successo (a scelta). In questo modo puoi monitorare facilmente i tuoi test.

E inoltre avete la possibilità di eseguire selenio e soapUI in parallelo o consecutivamente.

---

Ho anche alcuni suggerimenti sui test soapUI.

Più casi di test hai, più tempo hai bisogno di sviluppare, eseguire e gestire. Il punto importante è considerare la manutenibilità durante la progettazione dei test.

Se un'applicazione dispone di più servizi Web, i WSDL sono destinati a cambiare e devono essere aggiornati in SoapUI. Con tutto in un unico progetto soapUI è sufficiente aggiornare i WSDL in un unico posto, non in più progetti. Quindi crea un solo progetto soapUI per un'applicazione.

Quindi è necessario creare una suite di test e casi di test.

Includere tutti i flussi principali dei servizi (scenari di successo) in una sola suite di test di regressione. Le richieste dei servizi Web devono essere ordinate in base al flusso aziendale logico. Ad esempio, se si testano i servizi Web di un negozio online, è necessario innanzitutto cercare l'articolo e quindi acquistarlo. Se si mantiene questo ordine aziendale logico all'interno dei test soapUI, è possibile impostare facilmente una singola variabile globale per ogni passaggio di prova. Voglio dire, al primo passaggio puoi cercare l'oggetto X e poi acquistare lo stesso oggetto, in questo modo puoi impostare una variabile globale per l'elemento X. È più facile mantenere o estendere tale progetto soapUI. Hai la possibilità di creare un'origine dati e raccogliere variabili (diversi elementi nel nostro esempio di negozio online) e estendere il caso per quegli articoli in un ciclo.

Answer 2

Ti consiglio di creare una suite di test con soapui e di riportare i risultati dei test con jenkins.

È possibile eseguire test soapui e test di idoneità con il file dei risultati del test xen di jenkins e genrate. Questa configurazione è davvero utile quando si costruiscono test end2end. Siamo in grado di legare bene qualsiasi test set o suite di test con Jenkins e devi presentare un modo eccezionale di presentare e conservare i risultati dei test.

Quando ci si concentra su un componente di lavoro, fare le cose nello sprint o nell'app completa non è abbastanza stabile da investire enormi quantità di sforzi nel lavoro del test end2end già penso che dovresti concentrarti sul test di soapui separatamente.