Meni

Korištenje JSON-a za testiranje sučelja

using json interface testing

Isprobajte Naš Instrument Za Uklanjanje Problema

Korištenje JSON-a za testiranje sučelja:

Testiranje sučelja provjerava komunikaciju između dva različita sustava. Izvodi se na testiranoj aplikaciji kako bi se provjerilo je li komunikacija između dviju mreža ispravno izvedena.

Sučelje je u osnovi veza između dva softverska sustava i testiranje te veze za prijenos podataka naziva se ispitivanje sučelja. Sučelje pokriva širok spektar usluga u stvarnom svijetu, može se koristiti za upućivanje na web uslugu, API itd.

Ispitivanje sučelja

Sučelje sadrži skup pravila, poruka, naredbi itd. Koje olakšavaju komunikaciju između dva sustava.

Ovo se ispitivanje uglavnom koncentrira na ispitivanje dva glavna segmenta:

  • Komunikacija baze podataka i poslužitelja aplikacija
  • Komunikacija s webom i aplikacijskim poslužiteljem

Ispitivanje sučelja provodi se za procjenu gore spomenutih scenarija kako bi se provjerilo jesu li komponente ispravno međusobno prosljeđivale kontrolu i podatke. Također provjerava interakciju između različitih modula.

Što ćete naučiti:

Zašto se provodi ispitivanje sučelja?

Izvodi se kako bi se osiguralo:

  • IIako se komunikacija između sustava vrši pravilno.
  • Sav softver i hardver koji se koriste u sustavu rade ispravno.
  • Svi dokumenti koji su povezani s komunikacijom dostupni su na svim integriranim platformama.
  • Zahtjevi sigurnosti i šifriranja pridržavaju se komunikacije između sustava.
  • Integrirane komponente sposobne su se nositi s mrežnim kvarovima i gubitkom komunikacije.

Vrste pronađenih nedostataka

Većina nedostataka pronađenih u testiranju korisničkog sučelja posljedica je pogrešnog mapiranja podataka između sustava. Stoga se većina bugova u osnovi može klasificirati u sljedeće kategorije.

  • Nedosljedan prijenos podataka između dva sustava.
  • Jedan od sustava pogrešno tumači prijenos podataka iz drugog sustava.
  • Kanal za prijenos ili sučelje između dva sustava ne uspijevaju, a to ograničava prijenos podataka između sustava, što uzrokuje neuspjeh cijelog sučelja.

Kako se izvodi?

Može se uglavnom kategorizirati u sljedeće faze:

  • Sučelja se mogu pojedinačno testirati tijekom ispitivanje sustava . Ova vrsta ispitivanja uglavnom se provodi pomoću kliznog ili lažnog sustava. Lažni sustav ili klica oponašaju ponašanje čitavog sustava.
  • Sljedeća je instanca u kojoj se provodi ispitivanje sučelja spoj na kojem dva sustava međusobno komuniciraju.
  • Stoga testiramo jesu li podaci koje je poslao jedan sustav pravilno mapirani i umetnuti u drugi sustav ili ne. Osim umetanja podataka, također provjeravamo cjelovitost podataka, tj. Podacima kada se ubace u drugi sustav, nije manipulirano ili promijenjeno itd.
  • Testiranje se može provesti i kada sustav prenosi podatke u drugu bazu podataka aplikacija. Ovdje ćemo testirati jesu li podaci iz jednog sustava ispravno umetnuti u zadani stupac dane tablice na temelju mapiranja. Također ćemo testirati cjelovitost podataka i njihovu dosljednost u odnosu na izvorni sustav.

U svim ovim scenarijima ispitivanja, ispitivanje sučelja vrši se na temelju poslovnih zahtjeva i pravila poslovnog toka.

Razlika između ispitivanja sučelja i testiranja integracije

Pozvani su provjera i provjera funkcionalnosti od kraja do kraja komponenata povezanih zajedno Integracijsko ispitivanje ili popularnije kao testiranje integracije sustava. Integracijsko testiranje uglavnom potvrđuje jesu li dva ili više integriranih sustava radili besprijekorno ili ne.

Testiranje Sučelje s druge strane u osnovi se koncentrira na kanal veze između dva sustava. Kanal veze između dva ili više sustava naziva se sučelje. Ispitivanje ovog kanala veze naziva se ispitivanje sučelja. Većina sučelja su API ili web usluge. Nema korisničko sučelje, ali uzima ulaz i daje korisniku izlaz.

Na primjer

Ispitivanje sučelja

U gornjem primjeru web stranica i baza podataka dijele sučelje za prijenos podataka za prijavu, tj. Korisničko ime i lozinku.

Sučelje koristi web uslugu za slanje podataka za prijavu u bazu podataka, što zauzvrat provjerava autentičnost dolazne poruke (korisničko ime i lozinka) i vraća vrijednost kao true ako se i korisničko ime i lozinka podudaraju sa zapisom koji se nalazi u bazi podataka ili false u slučaju da se bilo koji od njih ili korisničko ime i lozinka ne podudaraju s podacima koji se nalaze unutra.

Razgovarajmo o primjeru ispitivanja sučelja:

Recimo da imamo aplikaciju u kojoj imamo različite baze podataka koje međusobno komuniciraju.

U ovome primjer , razmotrit ćemo dvije interakcije baze podataka putem kanala sučelja.

Uzmimo u obzir da postoje dvije baze podataka ili aplikacija, baza podataka A i B. 'A' prenosi neke podatke u 'B', koju B zatim koristi za izvođenje neke operacije. Nakon izvođenja određene radnje na dolaznim podacima B ubacuje te podatke u bazu podataka i stvara izlazni JSON za potvrdu s popisom ažuriranih podataka i šalje ga natrag A.

I A i B koriste kanal sučelja za međusobnu komunikaciju.

Poslovni scenarij

'A' sadrži podatke o zaposlenicima za sve zaposlenike koji pripadaju financijskom odjelu.

Podatke treba prenijeti na „B ' svakodnevno. “B” sadrži podatke o općim detaljima zaposlenika. Svi podaci iz 'A' trebaju se prenijeti u određenu tablicu i stupac 'B'. Osim unosa podataka, 'B' također mora sortirati i organizirati podatke. Također mora biti siguran jesu li podaci uneseni protiv ispravnog zaposlenika.

Jednom kada su podaci uneseni u sustav, 'B' treba poslati izlazni JSON kako bi potvrdio jesu li podaci umetnuti u bazu podataka.

U slučaju bilo kakvih odstupanja u JSON shemi ili nedostajućih podataka, 'B' neće obrađivati ​​podatke i poslat će poruku Odbiti JSON s razlogom odbijanja.

Poslovni scenarij ispitivanja sučelja

Ispitajte postavke okruženja

Da bismo testirali scenarij poput ovog, trebat će nam testni krad koji oponaša bazu podataka 'A'. Razvojni programer može pružiti mjesto na kojem možete izbaciti svoj testni JSON ili lažni korisnički interfejs i zalijepiti svoje JSON podatke i pozvati obradu kroz sučelje. Za potrebe testiranja možemo imati i izlazno mjesto na kojem možemo dobiti potvrdu JSON od 'B'.

U našem primjer , koristit ćemo put do mape gdje ćemo staviti naš testni JSON, usluga će neprestano probijati mjesto za JSON datoteku. Jednom kada datoteka postoji, usluga će je preuzeti i poslati na 'B' putem sučelja. Nakon što je datoteka preuzeta, ona će se izbrisati s mjesta preuzimanja.

Početak testiranja

Nakon postavljanja testnog okruženja, sljedeći je korak stvaranje testnih podataka.

Tijekom stvaranja testnih podataka (pročitajte testni JSON) trebali bismo imati na umu nekoliko stvari:

  • Slijedite poslovna pravila.
  • Obavezno popunite polja.
  • Promijenite vrijednost polja prema poslovnim pravilima za svaki test.
  • Provjerite je li JSON shema u ispravnom formatu.
  • Provjerite je li pridržana nomenklatura za naziv datoteke JSON.

Pogledajmo uzorak testa JSON koji ćemo koristiti za testiranje:

{ 'employeeID ': 2569875, 'LastName': “Jackson”, 'baseSalary': 2569, 'DesignationCode':'P102', “Expenditure”:{ 'Month':“Feb”, 'Year': 2017, 'Official':560, 'Others”:0, } }

Započnite svoj test

Nakon što stvorite svoju testnu JSON datoteku, odbacite je na mjesto za preuzimanje. Služba će to preuzeti i poslati u bazu podataka B.

Scenariji za testiranje:

Postoji nekoliko scenarija koje treba testirati za ovaj primjer, poput:

  • Rad s web uslugom za slanje i primanje podataka.
  • Integritet podataka za ulazne podatke. To se može provjeriti ispitivanjem tablica i stupaca u bazi podataka B za podatke unesene kroz testni JSON.
  • Negativni scenariji.

Isprva ćemo provjeriti je li testna JSON datoteka preuzeta s lokacije ili nije prisutna na lokaciji. Ovo će potvrditi rad službe. Dalje ćemo prijeći na izlaznu mapu kako bismo pogledali izlazni JSON. Prisutnost izlaza JSON provjerava je li ulazni podatak poslan u bazu podataka B i primljena potvrda za isti.

Sljedeći dio testiranja sastoji se od provjere valjanosti podataka unesenih u bazu podataka.

U gore navedenom testu provjerit ćemo jesu li podaci poslani putem testnog JSON-a ispravno unijeti u bazu podataka. Provjerit ćemo cjelovitost podataka, njihovu dosljednost i umetanje. Morat ćemo zatražiti bazu podataka B za zadani stupac u određenoj tablici kako bismo provjerili je li podatak ispravno umetnut u tablicu.

Recimo da imamo tablicu EmpDetails u koju se moraju umetnuti podaci. Dakle, pokrenut ćemo upit za provjeru valjanosti podataka.

Upit će biti otprilike ovakav:

SELECT employeeID, LastName, baseSalary, DesignationCode, Month, Year, Official, Others FROM EmpDetails Where employeeID = 2569875;

Ovdje ćemo upotrijebiti id zaposlenika kao primarni ključ za upite podataka u tablici EmpDetails. Upit ćemo izvršiti koristeći sve nazive stupaca u koje su umetnuti podaci. Tada se podaci u nazivu stupca mogu provjeriti valjanošću podataka poslanih putem JSON-a.

U gore navedenom slučaju podaci iz JSON-a pohranjuju se u više tablica baze podataka, stoga možete koristiti SQL JOINS za dohvaćanje svih željenih podataka.

Treći korak u testiranju bit će testiranje negativnih scenarija.

Neki od negativnih scenarija koji se mogu testirati su:

  • Ponašanje sustava kada se putem JSON-a unose netočni podaci.
  • Kada JSON ima pogrešnu shemu ili strukturu.
  • Kada obrađenom JSON-u nedostaje primarni ključ ili neko obavezno polje.
  • Nomenklatura JSON datoteke nije važeća.

U svim tim slučajevima, sustav bi trebao biti u mogućnosti obrađivati ​​ove scenarije i ne bi se trebali unositi podaci u sustav prema poslovnom pravilu.

Zaključak

Kanal veze između dvaju sustava putem kojih se prenose podaci naziva se sučeljem i ispitivanje sučelja uglavnom djeluje oko testiranja tih veza. Većina sučelja koristi web usluge ili API-je. Ne sadrži uvijek korisničko sučelje, ali prihvaća ulaz i daje izlaz.

pitanja i odgovori na intervjuu za osiguranje kvalitete

Kao jedan od najčešće korištenih formata prijenosa podataka, JSON se može koristiti za prijenos podataka putem sučelja.

Tester mora imati osnovno znanje o JSON strukturi za stvaranje testnih podataka (u obliku JSON-a) i čitanje izlaznih podataka iz sustava. Tester bi također trebao biti dobro upućen u mapiranje između JSON ključeva i stupca tablice baze podataka.

Svaki ispitivač koji želi raditi na testiranju sučelja trebao bi imati jasno znanje o poslovnim smjernicama i pravilima aplikacije. Tester bi također trebao imati odgovarajuće znanje o bazi podataka i trebao bi biti u stanju pisati jednostavne SQL upite.

Za bilo kakva pitanja ili pojašnjenja, kontaktirajte nas u odjeljku za komentare.

Vodič br. 5: Pitanja za intervju za JSON

Preporučena literatura

^