Kas ir SOA testēšana?
SOA (uz pakalpojumu orientēta arhitektūra) testēšana ir SOA arhitektūras stila pārbaude, kurā lietojumprogrammu komponenti ir paredzēti saziņai, izmantojot sakaru protokolus, parasti tīklā.
Šajā apmācībā jūs uzzināsiet
- Kas ir SOA?
- Kas ir serviss?
- SOA testēšana
- SOA testēšanas stratēģija
- SOA testēšanas metodes
- Izaicinājumi SOA testēšanā
- SOA testēšanas rīki
- SOA testēšanas lietošanas gadījumi
Kas ir SOA?
SOA ir metode biznesa lietojumprogrammu un procesu integrēšanai, lai apmierinātu biznesa vajadzības.
Programmatūras inženierijā SOA nodrošina veiklību un elastību biznesa procesos. Procesa vai lietojumprogrammas izmaiņas var novirzīt uz konkrētu komponentu, neietekmējot visu sistēmu.
SOA programmatūras izstrādātāji vai nu izstrādā, vai pērk programmu daļas, kuras sauc par SERVICES.
Kas ir serviss?
- Pakalpojumi var būt funkcionāla lietojumprogrammas vai biznesa procesa vienība, kuru var atkārtoti izmantot vai atkārtot ar jebkuru citu lietojumprogrammu vai procesu.
(Piemēram, iepriekš redzamajā attēlā Payment Gateway ir pakalpojums, kuru var atkārtoti izmantot jebkura e-komercijas vietne. Ikreiz, kad nepieciešams veikt maksājumu, e-komercijas vietne zvana / pieprasa Payment Gateway pakalpojumu. Pēc tam, kad maksājums ir veikts vārteju, atbilde tiek nosūtīta uz e-komercijas vietni)
- Pakalpojumus ir viegli montēt un viegli pārkonfigurēt komponentus.
- Pakalpojumus var salīdzināt ar celtniecības blokiem. Viņi var izveidot jebkuru nepieciešamo lietojumprogrammu. Tās ir viegli pievienot un noņemt no lietojumprogrammas vai biznesa procesa.
- Pakalpojumus vairāk nosaka uzņēmējdarbības funkcija, ko tie veic, nevis kā koda gabali.
Tīmekļa pakalpojumi
Tīmekļa pakalpojumi ir neatkarīgi lietojumprogrammu komponenti, kas ir pieejami tīmeklī.
Tos var publicēt, atrast un izmantot tīmeklī. Viņi var sazināties, izmantojot internetu.
- Pakalpojuma sniedzējs publicē pakalpojumu internetā.
- Klients meklē Web servera reģistrā noteiktu tīmekļa pakalpojumu
- Tiek atgriezts vajadzīgā tīmekļa pakalpojuma URL un WSDL.
>> Izmantojot WSDL un URL, saziņa starp pakalpojumu sniedzēju un pieprasītāju notiek, izmantojot SOAP ziņojumus. <<
- Kad patērētājs zvana uz tīmekļa pakalpojumu, ar pakalpojumu sniedzēju tiks izveidots HTTP savienojums.
Tiek izveidots SOAP ziņojums, lai norādītu pakalpojumu sniedzējam izsaukt nepieciešamo tīmekļa pakalpojumu loģiku.
- No pakalpojumu sniedzēja saņemtā atbilde ir SOAP ziņojums, kas tiks iegults HTTP atbildē. Šī HTTP atbilde ir datu formāts, kuru saprot patērētāja lietojumprogramma.
Piemērs
Vietnes un meklētājprogrammas mājas lapā tiek rādīti ikdienas laika apstākļu pārskati. Tā vietā, lai visā kodētu laika ziņu sadaļu, laika ziņu pakalpojumu var iegādāties no pārdevēja un integrēt lapās.
SOA testēšana
SOA sastāv no dažādām tehnoloģijām. Lietojumprogrammām, kas izveidotas, izmantojot SOA, ir dažādi pakalpojumi, kas ir brīvi savienoti.
SOA testēšanai jākoncentrējas uz 3 sistēmas slāņiem
Pakalpojumu slānis
Šis slānis sastāv no pakalpojumiem, pakalpojumiem, kas pakļauti sistēmai, kas atvasināta no uzņēmējdarbības funkcijām.
Piemēram -
Apsveriet Wellness vietni, kas sastāv no
- Svara izsekotājs
- Asins cukura izsekotājs
- Asinsspiediena izsekotājs
Trekeri parāda attiecīgos datus un ievadīšanas datumu. Pakalpojumu slānis sastāv no pakalpojumiem, kas attiecīgos datus iegūst no datu bāzes
- Svara izsekošanas pakalpojums
- Asins cukura izsekošanas pakalpojums
- Asinsspiediena izsekošanas pakalpojums
- Pieteikšanās pakalpojums
Procesa slānis
Procesu slānis sastāv no procesiem, pakalpojumu apkopošanas, kas ir daļa no vienas funkcionalitātes.
Procesi var būt lietotāja interfeisa daļa (ex - meklētājprogrammai), ETL rīka daļa (datu iegūšanai no datu bāzes).
Šajā slānī galvenā uzmanība tiks pievērsta lietotāju saskarnēm un procesam.
Svaru uzskaites lietotāja saskarne un tās integrācija ar datu bāzi ir galvenā uzmanība.
Zemāk redzamās funkcijas tiks ņemtas vērā
- Jaunu datu pievienošana
- Esošo datu rediģēšana
- Izveido jaunu izsekotāju
- Datu dzēšana
Patērētāja slānis
Šis slānis galvenokārt sastāv no lietotāja saskarnēm.
Pamatojoties uz slāni, SOA lietojumprogrammas testēšana tiek sadalīta trīs līmeņos.
- Pakalpojuma līmenis
- Saskarnes līmenis
- No gala līdz beigām līmenis
- Testa projektēšanā tiek izmantota pieeja no augšas uz leju.
- Testa izpildei tiek izmantota pieeja no apakšas uz augšu.
SOA testēšanas stratēģija
Testa plānošanas pieeja,
- SOA testētājiem ir jāsaprot visa lietojuma arhitektūra.
- Lietojumprogramma jāsadala neatkarīgos pakalpojumos (pakalpojums, kuram ir sava pieprasījuma un atbildes struktūra un kurš nav atkarīgs no cita pakalpojuma, lai veidotu atbildi).
- Lietojumprogrammu struktūra jāpārkārto trīs komponentos - dati, pakalpojumi un priekšējās lietojumprogrammas.
- Visi komponenti ir rūpīgi jāanalizē, un biznesa scenāriji ir jāaplūko.
- Biznesa scenāriji ir jāklasificē kā kopīgi scenāriji un lietojumprogrammu scenāriji.
- Būtu jāsagatavo izsekojamības matrica, un visi testa gadījumi būtu jāseko biznesa scenārijiem.
Testa izpildes pieeja
- Katrs servisa komponents jāpārbauda.
- Integrācija Lai pārbaudītu datu plūsmu caur pakalpojumiem un datu integritāti, jāveic pakalpojumu komponentu pārbaude.
- Lai pārbaudītu datu plūsmu starp priekšgala lietojumprogrammu un datu bāzi, jāveic visa modeļa pārbaude.
- Veiktspējas pārbaude jāveic, lai precizētu un nodrošinātu optimālu veiktspēju.
SOA testēšanas metodes
1) uzņēmējdarbības scenāriju balstīta uz datiem balstīta testēšana,
- Jāanalizē dažādi ar sistēmu saistīti biznesa aspekti.
- Scenāriji jāizstrādā, pamatojoties uz
- Dažādi lietojumprogrammas tīmekļa pakalpojumi
- Tīmekļa pakalpojumi un lietojumprogrammas.
- Dati jāveido, pamatojoties uz iepriekš minētajiem scenārijiem.
- Dati ir jāizveido tā, lai tie aptvertu arī beigu beigu scenārijus.
2) Stubs
- Pakalpojumu pārbaudei tiks izveidotas manekena saskarnes.
- Caur šīm saskarnēm var nodrošināt dažādas ieejas, un izejas var apstiprināt.
- Kad lietojumprogramma izmanto saskarni ārējam pakalpojumam, kas netiek testēts (trešās puses pakalpojums), integrācijas testēšanas laikā var izveidot saiti.
3) Regresijas pārbaude
- Lai nodrošinātu sistēmu stabilitāti un pieejamību, lietojumprogrammas regresijas pārbaude jāveic, ja ir vairākas izlaišanas.
- Tiks izveidots visaptverošs regresijas testa komplekts, kas aptvers pakalpojumus, kas ir nozīmīga lietojumprogrammas sastāvdaļa.
- Šo testa komplektu var atkārtoti izmantot vairākos projekta laidienos.
4) Pakalpojuma līmeņa pārbaude
Pakalpojuma līmeņa pārbaude ietver komponenta funkcionalitātes, drošības, veiktspējas un savietojamības pārbaudi.
Katrs pakalpojums vispirms jāpārbauda neatkarīgi.
5) Funkcionālā pārbaude
Funkcionālā pārbaude jāveic katram pakalpojumam
- Pārliecinieties, ka pakalpojums sniedz pareizo atbildi uz katru pieprasījumu.
- Pareizas kļūdas tiek saņemtas pieprasījumiem ar nederīgiem datiem, sliktiem datiem utt.
- Pārbaudiet katru pieprasījumu un atbildi par katru darbību, kas dienestam jāveic izpildes laikā.
- Apstipriniet kļūdas ziņojumus, kad servera, klienta vai tīkla līmenī rodas kļūda.
- Pārbaudiet, vai saņemtās atbildes ir pareizajā formātā.
- Pārbaudiet, vai par atbildi saņemtie dati atbilst pieprasītajiem datiem.
6) Drošības pārbaude
Tīmekļa pakalpojuma drošības pārbaude ir svarīgs aspekts SOA lietojumprogrammas servisa līmeņa testēšanas laikā; tas nodrošina lietojuma drošību.
Pārbaudes laikā jāņem vērā šādi faktori:
- WS-Security testēšanas definētais nozares standarts jāievēro Web pakalpojumam.
- Drošības pasākumiem vajadzētu darboties nevainojami.
- Datu un ciparparakstu šifrēšana dokumentos
- Autentifikācija un autorizācija
- SQL Injection, Malware, XSS, CSRF un citas ievainojamības ir jāpārbauda XML.
- Pakalpojuma atteikuma uzbrukumi
7) Veiktspējas pārbaude
Jāveic pakalpojuma veiktspējas pārbaude, jo pakalpojumi ir atkārtoti izmantojami un vairākas programmas var izmantot vienu un to pašu pakalpojumu.
Testēšanas laikā tiek ņemti vērā šādi faktori:
- 8) Pakalpojuma veiktspēja un funkcionalitāte jāpārbauda pie lielas slodzes.
- Pakalpojuma veiktspēja ir jāsalīdzina, strādājot atsevišķi un lietojumprogrammā, un tas ir apvienots.
- Jāveic servisa slodzes pārbaude
- lai pārbaudītu reakcijas laiku
- lai pārbaudītu vājās vietas
- lai pārbaudītu CPU un atmiņas izmantošanu
- lai prognozētu mērogojamību
9) Integrācijas līmeņa pārbaude
- Pakalpojumu līmeņa pārbaude nodrošina pareizu tikai pakalpojumu individuālu darbību, tā negarantē savienoto komponentu darbību.
- Integrācijas testēšana tiek veikta, galvenokārt koncentrējoties uz saskarnēm.
- Šis posms aptver visus iespējamos biznesa scenārijus.
- Šajā posmā lietojumprogrammas nefunkcionālā pārbaude jāveic vēl vienu reizi. Drošība, atbilstība un veiktspējas pārbaude nodrošina sistēmas pieejamību un stabilitāti visos aspektos.
- Sakaru un tīkla protokoli jāpārbauda, lai apstiprinātu datu sakaru konsekvenci starp dienestiem.
10) Testēšana no gala līdz beigām
Šis posms nodrošina, ka lietojumprogramma funkcionāli un nefunkcionāli apstiprina biznesa prasības.
Tālāk minētie elementi tiek pārbaudīti testēšanas laikā līdz beigām
- Visi pakalpojumi pēc integrācijas darbojas kā paredzēts
- Izņēmumu apstrāde
- Lietotnes lietotāja saskarne
- Pareiza datu plūsma caur visiem komponentiem
- Biznesa process
Izaicinājumi SOA testēšanā
- Pakalpojumu saskarņu trūkums
- Pārbaudes process aptver vairākas sistēmas, tādējādi radot sarežģītas datu vajadzības
- Lietojumprogramma ir dažādu komponentu kolekcija, kurai ir tendence mainīties. Regresijas testēšanas nepieciešamība ir biežāka.
- Daudzslāņu arhitektūras dēļ ir grūti izolēt defektus.
- Tā kā pakalpojums tiks izmantots dažādās saskarnēs, ir grūti prognozēt slodzi, tādējādi veiktspējas testu plānošana kļūst apgrūtinoša.
- SOA ir neviendabīgu tehnoloģiju kolekcija. SOA lietojumprogrammas testēšanai nepieciešami cilvēki ar dažādām prasmju kopām, kas savukārt palielina plānošanas un izpildes izmaksas.
- Tā kā lietojumprogramma ir vairāku pakalpojumu integrācija, drošības pārbaudei ir sava daļa no bēdām. Autentifikācijas un autorizācijas apstiprināšana ir diezgan sarežģīta.
SOA testēšanas rīki
Tirgū ir pieejami daudzi SOA testēšanas rīki, kas testētājiem palīdzēs pārbaudīt SOA lietojumprogrammas. Šeit ir daži no populārajiem SOA testēšanas rīkiem :
1) ZIEPES UI
"SOAP UI" ir atvērtā pirmkoda funkcionālais testēšanas rīks pakalpojumiem un API testēšanai.
- Darbvirsmas lietojumprogramma
- Atbalsta vairākus protokolus - SOAP, REST, HTTP, JMS, AMF, JDBC
- Tīmekļa pakalpojumus var izstrādāt, pārbaudīt un atsaukties.
- Var izmantot arī slodzes testēšanai, automatizācijas testēšanai un drošības testēšanai
- Stubus var izveidot MockServices
- Tīmekļa pakalpojuma pieprasījumus un testus var automātiski ģenerēt, izmantojot tā tīmekļa pakalpojumu klientu.
- Ir iebūvēti pārskatu rīki
- Izstrādājis SmartBear
2) iTKO LISA
"LISA" ir produktu komplekts, kas nodrošina funkcionālu testēšanas risinājumu tādām izplatītām sistēmām kā SOA.
- Var izmantot arī regresijas, integrācijas, slodzes un veiktspējas testēšanai.
- Izstrādājis iTKO (CA Technologies)
- Var izmantot, lai izstrādātu un veiktu testus.
3) HP servisa pārbaude
"Pakalpojuma pārbaude" ir funkcionāls testēšanas rīks, kas atbalsta gan lietotāja saskarnes, gan koplietojamo pakalpojumu testēšanu
- Gan pakalpojumu funkcionālo, gan veiktspējas pārbaudi var veikt ar vienu skriptu.
- Integrēta ar HP QC.
- Var pārvaldīt milzīgo pakalpojumu un datu apjomu.
- Atbalsta sadarbspējas testēšanu, simulējot JEE, AXIS un DotNet klientu vides.
- Izstrādāts HP.
4) Parasoft SOA tests
SOA tests ir testēšanas un analīzes rīku komplekts, kas izstrādāts API un API lietojumprogrammu testēšanai.
- Atbalsta Web Services, REST, JSON, MQ, JMS, TIBCO, HTTP, XML tehnoloģijas.
- Iespējamas funkcionālās, vienības, integrācijas, regresijas, drošības, savietojamības, atbilstības un veiktspējas pārbaudes.
- Cietumus var izveidot, izmantojot Parasoft Virtualize, kas ir inteliģenti nekā SOAP UI.
- Izstrādāts ParaSoft
SOA testēšanas lietošanas gadījumi
Apsveriet e-komercijas vietni, kurā ir šādas funkcijas un apakšfunkcijas:
Pasūtījumu apstrāde
1. FĀZE
SOA testēšanas pirmajā posmā, ti, testa stratēģijas fāzē, lietojumprogramma ir sadalīta pakalpojumos un uzņēmējdarbības funkcijās.
Ļaujiet mums apsvērt tālāk ir Pakalpojumi lietojumprogrammā.
- Izveidot pasūtījumu
- Pārbaudiet klienta statusu
- Mainīt pasūtījuma statusu
- Pārbaudiet pasūtījuma statusu
- Pārbaudiet krājumu
Biznesa funkcijas ir vienādas ar Vietnes funkcijām.
Piezīme . Testa stratēģijas dokumentā būtu jāiekļauj pārbaudāmā pakalpojuma un funkciju saraksts.
2. FĀZE
Testa plānošanas fāze. Katram līmenim tiek rakstīti testa gadījumi.
- No gala līdz beigām līmenis. Pārbaudes gadījumi tiek rakstīti katram uzņēmējdarbības gadījumam un plūsmai.
Zemāk ir testa gadījumu piemērs
- Izveidojiet pasūtījumu pie aktīvā lietotāja.
- Izveidojiet pasūtījumu pie neaktīva lietotāja.
- Izveidojiet pasūtījumu ar pieejamo produktu ar pasūtījuma daudzumu
- Izveidojiet pasūtījumu ar pieejamo produktu ar pasūtījuma daudzumu> pieejamo daudzumu.
- Izveidojiet pasūtījumu ar vairākiem vienumiem
- Pilnīgi atcelt pasūtījumu.
- Daļēji atcelt pasūtījumu.
- Integrācijas līmenis. Testa gadījumi tiek rakstīti datu bāzes un lietotāja saskarnes integrēšanai.
Tālāk ir sniegti testa gadījumu piemēri.
- Izveidojiet jaunu pasūtījumu ar vienu vienumu. Pārbaudiet, vai pasūtījums ir izveidots datu bāzē.
- Izveidojiet jaunu pasūtījumu ar vienu vienumu. Pārbaudiet, vai pasūtījumam aprēķinātā cena ir pareiza.
- Izveidojiet jaunu pasūtījumu ar vienu vienumu. Pārbaudiet, vai pieejamā produkta daudzums ir mazāks par pasūtījuma summu.
- Pārbaudiet, vai UI attēlotā pasūtījuma statuss ir tāds pats kā datu bāzē.
- Atcelt pasūtījumu un pārbaudiet, vai datu bāzē ir mainīts pasūtījuma statuss.
- Pirmo reizi veicot maksājumu, pārbaudiet, vai lietotāja saskarnē ievadītā maksājuma informācija ir saglabāta datu bāzē.
- Lai atgrieztu maksājumus, pārbaudiet, vai datu bāzē informācija par maksājumu ir parādīta lietotāja saskarnē.
- Pakalpojuma līmenis. Katram pakalpojumam tiek pārbaudīti visi datu apstākļi.
Zemāk ir daži piemēri.
| Nē. | pasūtījuma detaļas | Pasūtījuma nosacījums |
|---|---|---|
| 1 | Izveidot pasūtījumu. Preču skaits = 1 | Pasūtījuma daudzums |
| 2 | Izveidot pasūtījumu. Preču skaits> 1 | Pasūtījuma daudzums |
| 3 | Izveidot pasūtījumu skaitu = 1 | Daudzums pēc pasūtījuma> Daudzums datubāzē |
| 4 | Pārbaudiet pasūtījuma statusu | Statuss datu bāzē = aktīvs |
| 5 | Pārbaudiet pasūtījuma statusu | Statuss datu bāzē = nosūtīts |
| 6 | Pārbaudiet pasūtījuma statusu | Statuss datu bāzē = Atcelts |
| 7 | Pārbaudiet pasūtījuma statusu | Pasūtījuma id = nederīgs |
| 8 | Pārbaudiet produkta pieejamību | Produkta daudzums> 0 |
| 9 | Pārbaudiet produkta pieejamību | Produkta daudzums = 0 |
| 10 | Pārbaudiet produkta pieejamību | Produkta ID = nederīgs |
3. FĀZE - testa izpilde
Testa izpildē tiek izmantota augšupēja pieeja, ti, vispirms tiek veikta servisa līmeņa pārbaude, pēc tam integrācijas līmeņa testēšana un visbeidzot - testēšana no gala līdz beigām.
1) Pakalpojuma līmenis
Apsvērsim, ka lietojumprogrammas testēšanai tiek apsvērts Soapui rīks.
WSDL un URL tiek pārlūkoti SOAP testa logā.
Katra pakalpojuma pieprasījums tiks parādīts pieprasījuma logā.
Mainot datus atbilstoši pakalpojumu līmeņa pārbaudes gadījumiem, katram testa gadījumam tiek izveidoti pieprasījumi.
|
Pārbaudes gadījums |
Pieprasījums |
Paredzētā atbilde |
|---|---|---|
|
Izveidot pasūtījumu. Preču skaits = 1Pasūtījuma daudzums |
|
|
|
Izveidot pasūtījumu. Nē. no 1 priekšmetiem> 1Piegādes pasūtījuma daudzums |
|
|
|
Izveidot pasūtījumu Nr. no vienumiem = 1Sūtījuma daudzums> Daudzums db |
|
|
|
Pārbaudiet pasūtījuma statusu statusu datu bāzē = aktīvs |
|
|
|
Pārbaudiet pasūtījuma statusu statusu datu bāzē = nosūtīts |
|
|
|
Pārbaudiet pasūtījuma statusuOrder id = Nederīgs |
|
|
|
Pārbaudiet produkta pieejamību Produkta daudzums> 0 |
|
|
|
Produkta daudzums = 0 |
|
|
|
Produkta ID = nederīgs |
|
|
2) Integrācijas līmenis
Integrācijas līmeņa pārbaudes gadījumi tiek izpildīti lietotāja saskarnē un datu bāzē.
- Izveidojiet pasūtījumu ar vienu vienumu -
- Lietotājs atver vietni.
- Dodas veikt pasūtījumu.
- Atlasa derīgu produktu un daudzumu un saglabā pasūtījumu.
- Jāparāda ziņojums, ka pasūtījums ir veiksmīgi noformēts.
- Lietotājs atver datu bāzi un pārbauda, vai pasūtījuma informācija ir tāda pati kā ievadītā vietnē.
3) līmenis līdz galam
Biznesa plūsmas un lietošanas gadījumi tiek izpildīti lietotāja saskarnē.
- Izveidojiet pasūtījumu ar vairākiem vienumiem -
- Lietotājs atver vietni.
- Dodas veikt pasūtījumu.
- Jautājumi par derīgu produktu un daudzums tiek pievienots grozam.
- Citi derīgi produkti tiek pievienoti ar derīgiem daudzumiem, un pasūtījums tiek saglabāts. Maksājums tiek veikts, izmantojot jaunu maksājuma veidu, un tiek veikts pasūtījums.
- Būtu jāparāda ziņojums "Pasūtījums veiksmīgi veikts".
- Testētājam ir jāpārbauda, vai visa plūsma tiek veikta bez datu izkropļošanas.
Secinājums:
Ieskicējot pareizo testēšanas stratēģiju, resursus, rīkus un atbilstību, lai nodrošinātu labu servisu, SOA testēšana var nodrošināt pilnīgi un nevainojami pārbaudītu lietojumprogrammu.