În acest articol voi prezenta pe scurt cum se poate acoperi testarea funcţională a serviciilor web folosind aplicaţia SOAP UI şi Groovy Script. Testarea serviciilor web este realizată folosind ori modelul cascadă, în care outputul unui pas de test este inputul pasului următor, ori modelul ce presupune o conexiune la DB şi prelucrarea datelor stocate în fişier Excel.
Testele realizate sunt incluse într-un sistem de build automat folosind Maven. În urmă execuţiei testelor se trimite pe email raportul de execuţie ce conţine statusul pentru fiecare metodă din serviciile testate.
Într-o aplicaţie orientată pe servicii, serviciile web sunt slab cuplate, astfel încât, odată ce un serviciu este implementat, acesta poate fi testat independent de celelalte. Dacă o aplicaţie este expusă atât pe web cât pe mobile, testarea serviciilor se realizează o singură dată, validarea UI fiind realizată ulterior pentru web, respectiv mobile.
Serviciile web comunică între ele dar şi cu alte aplicaţii prin transmiterea de mesaje. Simple Object Access Protocol (SOAP) este un standard frecvent utilizat pentru transmiterea mesajelor. Un mesaj SOAP este un document XML ce prezintă structura de mai jos:
SOAP envelope este elementul care conţine toate nodurile dintr-un mesaj. Identifică şi versiunea de SOAP – SOAP 1.1 sau SOAP 1.2
SOAP header este un element opţional care conţine meta-informaţie (instrucţiuni de procesare a mesajului, date de securitate, informaţii de adresă).
Web Service Description Language (WSDL) este un format XML care descrie serviciile web ca un set de puncte de access care procesează mesaje, structura acestuia fiind împărţită in Types, Message, Port Type si Binding.
SOAP UI este o aplicaţie free şi open source, parte din suita de aplicaţii dezvolate de SmartBear Software, ce poate fi folosită pentru testarea serviciilor web. Există şi versiune contra cost a aplicaţiei, care oferă intefaţă bazată pe formulare cât şi opţiuni suplimentare de testare.
SOAP UI poate fi folosit pentru:
Pe baza contractului se generează request-uri default cu date prepopulate. Când se adaugă un WSDL, SOAP UI scanează toate SOAP bindings care apar în WSDL şi găseşte metodele expuse de către serviciu. Generează apoi request-urile aferente acestor metode, corespunzător schemei XML a serviciului.
Testare funcţională, de integrare, de performanţă, de securitate folosind acelaşi mediu de testare.
Simularea serviciilor.
Integrarea de scripting folosind Groovy Script sau JavaScript.
Refactorizare WSDL – modificare automată a testelor existente pentru a fi la zi cu noua versiune a contractului.
Se integrează cu alte aplicaţii, inclusiv cu cele de integrare continuă. Există plugin-uri pentru Maven, Intellij IDEA, Eclipse, JBoss, NetBeans.
Se pot genera rapoarte de execuţie, cu diferite metrici. Selectând opțiunea de Test Coverage, SOAP UI permite analiza gradului de acoperire a elementelor contractului, prin testele funcţionale create.
Fiind dezvoltat în Java, rulează pe diferite tipuri de sisteme de operare.
Când se creează un proiect SOAP UI, acestuia I se ataşează unul sau mai multe contracte. Când se încarcă contractul, se vor încărca toate metodele expuse de pe acel serviciu şi se pot crea request-uri default pentru fiecare metodă în parte.
Imaginea 1 – Încărcarea contractului
În cadrul firmei folosim intens SOAP UI, versiunea Ready! API – SOAP UI NG, pentru testarea funcţională a servicilor web.
Testele sunt organizate în Proiecte. Un proiect poate avea mai multe suite de teste (Test suites). O suită poate avea mai multe Test cases. Fiecare Test case conţine Test steps. Prin test steps organizăm logica de validare a unei anumite funcţionalităţi dintr-un serviciu web.
Imaginea 2 – Exemplu de request, response şi assert pe response
Pentru a ne asigura că datele de test sunt unice la fiecare execuţie a testelor, una din abordările folosite este testarea in cascadă. Dacă se doreşte validarea metodei Update de exemplu, mai întâi apelăm metoda Create. Rezultatul generat de metoda Create devine intrare pentru metoda Update. Ultima operaţie va fi cea de ştergere a datelor inserate în baza de date. Răspunsul returnat de către metoda Update este validat, prin crearea de multiple assert-uri pe elementele din răspuns. Se efectuează multiple validări – conţinutul elementului este cel aşteptat, data întoarsă este de un anumit tip ( exemplu datetime), dacă un anumit element este obligatoriu, dacă se întoarce un anumit cod se eroare şi mesajul aferent codului de eroare, dacă se respectă lungimea maximă pentru un anumit câmp, dacă se permit caractere speciale.
Pentru a pune în practică abordarea cascadă, folosind Groovy Script, am creat o serie de metode ajutătoare care sunt apelate în cadrul test case-urilor. Aceste metode ajutătoare generează test case-uri tipizate pentru toate metodele unui serviciu, generează date de un anumit tip, copiază datele din răspuns într-un pas de tipul Properties (câmp - valoare), copiază date dintr-un pas în altul, creează validări mai complexe, etc. .
Imaginea 3 – Abordarea Cascadă
SOAP UI execută Test case-urile secvenţial. Organizând testele în ordinea dorită, ne asigurăm că la fiecare execuţie datele de test sunt unice şi nealterate. Dacă primul test, cel de creare element, eşuează, , toate testele ulterioare vor eşua.
Pentru a avea un grad mare de acoperire a elementelor din contract, se trimite request-ul cu toate elementele având date valide şi se crează assert-uri pe fiecare element din răspuns. În funcţie de validarea dorită, se selectează unul din assert-urile standard sau folosind Groovy Script se pot crea assert-uri mai complexe. Pentru validarea conţinutului datelor din răspuns, comparăm datele generate şi stocate într-un pas de tipul Properties cu cele întoarse în răspuns.
După fiecare execuţie se pot genera rapoarte de execuţie, conţinând toatele metodele executate, câte teste au trecut, câte au eşuat, care este cauza pentru care au eşuat, care este rata de acoperire a elementelor din contract.
În funcţie de specificul proiectului, poate fi necesară inserarea sau ştergerea direct din baza de date. În acest sens, folosim Setup script şi Tear down script existente în fiecare Test case. Datele de intrare şi cele de validare a răspunsului sunt organizate într-un fişier Excel. Funcţiile Groovy necesare pentru stabilirea conexiunii la DB, pentru manipulare date, pentru ştergere conexiune, sunt grupate într-un fiser groovy script. Pentru a putea accesa baza de date din cadrul SOAP UI este nevoie de driver-ul ojdbc6 .jar. Driver-ul trebuie copiat în locaţia directorInstalareSOAPUI \jre\lib\ext. Pentru ca execuţia testelor să fie foarte rapidă, fiecare metodă care se testează are propriul fişier cu date de test. Pentru un serviciu vom avea atâtea fişiere Excel câte metode sunt pe serviciu.
Imaginea 4 – Testare folosind conexiunea la DB
În partea de setup se iniţializează conexiunea la DB şi se setează conexiunea pe context pentru a putea fi folosită ulterior în cadrul aceluiaşi Test case. Se citesc datele din fişierul Excel şi se inserează în DB.
Se execută paşii următori din test case– încărcarea datelor necesare validării răspunsului, efectuarea de request-uri, validarea răspunsului.
În partea de Tear down script, ultimul pas executat din Test case, se utilizează conexiunea existentă la DB dacă e disponibilă, dacă nu este disponibilă se creează o conexiune nouă. Se citesc din fişierul Excel datele ce trebuie şterse din DB şi se efectuează ştergerea din baza de date. Se şterge conexiunea creată pentru accesul la baza de date.
Imagine 5 – Setup script
Testele SOAP UI sunt salvate în format XML. Aceste teste le- am integrat într-un sistem de build automat, utilizând Jenkins. Există un job configurat să execute testele automat, ori de câte ori se face build pentru codul comis. Testele sunt executate pe o maşină configurată pentru testare. Pentru integrarea în Jenkins am utilizat Maven.
Imaginea 6 – Jenkins job -comnada Maven pentru execuţia testelor
În urmă execuţiei testelor se trimite un email care conţine raportul execuţiei testelor. În acest fel avem un feedback rapid şi constant privitor la codul implementat.
Un exemplu de raport primit pe email este prezentat în figura de mai jos. Emailul conţine statusul per fiecare serviciu/per fiecare metodă din serviciu, cât şi link-uri către raport general şi de coverage pentru fiecare serviciu în parte.
Imaginea 7 – Raport de execuţie primit pe Email
Imagine 8 - Exemplu raport de acoperire
de Ovidiu Mățan
de Cristina Juc
de Ovidiu Mățan
