Dentro del software, existen muchos conceptos y definiciones técnicos. Puede resultar abrumador aprender nuevos temas o incluso cambiar entre empresas que utilizan términos diferentes.
Las pruebas son uno de esos temas. A medida que las empresas de tecnología moderna maduran a lo largo de su viaje de DevOps mediante la adopción de prácticas de integración continua , se está otorgando un nivel de importancia cada vez mayor a las pruebas y la automatización de pruebas. No se pierda en la confusión de todos los diferentes métodos. Aquí hay una referencia de alto nivel a los tipos más comunes de pruebas de software.
1. Prueba unitaria
La prueba unitaria es un método de prueba que se centra en examinar “unidades” individuales o fragmentos de código.
El objetivo principal de las pruebas unitarias es determinar la integridad lógica: que un fragmento de código haga lo que se supone que debe hacer.
Generalmente, la gente probará métodos o funciones individuales como unidades y, dependiendo del tamaño y complejidad del código, también clases. Se prueban de forma aislada y, posteriormente, las dependencias típicas se eliminan o se burlan .
Un ejemplo de esto sería si tuviera una función que masajee los datos de una base de datos. Sin embargo, dado que es una prueba unitaria, no usaría una base de datos real: haría una llamada a un punto final con stub, que devuelve los datos que normalmente esperaría de una base de datos. De esa forma, la única funcionalidad que se está probando es este fragmento de código o la unidad.
La mayoría de los lenguajes tienen al menos un marco de prueba unitario recomendado para sí mismo (por ejemplo, Java → JUnit , Python → PyUnit o PyTest , JavaScript → Mocha , Jest , Karma , etc.)
2. Prueba de integración
Las pruebas de integración son un método de prueba centrado en examinar varios componentes juntos.
El objetivo principal de las pruebas de integración es garantizar la integridad de la relación y el flujo de datos entre componentes o unidades.
Por lo general, las personas ejecutarán primero pruebas unitarias para probar la integridad lógica de las unidades individuales. Luego, ejecutarán pruebas de integración para garantizar que la interacción entre estas unidades se comporte como se esperaba. Continuando con el ejemplo anterior, una prueba de integración en este caso sería ejecutar la misma prueba contra una base de datos real. Con bases de datos reales, tiene escenarios y comportamientos adicionales a considerar.
“Prueba de integración” es un término amplio y abarca cualquier prueba en la que estén involucrados múltiples componentes. Posteriormente, se puede usar una gran variedad de tecnologías y marcos, incluidos los mismos que se usaron anteriormente en pruebas unitarias, o marcos separados basados en el comportamiento (los ejemplos se enumeran en la siguiente sección).
3. Prueba de extremo a extremo (E2E, sistema)
Las pruebas del sistema, o pruebas de un extremo a otro (E2E), se centran en examinar el comportamiento de un sistema de un extremo a otro.
El objetivo principal de las pruebas de extremo a extremo es garantizar que toda la aplicación o el sistema como una unidad se comporte como esperamos, independientemente del funcionamiento interno.
En esencia, las pruebas unitarias y de integración son típicamente de “caja blanca” (por ejemplo, se conocen los internos) mientras que las pruebas E2E son típicamente de “caja negra” (por ejemplo, solo verificamos combinaciones de entrada y salida). Un ejemplo de prueba E2E podría ser una historia de usuario genérica como “Obtener datos de un usuario”. La entrada podría ser una simple solicitud GET a una ruta específica, y luego verificamos que la salida devuelta sea la que esperamos. La forma en que el sistema obtuvo esos datos es irrelevante.
Como puede ver, las pruebas E2E solo pueden verificar el comportamiento general, por eso son necesarias las pruebas unitarias y de integración. Podría ser que, aunque el resultado sea correcto, la forma en que se obtiene el resultado internamente sea incorrecta, y una prueba E2E no lo detectaría.
Para las pruebas E2E, normalmente utiliza marcos basados en el comportamiento. Puede usar marcos como Cucumber , Postman , SoapUI , Karate , Cypress , Katalon , etc. Tenga en cuenta que muchos marcos de prueba de API se utilizan para las pruebas E2E porque una API es típicamente la forma en que interactúa programáticamente con una aplicación.
4. Prueba de aceptación
Las pruebas de aceptación suelen ser una fase del ciclo de desarrollo.
El objetivo principal de las pruebas de aceptación es verificar que un producto o característica determinada se haya desarrollado de acuerdo con las especificaciones establecidas por un cliente o un interesado interno, como un gerente de producto.
Dentro de las pruebas de aceptación, también puede haber múltiples fases, como las pruebas α o las pruebas β. A medida que gran parte del mundo del desarrollo de software avanza hacia los procesos ágiles, las pruebas de aceptación del usuario se han vuelto mucho menos rígidas y más colaborativas.
Es importante tener en cuenta que, si bien las pruebas de aceptación pueden verificar que la aplicación se comporte como el usuario desea, no verifica la integridad del sistema. Otra advertencia de las pruebas de aceptación del usuario es que hay un límite para los casos y escenarios de la esquina que una persona puede idear; es por eso que los métodos de prueba automatizados anteriores son importantes ya que cada caso de uso y escenario está codificado.
5. Prueba de caja blanca (estructural, caja transparente)
Las pruebas de caja blanca (también llamadas estructurales o de caja transparente) describen pruebas o métodos en los que se conocen los detalles y el funcionamiento interno del software que se está probando.
Dado que conoce las funciones, los métodos, las clases, cómo funcionan y cómo se unen, generalmente está mejor equipado para examinar la integridad lógica del código.
Por ejemplo, es posible que sepa que hay una peculiaridad en la forma en que un determinado idioma maneja ciertas operaciones. Podría escribir pruebas específicas para eso, que de otro modo no sabría escribir en un escenario de caja negra.
Las pruebas unitarias y las pruebas de integración suelen ser una caja blanca.
6. Pruebas de caja negra (funcional, conductual, caja cerrada)
Por el contrario, las pruebas de caja negra (también llamadas funcionales, de comportamiento o de caja cerrada) describen cualquier prueba o método en el que se desconocen los detalles y el funcionamiento interno del software que se está probando.
Dado que no conoce ninguno de los detalles, realmente no puede crear casos de prueba que se dirijan a escenarios de nicho específicos o que hagan hincapié en la lógica específica del sistema.
Lo único que sabe es que para una solicitud o una entrada determinada, se espera un determinado comportamiento o salida. Por lo tanto, las pruebas de caja negra prueban principalmente el comportamiento de un sistema. Las pruebas de un extremo a otro suelen ser una caja negra.
7. Prueba de caja gris
La prueba de caja gris es solo una combinación híbrida de caja negra y caja blanca.
La prueba de caja gris toma la facilidad y simplicidad de la prueba de caja negra (por ejemplo, entrada → salida) y apunta a sistemas específicos relacionados con el código de prueba de caja blanca.
La razón por la que existen las pruebas de caja gris es porque las pruebas de caja negra y las pruebas de caja blanca por sí solas pueden perder una funcionalidad importante.
- Las pruebas de caja negra solo prueban que obtiene una determinada salida para una entrada determinada. No prueba la integridad de los componentes internos; podría obtener la salida correcta por pura casualidad.
- Las pruebas de caja blanca se centran en la integridad de las unidades individuales y en cómo funcionan juntas, pero a veces son insuficientes para encontrar defectos en todo el sistema o en varios componentes.
Al combinar los dos tipos juntos, las pruebas de caja gris pueden abarcar escenarios más complicados para validar realmente que una aplicación es sólida en estructura y lógica.
8. Prueba manual
Se explica por sí mismo: las pruebas manuales son pruebas en las que un usuario especifica manualmente la entrada o interactúa con un sistema. También pueden evaluar manualmente los resultados.
Este método de prueba generalmente puede ser lento y propenso a errores. Gran parte de la industria del software se ha movido hacia las pruebas automatizadas junto con la adopción de principios ágiles.
Hoy en día, los usuarios pueden probar manualmente un producto en versión beta para verificar su aceptación, casos extremos y escenarios de nicho.
9. Prueba estática
La prueba estática describe cualquier método o método de prueba en el que no se ejecuta ningún código real.
En realidad, esto incluye revisar el código junto con otros, verificar manualmente la lógica y la integridad de las funciones, clases, etc.
Al igual que las pruebas manuales, las pruebas estáticas pueden ser lentas y propensas a errores, y generalmente las pruebas estáticas se realizan como primera línea de defensa para detectar problemas muy obvios.
Muchas empresas se involucran en revisiones de código antes de que el trabajo de un ingeniero se fusione en la rama principal. Estas revisiones de código son para ahorrar tiempo y atrapar la fruta madura.
10. Pruebas dinámicas
Las pruebas dinámicas describen cualquier método o método de prueba en el que se esté ejecutando realmente el código.
Generalmente, todos los métodos de prueba mencionados anteriormente son dinámicos, excepto los manuales y, a veces, de aceptación. Por lo general, ejecuta scripts automatizados o utiliza marcos para ejecutar entradas en su sistema.
11. Pruebas visuales / de interfaz de usuario (pruebas de navegador)
Las pruebas de la interfaz de usuario o del navegador describen pruebas que examinan específicamente la integridad y el comportamiento de los componentes de la interfaz de usuario.
A menudo, cuando se utiliza un sitio web, se espera que determinadas acciones den lugar a determinados estados. Las pruebas de IU verifican que esto ocurra correctamente. Por ejemplo, la forma en que ha implementado cierto CSS puede fallar en Firefox, pero no en Chrome. Las pruebas del navegador pueden comprobarlo.
Hay muchos marcos de prueba de navegadores populares, como Selenium , Cypress , TestCafe , SauceLabs , Katalon Studio , Browsersync , Robot , etc.
12. Prueba de humo
Las pruebas de humo solo se refieren a un subconjunto más pequeño de controles para verificar razonablemente que un sistema está funcionando.
Es solo elegir y ejecutar un conjunto no exhaustivo de pruebas que examinan la funcionalidad principal.
Un ejemplo de esto podría ser probar solo un par de flujos de usuarios, como “Obtener datos de un usuario” de arriba. No es exhaustivo, pero dado que la mayoría de su aplicación incluye un usuario que inicia sesión, realiza una solicitud y obtiene datos de algún lugar, esta prueba o algunas pruebas pueden brindarle una confianza razonable de que su sistema es funcional y está funcionando.
Por lo general, las pruebas de humo se ejecutan cuando los usuarios esperan que los cambios no hayan tenido ningún impacto significativo en la lógica y la función generales. Puede ser costoso y llevar mucho tiempo ejecutar el conjunto completo de todas las pruebas cada vez, por lo que las pruebas de humo se utilizan como una medida de seguridad económica que se puede ejecutar con más frecuencia.
13. Prueba de regresión
La prueba de regresión es un método de prueba para verificar si alguna característica previamente funcional se ha roto (o retrocedido) repentinamente.
Esto a menudo incluye ejecutar la totalidad de todas las pruebas de unidad, integración y sistema para garantizar que ninguna funcionalidad haya cambiado inesperadamente. Como todos sabemos, a veces el software tiene la forma más extraña de romperse.
Las pruebas de regresión a menudo requieren mucho tiempo y pueden ser muy costosas, por lo que a veces las personas realizan pruebas de humo en su lugar, especialmente si no se espera lógicamente que los cambios recientes afecten a todo el sistema.
A menudo, cuando las personas configuran CI / CD, ejecutarán pruebas de humo en casi todas las confirmaciones, mientras que las suites de regresión pueden ejecutarse a intervalos establecidos o en funciones grandes para garantizar una integración continua sin problemas.
14. Prueba de carga
Las pruebas de carga se refieren a probar la respuesta de una aplicación al aumento de la demanda.
Esto incluye probar las afluencias repentinas de solicitudes o usuarios que podrían ejercer una presión inesperada en el sistema. Las pruebas de carga a menudo se realizan como parte de las pruebas de seguridad para garantizar que una aplicación y su sistema no puedan ser DDOS .
Las pruebas de carga también se realizan para verificar la cantidad máxima de datos que un sistema puede manejar en un momento dado. Es fundamental para ayudar a los equipos a determinar fórmulas de escalamiento e implementación de alta disponibilidad (HA) efectivas.
15. Pruebas de inserción
Las pruebas de inserción son una forma de prueba de seguridad que implica verificar la solidez de la seguridad de una aplicación.
Se explotan todas las formas en que una aplicación puede verse comprometida (secuencias de comandos entre sitios, entradas no desinfectadas, ataques de desbordamiento de búfer, etc.) para comprobar cómo la maneja el sistema. Las pruebas de penetración son una parte importante para asegurarse de que una empresa no sea víctima de infracciones graves.
Conclusión
Como puede ver, hay muchos términos diferentes que se usan en las pruebas de software, y muchos de ellos a menudo se superponen o se usan indistintamente (aunque de manera incorrecta).
Al comprender exactamente lo que significa cada uno de estos términos y saber lo que abarcan, podrá comprender de qué está hablando la gente y profundizar en sus necesidades. Incluso podría corregirlos ahora.
Referencia
CircleCi – Vinny Thanh (2020) 15 testing methods all developers should know.
Recuperado de: https://circleci.com/blog/testing-methods-all-developers-should-know/
