Mitä SOA-testaus on? Opetusohjelma esimerkin kanssa

⚡ Älykäs yhteenveto

SOA-testaus validoi palvelukeskeisen ArchiRakenne, jossa löyhästi kytketyt palvelut vaihtavat viestejä verkon yli tarkistaen jokaisen palvelun erikseen, niiden väliset integraatiot ja koko liiketoimintavirran päästä päähän.

  • 🔘 Archirakenne: Palvelut ovat uudelleenkäytettäviä liiketoimintafunktioita, joita mikä tahansa sovellus voi kutsua, koota tai korvata itsenäisesti.
  • ☑️ Tasot: Testaus kohdistuu sovelluksen palvelukerrokseen, prosessikerrokseen ja kuluttajakerrokseen.
  • Tasot: Palvelutaso-, rajapinta- ja kokonaisvaltainen testaus yhdessä kattavat haitattracts, tietovirta ja liiketoimintaskenaariot.
  • 🧪 Menetelmät: Skenaariopohjaista datatestausta, tynkätestejä, toiminnallisuus-, tietoturva-, suorituskyky-, integraatio- ja regressiotarkistuksia sovelletaan jokaisella tasolla.
  • 🛠️ työkalut: SoapUIBroadcomin palveluvirtualisointi OpenText UFT One ja Parasoft SOAtest kattavat toiminnallisen, virtuaalisen ja kuormitustestauksen.
  • ⚠️ haasteet: Puuttuvat rajapinnat, monikerroksiset vikojen eristysmenetelmät, arvaamaton kuormitus ja heterogeeniset teknologiat nostavat suunnittelukustannuksia.

SOA-testaus

Mitä SOA-testaus on?

SOA (palvelukeskeinen Archirakenne) Testaus on SOA-arkkitehtuurityylin testausta, jossa sovelluskomponentit on suunniteltu kommunikoimaan tietoliikenneprotokollien kautta, tyypillisesti verkon yli.

Mikä on SOA?

SOA on tapa integroida liiketoimintasovelluksia ja prosesseja yhteen vastaamaan liiketoiminnan tarpeita.

In OhjelmistotuotantoSOA tuo ketteryyttä ja joustavuutta liiketoimintaprosesseihin. Prosessin tai sovelluksen muutos voidaan kohdistaa tiettyyn komponenttiin vaikuttamatta koko järjestelmään.

SOA-ympäristössä työskentelevät ohjelmistokehittäjät joko kehittävät tai ostavat ohjelmapaloja, joita kutsutaan palvelut.

Mitä Palvelu on?

Alla oleva kaavio näyttää maksuyhdyskäytävän, joka on julkaistu palveluna, johon useat verkkokauppasivustot voivat kutsua.

Maksuyhdyskäytävä, joka on julkaistu uudelleenkäytettävänä SOA-palveluna, jota verkkokauppasovellus kutsuu

  • Palvelu voi olla sovelluksen tai liiketoimintaprosessin toiminnallinen yksikkö, jota mikä tahansa muu sovellus tai prosessi voi käyttää uudelleen tai toistaa. (Esimerkiksi yllä olevassa kuvassa maksuyhdyskäytävä on palvelu, jota mikä tahansa verkkokauppasivusto voi käyttää uudelleen. Aina kun maksu on suoritettava, verkkokauppasivusto kutsuu tai pyytää maksuyhdyskäytäväpalvelua. Kun maksu on suoritettu yhdyskäytävässä, vastaus lähetetään takaisin verkkokauppasivustolle.)
  • Palvelut on helppo koota ja komponentit on helppo konfiguroida uudelleen.
  • Palveluita voidaan verrata rakennuspalikoihin. Ne voivat rakentaa minkä tahansa tarvittavan sovelluksen, ja niiden lisääminen tai poistaminen sovelluksesta tai liiketoimintaprosessista on helppoa.
  • Palvelut määritellään enemmän niiden suorittaman liiketoimintafunktion kuin koodipätkien perusteella.

Web Services

Useimmat SOA-palvelut ovat web-palveluita, joten web-palvelukutsun mekaniikka kannattaa esitellä ennen testikerroksia.

Verkkopalvelu, joka toimii itsenäisenä sovelluskomponenttina ja on saatavilla verkon kautta

Web-palvelut ovat itsenäisiä sovelluskomponentteja, jotka ovat saatavilla verkossa.

Ne voidaan julkaista, löytää ja käyttää verkossa, ja ne kommunikoivat internetin kautta. Alla oleva sekvenssi osoittaa, miten palveluntarjoaja, rekisteri ja kuluttaja ovat vuorovaikutuksessa keskenään.

Julkaise, etsi ja sitoo sekvenssin palveluntarjoajan, verkkopalvelurekisterin ja kuluttajan välillä

  • Palveluntarjoaja julkaisee palvelun Internetissä.
  • Asiakas etsii tiettyä verkkopalvelua verkkopalvelurekisteristä.
  • A URL ja wsdl palautetaan vaaditulle verkkopalvelulle. Käyttämällä WSDL:ää ja URLPalveluntarjoajan ja pyytäjän välinen viestintä tapahtuu SOAP-viestien kautta.
  • Kun kuluttaja kutsuu verkkopalvelua, palveluntarjoajaan muodostetaan HTTP-yhteys.
  • SOAP-viesti luodaan ohjeistamaan palveluntarjoajaa käynnistämään vaadittu verkkopalvelulogiikka.
  • Palveluntarjoajalta vastaanotettu vastaus on SOAP-viesti, joka on upotettu HTTP-vastaukseen. Tämä HTTP-vastaus on kuluttajasovelluksen ymmärtämässä tietomuodossa.

esimerkki

Alla olevassa kuvakaappauksessa näkyy ulkoisen palvelun toimittama ja hakukoneen kotisivulle upotettu sääraportti.

Sääraporttipalvelu, joka ostetaan myyjältä ja upotetaan verkkosivuston etusivulle

Verkkosivuston etusivulla ja hakukoneessa näytetään päivittäinen säätiedotus. Sen sijaan, että säätiedotusosio koodattaisiin alusta alkaen, säätiedotuspalvelu voidaan ostaa toimittajalta ja integroida sivuille.

SOA-testauskerrokset

SOA koostuu useista eri teknologioista, ja SOA:lla rakennetuilla sovelluksilla on erilaisia ​​palveluita, jotka ovat löyhästi kytköksissä toisiinsa. Alla oleva kaavio kuvaa kolmea tasoa, jotka testaussuunnitelman on katettava.

Kolme SOA-testauskerrosta pinottuina palvelukerrokseksi, prosessikerrokseksi ja kuluttajakerrokseksi

SOA-testauksen tulisi keskittyä kolmeen järjestelmäkerrokseen.

Palvelutaso

Tämä kerros koostuu järjestelmän tarjoamista palveluista, jotka on johdettu liiketoimintatoiminnoista.

Tarkastellaan esimerkiksi hyvinvointisivustoa, joka koostuu seuraavista osista:

  • Paino Tracker
  • Verensokeri Tracker
  • Verenpaine Tracker

TracKerros näyttää vastaavat tiedot ja niiden syöttöpäivämäärän. Palvelukerros koostuu palveluista, jotka hakevat vastaavat tiedot tietokannasta:

  • Paino Tracker-palvelu
  • Verensokeri Tracker-palvelu
  • Verenpaine Tracker-palvelu
  • Kirjautumispalvelu

Prosessikerros

Prosessikerros koostuu prosesseista eli kokoelmasta palveluita, jotka ovat osa yhtä toiminnallisuutta.

Prosessit voivat olla osa käyttöliittymää (esimerkiksi hakukonetta) tai osa ETL-työkalua, joka hakee tietoja tietokannasta.

Tämän kerroksen pääpaino on käyttöliittymissä ja prosesseissa. Painon käyttöliittymä tracker ja sen integrointi tietokantaan on ensisijainen painopiste.

Seuraavat toiminnot ovat huomionarvoisia:

  • Uusien tietojen lisääminen
  • Muokkaa olemassa olevia tietoja
  • Uuden luominen tracker
  • Tietojen poistaminen

Kuluttajakerros

Tämä kerros koostuu pääasiassa käyttöliittymistä, kuten alla oleva näyttökuva havainnollistaa.

Hyvinvointisivuston kuluttajakerroksen käyttöliittymä, joka kutsuu pohjana olevaa toimintoa tracker-palvelut

Näiden kerrosten perusteella SOA-sovelluksen testaus jaetaan kolmeen tasoon:

  • Palvelutaso
  • Liitäntätaso
  • Päästä loppuun tasolle

Kaksi etenemissuuntaa eroavat toisistaan: testien suunnittelussa käytetään ylhäältä alas -lähestymistapaa, kun taas testien suorituksessa käytetään alhaalta ylös -lähestymistapaa.

SOA-testauksen strategia

Testaussuunnittelun lähestymistapa

  • SOA-testaajien tulisi ymmärtää sovelluksen koko arkkitehtuuri.
  • Sovellus on jaettava itsenäisiin palveluihin (palvelu, jolla on oma pyyntö- ja vastausrakenteensa eikä se ole riippuvainen mistään muusta palvelusta vastauksen muodostamiseksi).
  • Sovellusrakenne on järjestettävä uudelleen kolmeen osaan: dataan, palveluihin ja käyttöliittymäsovelluksiin.
  • Kaikki osatekijät on analysoitava huolellisesti ja liiketoimintaskenaariot on hahmoteltava.
  • Liiketoimintaskenaariot tulisi luokitella yleisiin skenaarioihin ja sovelluskohtaisiin skenaarioihin.
  • A Tracsuorituskykymatriisi tulee valmistella, ja kaikki testitapaukset tulee olla tracliiketoimintaskenaarioihin.

Testin suorittamisen lähestymistapa

  • Jokainen palvelukomponentti tulee testata.
  • Integraation testaus Palvelukomponentit tulisi tehdä palvelujen läpi kulkevan tietovirran ja tietojen eheyden validoimiseksi.
  • Järjestelmän testaus Koko mallin testaus tulisi tehdä käyttöliittymäsovelluksen ja tietokannan välisen tiedonkulun validoimiseksi.
  • Suorituskykytestaus tulee tehdä hienosäätöä ja optimaalista suorituskykyä varten.

SOA-testausmenetelmät

1) Liiketoimintaskenaarioihin perustuva dataan perustuva testaus

  • Järjestelmään liittyviä erilaisia ​​liiketoimintaan liittyviä näkökohtia tulisi analysoida.
  • Skenaarioita tulisi kehittää sovelluksen eri verkkopalveluiden ja verkkopalveluiden ja sovelluksen välisen integroinnin perusteella.
  • Datan määritys tulisi tehdä yllä olevien skenaarioiden perusteella.
  • Datan kokoonpanon tulisi kattaa myös kokonaisvaltaiset skenaariot.

2) Tyngät

  • Palveluiden testaamista varten luodaan valerajapintoja.
  • Näiden liitäntöjen kautta voidaan tarjota erilaisia ​​tuloja, ja lähdöt voidaan validoida.
  • Kun sovellus käyttää rajapintaa ulkoiseen palveluun, jota ei testata parhaillaan (kolmannen osapuolen palvelu), integraatiotestauksen aikana voidaan luoda tynkä.

3) Regressiotestaus

  • Regressiotestaus sovelluksessa tulisi tehdä, kun julkaisuja on useita, järjestelmien vakauden ja saatavuuden varmistamiseksi.
  • Luodaan kattava regressiotestipaketti, joka kattaa sovelluksen tärkeän osan muodostavat palvelut.
  • Tätä testipakettia voidaan käyttää uudelleen useissa projektin julkaisuissa.

4) Palvelutason testaus

Palvelutasotestaus sisältää komponentin toiminnallisuuden, turvallisuuden, suorituskyvyn ja yhteentoimivuuden testaamisen. Jokainen palvelu on testattava ensin erikseen.

5) Toiminnallinen testaus

Toiminnallinen testaus tulisi tehdä jokaiselle palvelulle seuraavasti:

  • Varmista, että palvelu vastaa jokaiseen pyyntöön oikein.
  • Varmista, että vastaanotetaan oikeat virheilmoitukset pyynnöistä, jotka sisältävät virheellisiä tai huonoja tietoja.
  • Tarkista jokainen pyyntö ja vastaus jokaiselle toiminnolle, joka palvelun on suoritettava suorituksen aikana.
  • Vahvista vikailmoitukset, kun palvelimella, asiakasohjelmassa tai verkossa tapahtuu virhe.
  • Tarkista, että saadut vastaukset ovat oikeassa muodossa.
  • Varmista, että vastauksessa vastaanotetut tiedot vastaavat pyydettyjä tietoja.

6) Turvallisuustestaus

Verkkopalvelun tietoturvatestaus on tärkeä osa SOA-sovelluksen palvelutasotestausta, koska se varmistaa sovelluksen turvallisuuden.

Testauksen aikana on otettava huomioon seuraavat tekijät:

  • Verkkopalvelun tulisi noudattaa WS-Securityn määrittelemää alan standardia.
  • Turvatoimenpiteiden tulee toimia moitteettomasti.
  • Tietojen salaus ja digitaaliset allekirjoitukset asiakirjoissa.
  • Todennus ja valtuutus.
  • SQL-injektio, haittaohjelmat, XSS, CSRF ja muut haavoittuvuudet testataan XML.
  • Palvelunestohyökkäykset.

7) Suorituskykytestaus

Palvelun suorituskykytestaus on tehtävä, koska palvelut ovat uudelleenkäytettäviä ja useat sovellukset saattavat käyttää samaa palvelua.

Seuraavat tekijät otetaan huomioon testin aikana:

  • Palvelun suorituskykyä ja toimivuutta on testattava raskaassa kuormituksessa.
  • Palvelun suorituskykyä on verrattava, kun se toimii yksinään ja kun se on kytketty sovelluksen sisällä.
  • Kuormitustestaus Palvelun testaus tulisi suorittaa vasteajan varmistamiseksi, pullonkaulojen tarkistamiseksi, suorittimen ja muistin käyttöasteen varmistamiseksi sekä skaalautuvuuden ennustamiseksi.

8) Integraatiotason testaus

  • Palvelutasotestaus varmistaa yksittäisten palveluiden moitteettoman toiminnan; se ei takaa kytkettyjen komponenttien toimivuutta.
  • Integraatiotestausta tehdään keskittyen pääasiassa rajapinnat.
  • Tämä vaihe kattaa kaikki mahdolliset liiketoimintaskenaariot.
  • Sovelluksen ei-toiminnallinen testaus tulisi tehdä vielä kerran tässä vaiheessa. Tietoturva-, vaatimustenmukaisuus- ja suorituskykytestaus varmistavat järjestelmän saatavuuden ja vakauden kaikilta osin.
  • Viestintä- ja verkkoprotokollia tulisi testata palvelujen välisen tiedonsiirron johdonmukaisuuden varmistamiseksi.

9) End to End -testaus

Tässä vaiheessa varmistetaan, että sovellus täyttää liiketoimintavaatimukset sekä toiminnallisesti että ei-toiminnallisesti.

Alla olevat kohteet testataan varmasti testauksen aikana end-to-end-testaus:

  • Kaikki palvelut toimivat odotetusti integroinnin jälkeen
  • Poikkeusten käsittely
  • Sovelluksen käyttöliittymä
  • Oikea tiedonkulku kaikkien komponenttien läpi
  • Liiketoimintaprosessi

SOA-testauksen haasteet

Näiden menetelmien soveltaminen on harvoin suoraviivaista, ja alla olevat vaikeudet toistuvat lähes jokaisessa SOA-ohjelmassa.

  • Palveluiden rajapintojen puute.
  • Testausprosessi kattaa useita järjestelmiä, mikä luo monimutkaisia ​​datatarpeita.
  • Sovellus on kokoelma erilaisia ​​komponentteja, jotka yleensä muuttuvat, joten regressiotestausta tarvitaan useammin.
  • Monikerroksisen rakenteen vuoksi vikojen eristäminen on vaikeaa.
  • Koska palvelua käyttävät useat eri rajapinnat, kuormitusta on vaikea ennustaa, mikä tekee suorituskykytestien suunnittelusta hankalaa.
  • SOA on kokoelma heterogeenisiä teknologioita. SOA-sovelluksen testaaminen vaatii ihmisiä, joilla on erilaisia ​​taitoja, mikä puolestaan ​​lisää suunnittelu- ja toteutuskustannuksia.
  • Koska sovellus integroi useita palveluita, tietoturvatestauksessa on omat ongelmansa. Todennuksen ja valtuutuksen validointi on vaikeaa.

SOA-testaustyökalut

Markkinoilla on saatavilla monia SOA-testaustyökaluja, jotka auttavat testaajia SOA-sovellusten testaamisessa. Tässä on joitakin suosituimmista SOA-testaustyökaluista.

1) SoapUI

SoapUI on avoimen lähdekoodin toiminnallinen testaustyökalu palveluille ja API-testaus.

  • Työpöytäsovellus
  • Tukee useita protokollia — SOAP, REST, HTTP, JMS, AMF, JDBC
  • Verkkopalveluita voidaan kehittää, tarkastaa ja kutsua.
  • Voidaan käyttää myös kuormitustestaukseen, Automaatiotestausja turvatestaukset
  • MockServices voi luoda tyngät
  • Verkkopalvelupyynnöt ja -testit voidaan luoda automaattisesti sen verkkopalveluasiakasohjelman kautta.
  • Sisäänrakennetut raportointityökalut
  • SmartBearin kehittämä, joka toimittaa molemmat avoimen lähdekoodin SoapUI jakelu ja kaupallinen ReadyAPI painos

2) Broadcom-palveluvirtualisointi (aiemmin iTKO LISA)

LISA on tuotepaketti, joka tarjoaa toiminnallisen testausratkaisun hajautetuille järjestelmille, kuten SOA:lle. Tuote siirtyi iTKO:lta CA Technologiesille, ja sitä myydään nykyään nimellä Broadcom Service Virtualization.

  • Voidaan käyttää myös regressio-, integrointi-, kuormitus- ja suorituskykytestaukseen.
  • Voidaan käyttää testien suunnitteluun ja suorittamiseen.

3) UFT Yksi (aiemmin HP:n huoltotesti)

Service Test on toiminnallinen testaustyökalu, joka tukee sekä käyttöliittymän että jaettujen palveluiden testausta. Sen API-testausominaisuudet liitettiin osaksi Unified Functional Testingiä, jota nyt myy OpenText as UFT Yksi.

  • Palveluiden sekä toiminnalliset että suorituskykytestit voidaan tehdä yhdellä skriptillä.
  • Integroitu Quality Centerin kanssa, myydään nyt nimellä OpenText ALM / Laatukeskus.
  • Valtava määrä palveluita ja dataa voidaan hallita.
  • Tukee yhteentoimivuuden testausta simuloimalla JEE-, AXIS- ja DotNet-asiakasympäristöjä.

4) Parasoft SOAtest

Parasoft SOAtest on testaus- ja analysointityökalupaketti, joka on kehitetty API-rajapintoihin ja API-pohjaiseen sovellustestaukseen.

  • Tukee web-palveluita, REST-, JSON-, MQ-, JMS-, TIBCO-, HTTP- ja XML-teknologioita.
  • Toiminnallinen testaus, yksikkötestaus, integraatiotestaus, regressiotestaus, tietoturvatestaus, yhteentoimivuustestaus, vaatimustenmukaisuustestaus ja suorituskykytestaus ovat mahdollisia.
  • Tyngät voidaan luoda käyttämällä Parasoft Virtualisointi, jotka ovat kykenevämpiä kuin SoapUI MockServices.

SOA-testauksen käyttötapaukset

Alla oleva esimerkki soveltaa yllä olevaa strategiaa, menetelmiä ja työkaluja yhteen verkkokauppasivustoon vaihe vaiheelta.

Tarkastellaan verkkokauppasivustoa, joka sisältää alla olevat toiminnot ja alitoiminnot.

Tilausta Käsitellään

Alla oleva kaavio jakaa tilausten käsittelyn alitoimintoihin, joista tulee palveluita.

Tilausten käsittely jaettuna alitoimintoihin, kuten tilauksen luominen, varaston tarkistaminen ja tilauksen tilan muuttaminen

PHASE 1

SOA-testauksen ensimmäisessä vaiheessa, testausstrategiavaiheessa, sovellus jaetaan palveluihin ja liiketoimintatoimintoihin.

Tarkastellaan alla olevia palveluita sovelluksessa.

  • Luo tilaus
  • Tarkista asiakkaan tila
  • Muuta tilauksen tilaa
  • Tarkista tilauksen tila
  • Tarkista varasto

Liiketoimintatoiminnot ovat samat kuin verkkosivuston toiminnot.

Huomautus: Testausstrategia-asiakirja sisältää luettelon testattavista palveluista ja toiminnoista.

PHASE 2

Tämä on testisuunnitteluvaihe. Testata tapauksia on kirjoitettu kullekin tasolle.

Päästä päähän -taso. Testitapaukset kirjoitetaan kullekin liiketoiminnan käyttötapaukselle ja työnkululle. Alla on esimerkkejä testitapauksista.

  • Luo tilaus aktiivisella käyttäjällä.
  • Luo tilaus passiivisen käyttäjän kanssa.
  • Luo tilaus saatavilla olevalla tuotteella, jonka tilausmäärä on < saatavilla oleva määrä.
  • Luo tilaus saatavilla olevalla tuotteella, jonka tilausmäärä on > saatavilla oleva määrä.
  • Luo tilaus, jossa on useita tuotteita.
  • Peruuta tilaus kokonaan.
  • Peruuta tilaus osittain.

Integraatiotaso. Testitapaukset kirjoitetaan tietokannan ja käyttöliittymän integrointia varten. Alla on esimerkkejä testitapauksista.

  • Luo uusi tilaus yhdellä tuotteella. Varmista, että tilaus on luotu tietokantaan.
  • Luo uusi tilaus yhdellä tuotteella. Varmista, että tilaukselle laskettu hinta on oikea.
  • Luo uusi tilaus yhdellä tuotteella. Varmista, että tilauksen summa on vähennetty saatavilla olevan tuotteen määrästä.
  • Varmista, että käyttöliittymässä näkyvä tilauksen tila on sama kuin tietokannassa.
  • Peruuta tilaus ja varmista, että tilauksen tilaa on muutettu tietokannassa.
  • Ensimmäisellä maksukerralla varmista, että käyttöliittymään syötetyt maksutiedot on tallennettu tietokantaan.
  • Palauta maksuja varten, että tietokannan maksutiedot näkyvät käyttöliittymässä.

Palvelutaso. Jokainen palvelu testataan kaikkien dataehtojen osalta. Alla on muutamia esimerkkejä.

Ei. tilauksen tiedot Tilauksen kunto
1 Luo tilaus. Tuotteiden lukumäärä = 1 Tilausmäärä < Määrä tietokannassa
2 Luo tilaus. Kohteiden määrä > 1 Tilauksen määrä < tietokannan määrä
3 Luo tilaus. Tuotteiden lukumäärä = 1 Määrä tilauksessa > Määrä tietokannassa
4 Tarkista tilauksen tila Tila tietokannassa = aktiivinen
5 Tarkista tilauksen tila Tila tietokannassa = Lähetetty
6 Tarkista tilauksen tila Tila tietokannassa = Peruutettu
7 Tarkista tilauksen tila Tilaustunnus = Virheellinen
8 Tarkista tuotteen saatavuus Tuotteen määrä >0
9 Tarkista tuotteen saatavuus Tuotteen määrä =0
10 Tarkista tuotteen saatavuus Tuotetunnus = virheellinen

VAIHE 3 — Testien suorittaminen

Testien suorituksessa käytetään alhaalta ylöspäin suuntautuvaa lähestymistapaa: ensin tehdään palvelutason testaus, sitten integraatiotason testaus ja lopuksi kokonaisvaltainen testaus.

1) Palvelutaso

Tarkastellaanpa sitä, että SoapUI työkalua käytetään sovelluksen testaamiseen. WSDL ja URL selataan testi-ikkunaan SoapUI, ja kunkin palvelun pyyntö näytetään pyyntöikkunassa. Muokkaamalla tietoja palvelutason testitapausten mukaisesti, jokaiselle testitapaukselle luodaan pyynnöt.

Testitapaus Pyydä Odotettu vastaus
Luo tilaus. Tuotteiden lukumäärä = 1, tilauksen määrä < tietokannan määrä x2 2 o3251 Onnistui
Luo tilaus. Tuotteiden lukumäärä > 1, tilauksen määrä < tietokannan määrä y1 1 y2 3 o3251 Onnistui
Luo tilaus. Tuotteiden lukumäärä = 1, tilauksen määrä > tietokannan määrä x23 200 tyhjä Epäonnistui
Tarkista tilauksen tila. Tila tietokannassa = Aktiivinen o9876 Aktiivinen Onnistunut
Tarkista tilauksen tila. Tila tietokannassa = Lähetetty o9656 Lähetetty Onnistunut
Tarkista tilauksen tila. Tilaustunnus = Virheellinen y5686 tyhjä Epäonnistunut
Tarkista tuotteen saatavuus. Tuotteiden määrä >0 d34 34 Joo Onnistui
Tarkista tuotteen saatavuus. Tuotteen määrä = 0 y34 0 ei Onnistui
Tarkista tuotteen saatavuus. Tuotetunnus = virheellinen sder Epäonnistui

2) Integraatiotaso

Integrointitason testitapaukset suoritetaan käyttöliittymässä ja tietokannassa. Luo tilaus, jossa on yksi tuote:

  • Käyttäjä avaa verkkosivuston.
  • Käyttäjä menee tekemään tilauksen.
  • Käyttäjä valitsee kelvollisen tuotteen ja määrän ja tallentaa tilauksen.
  • Näyttöön pitäisi tulla viesti, jossa ilmoitetaan tilauksen onnistuneesta tekemisestä.
  • Käyttäjä avaa tietokannan ja tarkistaa, ovatko tilauksen tiedot samat kuin verkkosivustolle syötetyt tiedot.

3) Päästä loppuun tasolle

Liiketoimintavirrat ja käyttötapaukset suoritetaan käyttöliittymässä. Luo tilaus, jossa on useita tuotteita:

  • Käyttäjä avaa verkkosivuston.
  • Käyttäjä menee tekemään tilauksen.
  • Käyttäjä tiedustelee kelvollista tuotetta ja määrää ja lisää ne ostoskoriin.
  • Muut kelvolliset tuotteet ja niiden määrät lisätään ja tilaus tallennetaan. Maksu suoritetaan uudella maksutavalla ja tilaus tehdään.
  • Näyttöön tulee viesti "Tilaus tehty onnistuneesti".
  • Testaajan tulisi varmistaa, että koko prosessi sujuu virheettömästi.

UKK

Tasot ovat samat, mutta SOA-palvelut ovat karkeampia ja yleensä reititetään yrityspalveluväylän kautta, joten integraatiotestit kohdistuvat väylään. Mikropalvelut ovat hienojakoisempia ja itsenäisesti käyttöönotettavia, mikä siirtää painopisteen ominaisuuksiin.tract- ja joustavuustestaus.

kanssatract-testaus tarkistaa, että palveluntarjoaja noudattaa edelleen asiakkaidensa odottamaa pyyntö- ja vastausmuotoa, yleensä WSDL:ää tai skeemaa vasten. Se sijoittuu palvelutason ja integraatiotason väliin ja havaitsee rikkovat muutokset ennen täyttä integraatioajoa.

Käsin kirjoitettu tynkä riittää kiinteään vastaukseen. Virtualisointi on lisenssin arvoinen, kun riippuvuus on mitattu, nopeusrajoitettu tai tilallinen, koska se toistaa realistisen viiveen, virhekoodit ja datavariaation, jota staattinen tynkä ei pysty toistamaan.

Kyllä. Tasot ja kerrokset ovat protokollariippumattomia. SOAP-palvelut validoidaan WSDL- ja WS-Security-sääntöjä vasten, kun taas REST-palvelut validoidaan OpenAPI-määritelmää, tilakoodeja ja token-pohjaista todennusta vasten. Useimmat työkalupaketit käsittelevät molemmat.

Koneoppimismallit luovat pyyntöjen hyötykuormia skeemasta, luokittelevat palvelut vikahistorian perusteella siten, että regressiopaketit suoritetaan ensin riskialttiimmilla menetelmillä, ja ryhmittelevät virhevastaukset kerrosten välillä rajatakseen virheen alkuperän monikerroksisessa arkkitehtuurissa.

Copilot luonnostelee pyyntöjen hyötykuormat WSDL:stä tai skeemasta, kirjoittaa vahvistuskoodin, tukee mallipalveluita ja luo prosessin vaiheita. Testaajan on edelleen annettava liiketoimintasäännöt, negatiiviset dataehdot ja odotetut vikailmoitukset, joita malli ei pysty päättelemään.

Code Kattavuus on harvoin saatavilla heterogeenisten palveluiden välillä, joten tiimit mittaavat toiminnan kattavuutta (jokainen harjoitettu toiminto), viestin kattavuutta (jokainen vika- ja onnistumispolku) ja liiketoimintaskenaarioiden kattavuutta tractestaussuunnittelun aikana rakennetun matriisin avulla.

WSDL-, XSD- ja XML- tai JSON-hyötykuormien lukeminen, SQL-koodin kirjoittaminen datan tarkistamiseksi lepotilassa, sujuva työskentely API-asiakasohjelman kanssa ja käytössä olevan viestintäohjelmiston ymmärtäminen. Perustason komentosarjakirjoitus auttaa, koska useimmat ohjelmistopaketit automatisoidaan.

Tiivistä tämä viesti seuraavasti: