13
Usare Groovy con SOAPUI per l’automazione dei test R. Turco Nell’articolo “Realizzare un Framework di Test con SOAPUI” abbiamo mostrato le potenzialità di SOAPUI. In realtà esso permette di lavorare non solo per Web Services SOAP (su http/https o su jms) ma anche quelli REST, la cui descrizione è attraverso le WADL. SOAPUI ci permette vari scenari: a) Simulare un servizio (Mock Service) disponendo della sola WSDL del servizio esterno al nostro sistema e quindi ottenere risposte da esso a richieste del nostro sistema b) Testare un nostro Web Service Groovy ci permetterà, invece, di rendere dinamici i valori marcati con ? da passare nelle request o nelle response. Esamineremo il caso b), in questo breve tutorial. Se possibile usiamo l’ultima versione disponibile di SOAPUI. Il Proxy In tale caso sul vostro PC preparate la suite di Test e in remoto c’è il Web Service. In tal caso vi serve eventualmente, in una azienda, settare il proxy (per andare in remoto) settando da File -> Preferences -> Proxy Settings -> Manual (inserire tutte le info). Se, invece, il Web Service ce l’avete in locale al PC per testarlo Proxy Settings -> None. Il Progetto Create un nuovo progetto con New SOAP Project -> Automation-PrepaidMobileNumberInformation. In Initial WSDL si deve mettere la url del servizio implementato che dobbiamo testare. Ad esempio dovreste mettere la URI del servizio in: Initial WSDL-> http://<ip>:8105/IB/services/PrepaidMobileNumberInformationQuery-v1?wsdl" (Se invece usate un Mock Service <ip>=localhost e la porta deve essere libera altrimenti la cambiate nella WSDL e su SOAPUI come vedremo. La URI la trovate nella WSDL del vostro servizio nella parte binding). Tuttavia è possibile che del tutorial vi interessi solo come sfruttare Groovy con SOAPUI e non di sviluppare il servizio, allora vi consiglio di utilizzare il WSDL in APPENDICE e di testarlo prima con un tool per verificarne la validità e che sia well-formed. Attenzione che nel binding, per creare un Mock Service che funzioni da PC, vi conviene mettere nel WSDL il binding a localhost. Per cui adesso ci generiamo il Mock Service dalla WSDL e non implementiamo il servizio. Selezioniamo la WSDL e facciamo check su “Create Request” e “Create Test Suite” e premere OK.

Usare Groovy Con SOAPUI

Embed Size (px)

DESCRIPTION

Un semplice HowTo per automatizzare i test con Groovy e SOAPUI

Citation preview

  • Usare Groovy con SOAPUI per lautomazione dei test R. Turco

    Nellarticolo Realizzare un Framework di Test con SOAPUI abbiamo mostrato le potenzialit di SOAPUI. In

    realt esso permette di lavorare non solo per Web Services SOAP (su http/https o su jms) ma anche quelli

    REST, la cui descrizione attraverso le WADL.

    SOAPUI ci permette vari scenari:

    a) Simulare un servizio (Mock Service) disponendo della sola WSDL del servizio esterno al nostro

    sistema e quindi ottenere risposte da esso a richieste del nostro sistema

    b) Testare un nostro Web Service

    Groovy ci permetter, invece, di rendere dinamici i valori marcati con ? da passare nelle request o nelle

    response.

    Esamineremo il caso b), in questo breve tutorial. Se possibile usiamo lultima versione disponibile di

    SOAPUI.

    Il Proxy

    In tale caso sul vostro PC preparate la suite di Test e in remoto c il Web Service. In tal caso vi serve

    eventualmente, in una azienda, settare il proxy (per andare in remoto) settando da File -> Preferences ->

    Proxy Settings -> Manual (inserire tutte le info). Se, invece, il Web Service ce lavete in locale al PC per

    testarlo Proxy Settings -> None.

    Il Progetto

    Create un nuovo progetto con New SOAP Project -> Automation-PrepaidMobileNumberInformation.

    In Initial WSDL si deve mettere la url del servizio implementato che dobbiamo testare.

    Ad esempio dovreste mettere la URI del servizio in:

    Initial WSDL-> http://:8105/IB/services/PrepaidMobileNumberInformationQuery-v1?wsdl"

    (Se invece usate un Mock Service =localhost e la porta deve essere libera altrimenti la cambiate nella

    WSDL e su SOAPUI come vedremo. La URI la trovate nella WSDL del vostro servizio nella parte binding).

    Tuttavia possibile che del tutorial vi interessi solo come sfruttare Groovy con SOAPUI e non di sviluppare il

    servizio, allora vi consiglio di utilizzare il WSDL in APPENDICE e di testarlo prima con un tool per verificarne

    la validit e che sia well-formed.

    Attenzione che nel binding, per creare un Mock Service che funzioni da PC, vi conviene mettere nel WSDL il

    binding a localhost.

    Per cui adesso ci generiamo il Mock Service dalla WSDL e non implementiamo il servizio. Selezioniamo la

    WSDL e facciamo check su Create Request e Create Test Suite e premere OK.

  • Ora sulla finestra Generate Test Suite selezionare Single TestCase with one Request for each Operation.

    Lasciamo il nome della Test Suite che ci propone. Inoltre non volendo sviluppare il servizio dobbiamo

    almeno avere il MockService. Generiamo il Mock Service come segue.

    Mettendo il mouse su PrepaidMobileNumberInformationQueryBinding con tasto destro del mouse

    facciamo Generate SOAP Mock Service poi in path (importante)mettiamo

    /IB/services/PrepaidMobileNumberInformationQuery-v1

    Mentre su port mettiamo 8086; questi valori li avremo selezionato dalla WSDL da soap:address location.

    Lasciamo anche il nome proposto da SOAPUI per il Mock Service. Dovremmo avere adesso una situazione

    come in figura successiva.

  • Ora, come detto in premessa, come se avessimo a disposizione il Servizio implementato che vogliamo

    testare (il Mock Service).

    Sono almeno due gli scenari che possiamo fare.

    Servizio sviluppato da testare Invio ad esso di varie Richieste ed il Servizio ci d risposte

    Lobiettivo in questo caso testare un servizio realizzato e deployato, per cui di interesse magari fare vari

    tipi di request e aspettarci le risposte del nostro servizio posto sotto test.

    In generale, come nel caso della nostra WSDL in APPENDICE, potremmo avere sia lHEADER che il BODY che

    potremmo voler valorizzare dinamicamente. In tal caso possiamo mettere su vari file la parte tra

    Lidea di avere questi pezzi di requests scritte in diversi file con nome del tipo TestX.xml dove X un

    numerico (1,2,). In ognuno di esso c siolo la parte di body della request.

    Sistema sviluppato che fa richieste ad un Web Service Varie Risposte dal Mock Service

    Questo il caso dove abbiamo il sistema sviluppato che fa richieste ad un Web Service esterno non

    sviluppato da noi, di cui disponiamo solo la WSDL e lo simuleremo con un Mock Service e siamo interessati

    a ricevere dal Mock Service varie risposte con valori diversi ovvero response diverse. Possiamo anche in

    questo caso usare dei file per le response.

    Directory dei file request e response

    Creiamo una directory GroovyTest con le due sottodirectory Requests e Responces. Qui metteremo I file

    xml, con le sole parti del Body e le valorizzeremo con i valori che ci servono nel test al posto dei ?. Per

    esempio mettete due file e con valori di body diversi.

    Mock Service e primo scenario

    Attiviamo il Mock Service per fare il primo scenario. Su PrepaidMobileNumberInformationQueryBinding

    Mock Service -> doppio click e poi sulla freccia verde startare il Mock Service

  • Test Suite

    Posizioniamoci su Test Steps(1) e con tasto destro fare Add Step -> Groovy Script. Denominarlo Groovy

    Script Step 1.

    Prepariamoci una request sfruttando la Request1 generata da SOAPUI (copiandola solo, in realt non serve

    ma serviranno quelle delle operation) e selezioniamo solo il Body (le parti in rosso):

    ?

    ?

    ?

    ?

    ?

    ?

  • ?

    A questo punto dipende dai test che dobbiamo fare. Ci sono test dove magari i campi opzionali non

    interessano valorizzati e occorre valorizzare solo gli obbligatori. Altri in cui conviene valorizzare ogni cosa.

    Supponiamo di dover iniziare a fare i test solo dei campi obbligatori. Al posto del ? per le parti obbligatorie,

    number in questo caso, mettiamo ad esempio 1001 e salviamo questo file nella directory requests col nome

    Test1.xml, poi ne facciamo un altro col valore 2002 e lo salviamo col nome Test2.xml e cos via.

    Ora passiamo al Groovy Script. Incolliamo questo codice nella finestra che si apre cliccando su Groovy

    Script:

    def fileList = []

    new File("C: \\GroovyTest\\requests").eachFile {f ->

    if (f.isFile()&& f.name.endsWith('.xml'))

    {

    def fileName = f.name[0..-1]

    fileList.add(fileName)

    log.info fileName

    }

    }

    if (fileList.size()

    if (f.isFile()&& f.name.endsWith('.xml'))

    {

    def fileName = f.name[0..-1]

    fileList.add(fileName)

    // log.info fileName

    }

    }

    if (fileList.size()

  • ${=new File("C:\\GroovyTest\\requests\\" + (context.get('fileList')).last()).text}

    Nel getResponse e getResponse 2 possiamo mettere delle Assert per vedere se ci sono errori o cercare dei valori particolari.

    Sotto getResponse ad esempio facciamo Assertions e + e scegliamo ad esempio Compliance, Status e Standards e settiamo No

    SOAP Fault (vogliamo vedere che non ci sono errori). Qua si possono mettere anche altre Assertion in cascata.

    Nel Mock Service mettiamo due response Response 1 e Response 2 con il return code a 1 e 2, ad esempio. giusto affinch il servizio

    risponda un valore. Ovviamente dipender dai vostri test con che valore il Web Service reale deve rispondere.

    Lancio della Test Suite delle Request

    Sulla Test Suite con doppio click si apre la finestra a destra. Con click su freccia verde si ottiene il lancio di

    tutte le request (due nel nostro caso) e la barra che si colora di verde mi indica che i test sono andati OK. Se

    ci fosse stato un rosso avremmo potuto esaminare quale richiesta fosse andata in errore.

    Intanto vedendo Step 3 e Step 2 si possono vedere due cose:

  • Le request partite la prima con 1001 e la seconda con 2002

    Le response col return code a 1 e a 2 come risposta ad ogni request.

    Una suite di Test fortemente incoraggiata se il numero di test elevato si guadagna molto tempo in

    regressione per una anomalia etc. Il compilare dei file con editor xml estremamente facile e rapido,

    predisporre SOAPUI anche di pi.

    Altre possibilit sono letture dal DB di valori di interesse, introdotte come Step ordinati, etc.

    Secondo scenario

    Questa volta il Mock Service pu aiutarmi a simulare varie risposte quando il nostro servizio che chiama il

    Mock Service.

    Possiamo fare la stessa cosa di prima ma rendendo dinamiche le response questa volta mettendo i file nella

    sottodirectory responces.

    Lo lasciamo come esercizio al lettore.

    Asserts

    Come nellaltro articolo vi consiglio di usare le assert per verificare varie cose. Infine vi consiglio un

    approfondimento del linguaggio Groovy.

    Load Test

    SOAPUI anche forte per organizzare un Load Test ovvero un test di carico. Vedi documentazione

    http://www.soapui.org/Getting-Started/load-testing.html

    http://www.soapui.org/load-testing/creating-and-running-loadtests.html

    Database

    Per il database, invece, consultare la documentazione al link:

    http://www.soapui.org/jdbc/testing-jdbc-databases.html

    Groovy, SOAPUI e database.

    E possibile interagire col database da SOAPUI anche usando Groovy con lintenzione di automatizzare gli

    step.

    Si deve conoscere il tipo di database a cui connettersi e la sintassi dei comandi richiesta. Nellesempio

    successivo ipotizzo il DB Oracle e una select qualunque.

    Nel Groovy Script ci devono essere linee di codice del tipo:

    import groovy.sql.Sql;

    def con = Sql.newInstance("jdbc:oracle:thin:@::", "", "",

    "oracle.jdbc.driver.OracleDriver");

    def res = con.rows("SELECT sysdate FROM dual")

    log.info(res[0].sysdate.toString())

  • con.close()

    Lesempio di sopra preleva la data di sistema dalla tabella DUAL e lo stampa a log. In res cera il risultato

    della query.

    Altre istruzioni sql utili con SOAPUI

    firstRow( sqlQuery ) : Questo metodo ritorna la prima riga della tabella della query passata in input.

    Esempio

    def res = sql.firstRow(SELECT * FROM TEST_TABLE WHERE USERID=12345)

    Il risultato si pu accedere con res[0] o res.

    eachRow( sqlQuery, {closure} ) : Questo metodo usato per mantenere o modificare lintero whole

    ResultSet basandoci su qualche condizione. Il secondo argomento un set di istruzioni che possono essere

    eseguite per ogni risultato. Esempio:

    sql.eachRow( SELECT * FROM TEST_TABLE WHERE USERID=12345,

    {

    println( it.COLUMN_1 );

    println( it[2] );

    } )

    Le println di sopra sono, difatti, eseguite per ogni riga del ResultSet. Le Closure possono avere un qualsiasi

    numero di statement. Sopra sono 2.

    execute( sqlQuery ) : E usato per operazioni CRUD come INSERT/UPDATE/DELETE e non ritorna ResultSet.

    Esempio

    sql.execute( DELETE FROM TEST_TABLE WHERE USERID=12345 & USERNAME=SOMENAME )

    sql.execute( DELETE FROM TEST_TABLE WHERE USERID = ? & USERNAME = ? ,

    [ 12345, SOMENAME ] )

    Il secondo metodo simile alla tecnica di sql dinamico.

    SOAPUI e altre sorgenti dati

    SOAPUI pu anche leggere dati da un file CSV o da un excel.

    Vedi http://www.soapui.org/data-driven-tests/functional-tests.html

    Integrazione con OAUTH2

    Vedi http://www.soapui.org/oauth2/oauth2-overview.html

    Monitoraggio

    Vedi http://www.soapui.org/api-monitoring.html. Ma in questo caso occorre la versione PRO.

  • Conclusioni

    SOAPUI adatto a Test funzionali e di carico, si integra facilmente con Web Service di tipo SOAP e REST

    (compreso JMS), sia http/https, si integra con ogni tipo di database in termini jdbc, con altre fonti dati come

    excel e csv. Permette lautomazione degli step con Groovy, lintegrazione con un server di autenticazione

    come OAUTH2 e il Monitoraggio. Un vero Supereroe!!

    Alla prossima.

    APPENDICE

    WSDL_PrepaidMobileNumberInformationQuery_Concrete-v1

  • SOAPHeader_v1.1.xsd

    Informazioni di contesto dell'invocazione del servizio

    Sistema da cui proviene la richiesta

    Data e Ora di invocazione del servizio

    Identifica univocamente il processo

    dibusiness

    Identifica il messaggio in maniera univoca

    Identifica la transazione per gestire i ritornisincroni

  • Per compatibilit con i diversi prodotti o librerie software

    (es.Axis2 e BW) si scelto di utilizzare il tipo string. La restizione applicata accetta il formato: CCYY-MM-DD. Non sono presenti

    restrizionisul range dei valori.

    Per compatibilit con i diversi prodotti o librerie software

    (es.Axis2 e BW) si scelto di utilizzare il tipo string. La restizione applicata accetta il formato: hh:mm:ss.sss. Non sono presenti

    restrizioni sul range dei valori. Per gli ulteriori dettagli sul formato fare riferimento alla definizione di Time Data Type W3C,

    presente al link:http://www.w3schools.com/Schema/schema_dtypes_date.asp

    PrepaidMobileNumberInformationQuery.xsd

  • PrepaidMobileNumberInformationQueryEntities.xsd

  • TelephoneNumber

    Decimal

    DateTime