¿Qué son las pruebas no funcionales?
- 7 minutos
En Ejecución de pruebas funcionales en Azure Pipelines, se agregaron pruebas de interfaz de usuario de Selenium a la canalización. Las pruebas de interfaz de usuario son un tipo de pruebas funcionales. En esta parte, explorará los tipos de pruebas no funcionales que puede ejecutar en una canalización.
El equipo primero define las pruebas no funcionales. Hablan sobre algunos tipos de estas pruebas. Después, deciden agregar una prueba no funcional a su canalización.
¿En qué se diferencian las pruebas no funcionales de las pruebas funcionales?
En Ejecución de pruebas funcionales en Azure Pipelines, definimos las pruebas funcionales y las pruebas no funcionales.
Para resumirlo, las pruebas funcionales comprueban que cada función del software haga lo que debería. En otras palabras, las pruebas funcionales comprueban la funcionalidad de una aplicación.
Las pruebas no funcionales comprueban los aspectos no funcionales de una aplicación, como el rendimiento y la confiabilidad. También se pueden ejecutar pruebas no funcionales en sistemas que no son aplicaciones, como los componentes de la infraestructura. Un ejemplo de prueba no funcional es determinar cuántas personas pueden iniciar sesión simultáneamente en una aplicación sin causar un problema, como tiempos de respuesta más lentos.
Si tomamos el sitio web Space Game como ejemplo, una prueba funcional podría comprobar que el marcador aparece correctamente y que muestra los registros correctos cuando el usuario selecciona un filtro. Una prueba no funcional podría comprobar que el filtrado de los marcadores se completa en menos de un segundo, incluso cuando hay muchos usuarios conectados al sitio web al mismo tiempo.
Las pruebas no funcionales siempre prueban algo que se puede medir. El objetivo es mejorar el producto. Se puede lograr, por ejemplo, mejorando la eficacia de la aplicación en el uso de los recursos o mejorando los tiempos de respuesta cuando muchos clientes la usan simultáneamente. Estas son algunas de las preguntas que las pruebas no funcionales pueden responder:
- ¿Cómo funciona la aplicación en circunstancias normales?
- ¿Cómo funciona la aplicación cuando muchos usuarios inician sesión simultáneamente?
- ¿Cuál es la seguridad de la aplicación?
¿Qué tipos de pruebas no funcionales se pueden ejecutar?
Hay muchos tipos de pruebas no funcionales. Muchas pruebas se incluyen en las categorías genéricas de pruebas de rendimiento y pruebas de seguridad.
Pruebas de rendimiento
El objetivo de las pruebas de rendimiento es mejorar la velocidad, escalabilidad y estabilidad de una aplicación. La prueba de velocidad determina la rapidez con la que responde una aplicación. La prueba de escalabilidad determina la carga máxima de usuarios que puede controlar una aplicación. La prueba de estabilidad determina si la aplicación sigue siendo estable en diferentes cargas. Dos tipos comunes de pruebas de rendimiento son las pruebas de carga y las pruebas de esfuerzo.
Pruebas de carga
Las pruebas de carga determinan el rendimiento de una aplicación en cargas realistas. Por ejemplo, las pruebas de carga pueden determinar el rendimiento de una aplicación en el límite superior de su contrato de nivel de servicio (SLA). Básicamente, las pruebas de carga determinan el comportamiento de la aplicación cuando varios usuarios la necesitan al mismo tiempo.
Los usuarios no son necesariamente personas. Por ejemplo, una prueba de carga para el software de la impresora puede enviar una gran cantidad de datos a la aplicación. Una prueba de carga para un servidor de correo puede simular miles de usuarios simultáneos.
Las pruebas de carga también son una buena manera de descubrir problemas que solo existen cuando la aplicación está funcionando al límite. Ahí es cuando pueden surgir problemas como el desbordamiento del búfer y la fuga de memoria.
En este módulo, se usa Apache JMeter para realizar pruebas de carga. Se utiliza un conjunto de usuarios simulados que acceden al sitio web simultáneamente.
pruebas de esfuerzo
Las pruebas de esfuerzo determinan la estabilidad y la solidez de una aplicación bajo cargas pesadas. Las cargas van más allá de lo que se especifica para la aplicación. Las pruebas de esfuerzo determinan si la aplicación se bloqueará en estas cargas. Si se produce un error en la aplicación, la prueba de esfuerzo comprueba que se produzca de manera correcta. Por ejemplo, un error correcto podría emitir un mensaje informativo de error adecuado.
Con frecuencia se dan escenarios en los que las aplicaciones deben funcionar con cargas anormalmente gruesas. Por ejemplo, en caso de que el vídeo sea viral, querrá saber hasta qué punto los servidores pueden controlar la carga adicional. Otro escenario típico es el tráfico elevado en los sitios web de compras durante los períodos de fiestas.
Pruebas de seguridad
Las pruebas de seguridad garantizan que las aplicaciones no tengan vulnerabilidades, amenazas ni riesgos. Las pruebas de seguridad exhaustivas encuentran todos los errores y debilidades posibles del sistema que podrían provocar una vulneración de la seguridad de la información o una pérdida de ingresos.
Hay muchos tipos de pruebas de seguridad. Dos de ellos son las pruebas de penetración y las pruebas de cumplimiento.
Pruebas de penetración
Las pruebas de penetración, o pruebas de pluma, son un tipo de prueba de seguridad que prueba las zonas poco seguras de la aplicación. En concreto, prueba las vulnerabilidades que un atacante podría aprovechar. En una prueba de penetración suele intervenir un ciberataque simulado autorizado.
Pruebas de cumplimiento
Las pruebas de cumplimiento determinan si una aplicación cumple un conjunto de requisitos, ya sea dentro o fuera de la empresa. Por ejemplo, las organizaciones de atención sanitaria normalmente necesitan cumplir con la ley HIPAA (Ley de portabilidad y responsabilidad de seguros de salud de 1996), que proporciona normas de privacidad y seguridad de datos para proteger la información médica.
Además, puede que una organización tenga sus propios requisitos de seguridad. El software se debe probar para garantizar que cumpla estos requisitos. Por ejemplo, en los sistemas Linux, la máscara de usuario predeterminada debe ser 027 o más restrictiva. Una prueba de seguridad debe demostrar que se cumple este requisito.
El plan
En el resto de este módulo, se configura el entorno de Azure DevOps, se obtiene información sobre cómo planear pruebas de carga mediante Apache JMeter y ejecutar pruebas de carga en Azure Pipelines.