PRUEBAS DE SOFTWARE

El nico instrumento adecuado para determinar el status de la calidad de un producto software es el proceso de pruebas. En este proceso se ejecutan pruebas dirigidas a componentes del software o al sistema de software en su totalidad, con el objetivo de medir el grado en que el software cumple con los requerimientos. En las pruebas se usan casos de prueba, especificados de forma estructurada mediante Tcnicas de prueba. El proceso de pruebas, sus objetivos y los mtodos y tcnicas usados se describen en el plan de prueba. Atributos de una buena prueba 1.Alta probabilidad de encontrar un error 2.No debe ser redundante 3.Ejecutar un subconjunto de pruebas 4. Ni demasiado sencilla ni demasiado compleja

TIPOS DE PRUEBAS
1.- PRUEBAS UNITARIAS Particionar los mdulos en pruebas en unidades lgicas fciles de probar. Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca). Para esto los casos de prueba deben disearse de forma tal que se recorran todos los caminos de ejecucin posibles dentro del cdigo bajo prueba; por lo tanto el diseador debe construirlos con acceso al cdigo fuente de la unidad a probar. Los aspectos a considerar son los siguientes: Rutinas de excepcin, Rutinas de error, Manejo de parmetros, Validaciones, Valores vlidos, Valores lmites, Rangos, Mensajes posibles. 1.1.- Tcnica: Comparar el resultado esperado con el resultado obtenido. Si existen errores, reportarlos. Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas. Todos los defectos que se identificaron han sido tenidos en cuenta.

2.- PRUEBAS DE CAJA BLANCA Se debe conocer la estructura interna del programa. Las pruebas tratan de identificar o determinar:

1. Errores en las Estructuras internas de los datos 2. Determinar todos los posibles caminos que hay en un programa y ejecutarlos al menos una vez. 3. Recorrer los lmites de los ciclos repetitivos. 4. Ejercitar ambos lados de una instruccin IF.

3.- PRUEBAS DE INTEGRACIN

3.1.- Objetivo de la Prueba: Identificar errores introducidos por la combinacin de programas probados unitariamente. Determina cmo la base de datos de prueba ser cargada. Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente. Verificar que las especificaciones de diseo sean alcanzadas. Determina el enfoque para avanzar desde un nivel de integracin de las componentes al siguiente. 3.2.- Descripcin de la Prueba: Describe cmo verificar que las interfaces entre las componentes de software funcionan correctamente. Determina cmo la base de datos de prueba ser cargada. Determina el enfoque para avanzar desde un nivel de integracin de las componentes al siguiente. Decide qu acciones tomar cuando se descubren problemas.

4.- PRUEBA DE REGRESIN 4.1.- Objetivo de la Prueba: Determinar si los cambios recientes en una parte de la aplicacin tienen efecto adverso en otras partes. 4.2.- Descripcin de la Prueba: En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el debugging, mantenimiento o desarrollo de la nueva versin del sistema buscando efectos adversos en otras partes.

4.3.- Tcnica: La prueba de regresin es una nueva corrida de casos de prueba previos. Se requiere de polticas para ser creada la prueba de regresin y decidir qu casos de prueba incluir, para probar eficientemente. La prueba de regresin es un buen candidato para automatizacin. Desde que estas pruebas se repiten una y otra vez, las herramientas para minimizar el esfuerzo del trabajo son tiles. La prueba de viejas funcionalidades es ms importante que la de nuevas funcionalidades. Aquellos casos de uso (y los casos de prueba asociados) que descubren defectos tempranamente deben ser incluidos en la prueba de regresin.

5.- PRUEBAS DE HUMO (SMOKE TESTING O AD HOC) 5.1.- Objetivo de la Prueba: Los objetivos son los siguientes: Detectar los errores en reales es tempranos y de manera fcil Probar el sistema constantemente Garantizar poco esfuerzo en la integracin final del sistema Asegurar los resultados de las pruebas unitarias Se reducen los riesgos y a baja calidad. 5.2.- Descripcin de la Prueba: Toma ste nombre debido a que su objetivo es probar el sistema constantemente buscando que saque humo o falle. En algunos proyectos este tipo de prueba va junto con las pruebas funcionales. Permite detectar problemas que por lo regular no son detectados en las pruebas normales. Algunas veces, si las Pruebas ocurren tarde en el ciclo de desarrollo est ser una forma de garantizar el buen desarrollo.

6.- PRUEBAS DEL SISTEMA 6.1.- Objetivo de la Prueba: Asegurar la apropiada navegacin dentro del sistema, ingreso de datos, procesamiento y recuperacin.

6.2.- Descripcin de la Prueba: Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas pruebas es verificar el ingreso, procesamiento y recuperacin apropiado de datos, y la implementacin apropiada de las reglas de negocios. Este tipo de pruebas se basan en tcnicas de caja negra, esto es, verificar el sistema (y sus procesos internos), la interaccin con las aplicaciones que lo usan via GUI y analizar las salidas o resultados. En esta prueba se determina qu pruebas de Sistema (usabilidad, volumen, desempeo, etc.) asegurarn que la aplicacin alcanzar sus objetivos de negocio.

Otros Aspectos Son: Prueba funcionalidad Prueba de Usabilidad Prueba de Performance Prueba de Documentacin y Procedimientos Prueba de Seguridad y Controles Prueba de Volumen Prueba de Esfuerzo (Stress) Prueba de recuperacin Prueba de mltiples sitios

A.- Funcionalidad Para capitalizar el trabajo hasta ahora completado, los casos de prueba de las pruebas previas realizadas pueden frecuentemente ser reorganizados y rehusados durante la prueba de sistema. No obstante, deben ser desarrollados casos de prueba adicionales para aquellos aspectos del sistema, tales como documentacin, procedimientos y desempeo que no han sido probados durante la prueba unitaria y de integracin. La prueba de sistema es compleja porque intenta validar un nmero de caractersticas al mismo tiempo, a diferencia de otras pruebas que slo se centran en uno o dos aspectos del sistema al mismo tiempo.

Tcnica: Ejecute cada caso de uso, flujo bsico o funcin utilizando datos vlidos e invlidos, para verificar que: Los resultados esperados ocurren cuando se utiliza un dato vlido. Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se utiliza un dato invlido. Cada regla de negocios es aplicada adecuadamente.

B.- Pruebas de Desempeo Objetivo de la Prueba: Validar el tiempo de respuesta para las transacciones o funciones de negocios bajo las siguientes dos condiciones: Volumen normal anticipado Volumen mximo anticipado.

Descripcin de la Prueba: Las pruebas de desempeo miden tiempos de respuesta, ndices de procesamiento de transacciones y otros requisitos sensibles al tiempo. El objetivo de las pruebas de desempeo es verificar y validar los requisitos de desempeo que se han especificado (en este caso, el desempeo ofrecido por el proponente). Las pruebas de desempeo usualmente se ejecutan varias veces, utilizando en cada una, carga diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar a la esperada en el sistema. Una segunda prueba debe hacerse utilizando una carga mxima. Adicionalmente, las pruebas de desempeo pueden ser utilizadas para perfilar y refinar el desempeo del sistema como una funcin de condiciones tales como carga o configuraciones de hardware Las principales actividades son: Comparar el desempeo del sistema actual con los requisitos, Poner a punto el sistema para mejorar las mtricas de desempeo y proyectar la capacidad futura de carga del sistema. Los objetivos de nivel de servicio definidos deben guiar la prueba de performance. Algunas caractersticas que afectan el desempeo son:

C.- Errores lgicos Procesamiento ineficiente Diseo pobre: muchas interfaces, instrucciones y entradas/salidas. Cuellos de botella en discos, CPU canales de entrada/salida Salidas del sistema Tiempos de respuesta D.- Capacidad de almacenamiento Tasa de entrada/salida de datos Nmero de transacciones que pueden ser manejadas simultneamente. Las pruebas de desempeo utilizan las tcnicas de caja blanca y caja negra. Tcnica: Utilice los procedimientos de prueba desarrollados para las pruebas del modelo del negocio (Pruebas del Sistema). Modifique archivos de datos (para incrementar el nmero de transacciones) o los scripts para incrementar el nmero de veces que ocurre cada transaccin. Los scripts deben ser ejecutados en una mquina y deben ser repetidos con mltiples clientes (virtuales o actuales). (Ver consideraciones especiales). 7.- PRUEBA DE LA CAJA NEGRA Las pruebas de caja negra se llevan a cabo sobre la interfaz del software, Obviando el comportamiento interno y la estructura del programa. Los casos de prueba de la caja negra pretenden demostrar que: Las funciones del software son operativas La entrada se acepta de forma correcta Se produce una salida correcta La integridad de la informacin externa se mantiene A continuacin se derivan conjuntos de condiciones de entrada que utilicen Todos los requisitos funcionales de un programa. Las pruebas de caja negra pretenden encontrar estos tipos de errores: Funciones incorrectas o ausentes Errores en la interfaz Errores en estructuras de datos o en accesos a bases de datos Externas Errores de rendimiento Errores de inicializacin y de terminacin Los tipos de prueba de cana negra que vamos a estudiar son: Prueba de particin equivalente Prueba de anlisis de valores lmites