Ce este testarea SOA? Tutorial cu Exemplu

Ce este testarea SOA?

SOA (Orientat pe servicii ArchiTestarea texturii este testarea stilului arhitectural SOA, în care componentele aplicației sunt proiectate să comunice prin protocoale de comunicație, de obicei printr-o rețea.

Ce este SOA?

SOA este o metodă de integrare a aplicațiilor și proceselor de afaceri împreună, astfel încât să răspundă nevoilor afacerii.

In Inginerie SoftwareSOA oferă agilitate și flexibilitate proceselor de business. O modificare a unui proces sau a unei aplicații poate fi direcționată către o anumită componentă fără a afecta întregul sistem.

Dezvoltatorii de software care lucrează în SOA fie dezvoltă, fie cumpără bucăți de programe numite Servicii.

Ce este Serviciul?

Diagrama de mai jos prezintă o poartă de plată publicată ca serviciu pe care o pot apela mai multe site-uri de comerț electronic.

• Un serviciu poate fi o unitate funcțională a unei aplicații sau a unui proces de business, care poate fi reutilizată sau repetată de orice altă aplicație sau proces. (De exemplu, în imaginea de mai sus, Payment Gateway este un serviciu care poate fi reutilizat de orice site de comerț electronic. Ori de câte ori trebuie efectuată o plată, site-ul de comerț electronic apelează sau solicită serviciul Payment Gateway. După ce plata este finalizată pe gateway, un răspuns este trimis înapoi către site-ul de comerț electronic.)
• Serviciile sunt ușor de asamblat și ușor de reconfigurat componente.
• Serviciile pot fi comparate cu niște blocuri de construcție. Acestea pot construi orice aplicație necesară, iar adăugarea sau eliminarea lor din aplicație sau din procesul de business este ușoară.
• Serviciile sunt definite mai mult de funcția de afaceri pe care o îndeplinesc decât ca bucăți de cod.

Servicii Web

Majoritatea serviciilor SOA sunt expuse ca servicii web, așa că mecanica unui apel de serviciu web merită prezentată înainte de nivelurile de testare.

servicii web sunt componente independente ale aplicației disponibile pe web.

Acestea pot fi publicate, găsite și utilizate pe web și comunică prin internet. Secvența de mai jos arată cum interacționează un furnizor, un registru și un consumator.

• Furnizorul de servicii publică serviciul pe internet.
• Clientul caută un anumit serviciu web în Registrul de servicii web.
• A URL si wsdl pentru serviciul web necesar sunt returnate. Folosind WSDL și URLComunicarea dintre furnizorul de servicii și solicitant se face prin mesaje SOAP.
• Când un consumator apelează un serviciu web, se stabilește o conexiune HTTP cu furnizorul.
• Un mesaj SOAP este creat pentru a instrui furnizorul să invoce logica serviciului web necesară.
• Răspunsul primit de la furnizor este un mesaj SOAP încorporat în răspunsul HTTP. Acest răspuns HTTP este formatul de date înțeles de aplicația consumatorului.

Exemplu

Captura de ecran de mai jos prezintă un raport meteo furnizat de un serviciu extern și încorporat în pagina principală a unui motor de căutare.

Pagina principală a unui site web și a unui motor de căutare afișează un raport meteo zilnic. În loc să se codeze secțiunea de buletine meteo de la zero, un serviciu de buletine meteo poate fi cumpărat de la un furnizor și integrat în pagini.

Straturile de testare SOA

SOA constă din diverse tehnologii, iar aplicațiile construite folosind SOA au diverse servicii care sunt slab legate între ele. Diagrama de mai jos prezintă cele trei straturi pe care trebuie să le acopere un plan de testare.

Testarea SOA ar trebui să se concentreze pe 3 niveluri de sistem.

Stratul de servicii

Acest strat constă din serviciile expuse de un sistem, derivate din funcțiile de business.

De exemplu, luați în considerare un site web de wellness care constă din:

• Greutate Tracker
• Zahăr din sânge Tracker
• Tensiune arterială Tracker

TracKerurile afișează datele respective și data la care au fost introduse. Stratul de servicii este format din serviciile care preiau datele respective din baza de date:

• Greutate Tracserviciu ker
• Zahăr din sânge Tracserviciu ker
• Tensiune arterială Tracserviciu ker
• Serviciu de autentificare

Stratul de proces

Stratul de procese este alcătuit din procese, colecția de servicii care fac parte dintr-o singură funcționalitate.

Procesele pot face parte dintr-o interfață cu utilizatorul (de exemplu, un motor de căutare) sau dintr-un instrument ETL care extrage date din baza de date.

Accentul principal în acest strat este pus pe interfețele utilizator și procese. Interfața utilizator a greutății tracker și integrarea sa cu baza de date este obiectivul principal.

Următoarele funcții sunt de luat în considerare:

• Adăugarea de date noi
• Editarea datelor existente
• Crearea unui nou tracker
• Ștergerea datelor

Stratul Consumatorului

Acest strat cuprinde în principal interfețe utilizator, așa cum ilustrează ecranul de mai jos.

Pe baza acestor straturi, testarea unei aplicații SOA este distribuită pe trei niveluri:

• Nivel de servicii
• Nivelul interfeței
• Nivel de la capăt la capăt

Cele două direcții de deplasare diferă: pentru proiectarea testelor se folosește o abordare de sus în jos, în timp ce pentru execuția testelor se folosește o abordare de jos în sus.

Strategie pentru testarea SOA

Abordarea planificării testelor

• Arhitectura completă a aplicației ar trebui să fie înțeleasă de către testerii SOA.
• Aplicația trebuie să fie împărțită în servicii independente (un serviciu care are propria structură de cereri și răspunsuri și nu depinde de niciun alt serviciu pentru a forma un răspuns).
• Structura aplicației trebuie reorganizată în trei componente - date, servicii și aplicații front-end.
• Toate componentele trebuie analizate cu atenție, iar scenariile de afaceri trebuie evidențiate.
• Scenariile de afaceri ar trebui clasificate în scenarii comune și scenarii specifice aplicației.
• A TracMatricea de eficiență ar trebui pregătite și toate cazurile de testare ar trebui să fie tracadaptat la scenarii de afaceri.

Abordarea executării testelor

• Fiecare componentă a serviciului trebuie testată.
• Testare de integrare a componentelor serviciului ar trebui făcut pentru a valida fluxul de date prin servicii și integritatea datelor.
• Testarea sistemului a modelului complet ar trebui efectuată pentru a valida fluxul de date dintre aplicația front-end și baza de date.
• Test de performanta ar trebui făcut pentru reglaj fin și performanță optimă.

Metode de testare SOA

1) Testare bazată pe date, bazată pe scenarii de afaceri

• Ar trebui analizate diverse aspecte comerciale legate de sistem.
• Scenariile ar trebui dezvoltate pe baza integrării diferitelor servicii web ale aplicației și a serviciilor web cu aplicația.
• Configurarea datelor trebuie făcută pe baza scenariilor de mai sus.
• Configurarea datelor ar trebui să acopere și scenarii complete.

2) cioturi

• Interfețele fictive sunt create pentru a testa serviciile.
• Prin aceste interfețe pot fi furnizate diverse intrări, iar ieșirile pot fi validate.
• Când o aplicație utilizează o interfață către un serviciu extern care nu este în curs de testare (un serviciu terț), se poate crea un stub în timpul testării integrării.

3) Testarea regresiei

• Testarea regresiei asupra aplicației ar trebui făcută atunci când există mai multe versiuni, pentru a asigura stabilitatea și disponibilitatea sistemelor.
• Va fi creată o suită cuprinzătoare de teste de regresie care acoperă serviciile care formează o parte importantă a aplicației.
• Această suită de teste poate fi reutilizată în mai multe versiuni ale proiectului.

4) Testarea nivelului de serviciu

Testarea nivelului de serviciu include testarea componentei pentru funcționalitate, securitate, performanță și interoperabilitate. Fiecare serviciu trebuie testat independent mai întâi.

5) Testare funcțională

Functional Testing ar trebui făcut pentru fiecare serviciu pentru a:

• Asigurați-vă că serviciul oferă răspunsul corect la fiecare solicitare.
• Asigurați-vă că sunt primite erorile corecte pentru solicitările cu date nevalide sau greșite.
• Verificați fiecare cerere și răspuns pentru fiecare operațiune pe care serviciul trebuie să o efectueze în timpul execuției.
• Validați mesajele de eroare atunci când apare o eroare la nivel de server, client sau rețea.
• Verificați dacă răspunsurile primite sunt în formatul corect.
• Validați dacă datele primite în răspuns corespund cu datele solicitate.

6) Testare de securitate

Testarea securității serviciului web este un aspect important în timpul testării nivelului de serviciu al aplicației SOA, deoarece asigură siguranța aplicației.

Următorii factori trebuie acoperiți în timpul testării:

• Standardul industrial definit de WS-Security trebuie respectat de serviciul web.
• Măsurile de securitate ar trebui să funcționeze impecabil.
• Criptarea datelor și semnăturile digitale de pe documente.
• Autentificare și autorizare.
• Injecțiile SQL, malware-ul, XSS, CSRF și alte vulnerabilități vor fi testate pe XML.
• Atacurile de refuz de serviciu.

7) Testarea performanței

Testarea performanței serviciului trebuie efectuată deoarece serviciile sunt reutilizabile și mai multe aplicații ar putea utiliza același serviciu.

Următorii factori sunt luați în considerare în timpul testării:

• Performanța și funcționalitatea serviciului trebuie testate sub sarcină grea.
• Performanța serviciului trebuie comparată atunci când funcționează individual și atunci când este cuplat în cadrul aplicației.
• Testare de sarcină serviciului ar trebui efectuată pentru a verifica timpul de răspuns, pentru a verifica dacă există blocaje, pentru a verifica utilizarea CPU și a memoriei și pentru a prezice scalabilitatea.

8) Testarea nivelului de integrare

• Testarea nivelului de serviciu asigură funcționarea corectă a serviciilor individual; nu garantează funcționarea componentelor cuplate.
• Testarea integrării se face concentrându-se în principal pe interfeţe.
• Această fază acoperă toate scenariile de afaceri posibile.
• Testarea nefuncțională a aplicației ar trebui efectuată încă o dată în această fază. Securitatea, conformitatea și testarea performanței asigură disponibilitatea și stabilitatea sistemului în toate aspectele.
• Protocoalele de comunicare și de rețea ar trebui testate pentru a valida consistența comunicării de date între servicii.

9) Testare de la capăt la capăt

Această fază asigură conformitatea aplicației cu cerințele de business, atât funcțional, cât și nefuncțional.

Se garantează că articolele de mai jos vor fi testate în timpul testarea end-to-end:

• Toate serviciile funcționează conform așteptărilor după integrare
• Manevrarea excepțiilor
• Interfața utilizator a aplicației
• Fluxul adecvat de date prin toate componentele
• Procesul de afaceri

Provocări în testarea SOA

Aplicarea acestor metode este rareori simplă, iar dificultățile de mai jos se repetă în aproape fiecare program SOA.

• Lipsa interfețelor pentru servicii.
• Procesul de testare se întinde pe mai multe sisteme, ceea ce creează nevoi complexe de date.
• Aplicația este o colecție de diverse componente care tind să se schimbe, așadar nevoia de testare a regresiei este mai frecventă.
• Din cauza arhitecturii multistrat, izolarea defectelor este dificilă.
• Deoarece un serviciu este utilizat de diferite interfețe, încărcarea este dificil de prezis, ceea ce face ca planificarea testelor de performanță să fie dificilă.
• SOA este o colecție de tehnologii eterogene. Testarea unei aplicații SOA necesită persoane cu seturi diferite de competențe, ceea ce, la rândul său, crește costurile de planificare și execuție.
• Întrucât aplicația integrează mai multe servicii, testarea securității are propriile probleme. Validarea autentificării și a autorizării este dificilă.

Instrumente de testare SOA

Există numeroase instrumente de testare SOA disponibile pe piață pentru a ajuta testerii să testeze aplicațiile SOA. Iată câteva dintre instrumentele de testare SOA populare.

1) SoapUI

SoapUI este un instrument open-source de testare funcțională pentru servicii și Testare API.

• Aplicație desktop
• Suportă mai multe protocoale — SOAP, REST, HTTP, JMS, AMF, JDBC
• Serviciile web pot fi dezvoltate, inspectate și invocate.
• Poate fi folosit și pentru testarea încărcării, Testarea automatizării, și teste de securitate
• Stub-urile pot fi create de MockServices
• Cererile și testele de servicii web pot fi generate automat prin intermediul clientului său de servicii web.
• Are instrumente de raportare încorporate
• Dezvoltat de SmartBear, care livrează atât open-source SoapUI distribuție și comercial ReadyAPI ediţie

2) Virtualizarea serviciilor Broadcom (fosta iTKO LISA)

LISA este o suită de produse care oferă o soluție de testare funcțională pentru sisteme distribuite, cum ar fi SOA. Produsul a fost transferat de la iTKO la CA Technologies și este vândut astăzi sub denumirea de Broadcom Service Virtualization.

• Poate fi folosit și pentru regresie, integrare, încărcare și testare a performanței.
• Poate fi folosit pentru a proiecta și executa teste.

3) UFT Unu (fostul HP Service Test)

Service Test este un instrument de testare funcțională care acceptă atât testarea interfeței utilizator, cât și testarea serviciilor partajate. Capacitatea sa de testare API a fost integrată în Unified Functional Testing, vândut acum de OpenText as UFT Unul.

• Atât testele funcționale, cât și cele de performanță ale serviciilor pot fi efectuate cu un singur script.
• Integrat cu Centrul de Calitate, acum vândut ca OpenText ALM / Centru de calitate.
• O cantitate masivă de servicii și date poate fi gestionată.
• Acceptă testarea interoperabilității prin simularea mediilor client JEE, AXIS și DotNet.

4) Parasoft SOAtest

Parasoft SOAtest este o suită de instrumente de testare și analiză dezvoltată pentru testarea API-urilor și a aplicațiilor bazate pe API.

• Suportă servicii web, tehnologii REST, JSON, MQ, JMS, TIBCO, HTTP și XML.
• Sunt posibile teste funcționale, unitare, de integrare, de regresie, de securitate, de interoperabilitate, de conformitate și de performanță.
• Stuburile pot fi create folosind Virtualizare Parasoft, care sunt mai capabile decât SoapUI Servicii simulate.

Cazuri de utilizare pentru testarea SOA

Exemplul de mai jos aplică strategia, metodele și instrumentele de mai sus unui singur site de comerț electronic, fază cu fază.

Luați în considerare un site web de comerț electronic care conține funcțiile și subfuncțiile de mai jos.

Procesarea comenzilor

Graficul de mai jos împarte procesarea comenzilor în subfuncții care devin servicii.

Faza 1

În prima fază a testării SOA, faza strategiei de testare, aplicația este împărțită în servicii și funcții de business.

Să luăm în considerare serviciile de mai jos în aplicație.

• Creați comandă
• Verificați starea clientului
• Modificați starea comenzii
• Verificați starea comenzii
• Verificați inventarul

Funcțiile de afaceri sunt aceleași cu funcțiile site-ului web.

Notă: Documentul strategiei de testare va conține lista serviciilor și funcțiilor care trebuie testate.

Faza 2

Aceasta este faza de planificare a testelor. Cazuri de testare sunt scrise pentru fiecare nivel.

Nivel de la capăt la capăt. Cazurile de testare sunt scrise pentru fiecare caz de utilizare și flux de business. Mai jos sunt exemple de cazuri de testare.

• Creați o comandă cu un utilizator activ.
• Creați o comandă cu un utilizator inactiv.
• Creați o comandă cu un produs disponibil cu cantitatea comandată < cantitatea disponibilă.
• Creați o comandă cu un produs disponibil cu cantitatea comandată > cantitatea disponibilă.
• Creați o comandă cu mai multe articole.
• Anulați o comandă complet.
• Anulați parțial o comandă.

Nivel de integrare. Cazurile de testare sunt scrise pentru integrarea bazei de date și a interfeței utilizator. Mai jos sunt exemple de cazuri de testare.

• Creați o nouă comandă cu un singur articol. Verificați dacă comanda este creată în baza de date.
• Creați o nouă comandă cu un singur articol. Verificați dacă prețul calculat pentru comandă este corect.
• Creați o comandă nouă cu un singur articol. Verificați dacă cantitatea produsului disponibil este redusă cu valoarea comenzii.
• Verificați dacă starea comenzii afișată în interfața cu utilizatorul este aceeași cu cea din baza de date.
• Anulați comanda și verificați dacă starea comenzii este modificată în baza de date.
• Pentru o primă plată, verificați dacă detaliile de plată introduse în interfața cu utilizatorul sunt salvate în baza de date.
• Pentru returnarea plăților, verificați dacă detaliile de plată din baza de date sunt afișate în UI.

Nivel de servicii. Fiecare serviciu este testat pentru toate condițiile de date. Mai jos sunt câteva exemple.

Nu.	Comanda Detalii	Starea comenzii
1	Creați comanda. Nr. articole = 1	Cantitate la comandă < Cantitate pe baza de date
2	Creați comanda. Număr de articole > 1	Cantitate din comandă < Cantitate din baza de date
3	Creați comanda. Nr. articole = 1	Cantitate pe comandă > Cantitate pe baza de date
4	Verificați starea comenzii	Stare pe baza de date = Activ
5	Verificați starea comenzii	Stare pe baza de date = Expediat
6	Verificați starea comenzii	Stare pe baza de date = Anulat
7	Verificați starea comenzii	ID comandă = Invalid
8	Verificați disponibilitatea produsului	Cantitatea de produs >0
9	Verificați disponibilitatea produsului	Cantitatea de produs =0
10	Verificați disponibilitatea produsului	ID produs = invalid

FAZA 3 — Executarea testului

Executarea testelor utilizează o abordare de jos în sus: mai întâi se face testarea la nivel de serviciu, apoi la nivel de integrare și, în final, testarea end-to-end.

1) Nivel de serviciu

Să considerăm că SoapUI Instrumentul este utilizat pentru testarea aplicației. WSDL și URL sunt accesate în fereastra de testare a SoapUI, iar cererea pentru fiecare serviciu este afișată în fereastra de cerere. Prin modificarea datelor conform cazurilor de testare la nivel de serviciu, se creează cereri pentru fiecare caz de testare.

Caz de testare	Cerere	Răspuns așteptat
Creare comandă. Nr. articole = 1, Cantitate din comandă < Cantitate din baza de date	x2 2	o3251 De succes
Creare comandă. Nr. articole > 1, Cantitate din comandă < Cantitate din baza de date	y1 1 y2 3	o3251 De succes
Creare comandă. Nr. articole = 1, Cantitate din comandă > Cantitate din baza de date	x23 200	nul Fără succes
Verificați starea comenzii. Stare în baza de date = Activă	o9876	Activ De succes
Verificați starea comenzii. Stare în baza de date = Expediată	o9656	Expediat De succes
Verificați starea comenzii. ID comandă = Invalid	y5686	nul Nereușit
Verificați disponibilitatea produsului. Cantitate produs >0	d34	34 da De succes
Verificați disponibilitatea produsului. Cantitatea produsului = 0	y34	0 Nu De succes
Verificați disponibilitatea produsului. ID produs = invalid	sder	Fără succes

2) Nivelul de integrare

Cazurile de testare la nivel de integrare sunt executate pe interfața utilizator și baza de date. Creați o comandă cu un singur articol:

• Un utilizator deschide site-ul web.
• Utilizatorul merge să plaseze o comandă.
• Utilizatorul selectează un produs și o cantitate valide și salvează comanda.
• Ar trebui să fie afișat un mesaj care să spună că comanda a fost plasată cu succes.
• Utilizatorul deschide baza de date și verifică dacă detaliile comenzii sunt aceleași cu cele introduse pe site.

3) Nivel de la capăt la final

Fluxurile de business și cazurile de utilizare sunt executate pe interfața cu utilizatorul. Creați o comandă cu mai multe articole:

• Un utilizator deschide site-ul web.
• Utilizatorul merge să plaseze o comandă.
• Utilizatorul întreabă despre un produs și o cantitate valide și le adaugă în coș.
• Alte produse valide sunt adăugate cu cantități valide, iar comanda este salvată. Plata se efectuează printr-o nouă metodă de plată, iar comanda este plasată.
• Ar trebui să fie afișat un mesaj care spune „Comandă plasată cu succes”.
• Un tester ar trebui să valideze dacă întregul flux se finalizează fără distorsionarea datelor.

Întrebări frecvente