Com provar aplicacions JAVA: consells amb casos de prova de mostra (primera part)

how test java applications tips with sample test cases

En aquest tutorial, aprendrem els components implicats en una aplicació Java i els diversos tipus de proves que cal dur a terme per garantir una aplicació d’alta qualitat i lliure d’errors.

Això és un sèrie de tres parts sobre proves d’aplicacions JAVA.

1. En aquest article, aprendrem els components J2EE i l'enfocament de proves manuals per a una aplicació J2EE.
2. En el segon, revisarem el Proves automatitzades enfocament per provar aplicacions J2EE i
3. Al tercer, revisarem una llista completa d’eines disponibles per provar aplicacions J2EE.

Què aprendreu:

• Comencem amb una visió general de les aplicacions J2EE
• Prova de l'aplicació JAVA / J2EE
• Prova manual d'aplicacions Java:
• Conclusió
• Lectura recomanada

Comencem amb una visió general de les aplicacions J2EE

A Java l'aplicació web consta de diversos components, cadascun dels quals té un propòsit important. MVC , que significa Model View Controller, és el patró de disseny arquitectònic més popular i utilitzat amb més freqüència.

Abans d'aprendre a provar, revisem breument el diversos components d’una aplicació J2EE.

• Client / Navegador demana una adreça web amb un URL.

• JSP (pàgines del servidor Java) - JSP és una tecnologia del costat del servidor destinada a presentar dades a l'usuari. Admet la visualització de contingut dinàmic amb l'ajut d'etiquetes especials anomenades etiquetes JSP, que ajuden a inserir codi Java a les pàgines HTML. (L'HTML estàtic sempre mostra el mateix contingut). En temps d'execució, un JSP es converteix en un Servlet. La lògica empresarial normalment no s’escriu aquí.

• JSF (Cares del servidor Java) - JSF és un marc de components de visualització per al disseny eficaç de la interfície d'usuari.

• Javascript / Jquery - són llenguatges de seqüència d'ordres que s'utilitzen per a la validació del costat de client de la visualització / pantalla.

• Servlet - Un Servlet valida les dades rebudes de l'entrada, selecciona el codi lògic empresarial adequat i transmet els valors al codi Bean.

• Enterprise Java Bean (EJB) - Aquí és on es sol escriure i gestionar tota la lògica empresarial. A continuació, el bean crida el codi per llegir, escriure o actualitzar la base de dades. Un cop completades les operacions de la base de dades, la resposta es torna a transferir al Servlet, que al seu torn selecciona el JSP adequat per mostrar els resultats.

• Serveis web - Els serveis web són components d’una aplicació que s’executa en un servidor separat i es comunica mitjançant protocol HTTP.

• Base de dades - emmagatzema totes les dades de l'aplicació.

Tingueu en compte que no totes les aplicacions web segueixen les instruccions JSP -> Servlet -> EJB -> Model de base de dades . La majoria de les aplicacions J2EE s’escriuen actualment amb un framework com Struts, Spring o Hibernate. El disseny d’aplicacions varia per a cada requisit en funció de la mida de l’aplicació, el cost, el temps de desenvolupament, els recursos i la mida de l’equip.

Prova de l'aplicació JAVA / J2EE

Passem ara a provar tota una aplicació J2EE. Això es fa en diversos passos.Per exemple, considerem que tenim tres pantalles:

• Una pantalla d'inici de sessió
• Una pantalla de visualització dels empleats, que mostra tots els empleats de l'organització
• Una pantalla de modificació / addició / eliminació d'empleats.

La interfície d’usuari (User Interface) d’aquestes tres pantalles es desenvolupa amb JSP / HTML i les validacions es realitzen mitjançant JavaScript. Com que és una aplicació de mostra, la lògica es troba al Servlet i al DAO (objecte d'accés a dades). DAO és una classe per connectar-se a la base de dades.

A continuació es mostren les pantalles de mostra:

Prova manual d'aplicacions Java:

Durant les proves manuals de JAVA, un provador prepara els casos de prova a partir del document de disseny detallat i intenta cobrir tots els escenaris i fragments de codi possibles.

# 1) PROVA DE LA UNITAT DE JAVA

La prova unitària és un tipus de prova en què un usuari ha de provar els fragments de codi més petits per comprovar-ne la precisió, la correcció i el compliment dels requisits.

Agafem elexemple de la pantalla d'inici de sessió. La pantalla d'inici de sessió té dos camps de text: nom d'usuari i contrasenya, i té dos botons: enviar i cancel·lar.

Els casos de prova haurien de cobrir tots els bucles i declaracions condicionals. Els casos de prova han de mostrar els resultats esperats i les dades de la prova. A continuació es mostren alguns dels casos generals de prova que un usuari podria executar manualment en una pantalla d'inici de sessió. Els resultats s’anoten al document del cas de prova.

A continuació es mostra un format de cas de prova de mostra per a la pantalla d'inici de sessió.

Tot i que la taula mostra alguns dels casos de prova, a continuació es mostra la llista completa:

• Comproveu si hi ha alguna excepció, inclosa l'excepció del punter NULL
• Comproveu si no es permeten NULLS per al nom d'usuari i la contrasenya
• Comproveu si el nom d’usuari / contrasenya té el format correcte
• Comproveu si no es permeten números per al nom d'usuari
• Comproveu si no es permeten caràcters especials al nom d'usuari
• Comproveu si s’introdueix la combinació correcta de nom d’usuari i contrasenya i l’aplicació us portarà a la pantalla següent, és a dir, a la pantalla d’informació dels empleats
• Comproveu si el nom d’usuari introduït té la longitud correcta
• Comproveu si el camp de text del nom d'usuari només permet el nombre màxim de caràcters especificat per a aquest camp
• Comproveu si el camp de la contrasenya si s’especifica als requisits és visible com a * mentre s’introdueix
• Comproveu si les contrasenyes distingeixen entre majúscules i minúscules
• Comproveu si el nom d’usuari no distingeix entre majúscules i minúscules
• Comproveu si la pàgina d'inici de sessió no recorda el nom d'usuari ni la contrasenya, fins i tot després de sortir
• Comproveu si el botó Envia i Cancel·la funciona segons els requisits
• Si utilitzeu l'aplicació per primera vegada, comproveu si el nom d'usuari té permís per entrar a l'aplicació
• Suprimiu una combinació de nom d'usuari / contrasenya de la base de dades i comproveu si la combinació no pot tornar a iniciar sessió
• Per a tots els casos anteriors, comproveu si es mostren els missatges d'error de validació adequats
• Comproveu si les etiquetes i els botons es troben al lloc correcte de la pantalla i que mostren el text correctament
• Comproveu si les aparicions de la pantalla són segons els requisits
• Comproveu si es gestionen excepcions
• Comproveu si es realitza el registre per a les accions necessàries

Després d’examinar els casos de prova, us adonareu que us ocupeu principalment de la prova de camps, botons, funcionalitat i validacions d’una pantalla concreta. Això és precís, ja que la prova unitària s’ocupa molt de les proves de tots els fragments i components de codi petits. S’ha de fer el mateix tipus de proves per a totes les pantalles.

Tingueu en compte que els anteriors són només exemples i que els casos de prova es preparen a partir d’un document de disseny detallat i específic del projecte.

Llegiu també=> Mostra de casos de prova preparats per utilitzar i escenaris de prova per a proves d'aplicacions web.

# 2) PROVES D'INTEGRACIÓ

A les proves d’integració, els mòduls individuals s’integren i es comproven junts per comprovar-ne la correcció.

millor anti spyware per a Windows 7

Deixeu que cadascuna de les tres pantalles de l’exemple anterior la desenvolupin tres membres de l’equip diferents. Ara que han acabat amb les proves de la unitat, és hora de reunir tot el codi i comprovar si funcionen bé junts. Es realitzen proves d’integració per garantir que les dades o el control es transfereixen correctament d’una pantalla a una altra.

A continuació, es mostren alguns exemples de casos de prova d’integració per a l’exemple d’aplicació per a empleats:

• Comproveu si l’usuari que ha iniciat la sessió i la sessió són iguals a totes les altres pantalles integrades noves
• Comproveu si els altres mòduls no estan actualitzant / suprimint / inserint cap registre a la base de dades no obligatori
• Deixeu que hi hagi un camp d'estat dels empleats que digui 'Nou' a la incorporació, 'Actualitzat' a la modificació i 'Suprimit' a la supressió. Tot i que dues o tres pantalles poden utilitzar el mateix camp d'estat, és important assegurar-se que el camp no s'estigui actualitzant incorrectament.
• Comproveu si la capçalera, el peu de pàgina, la mida de la pantalla i l’aspecte compleixen els requisits després de la integració
• Comproveu que en fer clic als botons Envia, el control es transfereixi a la pantalla següent
• Comproveu que en fer clic al botó Cancel·la l’acció realitzada es cancel·li

A més, els casos de proves d’integració generals per a una aplicació J2EE podrien ser:

• Comproveu de cap a cap el flux de dades, ja sigui Object, XML o Session. Comproveu la correcció.
• Comproveu si cada sessió gestiona correctament la sessió
• Si hi ha aplicacions externes (serveis web), comproveu si la vostra aplicació pot fer trucades i recuperar dades de l'aplicació

# 3) PROVES DEL SISTEMA

A les proves del sistema, es prova tota la funcionalitat i integritat de l'aplicació respecte als requisits. Probablement seria més fàcil preguntar-se quan es realitzen proves de la unitat de tots els components i els components del codi també es combinen i comproven junts durant les proves d’integració, Què pot diferir en les proves del sistema? No és inexacte dir que la idea de les proves de sistema és trencar l'aplicació :)

Escenari núm. 1: Desenvolupeu una nova aplicació per a empleats amb un framework;per exemple, Puntals. També hi ha diverses altres aplicacions que s’executen en diferents servidors de la vostra organització. Tot i això, tots ells trucen al mateix servei web existent per obtenir l'adreça i el número de telèfon de qualsevol persona en particular.

Durant les proves d'integració, hauríeu provat si la vostra aplicació és capaç de fer una trucada al servei web i si podeu obtenir la resposta. Però, què passa si hi ha un problema al propi servei web? O el servei web no respon a algunes entrades rares? El servei web, en el nostre cas, només pot contenir un nombre màxim d'empleats de 6 caràcters. O bé, el servei web genera excepcions per a determinats formats d’adreça mentre torna. Això és extern, però també forma part de les proves del sistema.

Escenari núm. 2 : La vostra sol·licitud d'empleat està completa. Afegiu un empleat i genera un número d'empleat # 1001. Podeu modificar, eliminar, actualitzar, afegir, modificar, eliminar, afegir, afegir, afegir, modificar, eliminar i, finalment, afegir un altre. Què passa si el número de nou empleat torna a ser # 1001?

Escenari núm. 3 : Suposem que dos usuaris utilitzen l'aplicació alhora. Tots dos comencen a treballar amb el mateix empleat, se suprimeix un. Què passa si l’altre usuari pot procedir a la modificació dels mateixos empleats que s’emmagatzemen a la sessió?

A continuació es mostren alguns aspectes importants de les proves del sistema:

• Assegureu-vos que el flux de dades i el control siguin correctes des de d'extrem a extrem
• Assegureu la seguretat de les dades de la transacció
• Assegureu-vos que l'aplicació compleixi totes les funcionalitats empresarials
• Comproveu si l'aplicació funciona bé com a producte final: comproveu els enllaços trencats, la gestió de sessions, les galetes, el registre, la gestió d'errors, la gestió d'excepcions, la validació i el flux de transaccions.

# 4) PROVES DE RENDIMENT

Aquest tipus de proves es realitzen quan hi ha un gran nombre d'usuaris que utilitzen l'aplicació o una gran quantitat de dades a la base de dades, o ambdues coses. A continuació es detallen alguns dels casos:

• Si hi ha diversos usuaris que inicien sessió al mateix temps, comproveu que les aplicacions no es bloquegin
• Si hi ha una gran quantitat de dades disponibles a la base de dades, comproveu que les quadrícules de la pantalla de cerca no trigin gaire a executar consultes abans del temps d'espera de la sessió.
• En un entorn de diversos fils, comproveu que l'aplicació pugui gestionar bé tots els fils
• A les aplicacions on es creen un gran nombre d'objectes, comproveu si hi ha prou memòria assignada, si es gestiona la recollida d'escombraries i si no hi ha excepcions de manca de memòria

Conclusió

En aquest article, hem tractat una visió general d’una aplicació J2EE. També hem vist com realitzar manualment proves d’unitat, integració, funcionals i de sistema per a cadascun dels components de l’aplicació amb un exemple.

A la article següent , veurem com les proves d'automatització poden ser beneficioses per a grans aplicacions J2EE.

Sobre l'autor: Aquest és un article convidat de Padmavaty S. Amb més de 7 anys d’experiència en proves de programari, té una àmplia experiència en les proves de Java, J2EE, MVC i Struts.

Feu-nos saber si esteu treballant en la prova d’aplicacions JAVA. Comparteix la teva experiència i consultes als comentaris que hi ha a continuació.

PREV Tutorial | NEXT Tutorial

Lectura recomanada

• Documentació de preguntes de mostra de certificació de proves ISTQB amb respostes
• Com realitzar proves d'automatització d'aplicacions JAVA / J2EE (part 2)
• Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
• Els 20 millors consells pràctics sobre proves de programari que heu de llegir abans de provar qualsevol aplicació
• Proves d'aplicacions sanitàries: consells i escenaris importants de proves (part 2)
• Com es pot trobar un error a l'aplicació? Consells i trucs
• Proves de bases de dades amb JMeter
• Màquina virtual Java: com ajuda JVM a executar aplicacions Java