Pruebas de Software
“las pruebas solo pueden demostrar la presencia de errores, no su ausencia”
Dijikstra
Objetivos
- Demostrar a l@s desarrollador@s y al cliente que el software satisface sus requerimientos.
- Descubrir defectos en el software en que el comportamiento de este es incorrecto, no deseable o no cumple su especificacion.
La mayoria de los tratamientos de pruebas comienzan con las pruebas de componentes y a continuacion se realizan las pruebas del sistema.
Pruebas del Sistema
Implican integrar dos o mas componentes que implementan funciones del sistema y a continuacion se prueba este sistema integrado. Existen dos fases:
- Pruebas de integracion - se tiene acceso al codigo fuente y se intentan buscar defectos del sistema. cuando se encuentra uno se intenta solucionarlo.
- Pruebas de entregas - se prueba el sistema como si fuera una caja negra y como si fuera lo que se va a entregar al cliente.
Pruebas de integracion
- Integracion descendente: cuando se crea un esqueleto y se le va agregando los componentes.
- Integracion ascendente: se integran los componentes que proporcionan servicios comunes.
Pruebas de entregas o pruebas funcionales
Es el proceso de probar una entrega del sistema que sera distribuida a los clientes. Hay guias (Whittaker, 2002) que pueden incrementar la probabilidad que las pruebas de defectos tengan exito. Por ejemplo, elegir entradas que fuerzen a que el sistema genere todos los mensajes de error.
Pruebas de rendimiento o estress
Una vez que el sistema se ha integrado, se puede probar rendimiento y fiabilidad. Implica planificar una serie de pruebas en las que la carga se va incrementando regularmente hasta que el rendimiento del sistema se hace inaceptable.
Pruebas de Componentes o Pruebas de Unidad
Es el proceso de probar los componentes individuales en el sistema. El objetivo es encontrar defectos en los componentes. Usualmente l@s encargad@s de las pruebas de componentes son l@s desarrollador@s de las mismas.
Tipos de componentes a probar
- Funciones individualles o metodos dentro de un objeto
- Clases de objetos que tienen varios atributos y metodos
- Componentes compuestos formados por diferentes objetos o funciones
Pruebas de Interfaces
Muchos componentes en un sistema no son simples funciones u ojbetos, sino que componentes compuestos formados por varios objetos que interactuan. Las pruebas sobre estos componentes se hacen a traves de sus interfaces definidas, probando que esta se comporta como fue especificado.
Diseno de Casos de Pruebas
El objetivo del proceso de disenio de casos de prueba (entradas y salidas esperadas) es crear un conjunto de casos de prueba que sean efectivos descuriendo defectos en los programas y muestren que el sistema satisface sus requerimientos.
Para diseniar un caso de prueba, se selecciona una caracteristica del sistema o componente que se esta probando. Se selecciona un conjunto de entradas qeu ejecutan dicha caracteriztica, documenta las salidas esperadas o rangos de salida.
Pruebas basadas en requerimientos
Los casos de prueba se disenian para probar los requerimientos del sistema. Las pruebas basadas en requerimientos son pruebas de validacion en lugar de pruebas de defectos.
Pruebas de particiones
Los datos de entrada y resultados de salida se pueden agrupar en varias clases diferetnes qeu tienen caracteristicas comunes, estas clases se denominan particiones de equivalencia o dominio. Se espera que el programa se comporte igual para todos los miembros de una clase. Se disenian los casos de pruebas para que se usen entradas de todas las particiones y se generen salidas de todas las particiones.
Pruebas estructurales o de caja blanca
Se crean casos de prueba para que se ejecute cada linea de codigo una vez.
Pruebas de Caminos
Son una estrategia de pruebas estructurales cuyo objetivo es probar cada camino de ejecucion independiente en un componente o programa.
Fuente: “Ingenieria de Software” de Ian Sommerville
