Ejemplo de casos de prueba para aplicación web (lista de verificación)

⚡ Resumen inteligente

La lista de verificación completa para pruebas de aplicaciones web abarca comprobaciones de usabilidad, funcionalidad, compatibilidad, base de datos, API, seguridad, rendimiento y accesibilidad. Cada sección a continuación proporciona escenarios de prueba listos para usar que los equipos de control de calidad pueden copiar directamente en una herramienta de gestión de pruebas.

  • ⚙️ Lo funcional primero: Valide los campos obligatorios, las longitudes de los límites, los años bisiestos, la división por cero y el comportamiento de los tiempos de espera antes de que comience cualquier revisión estética.
  • 🧭 Señales de usabilidad: Verifique la alineación, las sugerencias emergentes, el acceso mediante teclado, las barras de desplazamiento y la recuperación de mensajes de error para que un usuario novato nunca se quede atascado.
  • 🌐 Matriz de compatibilidad: Repita los flujos críticos en Chrome, Firefox, Edge, Safari y los navegadores móviles para exponer las diferencias de diseño y script.
  • 🗄️ Integridad de la base de datos: Comparar los valores de la interfaz con los registros almacenados, verificar las claves, los disparadores, los procedimientos almacenados y la longitud de los campos en ambas capas.
  • ???? Capa API: Los códigos de estado, los esquemas, la autenticación, los límites de velocidad y el manejo de fallos posteriores deben gestionarse de forma independiente del navegador.
  • 🔐 Línea base de seguridad: Forzar el uso de HTTPS, cifrar los secretos almacenados, bloquear las cuentas tras repetidos fallos y detectar inyecciones SQL y ataques de fuerza bruta.
  • 🚀 Rendimiento y acceso: Automatiza la carga de perfiles mediante scripts en lugar de hacerlo manualmente, y luego confirma el contraste, las etiquetas y el funcionamiento del teclado según las directrices WCAG.

Al probar las aplicaciones web, se debe considerar la plantilla que se menciona a continuación. La lista de verificación que se menciona a continuación es casi aplicable a todo tipo de aplicaciones web, según los requisitos comerciales.

La plantilla anterior muestra cómo una hoja puede contener escenarios para cada área de la lista de verificación. Para obtener más información, consulte la pruebas de aplicaciones web visión general.

Ahora veamos cada lista de verificación en detalle:

Prueba de funcion

¿Qué son las pruebas funcionales?

  • Probar las características y el comportamiento operativo de un producto para garantizar que corresponden a sus especificaciones.
  • Pruebas que ignoran el mecanismo interno de un sistema o componente y se centran únicamente en los resultados generados en respuesta a entradas seleccionadas y condiciones de ejecución.

¿Cuál es el propósito u objetivo de las pruebas funcionales?

  • El objetivo de los Prueba de funcion es verificar si su producto cumple con las especificaciones funcionales previstas mencionadas en su documentación de desarrollo.

Ejemplos de escenarios de pruebas funcionales:

  • Pruebe que todos los campos obligatorios deben estar validados.
  • Pruebe que el signo de asterisco debería aparecer en todos los campos obligatorios.
  • Pruebe que el sistema no debería mostrar el mensaje de error para los campos opcionales.
  • Pruebe que los años bisiestos se validen correctamente y no causen errores o errores de cálculo.
  • Pruebe que los campos numéricos no deberían aceptar los alfabetos y debería aparecer el mensaje de error adecuado.
  • Prueba números negativos si se permite para campos numéricos.
  • La división de prueba por cero debe manejarse adecuadamente para los cálculos.
  • Pruebe la longitud máxima de cada campo para asegurarse de que los datos no se trunquen.
  • Pruebe que debería aparecer el mensaje emergente (“Este campo está limitado a 500 caracteres”) si los datos alcanzan el tamaño máximo del campo.
  • Pruebe que se muestre un mensaje de confirmación para las operaciones de actualización y eliminación.
  • Pruebe que los valores de cantidad deben mostrarse en formato de moneda.
  • Pruebe todos los campos de entrada en busca de caracteres especiales.
  • Pruebe la funcionalidad de tiempo de espera.
  • Pruebe la funcionalidad de clasificación.
  • Pruebe la funcionalidad de los botones disponibles.
  • Pruebe que la Política de privacidad y las preguntas frecuentes están claramente definidas y deberían estar disponibles para los usuarios.
  • Pruebe si alguna funcionalidad falla y el usuario será redirigido a la página de error personalizada.
  • Pruebe que todos los documentos cargados se abran correctamente.
  • Pruebe que el usuario debería poder descargar los archivos cargados.
  • Pruebe la funcionalidad de correo electrónico del sistema.
  • Prueba el Java El script funciona correctamente en diferentes navegadores (IE, Firefox, Chrome, safari y Opera).
  • Pruebe para ver qué sucede si un usuario elimina las cookies mientras está en el sitio.
  • Pruebe para ver qué sucede si un usuario elimina las cookies después de visitar un sitio.
  • Pruebe que todos los datos dentro del cuadro combinado/lista estén organizados en orden cronológico.

Una vez que las funciones se comportan correctamente, la siguiente pregunta es si los usuarios reales pueden utilizarlas sin ayuda.

Las pruebas de usabilidad

¿Qué son las pruebas de usabilidad?

  • Las pruebas de usabilidad no son más que la comprobación de la facilidad de uso.
  • En las pruebas de usabilidad, se prueba el flujo de la aplicación para que un nuevo usuario pueda comprenderla fácilmente.
  • Básicamente, la navegación del sistema se comprueba en las pruebas de usabilidad.

¿Cuál es el propósito u objetivo de las pruebas de usabilidad?

Una prueba de usabilidad establece la facilidad de uso y la eficacia de un producto utilizando prácticas de prueba de usabilidad estándar.

Ejemplos de casos de prueba de usabilidad

  • El contenido de la página web debe ser correcto sin errores ortográficos ni gramaticales.
  • Todas las fuentes deben ser las mismas según los requisitos.
  • Todo el texto debe estar correctamente alineado.
  • Todos los mensajes de error deben ser correctos sin errores ortográficos o gramaticales y el mensaje de error debe coincidir con la etiqueta del campo.
  • El texto de información sobre herramientas debe estar ahí para cada campo.
  • Todos los campos deben estar correctamente alineados.
  • Se debe proporcionar suficiente espacio entre las etiquetas de los campos, columnas, filas y mensajes de error.
  • Todos los botones deben tener un formato y tamaño estándar.
  • El enlace de inicio debe estar en cada página.
  • Los campos deshabilitados deben aparecer en gris.
  • Compruebe si hay enlaces e imágenes rotos.
  • Debe mostrarse un mensaje de confirmación para cualquier tipo de operación de actualización o eliminación.
  • Consulte el sitio en diferentes resoluciones (¿640 x 480, 600 × 800, etc.?)
  • Verifique que el usuario final pueda ejecutar el sistema sin frustraciones.
  • Verifique que la pestaña debería funcionar correctamente.
  • La barra de desplazamiento debería aparecer sólo si es necesario.
  • Si hay un mensaje de error al enviar, la información completada por el usuario debe estar allí.
  • El título debe aparecer en cada página web.
  • Todos los campos (cuadro de texto, menú desplegable, botón de opción, etc.) y botones deben ser accesibles mediante atajos de teclado y el usuario debe poder realizar todas las operaciones usando el teclado.
  • Compruebe si los datos desplegables no están truncados debido al tamaño del campo. Además, verifique si los datos están codificados o administrados a través del administrador.

Un diseño que se visualiza correctamente en un navegador puede fallar en otro, por lo que conviene reproducir las mismas pantallas en todos los entornos compatibles.

Pruebas de compatibilidad

¿Qué son las pruebas de compatibilidad?

  • Las pruebas de compatibilidad se utilizan para determinar si su software es compatible con otros elementos de un sistema con el que debería funcionar, por ejemplo, navegadores, OperaSistemas de ting o hardware.

¿Cuál es el propósito u objetivo de las pruebas de compatibilidad?

  • El propósito de las pruebas de compatibilidad es evaluar qué tan bien funciona el software en un navegador en particular. OperaSistemas de ting, hardware o software.

Escenarios de prueba de compatibilidad de muestra:

  • Pruebe el sitio web en diferentes navegadores (IE, Firefox, Chrome, Safari y Opera) y asegúrese de que el sitio web se muestre correctamente.
  • Pruebe que la versión HTML que se utiliza sea compatible con las versiones apropiadas del navegador.
  • Pruebe que las imágenes se muestren correctamente en diferentes navegadores.
  • Pruebe que las fuentes se puedan utilizar en diferentes navegadores.
  • Pruebe que el código del script Java se pueda utilizar en diferentes navegadores.
  • Pruebe los GIF animados en diferentes navegadores.

La representación consistente no prueba nada sobre los registros detrás de la pantalla. pruebas de navegador cruzado La matriz mantiene esta área bajo control.

Prueba de base de datos

¿Qué es la prueba de base de datos?

  • In Prueba de base de datos Se prueban los registros backend que se han insertado a través de la web o aplicaciones de escritorio. Los datos que se muestran en la aplicación web deben coincidir con los datos almacenados en la base de datos.

Para realizar la prueba de la base de datos, el evaluador debe tener en cuenta los puntos mencionados a continuación:

  • El evaluador debe comprender a fondo los requisitos funcionales, la lógica empresarial, el flujo de aplicaciones y el diseño de la base de datos.
  • El evaluador debe descubrir las tablas, activadores, procedimientos de almacenamiento, vistas y cursores utilizados para la aplicación.
  • El evaluador debe comprender la lógica de los activadores, procedimientos de almacenamiento, vistas y cursores creados.
  • El evaluador debe determinar las tablas que se ven afectadas cuando se realizan operaciones de inserción, actualización y eliminación (DML) a través de aplicaciones web o de escritorio.

Con la ayuda de los puntos mencionados anteriormente, el evaluador puede escribir fácilmente los escenarios de prueba para las pruebas de bases de datos.

Casos de prueba de ejemplo para pruebas de bases de datos:

  • Verifique el nombre de la base de datos: El nombre de la base de datos debe coincidir con las especificaciones.
  • Verifique las tablas, columnas, tipos de columnas y valores predeterminados: todo debe coincidir con las especificaciones.
  • Verifique si la columna permite un valor nulo o no.
  • Verifique la clave primaria y externa de cada tabla.
  • Verifique el procedimiento almacenado:
  • Pruebe si el procedimiento almacenado está instalado o no.
  • Verifique el nombre del procedimiento almacenado
  • Verifique los nombres de los parámetros, los tipos y la cantidad de parámetros.
  • Pruebe los parámetros si son necesarios o no.
  • Pruebe el procedimiento almacenado eliminando algunos parámetros
  • Pruebe cuando la salida sea cero, los registros cero deberían verse afectados.
  • Pruebe el procedimiento almacenado escribiendo simple SQL consultas
  • Pruebe si el procedimiento almacenado devuelve los valores
  • Pruebe el procedimiento almacenado con datos de entrada de muestra.
  • Verifique el comportamiento de cada bandera en la tabla.
  • Verifique que los datos se guarden correctamente en la base de datos después de enviar cada página.
  • Verificar los datos si se realizan las operaciones DML (Actualizar, eliminar e insertar).
  • Verifique la longitud de cada campo: la longitud del campo en la parte posterior y frontal debe ser la misma.
  • Verifique los nombres de las bases de datos de QA, UAT y producción. Los nombres deben ser únicos.
  • Verifique los datos cifrados en la base de datos.
  • Verifique el tamaño de la base de datos. Pruebe también el tiempo de respuesta de cada consulta ejecutada.
  • Verifique los datos que se muestran en el front-end y asegúrese de que sean los mismos en el back-end.
  • Verifique la validez de los datos insertando los datos no válidos en la base de datos.
  • Verifique los desencadenantes.

Lista de verificación para pruebas de API

La mayoría de las reglas de negocio ahora se encuentran detrás de puntos finales REST o GraphQL, por lo que las comprobaciones del navegador por sí solas no pueden demostrar que el sistema funciona. Probar los puntos finales directamente expone la vulnerabilidad.tracy los defectos de autorización mucho antes de que la interfaz de usuario pueda.

Antes de aprobar un punto final, tenga en cuenta los siguientes escenarios:

Ejemplos de escenarios de prueba para la comprobación de API:

  • Verifique los códigos de estado documentados para éxito, fallo de validación, acceso no autorizado y error del servidor.
  • Verifique que la respuesta se ajuste al esquema publicado, incluidos los nombres de los campos y los tipos de datos.
  • Verificar que los parámetros faltantes o mal formados devuelvan un mensaje legible en lugar de una pila trace.
  • Verifique que los tokens de autenticación caduquen, se actualicen correctamente y no se puedan volver a utilizar después de cerrar la sesión.
  • Verifique la autorización basada en roles, de modo que una cuenta estándar no pueda acceder a los puntos finales del administrador alterando un identificador.
  • Verifique los valores límite de cada parámetro, incluidas las cadenas vacías y las longitudes máximas.
  • Verifique que la limitación de velocidad devuelva la respuesta de limitación correcta en lugar de fallar silenciosamente.
  • Verifique que el punto final se degrade correctamente cuando un servicio de terceros agote el tiempo de espera.
  • Verifique que no aparezcan contraseñas, tokens o rutas internas en las respuestas o mensajes de error.

Ejecute esta lista en todos los entornos, ya que los entornos de prueba y producción suelen exponer diferentes conjuntos de permisos. Consulte la Pruebas de API visión general y probar una API REST manualmente.

Varias de esas comprobaciones coinciden con las labores de seguridad.

Pruebas de seguridad

Pruebas de seguridad Implica la prueba para identificar fallas y brechas desde el punto de vista de la seguridad.

Escenarios de prueba de muestra para pruebas de seguridad:

  • Verifique que la página web que contiene datos importantes como contraseñas, números de tarjetas de crédito, respuestas secretas para preguntas de seguridad, etc., debe enviarse a través de HTTPS (SSL).
  • Verifique que la información importante como contraseña, números de tarjetas de crédito, etc., debe mostrarse en formato cifrado.
  • Verifique que las reglas de contraseña estén implementadas en todas las páginas de autenticación, como Registro, Olvidé mi contraseña y cambio de contraseña.
  • Verifique que si se cambia la contraseña, el usuario no debería poder iniciar sesión con la contraseña anterior.
  • Verifique que los mensajes de error no muestren ninguna información importante.
  • Verifique si el usuario cerró sesión en el sistema o si la sesión del usuario expiró, el usuario no debería poder navegar por el sitio.
  • Verifique para acceder a las páginas web seguras y no seguras directamente sin iniciar sesión.
  • Verifique que la opción "Ver código fuente" esté deshabilitada y no deba ser visible para el usuario.
  • Verifique que la cuenta de usuario se bloquee si el usuario ingresa la contraseña incorrecta varias veces.
  • Verifique que las cookies no deben almacenar contraseñas.
  • Verifique si alguna funcionalidad no funciona; el sistema no debería mostrar ninguna información de aplicación, servidor o base de datos. En su lugar, debería mostrar la página de error personalizada.
  • Verificar los ataques de inyección SQL.
  • Verifique los roles de los usuarios y sus derechos. Por ejemplo, el solicitante no debería poder acceder a la página de administración.
  • Verifique que las operaciones importantes se escriban en los archivos de registro y que esa información esté traccapaz.
  • Verifique que los valores de la sesión estén en formato cifrado en la barra de direcciones.
  • Verifique que la información de las cookies se almacene en formato cifrado.
  • Verificar la aplicación para ataques de fuerza bruta

Una aplicación endurecida que se deforma bajo carga sigue siendo inutilizable, por lo que la siguiente pasada mide la escala.

Test de rendimiento

Test de rendimiento Se lleva a cabo para evaluar el cumplimiento de un sistema o componente con requisitos de rendimiento específicos.

Escenarios de prueba generales:

  • Determinar el rendimiento, estabilidad y escalabilidad de una aplicación bajo diferentes condiciones de carga.
  • Para determinar si la arquitectura actual puede soportar la aplicación en niveles máximos de usuarios.
  • Determinar qué tamaño de configuración proporciona el mejor nivel de rendimiento.
  • Identificar cuellos de botella en aplicaciones e infraestructura.
  • Determinar si la nueva versión del software tuvo un impacto adverso en el tiempo de respuesta.
  • Evaluar el producto y/o el hardware para determinar si puede manejar los volúmenes de carga proyectados.

¿Cómo hacer pruebas de rendimiento? Mediante pruebas manuales o mediante automatización

Prácticamente no es posible realizar las pruebas de rendimiento manualmente debido a algunos inconvenientes como:

  • Se necesitarán más recursos.
  • No son posibles acciones simultáneas.
  • No se dispone de una supervisión adecuada del sistema.
  • No es fácil realizar la tarea repetitiva.

Por lo tanto, para superar los problemas anteriores debemos utilizar la herramienta de prueba de rendimiento. A continuación se muestra la lista de algunas herramientas de prueba populares.

Todavía falta un segmento de la población: los usuarios que acceden a estas pantallas mediante tecnologías de asistencia.

Lista de verificación para pruebas de accesibilidad

Las pruebas de accesibilidad confirman que las personas que utilizan lectores de pantalla, navegación solo con teclado o ampliación pueden completar los mismos recorridos que todos los demás. También es un requisito de adquisición, ya que la empresatracts comúnmente hacen referencia WCAG 2.2 Nivel AAEstos defectos son estructurales y su reparación temprana resulta mucho más económica.

Ejemplos de escenarios de prueba para las pruebas de accesibilidad:

  • Verifique que las imágenes significativas incluyan texto alternativo descriptivo y que las imágenes decorativas estén ocultas para las tecnologías de asistencia.
  • Verifique que cada control de formulario tenga una etiqueta asociada mediante programación, y no solo un texto de marcador de posición adyacente.
  • Verifique que la página funcione solo con el teclado, con un indicador de enfoque visible en cada parada.
  • Verifique que el texto y los elementos interactivos cumplan con la relación de contraste mínima con respecto a su fondo.
  • Verifique que los encabezados sigan un orden lógico sin niveles omitidos, para que la navegación del lector de pantalla funcione correctamente.
  • Verifique que los mensajes de error se anuncien a la tecnología de asistencia e identifique el campo que presenta el fallo.
  • Verifique que la página siga siendo utilizable con un zoom del 200 por ciento sin desplazamiento horizontal.
  • Verifique que los widgets personalizados, como modales, pestañas y acordeones, muestren los roles y estados correctos.

Los escáneres automatizados solo detectan una parte de estos problemas, así que añada un pase manual de teclado y lector de pantalla. pruebas de accesibilidad La referencia abarca las herramientas.

Preguntas Frecuentes

Un plan de pruebas es un documento formal que abarca el alcance, el cronograma, los recursos, los riesgos y los criterios de finalización de una versión. Una lista de verificación es un recordatorio conciso de la cobertura que enumera las condiciones a verificar. El plan rige el proyecto; la lista de verificación rige la sesión de pruebas individual.

RevRevísala después de cada lanzamiento importante, nueva integración o incidente en producción. Cada defecto detectado debe añadir una línea para evitar que se repita el mismo fallo. Una lista de verificación que nunca se revisa deja de reflejar con precisión el comportamiento real de la aplicación.

La mayoría de los equipos basan la cobertura de seguridad en el Guía de pruebas de seguridad web de OWASP, accesibilidad a WCAG 2.2 y terminología general del proceso según ISTQB. Estas referencias permiten auditar la lista de verificación en lugar de basarla únicamente en los hábitos del equipo.

Sí. Al introducir requisitos, historias de usuario o especificaciones de API en un modelo de lenguaje extenso, se obtiene un primer borrador sólido de escenarios. Sin embargo, el evaluador debe eliminar duplicados, añadir reglas de negocio que el modelo no puede inferir y confirmar que cada elemento sea realmente verificable.

Los localizadores autorreparables vuelven a identificar los elementos tras los cambios de marcado, reduciendo los fallos intermitentes que consumen la mayor parte del mantenimiento. La IA también agrupa los defectos duplicados y prioriza qué conjuntos de pruebas ejecutar, de modo que los ciclos de regresión se mantienen cortos a medida que aumenta la lista de verificación.

Resumir este post con: