how test java applications tips with sample test cases
En este tutorial, aprenderemos los componentes involucrados en una aplicación Java y los diversos tipos de pruebas que se deben realizar para garantizar una aplicación de alta calidad y sin errores.
Esto es un Serie de tres partes sobre pruebas de aplicaciones JAVA.
- En este artículo, aprenderemos los componentes J2EE y el enfoque de prueba manual para una aplicación J2EE.
- En el segundo repasaremos el Prueba automatizada enfoque para probar aplicaciones J2EE, y
- En el tercero, revisaremos una lista completa de herramientas que están disponibles para probar aplicaciones J2EE.
Lo que vas a aprender:
- Comencemos con la descripción general de las aplicaciones J2EE
- Prueba de la aplicación JAVA / J2EE
- Prueba manual de aplicaciones Java:
- Conclusión
- Lectura recomendada
Comencemos con la descripción general de las aplicaciones J2EE
A Java La aplicación web consta de varios componentes, cada uno de los cuales tiene un propósito importante. MVC , que significa Model View Controller, se erige como el patrón de diseño arquitectónico más popular y de uso frecuente.
Antes de aprender a probar, repasemos brevemente el varios componentes de una aplicación J2EE.
- Cliente / Navegador solicita una dirección web con una URL.
- JSP (páginas del servidor Java) - JSP es una tecnología del lado del servidor destinada a presentar datos al usuario. Admite la visualización de contenido dinámico con la ayuda de etiquetas especiales llamadas etiquetas JSP, que ayudan a insertar código Java dentro de las páginas HTML. [El HTML estático siempre muestra el mismo contenido]. En tiempo de ejecución, una JSP se convierte en un servlet. La lógica empresarial no suele escribirse aquí.
- JSF (Caras del servidor Java) - JSF es un marco de componentes de vista para el diseño eficaz de la interfaz de usuario.
- Javascript / Jquery - son lenguajes de secuencias de comandos que se utilizan para la validación del lado del Cliente de la Vista / pantalla.
- Servlet - Un Servlet valida los datos recibidos de la entrada, selecciona el código de lógica de negocios apropiado y pasa los valores al código Bean.
- Enterprise Java Bean (EJB) - Aquí es donde normalmente se escribe y se maneja toda la lógica empresarial. Luego, el bean llama al código para leer, escribir o actualizar la base de datos. Una vez que se completan las operaciones de la base de datos, la respuesta se transfiere de nuevo al Servlet, que a su vez selecciona el JSP apropiado para mostrar los resultados.
- Servicios web - Los servicios web son componentes de una aplicación que se ejecutan en un servidor separado y se comunican a través del protocolo HTTP.
- Base de datos - almacena todos los datos de la aplicación.
Tenga en cuenta que no todas las aplicaciones web siguen las JSP -> Servlet -> EJB -> Modelo de base de datos . La mayoría de las aplicaciones J2EE están escritas actualmente con un marco como Struts, Spring o Hibernate. El diseño de las aplicaciones varía para cada requisito según el tamaño de la aplicación, el costo, el tiempo de desarrollo, los recursos y el tamaño del equipo.
Prueba de la aplicación JAVA / J2EE
Pasemos ahora a probar una aplicación J2EE completa. Esto se hace en varios pasos.Por ejemplo, considera que tenemos tres pantallas:
- Una pantalla de inicio de sesión
- Una pantalla de visualización de empleados, que enumera todos los empleados de la organización.
- Una pantalla de modificación / adición / eliminación de empleados.
La UI (User Interface) de estas tres pantallas se desarrolla con JSP / HTML y las validaciones se realizan a través de JavaScript. Debido a que es una aplicación de muestra, la lógica está en el Servlet y DAO (Objeto de acceso a datos). DAO es una clase para conectarse a la base de datos.
A continuación se muestran las pantallas de muestra:
Prueba manual de aplicaciones Java:
Durante las pruebas manuales de JAVA, un evaluador prepara los casos de prueba a partir del documento de diseño detallado e intenta cubrir todos los escenarios y fragmentos de código posibles.
# 1) PRUEBAS DE LA UNIDAD JAVA
La prueba unitaria es un tipo de prueba en el que un usuario necesita probar el más pequeño de los fragmentos de código para verificar su precisión, corrección y cumplimiento de los requisitos.
Tomemos elejemplo de la pantalla de inicio de sesión. La pantalla de inicio de sesión tiene dos campos de texto: nombre de usuario y contraseña, y tiene dos botones: enviar y cancelar.
Los casos de prueba deben cubrir todos los bucles y declaraciones condicionales. Los casos de prueba deben mostrar los resultados esperados y los datos de prueba. A continuación se muestran algunos de los casos de prueba generales que un usuario podría ejecutar manualmente en una pantalla de inicio de sesión. Luego, los resultados se anotan en el documento del caso de prueba.
A continuación se muestra un ejemplo de formato de caso de prueba para la pantalla de inicio de sesión.
S.No. | Caso de prueba | Resultado Esperado | Resultado actual | Contraseña errónea |
---|---|---|---|---|
4 | El usuario ingresa un nombre de usuario de más de 10 caracteres | Mensaje de error Se debe mostrar 'El nombre de usuario no debe tener más de 10 caracteres' | No se muestra el mensaje de error | FALLAR |
1 | El usuario comprueba la apariencia de las etiquetas Nombre de usuario, Contraseña | Las etiquetas deben estar correctamente escritas y mostradas en fuente de tamaño normal | El nombre de usuario y la contraseña de la etiqueta se muestran correctamente | PASAR |
2 | El usuario comprueba la apariencia del botón Enviar y cancelar | Los botones deben mostrarse con el nombre correcto | Los botones Enviar y Cancelar se muestran correctamente | PASAR |
3 | El usuario comprueba el color de fondo de la pantalla | El formulario de inicio de sesión debe estar dentro de una tabla blanca y la pantalla debe tener un fondo gris | La apariencia de la pantalla no coincide con los requisitos. | FALLAR |
4 | El usuario deja el cuadro de texto del nombre de usuario en blanco | Se debe mostrar el mensaje de error 'El nombre de usuario no puede estar vacío' | Aparece el mensaje de error 'El nombre de usuario no puede estar vacío' | PASAR |
5 | El usuario ingresa algún valor en el cuadro de texto del nombre de usuario y deja el cuadro de texto de la contraseña en blanco | Se debe mostrar el mensaje de error 'La contraseña no puede estar vacía' | Aparece el mensaje de error 'La contraseña no puede estar vacía' | PASAR |
6 | El usuario ingresa el nombre de usuario como 'abcd' y la contraseña como 'xxxx' | Mensaje de error 'Combinacion de usuario y contraseña invalida' debe ser mostrado | Mensaje de error 'Combinacion de usuario y contraseña invalida' se visualiza | PASAR |
5 | El usuario ingresa el nombre de usuario como 'usuario de prueba' y la contraseña como 'contraseña' y hace clic en el botón Enviar | El usuario debería poder ver la 'pantalla de detalles del empleado' | Se muestra la pantalla de detalles del empleado | PASAR |
Si bien la tabla enumera algunos de los casos de prueba, a continuación se muestra la lista completa:
- Compruebe si hay alguna excepción, incluida la excepción de puntero NULL
- Compruebe si no se permiten NULLS para nombre de usuario y contraseña
- Compruebe si el nombre de usuario / contraseña tiene el formato correcto
- Compruebe si no se permiten números para el nombre de usuario
- Compruebe si no se permiten caracteres especiales en el nombre de usuario
- Verifique si se ingresó la combinación correcta de nombre de usuario y contraseña, luego la aplicación lo lleva a la siguiente pantalla, es decir, la pantalla de información del empleado
- Verifique si el nombre de usuario ingresado tiene la longitud correcta
- Verifique si el campo de texto del nombre de usuario permite solo el número máximo de caracteres especificado para ese campo
- Verifique si el campo de contraseña, si se especifica en los requisitos, está visible como * al ingresar
- Compruebe si las contraseñas distinguen entre mayúsculas y minúsculas
- Compruebe si el nombre de usuario no distingue entre mayúsculas y minúsculas
- Compruebe si la página de inicio de sesión no recuerda el nombre de usuario o la contraseña, incluso después de salir
- Compruebe si el botón Enviar y Cancelar funciona según el requisito
- Si usa la aplicación por primera vez, verifique si el nombre de usuario tiene permiso para ingresar a la aplicación
- Elimine una combinación de nombre de usuario / contraseña de la base de datos y verifique si la combinación no puede iniciar sesión nuevamente
- Para todos los casos anteriores, verifique si se muestran los mensajes de error de validación apropiados
- Compruebe si las etiquetas y los botones están en el lugar correcto en la pantalla y que muestran el texto correctamente.
- Compruebe si las apariencias de la pantalla se ajustan a los requisitos
- Verifique si se manejan las excepciones
- Compruebe si se realiza el registro para las acciones necesarias
Después de pasar por los casos de prueba, puede darse cuenta de que se trata principalmente de probar campos, botones, funcionalidad y validaciones de una pantalla en particular. Esto es exacto, ya que Unit Testing se ocupa de la prueba de cada pequeño fragmento de código y componente. Se debe realizar el mismo tipo de prueba para todas las pantallas.
Tenga en cuenta que los anteriores son solo ejemplos y que los casos de prueba se preparan en base a un documento de diseño detallado y específico del proyecto.
Leer también=> Muestra casos de prueba listos para usar y escenarios de prueba para pruebas de aplicaciones web.
# 2) PRUEBAS DE INTEGRACIÓN
En las pruebas de integración, los módulos individuales se integran y prueban juntos para verificar su exactitud.
ejemplo de tabla hash de c ++
Deje que cada una de las tres pantallas del ejemplo anterior sea desarrollada por tres miembros del equipo diferentes. Ahora que han terminado con las pruebas unitarias, es hora de juntar todo el código y comprobar si funcionan bien juntos. Las pruebas de integración se realizan para garantizar que los datos o el control se transfieran correctamente de una pantalla a otra.
A continuación, se muestran algunos casos de prueba de integración de muestra para el ejemplo de aplicación de empleado:
- Compruebe si el usuario que inició sesión y la sesión son iguales en todas las demás pantallas integradas nuevas
- Verifique si los otros módulos no están actualizando / eliminando / insertando ningún registro en la base de datos no requerido
- Que haya un campo de estado de empleado, que diga 'Nuevo' al agregar, 'Actualizado' al modificar y 'Eliminado' al eliminarlo. Aunque dos o tres pantallas pueden usar el mismo campo de estado, es importante asegurarse de que el campo no se actualice incorrectamente.
- Compruebe si el encabezado, el pie de página, el tamaño de la pantalla y la apariencia cumplen los requisitos después de la integración
- Compruebe que al hacer clic en los botones Enviar, el control se transfiere a la siguiente pantalla
- Compruebe que al hacer clic en el botón Cancelar, se cancela la acción realizada
Además, los casos de prueba de integración general para una aplicación J2EE podrían ser:
- Verifique el flujo de datos, ya sea Objeto, XML o Sesión de un extremo a otro. Verifique la corrección.
- Comprobar si la sesión es gestionada correctamente por cada uno de los módulos
- Si hay aplicaciones externas (servicios web) involucradas, verifique si su aplicación puede realizar llamadas y recuperar datos de la aplicación.
# 3) PRUEBAS DEL SISTEMA
En las pruebas del sistema, se prueba la funcionalidad y la integridad de toda la aplicación con respecto a los requisitos. Probablemente sería más fácil preguntar cuándo se realizan las pruebas unitarias de cada componente y los componentes del código también se combinan y prueban juntos durante las pruebas de integración. ¿Qué podría ser diferente en las pruebas del sistema? No es inexacto decir que la idea en System Testing es romper la aplicación :)
Escenario 1: Desarrolla una nueva aplicación para empleados con un marco;por ejemplo, Puntales. También hay varias otras aplicaciones que se ejecutan en diferentes servidores de su organización. Sin embargo, todos ellos llaman al mismo servicio web existente para buscar la dirección y el número de teléfono de cualquier persona en particular.
Durante las pruebas de integración, habría probado si su aplicación puede realizar una llamada al servicio web y si puede obtener la respuesta. Pero, ¿qué pasa si hay un problema en el propio servicio web? ¿O el servicio web no responde a algunas entradas poco frecuentes? El servicio web, en nuestro caso, solo puede tener un número de empleado máximo de 6 caracteres. O el servicio web arroja excepciones para ciertos formatos de dirección mientras regresa. Esto es externo, pero también forma parte de las pruebas del sistema.
Escenario n. ° 2 : Su solicitud de empleado está completa. Agrega un empleado y genera un Número de empleado # 1001. Modifica, elimina, actualiza, agrega, modifica, elimina, agrega, agrega, agrega, modifica, elimina y finalmente agrega otro. ¿Qué pasa si el nuevo número de empleado es nuevamente # 1001?
Escenario n. ° 3 : Supongamos que dos usuarios están utilizando la aplicación al mismo tiempo. Ambos comienzan a trabajar en el mismo empleado, uno elimina. ¿Qué pasa si el otro usuario puede continuar con la modificación de los mismos empleados tal como está almacenada en la sesión?
A continuación se muestran algunos aspectos importantes de las pruebas del sistema:
- Asegúrese de que el flujo de datos y el control sea correcto desde de extremo a extremo
- Garantizar la seguridad de los datos de la transacción.
- Asegúrese de que la aplicación cumpla con todas las funcionalidades comerciales
- Verifique si la aplicación funciona bien como producto final: verifique los enlaces rotos, la administración de sesiones, las cookies, el registro, el manejo de errores, el manejo de excepciones, la validación y el flujo de transacciones.
# 4) PRUEBAS DE RENDIMIENTO
Este tipo de prueba se realiza cuando hay una gran cantidad de usuarios usando la aplicación o una gran cantidad de datos en la base de datos, o ambos. A continuación se muestran algunos de los casos:
- Si varios usuarios inician sesión al mismo tiempo, verifique que las aplicaciones no se cuelguen / bloqueen
- Si hay una gran cantidad de datos disponible en la base de datos, verifique que las cuadrículas de la pantalla de búsqueda no tarden mucho en ejecutar consultas antes del tiempo de espera de la sesión.
- En un entorno de subprocesos múltiples, verifique que la aplicación pueda manejar bien todos los subprocesos
- En aplicaciones donde se crean grandes cantidades de objetos, verifique si se asigna suficiente memoria, se maneja la recolección de basura y que no hay excepciones de memoria insuficiente
Conclusión
En este artículo, hemos cubierto una descripción general de una aplicación J2EE. También hemos visto cómo realizar manualmente pruebas unitarias, de integración, funcionales y de sistema para cada uno de los componentes de la aplicación con un ejemplo.
En el artículo siguiente , veremos cómo las pruebas de automatización pueden ser beneficiosas para grandes aplicaciones J2EE.
Sobre el autor: Este es un artículo invitado de Padmavaty S. Con más de 7 años de experiencia en pruebas de software, tiene una amplia experiencia en pruebas de Java, J2EE, MVC y Struts.
Háganos saber si está trabajando en probar aplicaciones JAVA. Comparta su experiencia y consultas en los comentarios a continuación.
PREV Tutorial | SIGUIENTE Tutorial
Lectura recomendada
- Documentos de preguntas de muestra de certificación de pruebas ISTQB con respuestas
- Cómo realizar pruebas de automatización de aplicaciones JAVA / J2EE (Parte 2)
- Mejores herramientas de prueba de software 2021 [Herramientas de automatización de pruebas de control de calidad]
- Los 20 principales consejos prácticos de prueba de software que debe leer antes de probar cualquier aplicación
- Prueba de aplicaciones sanitarias: consejos y escenarios de prueba importantes (parte 2)
- ¿Cómo encontrar un error en la aplicación? Consejos y trucos
- Prueba de base de datos con JMeter
- Máquina virtual Java: cómo JVM ayuda a ejecutar aplicaciones Java