Ce este testarea SOA? Tutorial cu Exemplu

Ce este testarea SOA?

SOA (Orientat pe servicii Architectura) Testarea este o testare a 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.

În Inginerie Software, SOA oferă agilitate și flexibilitate proceselor de afaceri. Modificările aduse procesului sau aplicației pot fi direcționate către o anumită componentă fără a afecta întregul sistem.

Dezvoltatorii de software din SOA fie dezvoltă, fie cumpără bucăți de programe numite SERVICII.

Ce este Serviciul?

• Serviciile pot fi o unitate funcțională a aplicației sau a procesului de afaceri, 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 să facă o plată, site-ul de comerț electronic apelează/Solicită serviciul Gateway de plată. După ce plata este efectuată pe un gateway, un răspuns este trimis către site-ul de comerț electronic)
• Serviciile sunt ușor de asamblat și ușor de reconfigurat componente.
• Serviciile pot fi comparate cu blocuri de construcție. Ei pot construi orice aplicație necesară. Adăugarea și eliminarea acestora din aplicație sau din procesul de afaceri este ușor.
• Serviciile sunt definite mai degrabă de funcția de afaceri pe care o îndeplinesc, decât ca bucăți de cod.

Servicii Web

Serviciile web sunt componente independente ale aplicației, care sunt disponibile pe web.

Ele pot fi publicate, găsite și pot fi folosite pe web. Ei pot comunica prin internet.

1. Furnizorul de servicii publică serviciul pe internet.
2. Clientul caută un anumit serviciu web din Registrul de servicii web
3. Se returnează o adresă URL și WSDL pentru serviciul web necesar. Folosind WSDL și URL-ul, comunicarea dintre furnizorul de servicii și solicitant are loc prin mesaje SOAP.
4. Când un consumator apelează un serviciu web, se va stabili o conexiune HTTP cu furnizorul.
   Un mesaj SOAP este creat pentru a instrui furnizorul să invoce logica serviciului web necesară.
5. Răspunsul primit de la furnizor este un mesaj SOAP care va fi încorporat în răspunsul HTTP. Acest răspuns HTTP este formatul de date care este de înțeles de către aplicația de consum.

Exemplu

O pagină de pornire a unui site web și a unui motor de căutare afișează un raport meteo zilnic. În loc să codificați secțiunea de buletin meteo peste tot, un serviciu de buletin meteo poate fi cumpărat de la un furnizor și integrat în pagini.

Testarea SOA

SOA constă din diverse tehnologii. Aplicațiile construite folosind SOA au diverse servicii care sunt slab cuplate.

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

Stratul de servicii

Acest nivel este format din serviciile, serviciile expuse de un sistem derivat din funcțiile de business.

De exemplu -

Luați în considerare un site web de wellness care constă din

1. Tracker de greutate
2. Tracker de zahăr din sânge
3. Următorul tensiunii arteriale

Trackerele afișează datele respective și data la care au fost introduse. Stratul de servicii este format din serviciile care primesc datele respective din baza de date –

• Serviciu de urmărire a greutății
• Serviciu de urmărire a zahărului din sânge
• Serviciu de monitorizare a tensiunii arteriale
• Serviciu de autentificare

Stratul de proces

Stratul de proces constă din procesele, colecția de servicii care fac parte dintr-o singură funcționalitate.

Procesele pot fi o parte a interfeței utilizator (de exemplu – Un motor de căutare), o parte a unui instrument ETL (pentru obținerea datelor din baza de date).

Accentul principal în acest strat va fi în interfețele utilizator și proces.

Interfața cu utilizatorul a instrumentului de urmărire a greutății și integrarea acesteia cu baza de date este principalul obiectiv.

Funcțiile de mai jos vor fi luate în considerare

1. Adăugarea de date noi
2. Editarea datelor existente
3. Se creează un nou tracker
4. Ștergerea datelor

Stratul Consumatorului

Acest strat cuprinde în principal interfețe cu utilizatorul.

Pe baza stratului, testarea unei aplicații SOA este distribuită pe trei niveluri.

1. Nivel de servicii
2. Nivelul interfeței
3. Nivel de la capăt la capăt

• Abordarea de sus în jos este utilizată pentru proiectarea testelor.
• Abordarea de jos în sus este utilizată pentru execuția testului.

Strategie pentru testarea SOA

Abordarea de planificare a testelor,

• Arhitectura completă a aplicației ar trebui să fie înțeleasă de către testerii SOA.
• Aplicația trebuie împărțită în servicii independente (Serviciul, care are propria sa structură de solicitare și răspuns și nu depinde de niciun alt serviciu pentru a forma 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 ar trebui elaborate.
• Scenariile de afaceri ar trebui clasificate ca scenarii comune și scenarii specifice aplicației.
• A Matricea de trasabilitate ar trebui să fie pregătite și toate cazurile de testare ar trebui urmărite până 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 făcut 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 bazate pe scenarii de afaceri,

• Ar trebui analizate diverse aspecte de afaceri legate de sistem.
• Scenariile ar trebui dezvoltate pe baza integrării
• Variat servicii web a cererii
• Servicii web și aplicație.
• Configurarea datelor ar trebui să se facă pe baza scenariilor de mai sus.
• Configurarea datelor ar trebui făcută astfel încât să acopere și scenariile cap la cap.

2) cioturi

• Vor fi create interfețe simulate 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 folosește o interfață cu un serviciu extern, care nu este testat (serviciu terță parte), se poate crea un stub în timpul testării integrării.

3) Testarea regresiei

• Testarea regresiei pe aplicație ar trebui făcută atunci când există mai multe versiuni astfel încât să se asigure 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 la nivel de serviciu include testarea componentei pentru funcționalitate, securitate, performanță și interoperabilitate.

Fiecare serviciu trebuie mai întâi testat independent.

5) Testare funcțională

Testarea funcțională ar trebui făcută pentru fiecare serviciu către

• Asigurați-vă că serviciul oferă răspunsul corect la fiecare solicitare.
• Se primesc erori corecte pentru cereri cu date invalide, date proaste etc.
• Verificați fiecare cerere și răspuns pentru fiecare operațiune pe care serviciul trebuie să o efectueze în timpul de execuție.
• 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 că datele primite pe răspuns corespund datelor solicitate.

6) Testare de securitate

Testarea de securitate a serviciului web este un aspect important în timpul testării la nivel de serviciu a aplicației SOA; aceasta asigură siguranța aplicației.

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

• Standardul industrial definit de testarea WS-Security ar trebui să fie respectat de Serviciul Web.
• Măsurile de securitate ar trebui să funcționeze impecabil.
• Criptarea datelor și Digital semnături pe documente
• Autentificare și autorizare
• SQL Injection, Malware, XSS, CSRF, alte vulnerabilități urmează să fie testate pe XML.
• Atacuri de negare a serviciului

7) Testarea performanței

Testarea performanței serviciului trebuie făcută, deoarece serviciile sunt reutilizabile și mai multe aplicații pot folosi 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ă în timp ce se lucrează individual și în cadrul aplicației, aceasta este cuplată.
• Trebuie efectuată testarea la sarcină a serviciului
• pentru a verifica timpul de răspuns
• pentru a verifica blocajele
• pentru a verifica utilizarea CPU și a memoriei
• pentru a prezice scalabilitatea

8) Testarea nivelului de integrare

• Testarea nivelului de service asigură funcționarea corectă numai a serviciilor în mod individual, nu garantează funcționarea componentelor cuplate.
• Testarea de integrare se face concentrându-se în principal pe interfețe.
• Această fază acoperă toate scenariile de afaceri posibile.
• Testarea non-funcțională a aplicației ar trebui făcută î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ă că aplicația confirmă cerințele de afaceri atât din punct de vedere funcțional, cât și nefuncțional.

Elementele de mai jos sunt asigurate că vor fi testate în timpul testării de la capăt la capăt

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

Provocări în testarea SOA

• Lipsa interfețelor pentru Servicii
• Procesul de testare se întinde pe mai multe sisteme, creând astfel nevoi complexe de date
• Aplicația este o colecție de diferite componente care tinde să se schimbe. Necesitatea testelor de regresie este mai frecventă.
• Datorită arhitecturii multistrat, este dificil să izolați defectele.
• Deoarece serviciul va fi utilizat în diferite interfețe, este dificil să se prezică sarcina, ceea ce face ca planificarea testelor de performanță să fie greoaie.
• SOA este o colecție de tehnologii eterogene. Testarea unei aplicații SOA necesită oameni cu seturi diferite de abilități care, la rândul lor, cresc costurile de planificare și execuție.
• Deoarece aplicația este o integrare a mai multor servicii, testarea de securitate are propria sa parte de probleme. Validarea autentificării și autorizării este destul de dificilă.

Cazuri de utilizare pentru testarea SOA

Luați în considerare un site de comerț electronic, care conține următoarele funcții și subfuncții:

Procesarea comenzilor

Faza 1

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

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

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

Funcțiile de afaceri fiind aceleași cu funcțiile Site-ului.

Notă: Documentul de strategie de testare ar conține lista serviciului și funcțiile care trebuie testate.

Faza 2

Faza de planificare a testului. Cazurile de testare sunt scrise pentru fiecare nivel.

1. Nivel de la capăt la final. Cazurile de testare sunt scrise pentru fiecare caz de utilizare și flux de afaceri. Mai jos sunt exemple de cazuri de testare
   • Creați o comandă cu utilizatorul activ.
   • Creați o comandă cu un utilizator inactiv.
   • Creați o comandă cu produsul disponibil cu cantitatea de comandă < cantitatea disponibilă.
   • Creați o comandă cu produsul disponibil cu cantitatea de comandă > cantitatea disponibilă.
   • Creați o comandă cu mai multe articole
   • Anulați o comandă complet.
   • Anulați parțial comanda.
2. Nivel de integrare. Cazurile de testare sunt scrise pentru integrarea bazei de date și a interfeței cu utilizatorul. 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 nouă comandă cu un singur articol. Verificați dacă cantitatea de produs disponibilă este mai mică cu valoarea comenzii.
   • Verificați dacă starea comenzii afișată pe UI 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 prima plată, verificați dacă detaliile de plată introduse în UI 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.
3. 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 pe comandă < Cantitate pe baza de date.
3	Creați numărul de comandă de 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

Execuția testului folosește abordarea de jos în sus, adică testarea la nivel de serviciu este efectuată mai întâi, apoi nivelul de integrare și în sfârșit Testare de la capăt la capăt.

1) Nivel de serviciu

Să luăm în considerare asta Soapui instrumentul este luat în considerare pentru testarea aplicației.

wsdl și URL-ul sunt răsfoite în fereastra de testare a SOAP.

Cererea pentru fiecare serviciu va fi afișată în fereastra de solicitare.

Prin modificarea datelor conform cazurilor de testare la nivel de serviciu, cererile sunt create pentru fiecare caz de testare.

Caz de testare	Cerere	Răspuns așteptat
Creați comanda. Nr. Articole = 1Cantitate pe comanda < Cantitate pe db	x2 2	o3251 De succes
Creare comanda.Nr. de articole > 1Cantitate pe comandă < Cantitate pe db	y1 1 y2 3	o3251 De succes
Creare comanda nr. de articole = 1Cantitate pe comandă > Cantitate pe db	x23 200	nul Fără succes
Verificați starea comenzii Stare pe baza de date = Activ	o9876	Activ De succes
Verificați starea comenzii Stare pe baza de date = Expediat	o9656	Expediat De succes
Verificați starea comenzii Id-ul comenzii = Invalid	y5686	nul Fără succes
Verificați disponibilitatea produsuluiCantitatea de produs >0	d34	34 da De succes
Verificați disponibilitatea produsuluiCantitatea de produs =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.
• Merge să plaseze o comandă.
• Selectează un produs și o cantitate validă și salvează comanda.
• Ar trebui să fie afișat un mesaj care spune că comanda a fost plasată cu succes.
• Un utilizator 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 afaceri și cazurile de utilizare sunt executate pe interfața cu utilizatorul.

• Creați o comandă cu mai multe articole -
• Un utilizator deschide un site web.
• Merge să plaseze o comandă.
• Întrebări despre un produs valid și cantitatea le adaugă în coș.
• Se adauga si alte produse valabile cu cantitati valabile si comanda este salvata. Plata se face printr-o nouă metodă de plată și se plasează comanda.
• Ar trebui să fie afișat un mesaj care spune „Comandă plasată cu succes”.
• Un tester ar trebui să valideze că întregul flux este realizat fără denaturarea datelor.

Concluzie

Prin schițarea strategiei potrivite pentru testare, resurse, instrumente și conformitate pentru a oferi servicii bune, testarea SOA poate oferi aplicații complet și perfect testate.