Pruebas de software: niveles
Hay diferentes niveles durante el proceso de prueba. En este capítulo, se proporciona una breve descripción sobre estos niveles.
Los niveles de prueba incluyen diferentes metodologías que se pueden utilizar al realizar pruebas de software. Los principales niveles de prueba de software son:
Pruebas funcionales
Pruebas no funcionales
Pruebas funcionales
Este es un tipo de prueba de caja negra que se basa en las especificaciones del software que se va a probar. La aplicación se prueba proporcionando información y luego se examinan los resultados que deben ajustarse a la funcionalidad para la que fue diseñada. Las pruebas funcionales de un software se llevan a cabo en un sistema completo e integrado para evaluar el cumplimiento del sistema con sus requisitos especificados.
Hay cinco pasos involucrados al probar la funcionalidad de una aplicación.
| Pasos | Descripción |
|---|---|
| yo | La determinación de la funcionalidad que la aplicación deseada debe realizar. |
| II | La creación de datos de prueba basados en las especificaciones de la aplicación. |
| III | La salida basada en los datos de prueba y las especificaciones de la aplicación. |
| IV | La redacción de escenarios de prueba y la ejecución de casos de prueba. |
| V | La comparación de los resultados reales y esperados en función de los casos de prueba ejecutados. |
Una práctica de prueba efectiva verá los pasos anteriores aplicados a las políticas de prueba de cada organización y, por lo tanto, se asegurará de que la organización mantenga los estándares más estrictos en lo que respecta a la calidad del software.
Examen de la unidad
Los desarrolladores realizan este tipo de prueba antes de que la configuración se entregue al equipo de pruebas para ejecutar formalmente los casos de prueba. Las pruebas unitarias son realizadas por los desarrolladores respectivos en las unidades individuales de áreas asignadas al código fuente. Los desarrolladores utilizan datos de prueba que son diferentes de los datos de prueba del equipo de garantía de calidad.
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas en términos de requisitos y funcionalidad.
Limitaciones de las pruebas unitarias
Las pruebas no pueden detectar todos y cada uno de los errores de una aplicación. Es imposible evaluar cada ruta de ejecución en cada aplicación de software. Lo mismo ocurre con las pruebas unitarias.
Existe un límite en la cantidad de escenarios y datos de prueba que un desarrollador puede usar para verificar un código fuente. Después de haber agotado todas las opciones, no queda más remedio que detener las pruebas unitarias y fusionar el segmento de código con otras unidades.
Pruebas de integración
La prueba de integración se define como la prueba de partes combinadas de una aplicación para determinar si funcionan correctamente. Las pruebas de integración se pueden realizar de dos formas: pruebas de integración ascendente y pruebas de integración descendente.
| No Señor. | Método de prueba de integración |
|---|---|
| 1 | Bottom-up integration Esta prueba comienza con pruebas unitarias, seguidas de pruebas de combinaciones de unidades de nivel progresivamente superior llamadas módulos o compilaciones. |
| 2 | Top-down integration En esta prueba, los módulos de nivel más alto se prueban primero y progresivamente, los módulos de nivel inferior se prueban a partir de entonces. |
En un entorno de desarrollo de software integral, las pruebas de abajo hacia arriba generalmente se realizan primero, seguidas de las pruebas de arriba hacia abajo. El proceso concluye con múltiples pruebas de la aplicación completa, preferiblemente en escenarios diseñados para imitar situaciones reales.
Prueba del sistema
La prueba del sistema prueba el sistema en su totalidad. Una vez que todos los componentes están integrados, la aplicación en su conjunto se prueba rigurosamente para comprobar que cumple con los estándares de calidad especificados. Este tipo de prueba es realizada por un equipo de pruebas especializado.
La prueba del sistema es importante por las siguientes razones:
La prueba del sistema es el primer paso en el ciclo de vida del desarrollo de software, donde la aplicación se prueba como un todo.
La aplicación se prueba minuciosamente para verificar que cumple con las especificaciones técnicas y funcionales.
La aplicación se prueba en un entorno muy cercano al entorno de producción donde se implementará la aplicación.
Las pruebas del sistema nos permiten probar, verificar y validar tanto los requisitos comerciales como la arquitectura de la aplicación.
Pruebas de regresión
Siempre que se realiza un cambio en una aplicación de software, es muy posible que otras áreas dentro de la aplicación se hayan visto afectadas por este cambio. La prueba de regresión se realiza para verificar que un error corregido no haya resultado en otra funcionalidad o violación de reglas comerciales. La intención de las pruebas de regresión es garantizar que un cambio, como la corrección de un error, no dé lugar a que se descubra otro error en la aplicación.
La prueba de regresión es importante por las siguientes razones:
Minimice las brechas en las pruebas cuando se deba probar una aplicación con cambios realizados.
Probar los nuevos cambios para verificar que los cambios realizados no afectaron a ninguna otra área de la aplicación.
Mitiga los riesgos cuando se realizan pruebas de regresión en la aplicación.
La cobertura de la prueba se incrementa sin comprometer los plazos.
Incrementar la velocidad de comercialización del producto.
Test de aceptación
Este es posiblemente el tipo de prueba más importante, ya que lo lleva a cabo el equipo de control de calidad, que evaluará si la aplicación cumple con las especificaciones previstas y satisface los requisitos del cliente. El equipo de control de calidad tendrá un conjunto de escenarios y casos de prueba escritos previamente que se utilizarán para probar la aplicación.
Se compartirán más ideas sobre la aplicación y se pueden realizar más pruebas para evaluar su precisión y las razones por las que se inició el proyecto. Las pruebas de aceptación no solo están destinadas a señalar errores de ortografía simples, errores cosméticos o lagunas en la interfaz, sino también a señalar cualquier error en la aplicación que resultará en fallas del sistema o errores importantes en la aplicación.
Al realizar pruebas de aceptación en una aplicación, el equipo de pruebas reducirá el rendimiento de la aplicación en producción. También existen requisitos legales y contractuales para la aceptación del sistema.
Prueba alfa
Esta prueba es la primera etapa de la prueba y se realizará entre los equipos (desarrolladores y equipos de control de calidad). Las pruebas unitarias, las pruebas de integración y las pruebas del sistema cuando se combinan juntas se conocen como pruebas alfa. Durante esta fase, se probarán los siguientes aspectos en la aplicación:
Faltas de ortografía
Enlaces rotos
Direcciones nubladas
La aplicación se probará en máquinas con la especificación más baja para probar los tiempos de carga y cualquier problema de latencia.
Prueba Beta
Esta prueba se realiza después de que la prueba alfa se haya realizado con éxito. En las pruebas beta, una muestra de la audiencia prevista prueba la aplicación. La prueba beta también se conoce comopre-release testing. Las versiones de prueba beta del software se distribuyen idealmente a una amplia audiencia en la Web, en parte para proporcionar al programa una prueba del "mundo real" y en parte para proporcionar una vista previa de la próxima versión. En esta fase, la audiencia probará lo siguiente:
Los usuarios instalarán, ejecutarán la aplicación y enviarán sus comentarios al equipo del proyecto.
Errores tipográficos, flujo de aplicaciones confuso e incluso bloqueos.
Al recibir los comentarios, el equipo del proyecto puede solucionar los problemas antes de lanzar el software a los usuarios reales.
Cuantos más problemas solucione que resuelvan problemas reales de los usuarios, mayor será la calidad de su aplicación.
Tener una aplicación de mayor calidad cuando la publiques al público en general aumentará la satisfacción del cliente.
Pruebas no funcionales
Esta sección se basa en probar una aplicación a partir de sus atributos no funcionales. Las pruebas no funcionales implican probar un software a partir de los requisitos que son de naturaleza no funcional pero importantes como el rendimiento, la seguridad, la interfaz de usuario, etc.
Algunos de los tipos de pruebas no funcionales importantes y de uso común se analizan a continuación.
Pruebas de rendimiento
Se utiliza principalmente para identificar cuellos de botella o problemas de rendimiento en lugar de encontrar errores en un software. Hay diferentes causas que contribuyen a reducir el rendimiento de un software:
Retraso de la red
Procesamiento del lado del cliente
Procesamiento de transacciones de base de datos
Equilibrio de carga entre servidores
Representación de datos
Las pruebas de rendimiento se consideran uno de los tipos de pruebas importantes y obligatorias en términos de los siguientes aspectos:
Velocidad (es decir, tiempo de respuesta, procesamiento de datos y acceso)
Capacity
Stability
Scalability
Las pruebas de rendimiento pueden ser cualitativas o cuantitativas y se pueden dividir en diferentes subtipos, como Load testing y Stress testing.
Prueba de carga
Es un proceso de prueba del comportamiento de un software aplicando la carga máxima en términos de acceso de software y manipulación de grandes datos de entrada. Puede realizarse tanto en condiciones de carga normal como máxima. Este tipo de prueba identifica la capacidad máxima del software y su comportamiento en horas pico.
La mayoría de las veces, las pruebas de carga se realizan con la ayuda de herramientas automatizadas como Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, etc.
Los usuarios virtuales (VUsers) se definen en la herramienta de prueba automatizada y el script se ejecuta para verificar la prueba de carga del software. El número de usuarios se puede aumentar o disminuir de forma simultánea o incremental según los requisitos.
Pruebas de estrés
Las pruebas de estrés incluyen probar el comportamiento de un software en condiciones anormales. Por ejemplo, puede incluir quitar algunos recursos o aplicar una carga más allá del límite de carga real.
El objetivo de las pruebas de estrés es probar el software aplicando la carga al sistema y asumiendo los recursos utilizados por el software para identificar el punto de ruptura. Esta prueba se puede realizar probando diferentes escenarios como:
Apagar o reiniciar los puertos de red al azar
Activar o desactivar la base de datos
Ejecutando diferentes procesos que consumen recursos como CPU, memoria, servidor, etc.
Pruebas de usabilidad
La prueba de usabilidad es una técnica de caja negra y se utiliza para identificar cualquier error (s) y mejoras en el software al observar a los usuarios a través de su uso y operación.
Según Nielsen, la usabilidad se puede definir en términos de cinco factores, es decir, eficiencia de uso, capacidad de aprendizaje, capacidad de memoria, errores / seguridad y satisfacción. Según él, la usabilidad de un producto será buena y el sistema será utilizable si posee los factores anteriores.
Nigel Bevan y Macleod consideraron que la usabilidad es el requisito de calidad que se puede medir como resultado de las interacciones con un sistema informático. Este requisito se puede cumplir y el usuario final estará satisfecho si los objetivos previstos se logran de manera efectiva con el uso de los recursos adecuados.
Molich en 2000 declaró que un sistema fácil de usar debe cumplir los siguientes cinco objetivos, es decir, fácil de aprender, fácil de recordar, eficiente de usar, satisfactorio de usar y fácil de entender.
Además de las diferentes definiciones de usabilidad, existen algunos estándares y modelos y métodos de calidad que definen la usabilidad en forma de atributos y sub-atributos como ISO-9126, ISO-9241-11, ISO-13407 e IEEE std. 610.12, etc.
UI vs pruebas de usabilidad
La prueba de IU implica probar la interfaz gráfica de usuario del software. Las pruebas de IU aseguran que la GUI funcione de acuerdo con los requisitos y se pruebe en términos de color, alineación, tamaño y otras propiedades.
Por otro lado, las pruebas de usabilidad aseguran una GUI buena y fácil de usar que se puede manejar fácilmente. Las pruebas de IU pueden considerarse una subparte de las pruebas de usabilidad.
Pruebas de seguridad
Las pruebas de seguridad implican probar un software para identificar fallas y brechas desde el punto de vista de la seguridad y la vulnerabilidad. A continuación se enumeran los aspectos principales que deben garantizar las pruebas de seguridad:
Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
El software está protegido contra vulnerabilidades conocidas y desconocidas
Los datos del software están seguros
El software cumple con todas las normas de seguridad.
Comprobación y validación de entrada
Ataques de inserción SQL
Defectos de inyección
Problemas de gestión de sesiones
Ataques de secuencias de comandos entre sitios
El búfer desborda vulnerabilidades
Ataques transversales de directorio
Prueba de portabilidad
Las pruebas de portabilidad incluyen probar un software con el objetivo de garantizar su reutilización y que también se pueda mover desde otro software. Las siguientes son las estrategias que se pueden utilizar para las pruebas de portabilidad:
Transferir un software instalado de una computadora a otra.
Construyendo ejecutable (.exe) para ejecutar el software en diferentes plataformas.
Las pruebas de portabilidad se pueden considerar como una de las subpartes de las pruebas del sistema, ya que este tipo de prueba incluye pruebas generales de un software con respecto a su uso en diferentes entornos. El hardware, los sistemas operativos y los navegadores de la computadora son el foco principal de las pruebas de portabilidad. Algunas de las condiciones previas para las pruebas de portabilidad son las siguientes:
El software debe diseñarse y codificarse teniendo en cuenta los requisitos de portabilidad.
Se han realizado pruebas unitarias en los componentes asociados.
Se han realizado pruebas de integración.
Se ha establecido un entorno de prueba.