Meny

Bruker JSON for testing av grensesnitt

  • Hoved
  • Annen
  • Bruker JSON for testing av grensesnitt

using json interface testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Bruke JSON for grensesnitttesting:

Grensesnitttesting verifiserer kommunikasjonen mellom to forskjellige systemer. Det utføres på applikasjonen som testes for å verifisere om frem og tilbake kommunikasjon mellom to nettverk er riktig utført.

Et grensesnitt er i utgangspunktet forbindelsen mellom to programvaresystemer og testing av tilkoblingen for dataoverføring kalles grensesnitttesting. Grensesnittet dekker et bredt spekter av tjenester i den virkelige verden, det kan brukes til å referere til webtjeneste, API, etc.

Grensesnitttesting

Et grensesnitt inneholder et sett med regler, meldinger, kommandoer osv. Som letter kommunikasjonen mellom to systemer.

Denne testingen konsentrerer seg hovedsakelig om testing av to hovedsegmenter:

  • Database- og applikasjonsserverkommunikasjon
  • Web- og applikasjonsserverkommunikasjon

Grensesnitt test utføres for å evaluere ovennevnte scenarier for å validere om komponentene overfører kontrollen og dataene riktig til hverandre riktig. Det verifiserer også samspillet mellom forskjellige moduler.

Hva du vil lære:

Hvorfor utføres grensesnitttest?

Det utføres for å sikre:

  • IIf kommunikasjonen mellom systemene utføres riktig.
  • All programvare og maskinvare som brukes i systemet, fungerer som de skal.
  • Alle dokumentene som er knyttet til kommunikasjonen er tilgjengelige på alle integrerte plattformer.
  • Sikkerhets- og krypteringskrav overholder kommunikasjonen mellom systemene.
  • De integrerte komponentene er i stand til å håndtere nettverksfeil og kommunikasjonstap.

Typer av feil funnet

De fleste feilene som ble funnet i testingen av brukergrensesnittet, skyldes feil kartlegging av dataene mellom systemene. Derfor kan de fleste feilene i utgangspunktet klassifiseres i følgende kategorier.

  • Inkonsekvent dataoverføring mellom de to systemene.
  • Ett av systemene tolker dataoverføring fra et annet system feil.
  • Overføringskanalen eller grensesnittet mellom de to systemene mislykkes, og det begrenser dataoverføringen mellom systemene og forårsaker dermed at hele grensesnittet mislykkes.

Hvordan utføres det?

Det kan hovedsakelig kategoriseres i følgende faser:

  • Grensesnitt kan testes individuelt under systemtesting . Denne typen testing utføres hovedsakelig ved hjelp av stubbe eller dummy-system. Et dummy-system eller stub etterligner oppførselen til hele systeminteraksjonen.
  • En annen forekomst der grensesnitttesten utføres er et veikryss der to systemer kommuniserer med hverandre.
  • Derfor tester vi om dataene som sendes av ett system er riktig kartlagt og satt inn i et annet system eller ikke. Annet enn datainnsatsen, sjekker vi også for dataintegritet, dvs. at dataene, når de settes inn i et annet system, ikke har blitt manipulert eller endret osv.
  • Testing kan også utføres når et system overfører data til en annen applikasjonsdatabase. Her vil vi teste om dataene fra ett system er riktig satt inn i en gitt kolonne i gitt tabell basert på kartleggingen. Vi vil også teste dataintegriteten og datakonsistensen med hensyn til kildesystemet.

I alle disse testscenariene utføres grensesnitttest basert på forretningskravene og forretningsflytreglene.

Forskjellen mellom grensesnitttesting og integrasjonstesting

Bekreftelse og validering av ende-til-slutt-funksjonalitet for komponenter som er koblet sammen kalles Integrasjonstesting eller mer populært som systemintegrasjonstesting. Integrasjonstesting validerer hovedsakelig hvis to eller flere system integrert sammen har jobbet feilfritt sammen eller ikke.

Testing Grensesnitt derimot konsentrerer man seg i utgangspunktet om tilkoblingskanalen mellom de to systemene. Forbindelseskanalen mellom to eller flere systemer kalles et grensesnitt. Testing av denne tilkoblingskanalen kalles Interface Testing. De fleste grensesnittene er enten API-er eller webtjenester. Den har ikke et brukergrensesnitt, men tar en innspill og gir brukeren en utgang.

For eksempel

Grensesnitttesting

I eksemplet ovenfor deler nettstedet og databasen et grensesnitt for å overføre påloggingsinformasjonen, dvs. brukernavn og passord.

Grensesnittet bruker webtjeneste til å sende påloggingsinformasjonen til databasen, som igjen validerer ektheten til den innkommende meldingen (brukernavn og passord) og returnerer verdien som sann hvis både brukernavnet og passordet samsvarer med posten i databasen eller usant i tilfelle hvis noen av dem eller både brukernavnet og passordet ikke samsvarer med dataene som er tilstede inne.

La oss diskutere eksempel på grensesnitttesting:

La oss si at vi har en applikasjon der vi har forskjellige databaser som interagerer med hverandre.

I dette eksempel , vil vi vurdere to databaseinteraksjoner gjennom en grensesnittkanal.

La oss vurdere at det er to databaser eller applikasjoner, database A og B. 'A' overfører noen data til 'B', som deretter brukes av B for å utføre noen operasjoner. Etter å ha utført en viss operasjon på innkommende data, setter B inn disse dataene i databasen og lager en utgang JSON for bekreftelse med listen over oppdaterte data og sender dem tilbake til A.

Både A og B bruker grensesnittkanal for kommunikasjon mellom dem.

Forretningsscenario

“A” inneholder ansattedata for alle ansatte som tilhører økonomiavdelingen.

Dataene må overføres til “B ' på en daglig basis. “B” inneholder data om generelle detaljer om ansatte. Alle dataene fra “A” må overføres til en bestemt tabell og kolonne av “B”. Annet enn inntastingsdataene, må 'B' også sortere og organisere data. Det må også sørge for om dataene er lagt inn mot riktig ansatt.

Når dataene er lagt inn i systemet, skal “B” sende en utgang JSON for å bekrefte om dataene er satt inn i databasen.

I tilfelle avvik i JSON-skjemaet eller manglende data, vil 'B' ikke behandle dataene, og det vil sende en Avvis JSON-melding med årsaken til avvisning.

Forretningsscenario for grensesnitttesting

Test miljøoppsett

For å teste et scenario som dette, trenger vi en teststub for å etterligne databasen “A”. Utvikleren kan gi et sted hvor du enten kan dumpe test-JSON eller en mock UI og lime inn JSON-dataene dine og påkalle behandlingen gjennom grensesnittet. For testformål kan vi også ha en utgangsplass der vi kan motta bekreftelsen JSON fra “B”.

I vår eksempel , vil vi bruke en mappebane der vi vil sette vår test JSON, tjenesten vil konstant peke stedet for JSON-filen. Når filen er til stede, vil tjenesten hente filen og sende den til “B” via grensesnittet. Når filen er hentet, blir den slettet fra hentestedet.

Starter testen

Når testmiljøet er satt opp, er neste trinn å opprette testdataene.

Når du lager testdata (les test JSON), bør vi huske på noen ting:

  • Følg forretningsreglene.
  • Forsikre deg om at de obligatoriske feltene er til stede.
  • Endre verdien på feltene i henhold til forretningsreglene for hver test.
  • Forsikre deg om at JSON-skjemaet er i riktig format.
  • Forsikre deg om at nomenklaturen for JSON-filnavnet er overholdt.

La oss ta en titt på prøvetesten JSON vi vil bruke til testing:

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

Begynn testen

Når du har opprettet JSON-filen, kan du slippe den på hentestedet. Tjenesten henter dette og legger det ut i database B.

Scenarier å teste:

Det kan være en rekke scenarier som må testes for dette eksemplet som:

  • Arbeider med nettjenesten for å sende og motta data.
  • Dataintegritet for inngangsdataene. Dette kan valideres ved å spørre tabeller og kolonner i database B for dataene som er lagt inn gjennom testen JSON.
  • Negative scenarier.

Først vil vi sjekke om JSON-filen er hentet fra stedet eller ikke er til stede på stedet. Dette vil validere tjenestens arbeid. Deretter navigerer vi til utdatamappen for å se utdata JSON. Tilstedeværelse av utgang JSON validerer hvis inngangsdataene er sendt til database B og bekreftelse for det samme er mottatt.

Den neste delen av testingen består i å validere dataene som er lagt inn i databasen.

I testen ovenfor vil vi validere om dataene som sendes gjennom testen JSON er riktig lagt inn i databasen. Vi vil validere dataintegritet, datakonsistens og datainnsetting. Vi må spørre database B for den gitte kolonnen i en bestemt tabell for å validere om dataene er riktig satt inn i tabellen.

La oss si at vi har EmpDetails-tabellen der dataene må settes inn. Så vi kjører et spørsmål for å validere dataene.

Spørringen vil være omtrent slik:

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

Her bruker vi medarbeider-ID som primærnøkkel for å spørre dataene i EmpDetails-tabellen. Vi spør etter alt kolonnenavnet som dataene er satt inn i. Da kan dataene i kolonnenavnet valideres med dataene som sendes gjennom JSON.

I det ovennevnte tilfellet lagres dataene fra JSON i mer enn en tabell i databasen, og du kan derfor bruke SQL JOINS til å hente alle ønskede data.

Det tredje trinnet i testing vil være å teste de negative scenariene.

Noen av de negative scenariene som kan testes er:

  • Oppførselen til systemet når feil data mates gjennom JSON.
  • Når JSON har feil skjema eller struktur.
  • Når den behandlede JSON mangler primærnøkkelen eller obligatoriske felt.
  • Nomenklaturen til JSON-filen er ikke gyldig.

I alle disse tilfellene skal systemet kunne håndtere disse scenariene, og ingen data skal settes inn i systemet i henhold til forretningsregelen.

Konklusjon

Forbindelseskanalen mellom to systemer som data overføres gjennom kalles et grensesnitt og grensesnitttesting fungerer hovedsakelig rundt testing av disse tilkoblingene. De fleste grensesnittene bruker Web Service eller APIer. Det har ikke alltid et brukergrensesnitt, men det godtar input og leverer output.

binært søketre c ++ eksempel

Å være et av de mest brukte dataoverføringsformatene, kan JSON brukes til overføring av grensesnittdata.

En tester må ha grunnleggende kunnskap om JSON-struktur for å lage testdata (i form av JSON) og for å lese utdata fra systemet. En tester bør også være godt kjent med kartleggingen mellom JSON-nøkler og databasetabellkolonne.

Enhver tester som ønsker å jobbe med grensesnitttesting, bør ha klar kunnskap om forretningsretningslinjene og reglene for en applikasjon. En tester skal også ha tilstrekkelig kunnskap om databasen og skal kunne skrive enkle SQL-spørsmål.

Ta kontakt med oss ​​i kommentarfeltet for spørsmål eller avklaring.

Opplæring # 5: JSON-intervjuspørsmål

Anbefalt lesing

^