how test java applications tips with sample test cases
I denne opplæringen vil vi lære komponentene som er involvert i et Java-program og de forskjellige typene tester som må utføres for å sikre en høykvalitets, feilfri applikasjon.
Dette er en tredelt serie om testing av JAVA-applikasjoner.
- I denne artikkelen vil vi lære J2EE-komponentene og manuell testing for en J2EE-applikasjon.
- I det andre vil vi gjennomgå Automatisert testing tilnærming for testing av J2EE-applikasjoner, og
- I den tredje vil vi gjennomgå en omfattende liste over verktøy som er tilgjengelige for testing av J2EE-applikasjoner.
Hva du vil lære:
- La oss starte med oversikt over J2EE-applikasjoner
- Testing av JAVA / J2EE-applikasjon
- Manuell Java-applikasjonstesting:
- Konklusjon
- Anbefalt lesing
La oss starte med oversikt over J2EE-applikasjoner
TIL Java webapplikasjon består av flere komponenter, som hver tjener et viktig formål. MVC , som står for Model View Controller, står som det mest populære og mest brukte arkitektoniske designmønsteret.
Før vi lærer å teste, la oss gå gjennom forskjellige komponenter i en J2EE-applikasjon.
- Klient / nettleser ber om en nettadresse med en URL.
- JSP (Java Server Pages) - JSP er en server-side teknologi beregnet på å presentere data for brukeren. Den støtter visning av dynamisk innhold ved hjelp av spesielle koder kalt JSP-koder, som hjelper til med å sette inn Java-kode i HTML-sider. (Statisk HTML viser alltid det samme innholdet). Ved kjøretid konverteres en JSP til en Servlet. Forretningslogikk skrives vanligvis ikke her.
- JSF (Java Server Faces) - JSF er et rammeverk for visningskomponenter for effektiv utforming av brukergrensesnittet.
- Javascript / Jquery - er skriptspråk som brukes til validering av visningen / skjermen på klientsiden.
- Servlet - En Servlet validerer dataene som mottas fra inngangen, velger riktig forretningslogikkode og overfører verdiene til Bean-koden.
- Enterprise Java Bean (EJB) - Det er her hele forretningslogikken vanligvis skrives og håndteres. Bønnen kaller deretter koden for å enten lese, skrive eller oppdatere databasen. Når databaseaksjonene er fullført, blir svaret deretter overført tilbake til Servlet, som igjen velger riktig JSP for å vise resultatene.
- Nettjenester - Webservices er komponenter i et program som kjører på en egen server og kommuniserer over HTTP-protokoll.
- Database - lagrer hele dataene i applikasjonen.
Vær oppmerksom på at ikke alle webapplikasjoner følger JSP -> Servlet -> EJB -> Databasemodell . De fleste av J2EE-applikasjonene er for tiden skrevet med et rammeverk som Struts, Spring eller Hibernate. Utformingen av applikasjoner varierer for hvert krav basert på størrelsen på applikasjonen, kostnad, utviklingstid, ressurser og teamstørrelse.
Testing av JAVA / J2EE-applikasjon
La oss nå gå over til å teste en hel J2EE-applikasjon. Dette gjøres i flere trinn.For eksempel, tenk at vi har tre skjermer:
- En påloggingsskjerm
- En ansattes skjerm, som viser alle ansatte i organisasjonen
- En ansatt modifikasjon / tillegg / fjerning skjermen.
Brukergrensesnittet (User Interface) for disse tre skjermbildene er utviklet med JSP / HTML og valideringene utført gjennom JavaScript. Fordi det er et eksempel på applikasjon, er logikken i Servlet og DAO (Data Access Object). DAO er en klasse for tilkobling til databasen.
Nedenfor er eksempelskjermene:
Manuell Java-applikasjonstesting:
Under manuell JAVA-testing forbereder en tester testtilfellene fra det detaljerte designdokumentet og prøver å dekke hvert mulig scenario og kodebit.
# 1) JAVA ENHETSTESTING
Enhetstesting er en type testing hvor en bruker trenger å teste den minste av kodebitene for nøyaktighet, korrekthet og for å oppfylle kravene.
La oss taeksempel på påloggingsskjermen. Påloggingsskjermen har to tekstfelt: brukernavn og passord, og har to knapper: send inn og avbryt.
Testtilfellene skal dekke alle sløyfene og betingede uttalelser. Testtilfeller skal vise forventede resultater og testdata. Nedenfor er noen av de generelle testtilfellene som en bruker kan utføre manuelt i en påloggingsskjerm. Resultatene blir deretter notert i testdokumentet.
Nedenfor er et eksempel på et testformat for påloggingsskjermen.
| S.No. | Testforsøk | forventet resultat | Egentlige resultatet | Bestått / ikke bestått |
|---|---|---|---|---|
| 4 | Bruker skriver inn et brukernavn på mer enn 10 tegn | Feilmelding “Brukernavnet skal ikke være mer enn 10 tegn” skal vises | Feilmelding vises ikke | FEIL |
| 1 | Bruker sjekker utseendet til etikettene Brukernavn, Passord | Etikettene skal være riktig stavet og vises med skrift i normal størrelse | Merket brukernavn og passord vises riktig | SENDE |
| to | Bruker sjekker utseendet til knappen Send inn og avbryt | Knappene skal vises med riktig navn | Knappene Send inn og Avbryt vises riktig | SENDE |
| 3 | Brukeren sjekker bakgrunnsfargen på skjermen | Innloggingsskjemaet skal være innenfor et hvitt bord og skjermen skal være bakgrunnsgrå | Skjermutseendet samsvarer ikke med kravene. | FEIL |
| 4 | Brukeren etterlater tekstboksen brukernavn som tom | Feilmelding 'Brukernavn kan ikke være tomt' skal vises | Feilmelding 'Brukernavn kan ikke være tomt' vises | SENDE |
| 5 | Brukeren legger inn noe verdi i brukernavnet tekstboks og la passordet tekstboksen stå tomt | Feilmelding 'Passord kan ikke være tomt' skal vises | Feilmelding “Passordet kan ikke være tomt” vises | SENDE |
| 6 | Bruker skriver inn brukernavn som “abcd” og passord som “xxxx” | Feilmelding 'Ugyldig brukernavn passord kombinasjon' skal vises | Feilmelding 'Ugyldig brukernavn passord kombinasjon' er vist | SENDE |
| 5 | Bruker skriver inn brukernavn som “testbruker” og passord som “passord” og klikker på Send-knappen | Brukeren skal kunne se 'skjermbildet for medarbeiderdetaljer' | Skjermbildet for medarbeiderdetaljer vises | SENDE |
Mens tabellen viser noen av testtilfellene, er den komplette listen nedenfor:
- Se etter unntak, inkludert unntak fra NULL-pekeren
- Sjekk om NULLS ikke er tillatt for brukernavn og passord
- Sjekk om brukernavn / passord er i riktig format
- Sjekk om tall ikke er tillatt for brukernavn
- Sjekk om spesialtegn ikke er tillatt i brukernavnet
- Sjekk om riktig kombinasjon av brukernavn og passord er oppgitt, så tar applikasjonen deg til neste skjermbilde, dvs. ansattes informasjonsskjerm
- Sjekk om det oppgitte brukernavnet er av riktig lengde
- Sjekk om tekstfeltet for brukernavn bare tillater det maksimale antall tegn som er spesifisert for det feltet
- Sjekk om passordfeltet, hvis spesifisert i kravene, er synlig som * mens du skriver inn
- Sjekk om passord er store og små bokstaver
- Sjekk om brukernavnet ikke er mellom store og små bokstaver
- Sjekk om påloggingssiden ikke husker brukernavnet eller passordet, selv etter at du har avsluttet
- Sjekk om Send og Avbryt-knappen fungerer etter behov
- Hvis du bruker applikasjonen første gang, sjekk om brukernavnet har tillatelse til å gå inn i applikasjonen
- Slett en brukernavn / passordkombinasjon fra databasen og sjekk om kombinasjonen ikke er i stand til å logge på igjen
- For alle de ovennevnte tilfellene, sjekk om riktige feilmeldinger vises
- Sjekk om etikettene og knappene er på rett sted på skjermen og at de viser teksten riktig
- Sjekk om skjermutseendet er i henhold til kravene
- Sjekk om unntak blir håndtert
- Sjekk om loggføring er utført for nødvendige handlinger
Etter å ha gått gjennom testsakene, kan du innse at du for det meste har å gjøre med testing av felt, knapper, funksjonalitet og validering av en bestemt skjerm. Dette er nøyaktig, ettersom Unit Testing veldig nøye med å teste alle små kodebiter og komponenter. Den samme typen testing bør utføres på alle skjermene.
Vær oppmerksom på at ovennevnte kun er eksempler, og testtilfeller utarbeides basert på et prosjektspesifikt og detaljert designdokument.
Les også=> Prøven er klar til bruk og test scenarier for testing av webapplikasjoner.
# 2) INTEGRASJONSTESTING
I integrasjonstesting integreres individuelle moduler og testes sammen for korrekthet.
hvordan å fange feil under byggeautomatisering
La hver av de tre skjermbildene i eksemplet ovenfor utvikles av tre forskjellige teammedlemmer. Nå som de er ferdige med enhetstesting, er det på tide å bringe all koden sammen og sjekke om de fungerer godt sammen. Integrasjonstesting utføres for å sikre at data eller kontroll overføres riktig fra en skjerm til en annen.
Her er noen eksempler på eksempler på integrasjonstest for eksemplet på ansattes søknad:
- Sjekk om brukeren som er pålogget og økt er den samme i alle de andre nye integrerte skjermbildene
- Sjekk om de andre modulene ikke oppdaterer / sletter / setter inn noen post i databasen uten behov
- La det være et ansattes statusfelt som sier 'Ny' i tillegg, 'Oppdatert' om modifikasjon og 'Slettet' ved sletting. Selv om to eller tre skjermer kan bruke samme statusfelt, er det viktig å sikre at feltet ikke oppdateres feil.
- Sjekk om topptekst, bunntekst, skjermstørrelse og utseende oppfyller kravene etter integrering
- Kontroller at når du klikker på Send-knapper, overføres kontrollen til neste skjermbilde
- Kontroller at når du klikker på Avbryt-knappen, blir handlingen utført avbrutt
I tillegg kan de generelle integrasjonstesttilfellene for en J2EE-applikasjon være:
- Kontroller datastrømmen, enten Object, XML eller Session fra ende til annen. Sjekk om det er riktig.
- Sjekk om økten administreres riktig av hver av modulene
- Hvis eksterne applikasjoner (webtjenester) er involvert, sjekk om applikasjonen din kan ringe og hente data tilbake fra applikasjonen
# 3) SYSTEMTESTING
I systemtesting blir hele applikasjonen testet for funksjonalitet og fullstendighet med hensyn til kravene. Det vil sannsynligvis være lettere å spørre når Enhetstesting av hver komponent utføres, og kodekomponentene blir også kombinert og testet sammen under integrasjonstesting, hva kan være annerledes i systemtesting? Det er ikke unøyaktig å si at ideen i System Testing er å bryte søknaden :)
Scenario nr. 1: Du utvikler en nyansatt applikasjon med et rammeverk;for eksempel, Struts. Det er også flere andre applikasjoner som kjører på forskjellige servere i organisasjonen din. Imidlertid ringer alle sammen den samme eksisterende nettjenesten for å hente adressen og telefonnummeret til en bestemt person.
Under integrasjonstesting ville du ha testet om applikasjonen din er i stand til å ringe til nettjenesten, og om du er i stand til å få svaret. Men hva om det er et problem i selve webtjenesten? Eller svarer ikke nettjenesten på noen sjeldne innganger? Nettjenesten, i vårt tilfelle, kan bare ta et ansattes antall på maks 6 tegn. Eller, nettjenesten kaster unntak for visse adresseformater mens du returnerer. Dette er eksternt, men det er også en del av systemtesting.
Scenario nr. 2 : Ansattesøknaden din er fullført. Du legger til en ansatt, og den genererer et ansatt nr. 1001. Du endrer, sletter, oppdaterer, legger til, endrer, sletter, legger til, legger til, legger til, endrer, sletter og til slutt legger du til en annen. Hva om nummeret til den nye ansatte er igjen # 1001?
Scenario # 3 : La oss anta at to brukere bruker applikasjonen samtidig. Begge to begynner å jobbe med den samme ansatte, sletter den ene. Hva om den andre brukeren er i stand til å fortsette med endringen av samme ansatte som den er lagret i økten?
Nedenfor er noen viktige aspekter ved systemtesting:
- Sørg for at datastrømmen og kontrollen er korrekt fra ende til ende
- Sikre sikkerheten til transaksjonsdataene
- Sørg for at applikasjonen følger alle forretningsfunksjonalitetene
- Sjekk om applikasjonen fungerer som et sluttprodukt - sjekk ødelagte lenker, øktadministrasjon, informasjonskapsler, logging, feilhåndtering, unntakshåndtering, validering og transaksjonsflyt.
# 4) TESTING AV YTELSE
Denne typen tester utføres når det vil være et stort antall brukere som bruker applikasjonen eller store mengder data i databasen, eller begge deler. Nedenfor er noen av tilfellene:
- Hvis flere brukere logger inn samtidig, må du kontrollere at applikasjonene ikke henger / krasjer
- Hvis en stor mengde data er tilgjengelig i databasen - sjekk at søkeskjermnettene ikke tar veldig lang tid å utføre spørringer før tidsavbrudd for økten
- I et flertrådet miljø, sjekk at applikasjonen er i stand til å håndtere alle tråder godt
- I applikasjoner der det opprettes et stort antall objekter, sjekk om det er tildelt nok minne, søppelhåndtering håndteres og at det ikke er unntak uten minne
Konklusjon
I denne artikkelen har vi dekket en oversikt over en J2EE-applikasjon. Vi har også sett hvordan manuell utføring av enhet, integrasjon, funksjonell og systemtesting for hver av komponentene i applikasjonen med et eksempel.
I neste artikkel , vil vi se hvordan automatiseringstesting kan være gunstig for store J2EE-applikasjoner.
Om forfatter: Dette er en gjesteartikkel av Padmavaty S. Med samlet 7+ års erfaring med programvaretesting har hun omfattende erfaring med å teste Java, J2EE, MVC og Struts framework.
Gi oss beskjed hvis du jobber med å teste JAVA-applikasjoner. Del din erfaring og spørsmål i kommentarene nedenfor.
PREV Opplæring | NESTE veiledning
Anbefalt lesing
- ISTQB Testing Certification Sample Question Papers With Answers
- Hvordan utføre automatiseringstesting av JAVA / J2EE-applikasjoner (del 2)
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Topp 20 praktiske tips om programvaretesting du bør lese før du tester applikasjoner
- Testing av helseprogrammer - tips og viktige testscenarier (del 2)
- Hvordan finne en feil i applikasjonen? Tips og triks
- Databasetesting med JMeter
- Java Virtual Machine: Hvordan JVM hjelper med å kjøre Java-applikasjoner