Menu

Sådan testes JAVA-applikationer - tip med eksempler på testtilfælde (del 1)

  • Vigtigste
  • Manuel Test
  • Sådan testes JAVA-applikationer - tip med eksempler på testtilfælde (del 1)

how test java applications tips with sample test cases

Prøv Vores Instrument Til At Fjerne Problemer

I denne vejledning lærer vi de komponenter, der er involveret i en Java-applikation, og de forskellige typer test, der skal udføres for at sikre en bug-fri applikation af høj kvalitet.

Dette er en tredelt serie om test af JAVA-applikationer.

  1. I denne artikel lærer vi J2EE-komponenterne og manuel testtilgang til en J2EE-applikation.
  2. I det andet vil vi gennemgå Automatiseret test tilgang til test af J2EE applikationer, og
  3. I det tredje gennemgår vi en omfattende liste over værktøjer, der er tilgængelige til test af J2EE-applikationer.

Test af JAVA-applikationer

Hvad du lærer:

Lad os starte med en oversigt over J2EE-applikationer

TIL Java webapplikation består af flere komponenter, der hver tjener et vigtigt formål. MVC , der står for Model View Controller, står som det mest populære og ofte anvendte arkitektoniske designmønster.

Før vi lærer at teste, lad os kort gennemgå forskellige komponenter i en J2EE-applikation.

J2EE ANVENDELSE Testning 1

  • Klient / browser beder om en webadresse med en URL.
  • JSP (Java Server Pages) - JSP er en serverside-teknologi beregnet til at præsentere data for brugeren. Det understøtter visning af dynamisk indhold ved hjælp af specielle tags kaldet JSP-tags, som hjælper med at indsætte Java-kode inden for HTML-sider. (Statisk HTML viser altid det samme indhold). Ved kørsel konverteres en JSP til en Servlet. Forretningslogik skrives typisk ikke her.
  • JSF (Java Server Faces) - JSF er en ramme for visningskomponenter til et effektivt design af brugergrænsefladen.
  • Javascript / Jquery - er scriptsprog, der bruges til validering af visningen / skærmen på klientsiden.
  • Servlet - En Servlet validerer de data, der modtages fra inputet, vælger den relevante forretningslogikode og videregiver værdierne til Bean-koden.
  • Enterprise Java Bean (EJB) - Det er her, hele forretningslogikken typisk skrives og håndteres. Bønnen kalder derefter koden for enten at læse, skrive eller opdatere databasen. Når databasehandlingerne er afsluttet, overføres svaret derefter tilbage til Servlet, som igen vælger den relevante JSP til at vise resultaterne.
  • Webtjenester - Webservices er komponenter i et program, der kører på en separat server og kommunikerer via HTTP-protokol.
  • Database - gemmer hele applikationens data.

Bemærk, at ikke alle webapplikationer følger JSP -> Servlet -> EJB -> Databasemodel . De fleste af J2EE-applikationerne er i øjeblikket skrevet med en ramme som Struts, Spring eller Hibernate. Udformningen af ​​applikationer varierer for hvert krav baseret på størrelsen på applikationen, omkostninger, udviklingstid, ressourcer og teamstørrelse.

Test af JAVA / J2EE-applikation

Lad os nu gå over til at teste en hel J2EE-applikation. Dette gøres i flere trin.For eksempel, mener, at vi har tre skærme:

  • En login-skærm
  • En medarbejderdisplayskærm, der viser alle medarbejdere i organisationen
  • En medarbejder modifikation / tilføjelse / fjernelse skærm.

UI (brugergrænseflade) til disse tre skærme er udviklet med JSP / HTML og valideringerne udført via JavaScript. Da det er et eksempel på applikation, er logikken i Servlet og DAO (Data Access Object). DAO er en klasse til oprettelse af forbindelse til databasen.

Nedenfor er eksempler på skærmbilleder:

J2EE-ANVENDELSE Testeksempler

J2EE-ANVENDELSE Testeksempel 2

J2EE-ANVENDELSE Testeksempel 3

Manuel Java-applikationstest:

Under manuel JAVA-test forbereder en tester testcases fra det detaljerede designdokument og forsøger at dække alle mulige scenarier og kodestykker.

# 1) JAVA-ENHEDSTESTING

Enhedstest er en type test hvor en bruger skal teste den mindste af kodestykkerne for nøjagtighed, korrekthed og opfyldelse af kravene.

Lad os tageeksempel på loginskærmen. Login-skærmen har to tekstfelter: brugernavn og adgangskode og har to knapper: send og annuller.

Testcases skal dække alle sløjfer og betingede udsagn. Testcases skal vise de forventede resultater og testdataene. Nedenfor er nogle af de generelle testsager, som en bruger kunne udføre manuelt i en login-skærm. Resultaterne noteres derefter i testdokumentet.

Nedenfor er et eksempel på et testformat til loginskærmen.

S. nr.Test sagforventet resultatFaktisk resultatBestå ikke-bestå
4Bruger indtaster et brugernavn på mere end 10 tegnFejl besked
“Brugernavn bør ikke være mere end 10 tegn” skal vises		Fejlmeddelelse vises ikkeSVIGTE
enBruger kontrollerer udseendet af etiketter Brugernavn, adgangskodeEtiketterne skal staves korrekt og vises i skrifttype med normal størrelseEtiketets brugernavn og adgangskode vises korrektPASSERE
toBruger kontrollerer udseendet af knappen
Send og annuller		Knapperne skal vises med det rigtige navnKnapperne Send og Annuller vises korrektPASSERE
3Bruger kontrollerer skærmens baggrundsfarveLoginformularen skal være inden for en hvid tabel, og skærmen skal være baggrundsgråSkærmens udseende svarer ikke til kravene.SVIGTE
4Brugeren efterlader brugernavnet tekstfelt som tomtFejlmeddelelsen 'Brugernavn kan ikke være tomt' skal visesFejlmeddelelsen 'Brugernavn kan ikke være tomt' visesPASSERE
5Brugeren indtaster en værdi i brugerfeltets tekstboks og efterlader adgangskodens tekstboks som tomFejlmeddelelsen 'Adgangskoden kan ikke være tom' skal visesFejlmeddelelsen 'Adgangskoden kan ikke være tom' visesPASSERE
6Bruger indtaster brugernavn som “abcd” og adgangskode som “xxxx”Fejl besked
'Ugyldig kombination af adgangskode til brugernavn'
skal vises		Fejl besked
'Ugyldig kombination af adgangskode til brugernavn'
vises		PASSERE
5Bruger indtaster brugernavn som “testbruger” og adgangskode som “adgangskode” og klikker på knappen SendBrugeren skal være i stand til at se 'skærmbilledet medarbejderoplysninger'Skærmbilledet for medarbejderoplysninger visesPASSERE

Mens tabellen viser nogle af testsagerne, er nedenstående komplet liste:

  • Kontroller for enhver undtagelse inklusive NULL-markørundtagelse
  • Kontroller, om NULLS ikke er tilladt for brugernavn og adgangskode
  • Kontroller, om brugernavn / adgangskode er i det korrekte format
  • Kontroller, om numre ikke er tilladt for brugernavnet
  • Kontroller, om specialtegn ikke er tilladt i brugernavnet
  • Kontroller, om den korrekte kombination af brugernavn og adgangskode er indtastet, så fører applikationen dig til det næste skærmbillede, dvs. skærmbilledet for medarbejderoplysninger
  • Kontroller, om det indtastede brugernavn har den korrekte længde
  • Kontroller, om brugerfeltets tekstfelt kun tillader det maksimale antal tegn, der er angivet for det felt
  • Kontroller, om adgangskodefeltet, hvis det er specificeret i kravene, er synligt som * under indtastning
  • Kontroller, om adgangskoder er store og små bogstaver
  • Kontroller, om brugernavnet ikke er store og små bogstaver
  • Kontroller, om login-siden ikke husker brugernavnet eller adgangskoden, selv efter at du har afsluttet
  • Kontroller, om knappen Send og Annuller fungerer efter behov
  • Hvis du bruger applikationen første gang, skal du kontrollere, om brugernavnet har tilladelse til at åbne applikationen
  • Slet en kombination af brugernavn / adgangskode fra databasen, og kontroller, om kombinationen ikke er i stand til at logge ind igen
  • I alle ovenstående tilfælde skal du kontrollere, om de relevante valideringsfejlmeddelelser vises
  • Kontroller, om etiketterne og knapperne er på det rigtige sted på skærmen, og at de viser teksten korrekt
  • Kontroller, om skærmens udseende er som krævet
  • Kontroller, om undtagelser håndteres
  • Kontroller, om der er foretaget logning for de nødvendige handlinger

Efter at have gennemgået testsagerne kan du muligvis indse, at du for det meste har at gøre med test af felter, knapper, funktionalitet og valideringer af en bestemt skærm. Dette er nøjagtigt, da Unit Testing meget meget beskæftiger sig med testningen af ​​hvert lille kodestykke og komponent. Den samme type test skal udføres for alle skærmbilleder.

Bemærk, at ovenstående kun er eksempler, og testcases udarbejdes på baggrund af et projektspecifikt og detaljeret designdokument.

Læs også=> Prøve klar til brug test tilfælde og test scenarier til test af webapplikationer.

# 2) INTEGRATIONSTESTING

I integrationstest integreres individuelle moduler og testes sammen for korrekthed.

forskel mellem venstre sammenføjning og venstre ydre sammenføjning i sql

Lad hver af de tre skærme i ovenstående eksempel er udviklet af tre forskellige teammedlemmer. Nu hvor de er færdige med enhedstest, er det tid til at samle al koden og kontrollere, om de fungerer godt sammen. Integrationstest udføres for at sikre, at data eller kontrol overføres korrekt fra en skærm til en anden.

Her er nogle eksempler på eksempler på integrationstest for eksemplet på ansøgning om ansat:

  • Kontroller, om brugeren logget ind og sessionen er den samme på alle de andre nye integrerede skærme
  • Kontroller, om de andre moduler ikke opdaterer / sletter / indsætter nogen post i databasen, der ikke kræves
  • Lad der være et medarbejderstatusfelt, der siger 'Ny' ved tilføjelse, 'Opdateret' om ændring og 'Slettet' ved sletning. Selvom to eller tre skærme kan bruge det samme statusfelt, er det vigtigt at sikre, at feltet ikke opdateres forkert.
  • Kontroller, om sidehoved, sidefod, skærmstørrelse og udseende opfylder kravene efter integrationen
  • Kontroller, at når du klikker på Send-knapper, overføres kontrollen til det næste skærmbillede
  • Kontroller, at når du klikker på knappen Annuller, annulleres den udførte handling

Derudover kunne de generelle integrationstestsager for en J2EE-applikation være:

  • Kontroller datastrømmen, enten Objekt, XML eller Session fra ende til slut. Kontroller for rigtighed.
  • Kontroller, om sessionen styres korrekt af hvert af modulerne
  • Hvis eksterne applikationer (webtjenester) er involveret, skal du kontrollere, om din applikation er i stand til at foretage opkald og hente data tilbage fra applikationen

# 3) SYSTEMTEST

I systemtest testes hele applikationen for funktionalitet og fuldstændighed med hensyn til kravene. Det ville sandsynligvis være lettere at spørge, hvornår enhedstest af hver komponent udføres, og kodekomponenterne også kombineres og testes sammen under integrationstest, hvad kan der være anderledes i systemtest? Det er ikke unøjagtigt at sige, at ideen i Systemtest er at bryde applikationen :)

Scenarie nr. 1: Du udvikler en ny medarbejderansøgning med en ramme;for eksempel, Struts. Der er også flere andre applikationer, der kører på forskellige servere i din organisation. Imidlertid ringer alle sammen til den samme eksisterende webservice for at hente adresse og telefonnummer til en bestemt person.

Under integrationstest ville du have testet, om din applikation er i stand til at foretage et opkald til webservicen, og hvis du er i stand til at få svaret. Men hvad hvis der er et problem i selve webservicen? Eller reagerer webservicen ikke på nogle sjældne input? Webtjenesten kan i vores tilfælde kun tage et medarbejderantal på maksimalt 6 tegn. Eller webtjenesten kaster undtagelser for visse adresseformater, mens de vender tilbage. Dette er eksternt, men det er også en del af systemtest.

Scenarie nr. 2 : Din ansattes ansøgning er færdig. Du tilføjer en medarbejder, og den genererer et medarbejdernummer # 1001. Du ændrer, sletter, opdaterer, tilføjer, ændrer, sletter, tilføjer, tilføjer, tilføjer, ændrer, sletter og derefter til sidst tilføjer en anden. Hvad hvis det nye medarbejdernummer igen er nr. 1001?

Scenarie # 3 : Lad os antage, at to brugere bruger applikationen på samme tid. Begge begynder at arbejde på den samme medarbejder, den ene sletter. Hvad hvis den anden bruger er i stand til at fortsætte med ændringen af ​​de samme medarbejdere, som den er gemt i sessionen?

Nedenfor er nogle vigtige aspekter af systemtest:

  • Sørg for, at strømmen af ​​data og kontrol er korrekt fra ende til ende
  • Sikre transaktionsdataens sikkerhed
  • Sørg for, at applikationen følger alle forretningsfunktioner
  • Kontroller, om applikationen fungerer godt som et slutprodukt - tjek ødelagte links, session management, cookies, logning, fejlhåndtering, undtagelseshåndtering, validering og transaktionsflow.

# 4) PRESTATIONSTESTING

Denne type test udføres, når der ville være et stort antal brugere, der bruger applikationen eller store mængder data i databasen eller begge dele. Nedenfor er nogle af tilfældene:

  • Hvis flere brugere logger ind på samme tid, skal du kontrollere, at applikationerne ikke hænger / går ned
  • Hvis der er en stor mængde data tilgængelige i databasen - skal du kontrollere, at søgeskærmsnet ikke tager meget lang tid at udføre forespørgsler inden sessionstimeout
  • I et miljø med flere tråde skal du kontrollere, at applikationen er i stand til at håndtere alle tråde godt
  • I applikationer, hvor der oprettes et stort antal objekter, skal du kontrollere, om der er tildelt tilstrækkelig hukommelse, affaldsindsamling håndteres, og at der ikke er undtagelser uden hukommelse

Konklusion

I denne artikel har vi dækket en oversigt over en J2EE-applikation. Vi har også set, hvordan man manuelt udfører enhed, integration, funktionel og systemtest for hver af komponenterne i applikationen med et eksempel.

I næste artikel , vil vi se, hvordan automatiseringstest kan være gavnligt for store J2EE-applikationer.

Om forfatter: Dette er en gæsteartikel af Padmavaty S. Med samlet 7+ års erfaring med softwaretest har hun omfattende erfaring med at teste Java, J2EE, MVC og Struts framework.

Fortæl os, hvis du arbejder på at teste JAVA-applikationer. Del din oplevelse og spørgsmål i kommentarerne nedenfor.

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^