Métodos de prueba de software

Hola a todos! La próxima semana vamos a lanzar un nuevo hilo en el curso "Automation Web Testing" . Este será el tema del material de hoy.

Este artículo analiza varias formas de probar software, como pruebas unitarias, pruebas de integración, pruebas funcionales, pruebas de aceptación, etc.



Hay muchos tipos diferentes de pruebas que puede aplicar para asegurarse de que los cambios en su código estén programados. No todos los tipos de pruebas son idénticos, aunque aquí vemos cómo las principales prácticas de prueba difieren entre sí.

Prueba: manual o automatizada?

Primero debe comprender las diferencias entre las pruebas manuales y automatizadas. Las pruebas manuales son realizadas directamente por una persona que hace clic en los botones de la aplicación o interactúa con el software o la API con las herramientas necesarias. Esto es bastante costoso, ya que requiere que el probador instale el entorno de desarrollo y ejecute las pruebas manualmente. Hay una probabilidad de error debido a un factor humano, como un error tipográfico o saltarse pasos en un caso de prueba.

Las pruebas automatizadas, por otro lado, son realizadas por una máquina que ejecuta un script de prueba que se escribió de antemano. Dichas pruebas pueden variar mucho según la complejidad, desde probar un único método en una clase hasta elaborar una secuencia de acciones complejas en una interfaz de usuario para asegurarse de que funcione correctamente. Este método se considera más confiable, pero su rendimiento aún depende de qué tan bien se haya escrito bien el script para la prueba.

Las pruebas automatizadas son un componente clave de la integración continua y la entrega continua, así como una buena forma de escalar su proceso de control de calidad al tiempo que agrega nuevas funcionalidades a su aplicación. Sin embargo, las pruebas manuales todavía tienen su propio valor. Por lo tanto, en el artículo definitivamente hablaremos sobre las pruebas exploratorias.

Diferentes tipos de pruebas

Pruebas unitarias

Las pruebas unitarias se consideran de bajo nivel, cercanas al código fuente de su aplicación. Están dirigidos a probar métodos y funciones individuales dentro de las clases, probando los componentes y módulos utilizados por su programa. Las pruebas unitarias en general no requieren costos especiales de automatización y pueden funcionar extremadamente rápido si utiliza un servidor de integración continua.

Pruebas de integración

Las pruebas de integración verifican si los servicios y módulos utilizados por su aplicación funcionan bien juntos. Por ejemplo, pueden probar la integración con una base de datos o asegurarse de que los microservicios interactúen correctamente entre sí. Estas pruebas se ejecutan a un costo mayor, ya que necesitan muchas partes de la aplicación para funcionar simultáneamente.

Pruebas de funcionamiento

Las pruebas funcionales se basan en los requisitos comerciales de la aplicación. Solo verifican la salida después de que se realiza la acción y no verifican los estados intermedios del sistema durante la reproducción de la acción.

A veces hay contradicciones entre las pruebas de integración y las pruebas funcionales, como ambos solicitan múltiples componentes que interactúan entre sí. La diferencia es que las pruebas de integración simplemente pueden garantizar que la base de datos sea accesible, mientras que una prueba funcional quiere obtener un cierto valor de la base de datos para verificar uno de los requisitos para el producto final.

Pruebas de punta a punta

Las pruebas de extremo a extremo simulan el comportamiento del usuario al interactuar con el software. Comprueba con qué precisión varios usuarios siguen el escenario previsto de la aplicación y puede ser bastante simple, por ejemplo, parecer cargar una página web o ingresar a un sitio web o, en un caso más complicado, confirmar una dirección de correo electrónico, pagos en línea, etc.

Las pruebas de extremo a extremo son extremadamente útiles, pero producirlas es costoso y puede ser difícil de automatizar. Se recomiendan varias pruebas transversales, pero aún confían más en las pruebas de bajo nivel (pruebas unitarias y de integración) para poder reconocer rápidamente los cambios importantes.

Prueba de aceptación

Las pruebas de aceptación son pruebas formales que se realizan para garantizar que el sistema satisfaga las necesidades comerciales. Requieren que la aplicación se ejecute y se ejecuten, e imitan las acciones del usuario. Las pruebas de aceptación pueden ir más allá y medir el rendimiento del sistema y rechazar los cambios recientes si no se han alcanzado los objetivos de desarrollo finales.

Pruebas de rendimiento

Las pruebas de rendimiento prueban el comportamiento de un sistema cuando está bajo una carga significativa. Estas pruebas no son funcionales y pueden tomar muchas formas para probar la confiabilidad, estabilidad y disponibilidad de la plataforma. Por ejemplo, puede monitorear el tiempo de respuesta al realizar una gran cantidad de solicitudes u observar cómo se comporta el sistema cuando interactúa con grandes datos.

Las pruebas de rendimiento son inherentemente costosas de realizar, pero pueden ayudarlo a comprender qué factores externos pueden afectar su sistema.

Prueba de humo

Las pruebas de humo son pruebas básicas que prueban la funcionalidad básica de una aplicación. Funcionan lo suficientemente rápido y su objetivo es dejar en claro que las funciones principales del sistema funcionan como deberían y nada más. Dichas pruebas tienen como objetivo identificar errores obvios.

Las pruebas de humo pueden ser útiles inmediatamente después de construir una nueva compilación para verificar si puede ejecutar pruebas más costosas, o inmediatamente después de la implementación, para asegurarse de que la aplicación funcione bien en el nuevo entorno.

Cómo automatizar pruebas

Un probador puede realizar todas las pruebas mencionadas anteriormente manualmente, pero esto será extremadamente costoso e improductivo. Porque las personas tienen una capacidad limitada para realizar una gran cantidad de acciones repetitivas mientras siguen probando de manera confiable. Sin embargo, la máquina puede reproducir fácilmente las mismas acciones y verificar, por ejemplo, que la combinación de nombre de usuario / contraseña funcionará por centésima vez sin ninguna queja.

Para automatizar las pruebas, primero debe escribirlas en algunos de los lenguajes de programación utilizando un marco de prueba que sea adecuado para su aplicación. PHPUnit , Mocha , RSpec son ejemplos de marcos de prueba que puede usar para PHP, Javascript y Ruby, respectivamente. Tienen muchas características para cada idioma, por lo que debe investigar un poco y consultar con las comunidades de desarrolladores para determinar qué marco es el mejor para usted.

Si sus pruebas se pueden ejecutar usando scripts desde la terminal, puede automatizarlas usando un servidor de integración continua al estilo Bamboo o el servidor en la nube Bitbucket Pipelines. Estas herramientas supervisarán sus repositorios y ejecutarán conjuntos de pruebas tan pronto como se introduzcan nuevos cambios en el repositorio principal.



Si es nuevo en las pruebas, consulte nuestra guía de integración continua para crear su primer conjunto de pruebas.

Pruebas de investigación

Cuantas más funciones y mejoras se agreguen a su código, mayor será la necesidad de realizar pruebas, ya que en cada etapa debe asegurarse de que el sistema funcione correctamente. Además, será necesario cada vez que repare un error, ya que no sería superfluo asegurarse de que no vuelva a aparecer después de varios lanzamientos. La automatización es la clave para hacer esto posible; Escribir pruebas tarde o temprano se convertirá en parte de su práctica de desarrollador.

La pregunta es, ¿es necesario realizar pruebas manuales en este caso? La respuesta corta es sí, y debe centrarse en lo que se llama prueba exploratoria, que ayuda a identificar errores sutiles.

Una sesión de prueba de investigación no debe exceder las dos horas y debe tener un alcance claramente definido para ayudar a los evaluadores a enfocarse en un área específica del software. Después de informar a todos los evaluadores sobre los límites de las pruebas, queda a su discreción las acciones que tomarán para verificar cómo se comporta el sistema. Dichas pruebas son de naturaleza costosa, pero muy útiles para identificar problemas con la interfaz de usuario o verificar el estado de los flujos de trabajo complejos para los usuarios. Es importante realizar tales pruebas siempre que se agregue una función radicalmente nueva a la aplicación para comprender cómo se comportará en condiciones límite.

Nota de prueba

Antes de terminar este artículo, quiero hablar sobre el propósito de las pruebas. Por un lado, es muy importante asegurarse de que los usuarios puedan usar su aplicación ("No puedo iniciar sesión", "No puedo guardar datos", etc.), pero por otro lado, es igualmente importante verificar que su sistema No se rompe al ingresar datos incorrectos o acciones inesperadas. Debe anticipar lo que sucederá cuando un usuario cometa un error tipográfico, intente guardar un formulario incompleto o use la API incorrecta. Debe verificar si uno de los usuarios puede comprometer fácilmente los datos, obtener acceso a un recurso en particular al que no debería tener acceso. Un buen conjunto de pruebas debería intentar romper su aplicación y ayudar a comprender el límite de sus capacidades.

Y finalmente, ¡las pruebas también son código! Por lo tanto, no se olvide de ellos durante la revisión del código, ya que pueden ser el último paso antes de lanzar el producto al mercado de consumo.

De acuerdo con la tradición establecida, estamos esperando sus comentarios e invitamos a todos a la jornada de puertas abiertas , que se llevará a cabo el 18 de marzo por nuestro maestro, el ingeniero de automatización de pruebas líder en el Grupo IB, Mikhail Samoilov .