ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 44
Abonament PDF

Testarea serviciilor web folosind SOAP UI

Ioana Luțaș
QA Engineer @ Bissoft



TESTARE


Î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.

Scurtă prezentare a SOAP UI

Î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:

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.

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

Abordarea cascadă pentru testarea funcţională a serviciilor web

Î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.

Testarea folosind conexiunea la DB

Î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

Integrarea testelor SOAP UI într-un sistem de build automat

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

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO