Ce este testarea SOA?
Testarea SOA (Service Oriented Architecture) este o testare a stilului arhitectural SOA în care componentele aplicației sunt proiectate pentru a comunica prin protocoale de comunicație de obicei pe o rețea.
În acest tutorial, veți învăța-
- Ce este SOA?
- Ce este serviciul?
- Testarea SOA
- Strategia pentru testarea SOA
- Metode de testare SOA
- Provocări în testarea SOA
- Instrumente de testare SOA
- Cazuri de utilizare pentru testarea SOA
Ce este SOA?
SOA este o metodă de integrare a aplicațiilor și proceselor de afaceri împreună, astfel încât să satisfacă nevoile afacerii.
În ingineria 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 dezvoltă fie cumpără bucăți de programe numite SERVICII.
Ce este serviciul?
- Serviciile pot fi o unitate funcțională de cerere sau proces 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 o plată trebuie să facă acest lucru, site-ul de e-commerce apelează / Solicită serviciul Gateway de plată. După ce plata este efectuată pe un gateway, un răspuns este trimis pe site-ul de comerț electronic)
- Serviciile sunt ușor de asamblat și ușor de reconfigurat componentele.
- Serviciile pot fi comparate cu elemente de bază. Ei pot construi orice aplicație necesară. Adăugarea și eliminarea acestora din aplicație sau din procesul de afaceri este ușoară.
- Serviciile sunt definite mai mult prin funcția de afaceri pe care o îndeplinesc, mai degrabă decât ca bucăți de cod.
Servicii Web
Serviciile web sunt componente independente ale aplicației, care sunt disponibile pe web.
Acestea pot fi publicate, găsite și pot fi utilizate pe web. Pot comunica prin internet.
- Furnizorul de servicii publică serviciul pe internet.
- Clientul caută un anumit serviciu web din Registrul serviciilor web
- 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. <<
- Când un consumator apelează un serviciu web, va fi stabilită o conexiune HTTP către furnizor.
Este creat un mesaj SOAP pentru a instrui furnizorul pentru invocarea logicii serviciului web necesar.
- 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 ușor de înțeles de aplicația de consum.
Exemplu
O pagină de pornire a unui site web și a unui motor de căutare afișează raportul meteo zilnic. În loc să codificați secțiunea de prognoze meteo peste tot, un serviciu de raport meteo poate fi cumpărat de la un furnizor și integrat în pagini.
Testarea SOA
SOA constă din diverse tehnologii. Aplicațiile construite utilizând SOA au diverse servicii care sunt cuplate slab.
Testarea SOA ar trebui să se concentreze pe 3 straturi de sistem
Stratul de servicii
Acest strat constă din servicii, servicii expuse de un sistem derivat din funcții de afaceri.
De exemplu -
Luați în considerare un site web Wellness care constă din
- Weight Tracker
- Urmărirea zahărului din sânge
- Urmărirea tensiunii arteriale
Trackerele afișează datele respective și data la care au fost introduse. Stratul de servicii constă din serviciile care obțin 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 urmărire a tensiunii arteriale
- Serviciu de autentificare
Strat proces
Process Layer constă în procesele, colectarea de servicii care fac parte dintr-o singură funcționalitate.
Procesele ar putea face parte din interfața cu utilizatorul (de exemplu, un motor de căutare), o parte dintr-un instrument ETL (pentru obținerea datelor din baza de date).
Accentul principal în acest strat va fi în interfețele de utilizator și proces.
Interfața cu utilizatorul tracker-ului de greutate și integrarea sa cu baza de date reprezintă obiectivul principal.
Funcțiile de mai jos vor fi luate în considerare
- Adăugarea de date noi
- Editarea datelor existente
- Se creează un nou tracker
- Ștergerea datelor
Stratul consumatorului
Acest strat cuprinde în principal interfețe utilizator.
Pe baza stratului, testarea unei aplicații SOA este distribuită pe trei niveluri.
- Nivel de servicii
- Nivelul interfeței
- Nivelul End to End
- Abordarea de sus în jos este utilizată pentru proiectarea testelor.
- Abordarea de jos în sus este utilizată pentru executarea testului.
Strategia pentru testarea SOA
Abordarea planificării testelor,
- Arhitectura completă a aplicației ar trebui să fie înțeleasă de testerii SOA.
- Aplicația trebuie împărțită în servicii independente (Serviciul, care are propria structură de cerere și răspuns și nu depinde de niciun alt serviciu pentru a forma răspuns).
- Structura aplicației trebuie să fie reorganizată în trei componente - date, servicii și aplicații front-end.
- Toate componentele trebuie analizate cu atenție, iar scenariile de afaceri ar trebui să fie clarificate.
- Scenariile de afaceri ar trebui clasificate ca scenarii comune și scenarii specifice aplicației.
- Ar trebui pregătită o matrice de trasabilitate și toate cazurile de testare ar trebui să fie trasate în scenarii de afaceri.
Abordarea de execuție a testului
- Fiecare componentă de serviciu ar trebui testată.
- Integrarea Testarea componentelor serviciului trebuie 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 între aplicația front-end și baza de date.
- Testarea performanței ar trebui făcută pentru reglaj fin și performanță optimă.
Metode de testare SOA
1) Testarea bazată pe date bazată pe scenariul de afaceri,
- Ar trebui analizate diverse aspecte comerciale legate de sistem.
- Scenariile ar trebui dezvoltate pe baza integrării
- Diverse servicii Web ale aplicației
- Servicii web și aplicații.
- Configurarea datelor trebuie făcută pe baza scenariilor de mai sus.
- Configurarea datelor trebuie făcută astfel încât să acopere și scenarii de la capăt la cap.
2) Cepuri
- Interfețele fictive vor fi create pentru a testa serviciile.
- Prin aceste interfețe pot fi furnizate diverse intrări, iar ieșirile pot fi validate.
- Atunci 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 de regresie a aplicației trebuie făcută atunci când există mai multe versiuni, astfel încât să se asigure stabilitatea și disponibilitatea sistemelor.
- Se va crea o suită de testare de regresie cuprinzătoare care să acopere serviciile care reprezintă o parte importantă a aplicației.
- Această suită de testare 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 mai întâi testat independent.
5) Testarea funcțională
Testarea funcțională ar trebui făcută pentru fiecare serviciu la
- Asigurați-vă că serviciul oferă răspunsul corect la fiecare solicitare.
- Se primesc erori corecte pentru solicitările cu date nevalide, date defecte etc.
- Verificați fiecare cerere și răspuns pentru fiecare operațiune pe care serviciul trebuie să o efectueze în timp de rulare.
- Validați mesajele de eroare atunci când apare o eroare la nivel de server, client sau rețea.
- Validați că răspunsurile primite sunt în formatul potrivit.
- Validați faptul că datele primite în răspunsul corespunzător datelor solicitate.
6) Testarea securității
Testarea securității serviciului web este un aspect important în timpul testării nivelului de serviciu al aplicației SOA; acest lucru 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 semnăturilor digitale pe documente
- Autentificare și autorizare
- SQL Injection, Malware, XSS, CSRF, alte vulnerabilități vor fi 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 ar putea folosi același serviciu.
Următorii factori sunt luați în considerare în timpul testării:
- 8) Performanța și funcționalitatea serviciului trebuie testate sub sarcină grea.
- Performanța serviciului trebuie să fie comparată în timp ce funcționează individual și în cadrul aplicației, este asociată.
- Ar trebui efectuate teste de încărcare ale serviciului
- pentru a verifica timpul de răspuns
- pentru a verifica blocajele
- pentru a verifica utilizarea procesorului și a memoriei
- pentru a prezice scalabilitatea
9) 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 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 trebuie efectuată încă o dată în această fază. Securitatea, conformitatea și testarea performanței asigură disponibilitatea și stabilitatea sistemului sub toate aspectele.
- Protocoalele de comunicare și de rețea ar trebui testate pentru a valida consistența comunicării datelor între servicii.
10) Testarea End to End
Această fază asigură faptul că aplicația confirmă cerințele afacerii atât funcțional, cât și nefuncțional.
Articolele de mai jos sunt asigurate pentru a fi testate în timpul testării de la capăt la cap
- Toate serviciile funcționează conform așteptărilor după integrare
- Manevrarea excepțiilor
- Interfața utilizator a aplicației
- Fluxul corect 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 necesități complexe de date
- Aplicația este o colecție de diferite componente care tinde să se schimbe. Nevoia de testare prin regresie este mai frecventă.
- Datorită arhitecturii multistrat, este dificil să se izoleze defectele.
- Deoarece serviciul va fi utilizat în diferite interfețe, este dificil să se prevadă încărcarea, ceea ce face dificilă planificarea testelor de performanță.
- SOA este o colecție de tehnologii eterogene. Testarea unei aplicații SOA necesită persoane cu seturi de abilități diferite care, la rândul lor, măresc costurile de planificare și execuție.
- Deoarece aplicația este o integrare a mai multor servicii, testarea securității are propria parte a problemelor. Validarea autentificării și autorizării este destul de dificilă.
Instrumente de testare SOA
Există multe instrumente de testare SOA disponibile pe piață pentru a ajuta testerii să testeze aplicații SOA. Iată câteva dintre instrumentele populare de testare SOA :
1) SOAP UI
„SOAP UI” este un instrument de testare funcțională open source pentru testare de servicii și API.
- Aplicație desktop
- Suportă mai multe protocoale - SOAP, REST, HTTP, JMS, AMF, JDBC
- Serviciile web pot fi dezvoltate, inspectate și invocate.
- Poate fi utilizat și pentru testarea sarcinii, testarea automatizării și testarea securității
- Butoanele pot fi create de MockServices
- Solicitările și testele serviciului web pot fi generate automat prin intermediul clientului său de servicii web.
- Aveți instrumente de raportare încorporate
- Dezvoltat de SmartBear
2) iTKO LISA
„LISA” este o suită de produse care oferă o soluție de testare funcțională pentru sisteme distribuite precum SOA.
- Poate fi utilizat și pentru regresie, integrare, sarcină și testarea performanței.
- Dezvoltat de iTKO (CA Technologies)
- Poate fi folosit pentru proiectarea și executarea testelor.
3) Test de service HP
„Service Test” este un instrument de testare funcțional, care acceptă atât testarea interfeței de utilizare, cât și testarea serviciilor partajate
- Atât testul funcțional, cât și cel de performanță al serviciilor pot fi realizate printr-un singur script.
- Integrat cu HP QC.
- Cantitatea masivă de servicii și date poate fi gestionată.
- Suportă testarea interoperabilității prin simularea mediilor client JEE, AXIS și DotNet.
- Dezvoltat de HP.
4) Test SOA Parasoft
Testul SOA este o suită de instrumente de testare și analiză dezvoltată pentru testarea aplicațiilor API și API.
- Suportă servicii Web, REST, JSON, MQ, JMS, TIBCO, HTTP, tehnologii XML.
- Sunt posibile teste funcționale, de unitate, de integrare, de regresie, de securitate, de interoperabilitate, de conformitate și de performanță.
- Stub-urile pot fi create folosind Parasoft Virtualize, care sunt inteligente decât SOAP UI.
- Dezvoltat de ParaSoft
Cazuri de utilizare pentru testarea SOA
Luați în considerare un site de comerț electronic, care conține funcțiile și subfuncțiile de mai jos:
Procesarea comenzilor
FAZA 1
În prima fază a testării SOA, adică a fazei strategiei de testare, 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
- Schimbaț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 de strategie de testare va conține lista serviciului și funcțiile care trebuie testate.
FAZA 2
Faza de planificare a testului. Testele sunt scrise pentru fiecare nivel.
- Nivelul End to End. Cazurile de testare sunt scrise pentru fiecare caz de utilizare și flux de afaceri.
Mai jos sunt exemplul cazurilor 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 comenzii
- Creați o comandă cu produsul disponibil cu cantitatea comenzii> cantitatea disponibilă.
- Creați o comandă cu mai multe articole
- Anulați complet o comandă.
- Anulați parțial comanda.
- Nivel de integrare. Testele 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 produsului disponibil este mai mică cu valoarea comenzii.
- Verificați dacă starea comenzii afișate în interfața de utilizare 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 dată, verificați dacă detaliile de plată introduse în interfața de utilizare sunt salvate în baza de date.
- Pentru returnarea plăților, verificați dacă detaliile de plată din baza de date sunt afișate în interfața de utilizare.
- 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 comandă. Număr de articole = 1 | Cantitate la comandă |
| 2 | Creați comandă. Număr de articole> 1 | Cantitate la comandă |
| 3 | Creați numărul comenzii de articole = 1 | Cantitate la comandă> Cantitate la baza de date |
| 4 | Verificați starea comenzii | Stare în baza de date = Activ |
| 5 | Verificați starea comenzii | Stare în baza de date = Expediat |
| 6 | Verificați starea comenzii | Stare în baza de date = Anulat |
| 7 | Verificați starea comenzii | ID comandă = nevalid |
| 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 = nevalid |
FASA 3 - Executarea testului
Execuția testului utilizează o abordare de jos în sus, adică testarea nivelului de serviciu se face mai întâi, apoi nivelul de integrare și, în cele din urmă, testarea End to End.
1) Nivelul serviciului
Să luăm în considerare că instrumentul Soapui este luat în considerare pentru testarea aplicației.
WSDL și URL-ul sunt răsfoite în fereastra de test a SOAP.
Solicitarea pentru fiecare serviciu va fi afișată în fereastra de solicitare.
Prin modificarea datelor conform cazurilor de testare la nivel de serviciu, se creează cereri pentru fiecare caz de testare.
|
Caz de testare |
Cerere |
Răspunsul așteptat |
|---|---|---|
|
Creați comandă. Număr de articole = 1 Cantitate la comandă |
|
|
|
Creați o comandă. de articole> 1Cantitate la comandă |
|
|
|
Creați comanda nr. de articole = 1 Cantitate la comandă> Cantitate la db |
|
|
|
Verificați starea comenzii Stare în baza de date = Activ |
|
|
|
Verificați starea comenzii Stare în baza de date = Expediat |
|
|
|
Verificați starea comenzii ID-ul comenzii = nevalid |
|
|
|
Verificați disponibilitatea produsului Cantitatea produsului> 0 |
|
|
|
Verificați disponibilitatea produsului Cantitatea produsului = 0 |
|
|
|
Verificați disponibilitatea produsului ID produs = invalid |
|
|
2) Nivel de integrare
Cazurile de testare la nivel de integrare sunt executate pe interfața de utilizator și baza de date.
- Creați o comandă cu un singur articol -
- Un utilizator deschide site-ul web.
- Merge la plasarea unei comenzi.
- Selectează un produs și o cantitate validă și salvează comanda.
- Ar trebui să fie afișat un mesaj care spune că ordinea este plasată cu succes.
- Un utilizator deschide baza de date și verifică dacă detaliile comenzii sunt aceleași cu cele introduse pe site.
3) Nivelul End to End
Fluxurile de afaceri și cazurile de utilizare sunt executate pe interfața utilizatorului.
- Creați o comandă cu mai multe articole -
- Un utilizator deschide un site web.
- Merge la plasarea unei comenzi.
- Cereți despre un produs valid și cantitatea le adaugă în coș.
- Alte produse valide sunt adăugate cu cantități valide și comanda este salvată. Plata se face printr-o nouă metodă de plată și se plasează comanda.
- Ar trebui afișat un mesaj care să spună „Comanda plasată cu succes”.
- Un tester ar trebui să confirme că întregul flux se realizează fără a distorsiona datele.
Concluzie:
Schițând strategia potrivită pentru testare, resurse, instrumente și conformitate pentru a oferi un serviciu bun, testarea SOA poate furniza aplicații testate complet și perfect.