La prueba de software es un proceso de investigación, prueba de un producto de software , que tiene como objetivo comprobar la correspondencia entre el comportamiento real del programa y su comportamiento esperado en un conjunto final de pruebas seleccionadas de una determinada manera ( ISO /IEC TR 19759:2005) [ 1] .
Se han dado varias definiciones a las pruebas en varios momentos y en varias fuentes, que incluyen:
Los primeros sistemas de software se desarrollaron como parte de programas de investigación científica o programas para las necesidades de los departamentos de defensa. Las pruebas de dichos productos se llevaron a cabo de manera estrictamente formal con un registro de todos los procedimientos de prueba, datos de prueba y los resultados obtenidos. Las pruebas se separaron en un proceso separado, que comenzaba después de completar la codificación, pero generalmente las realizaba el mismo personal.
En la década de 1960, se hizo mucho hincapié en las pruebas "exhaustivas", que deberían realizarse utilizando todas las rutas del código o todas las entradas posibles. Se observó que en estas condiciones no es posible realizar una prueba completa del software porque, en primer lugar, la cantidad de entradas posibles es muy grande, en segundo lugar, hay muchos caminos y, en tercer lugar, es difícil encontrar problemas en la arquitectura y las especificaciones. Por estas razones, se rechazó la prueba "exhaustiva" y se consideró teóricamente imposible.
A principios de la década de 1970, las pruebas de software se denominaban "el proceso de demostrar la corrección de un producto" o "la actividad de verificar el correcto funcionamiento del software". En la ingeniería de software naciente, la verificación de software se denominaba "prueba de corrección". Si bien el concepto era teóricamente prometedor, en la práctica requería mucho tiempo y no era lo suficientemente completo. Se decidió que la prueba de corrección era un método ineficiente para probar el software. Sin embargo, en algunos casos, la demostración del funcionamiento correcto todavía se usa hoy en día, por ejemplo, las pruebas de aceptación. En la segunda mitad de la década de 1970, se consideraba que las pruebas ejecutaban un programa con la intención de encontrar errores, no de probar que funcionaba. Una prueba exitosa es una prueba que descubre problemas previamente desconocidos. Este enfoque es directamente opuesto al anterior. Estas dos definiciones representan la “paradoja del testing”, que se basa en dos afirmaciones opuestas: por un lado, testing te permite asegurarte de que el producto funciona bien y, por otro lado, revela errores en los programas, mostrando que el el producto no funciona. El segundo objetivo de las pruebas es más productivo en términos de mejora de la calidad, ya que no permite que se ignoren las fallas del software.
En la década de 1980, las pruebas se ampliaron para incluir la prevención de defectos. El diseño de pruebas es la técnica de prevención de errores conocida más eficaz. Al mismo tiempo, comenzaron a expresarse pensamientos de que se necesitaba una metodología de prueba, en particular, que la prueba debería incluir verificaciones a lo largo del ciclo de desarrollo, y este debería ser un proceso controlado. Durante la prueba, es necesario verificar no solo el programa ensamblado, sino también los requisitos, el código, la arquitectura y las pruebas mismas. Las pruebas "tradicionales", que existieron hasta principios de la década de 1980, se referían solo al sistema compilado y terminado (ahora conocido comúnmente como pruebas del sistema), pero desde entonces, los probadores se han involucrado en todos los aspectos del ciclo de vida del desarrollo. Esto hizo posible encontrar problemas en los requisitos y la arquitectura antes y, por lo tanto, reducir el tiempo y el presupuesto de desarrollo. A mediados de la década de 1980 aparecieron las primeras herramientas para realizar pruebas automatizadas. Se suponía que la computadora podía realizar más pruebas que un humano, y hacerlo de manera más confiable. Al principio, estas herramientas eran extremadamente simples y no tenían la capacidad de escribir scripts en lenguajes de scripting.
A principios de la década de 1990, el concepto de "testing" comenzó a incluir la planificación, el diseño, la creación, el mantenimiento y la ejecución de pruebas y entornos de prueba, y esto significó una transición de testing a control de calidad, abarcando todo el ciclo de desarrollo de software. En este momento, comenzaron a aparecer varias herramientas de software para apoyar el proceso de prueba: entornos de automatización más avanzados con la capacidad de crear scripts y generar informes, sistemas de gestión de pruebas y software de prueba de carga. A mediados de la década de 1990, con el desarrollo de Internet y el desarrollo de una gran cantidad de aplicaciones web, las "pruebas ágiles" (similares a las metodologías de programación ágil) comenzaron a ganar particular popularidad.
Hay varios criterios por los cuales se acostumbra clasificar los tipos de pruebas. Suelen ser los siguientes:
Según el objeto de la pruebaA menudo, para el software gratuito y de código abierto, la etapa de prueba alfa caracteriza el contenido funcional del código, y la prueba beta caracteriza la etapa de corrección de errores. Al mismo tiempo, por regla general, en cada etapa de desarrollo, los resultados intermedios del trabajo están disponibles para los usuarios finales.
Las técnicas que se describen a continuación (pruebas de caja blanca y pruebas de caja negra) asumen que el código se está ejecutando y la diferencia está solo en la información que tiene el evaluador. En ambos casos, se trata de pruebas dinámicas .
Durante la prueba estática, el código del programa no se ejecuta; el programa se analiza en función del código fuente, que se lee manualmente o se analiza con herramientas especiales. En algunos casos, no es el código fuente lo que se analiza, sino el código intermedio (como bytecode o código MSIL ).
Las pruebas estáticas también incluyen requisitos de prueba , especificaciones y documentación .
Después de realizar cambios a la siguiente versión del programa, las pruebas de regresión confirman que los cambios realizados no afectaron el rendimiento del resto de la funcionalidad de la aplicación. Las pruebas de regresión se pueden realizar tanto manualmente como con herramientas de automatización de pruebas .
Los probadores utilizan escenarios de prueba en diferentes niveles: tanto en las pruebas de componentes como en las pruebas de integración y sistemas. Los scripts de prueba generalmente se escriben para probar componentes que tienen más probabilidades de fallar, o un error que no se encuentra a tiempo puede ser costoso.
Dependiendo del acceso del desarrollador de la prueba al código fuente del programa bajo prueba, se hace una distinción entre " prueba (por estrategia) de una caja blanca " y " prueba (por estrategia) de una caja negra ".
En las pruebas de caja blanca (también llamadas pruebas de caja transparente ), el desarrollador de la prueba tiene acceso al código fuente de los programas y puede escribir código que se vincule a las bibliotecas del software bajo prueba. Esto es típico de las pruebas de componentes, donde solo se prueban partes del sistema. Asegura que los componentes estructurales sean funcionales y estables, hasta cierto punto. Las pruebas de caja blanca utilizan métricas de cobertura de código o pruebas de mutación .
En las pruebas de caja negra, el probador tiene acceso al programa solo a través de las mismas interfaces que el cliente o usuario, o a través de interfaces externas que permiten que otra computadora u otro proceso se conecte al sistema para la prueba. Por ejemplo, un componente de prueba puede presionar virtualmente las teclas o los botones del mouse en el programa bajo prueba utilizando el mecanismo de comunicación del proceso, con la confianza de que todo va bien, que estos eventos provocan la misma respuesta que las pulsaciones de teclas y los botones del mouse reales. Por regla general, las pruebas de caja negra se llevan a cabo utilizando especificaciones u otros documentos que describen los requisitos del sistema. Por lo general, en este tipo de prueba , el criterio de cobertura es la suma de la cobertura de la estructura de datos de entrada, la cobertura de requisitos y la cobertura del modelo (en pruebas basadas en modelos ).
En las pruebas de caja gris, el desarrollador de la prueba tiene acceso al código fuente, pero cuando se ejecutan las pruebas directamente, generalmente no se requiere acceso al código.
Mientras que "pruebas alfa" y "beta" se refieren a las etapas antes de que se lance un producto (y también, implícitamente, al tamaño de la comunidad de prueba y las limitaciones en los métodos de prueba), las pruebas de caja blanca y caja negra se refieren a las formas en que el probador llega a la meta.
Las pruebas beta generalmente se limitan a las técnicas de caja negra (aunque un subconjunto constante de probadores generalmente continúa con las pruebas de caja blanca en paralelo a las pruebas beta). Por lo tanto, el término "prueba beta" puede indicar el estado del programa (más cerca del lanzamiento que "alfa"), o puede indicar un determinado grupo de probadores y el proceso llevado a cabo por este grupo. Es decir, un probador puede continuar trabajando en pruebas de caja blanca aunque el programa ya sea "beta", pero en este caso no es parte de las "pruebas beta".
La cobertura de código muestra el porcentaje del código fuente de un programa que se ejecutó ("cubrió") durante la prueba. De acuerdo con los métodos de medición, cobertura del operador, cobertura de condición, cobertura de ruta, cobertura de función, etc.
| Desarrollo de software | |
|---|---|
| Proceso | |
Conceptos de alto nivel | |
| Direcciones |
|
| Metodologías de desarrollo | |
| Modelos |
|
Figuras notables |
|