Definición de Pruebas; Es la ejecución del código
usando combinaciones de entradas, en un
determinado estado, para revelar defectos.
“Prueba de Software es el diseño e
implantación de un software especial: uno que
ejercita otro software con la intención de hallar
defectos.” Robert V. Binder, Testing Object-Oriented
Systems: Models, Patterns, and Tools (1999)
En que consisten las pruebas
- Determinar qué partes del sistema desea probar
- Definir valores de entrada que aporten información significativa
- Correr el software con los valores de entrada
- Comparar los resultados producidos con los esperados
- (Medir características de ejecución: tiempo, memoria usada, entre otros).
Tipos de pruebas según su alcance:
- Pruebas Unitarias o de Componente:Son ejecutadas normalmente por el equipo de desarrollo, básicamente consisten en la ejecución de actividades que le permitan verificar al desarrollador que los componentes unitarios están codificados bajo condiciones de robustez, esto es, soportando el ingreso de datos erróneos o inesperados y demostrando así la capacidad de tratar errores de manera controlada. Adicionalmente, las pruebas sobre componentes unitarios, suelen denominarse pruebas de módulos o pruebas de clases, siendo la convención definida por el lenguaje de programación la que influye en el término a utilizar. Por último, es importante que toda la funcionalidad de cada componente unitario sea cubierta, por al menos, dos casos de prueba, los cuales deben centrarse en probar al menos una funcionalidad positiva y una negativa.
- Pruebas de Integración: Este tipo de pruebas son ejecutas por el equipo de desarrollo y consisten en la comprobación de que elementos del software que interactúan entre sí, funcionan de manera correcta.Ejercita las interfases entre componentes para demostrar que son operables en conjunto
- Pruebas de Sistema: Este tipo de pruebas deben ser ejecutadas idealmente por un equipo de pruebas ajeno al equipo de desarrollo, una buena práctica en este punto corresponde a la tercerización de esta responsabilidad. La obligación de este equipo, consiste en la ejecución de actividades de prueba en donde se debe verificar que la funcionalidad total de un sistema. Los casos de prueba a diseñar en este nivel de pruebas, deben cubrir los aspectos funcionales y no funcionales del sistema. Para el diseño de los casos de prueba en este nivel, el equipo debe utilizar como bases de prueba entregables tales como: requerimientos iniciales, casos de uso, historias de usuario, diseños, manuales técnicos y de usuario final, etc. Por último, es importante que los tipos de pruebas ejecutados en este nivel se desplieguen en un ambiente de pruebas / ambiente de pre-producción cuya infraestructura y arquitectura sea similar al ambiente de producción, evitando en todos los casos utilizar el ambiente real del cliente, debido principalmente, a que pueda ocasionar fallos en los servidores, lo que ocasionaría indisponibilidad en otros servicios alojados en este ambiente.
- Funcional.
- Rendimiento.
- Estrés o carga.
- Prueba dirigida a defectos intención: revelar defectos a través de fallas. Pruebas unitarias e integración.
- Prueba dirigida a Cumplimiento intención: demostrar que está conforme con las capacidades requeridas. Prueba de sistema.
- Prueba de aceptación intención: permitir a un usuario/cliente decidir si acepta un producto de software.
- Prueba de aceptación: Independientemente de que se haya tercerizado el proceso de pruebas y así la firma responsable de estas actividades haya emitido un certificado de calidad sobre el sistema objeto de prueba, es indispensable, que el cliente designe a personal que haga parte de los procesos de negocio para la ejecución de pruebas de aceptación, es incluso recomendable, que los usuarios finales que participen en este proceso, sean independientes al personal que apoyó el proceso de desarrollo. Cuando las pruebas de aceptación son ejecutadas en instalaciones o ambientes proporcionados por la firma desarrolladora se les denominan pruebas Alpha, cuando son ejecutadas desde la infraestructura del cliente se les denomina pruebas Beta. En los casos en que las pruebas de aceptación del producto se hayan ejecutado en el ambiente del proveedor, el aplicativo no podrá salir a producción, sin que se hayan ejecutados las respectivas pruebas Beta en el ambiente del cliente, de lo anterior es importante concluir, que las pruebas Alpha son opcionales, pero las pruebas Beta son obligatorias.
- Prueba de Regresión Intención: Volver a probar un programa previamente probado, después de algunas modificaciones para asegurarse que no se hayan introducido o aparecido defectos debido a los cambios realizados.
- Pruebas de Mutación Intención: Introducir defectos a propósito en el software para determinar la calidad de las pruebas.
Componentes de una prueba:Caso de Prueba – especifica:
- El estado y ambiente del programa antes de ejecutar la prueba
- Las entradas a la prueba
- El resultado esperado
Resultados esperados- qué debe producir el programa:
- Valores devueltos
- Mensajes
- Excepciones
- Estado resultante del programa y el ambiente
Oráculo produce los resultados esperados del caso de prueba, puede decidir si se satisfizo la evaluación.
Diseño de Casos de Prueba:Definir los casos de prueba que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y tiempo.
- Pruebas de caja blanca: Encontrar casos de prueba “viendo” el código interno.
- Pruebas de caja negra: Encontrar casos de prueba “viendo” los requerimientos funcionales