UNIVERSIDAD TECNOLGICA DEL PER FIMAAS INGENIERA DE SOFTWARE

PRUEBAS DE SOFTWARE

PRUEBAS DE SOFTWARE
Es un proceso que se utiliza para ayudar a identificar la exactitud, integridad y calidad de software desarrollado, con el objetivo de medir el grado en que el software cumpla con los requerimientos. Proporciona una vista objetiva e independiente del software para permitir que la empresa conozca y entienda los riesgos del software. Las pruebas de software, dependiendo del mtodo de anlisis empleado, puede ser implementado en cualquier momento en el proceso de desarrollo.

QUIN SE ENCARGA DE LAS PRUEBAS DE SOFTWARE?

Las pruebas tcnicas son la responsabilidad de los ingenieros de software que han desarrollado el producto. Las pruebas funcionales son la responsabilidad de los tcnicos de pruebas, que disponen de los conocimientos y aptitudes necesarios para esta tarea tan importante y especfica. En proyectos a gran escala las pruebas funcionales son la responsabilidad de un equipo de pruebas, que consiste de uno o varios tcnicos, un coordinador de pruebas y un gestor de pruebas o de calidad.

PRINCIPIOS FUNDAMENTALES
Principio 1 Principio 2 Principio 3 Principio 4 Principio 5 Principio 6 Principio 7 Las pruebas evidencian la presencia de defectos Las pruebas en forma exhaustiva es imposible Probar en fases tempranas Agrupamiento de los defectos Paradoja del Pesticida Las pruebas son dependientes del contexto La ausencia de errores

PRUEBAS MANUALES
Cualquier tipo de aplicacin se puede probar de forma manual. Pueden ser repetitivas y aburridas. El probador tiene que ser muy paciente, creativo y tiene que pensar y actuar con una perspectiva de usuario final.

PRUEBAS AUTOMATIZADAS
70% ms rpido que la prueba manual. Pronstico en resultados. Ahorra tiempo y costo. Mejora la precisin. Aumenta la eficiencia.

NIVELES DE PRUEBAS

1. 2. 3. 4.

PRUEBAS DE UNIDAD PRUEBAS DE INTEGRACIN PRUEBAS DE SISTEMA PRUEBAS DE ACEPTACIN

1. PRUEBAS DE UNIDAD
El objetivo de las pruebas de unidad es aislar pequeas partes del programa, que son responsables de permitir algunas funciones muy especficas dentro del software a desarrollar y mostrar que las partes individuales son correctas. Nos permite probar las partes internas de software que no estn normalmente expuestos directamente al usuario final, por ejemplo, a travs de una interfaz grfica de usuario o en la pantalla, y por lo tanto no se puede validar fcilmente a travs de las pruebas convencionales. Proporciona retroalimentacin temprana de los equipos de programacin y les permite hacer pequeos cambios si es necesario.

POR QU ES IMPORTANTE?

A veces, los desarrolladores de software intentan ahorrar tiempo al hacer las pruebas unitarias mnimas. Pero sucede lo contario, ello conduce a mayores costos de fijacin de defectos durante las pruebas del sistema, pruebas de integracin e incluso pruebas beta. Realizar las pruebas de unidad apropiadamente durante la etapa de desarrollo ahorra tiempo y dinero al final.

IBM RATIONAL SOFTWARE

Tiene una funcin conocida como Rational Test Realtime que incluye una gama completa de herramientas de prueba. Se utiliza para Ada, Java, C y C + +.

2. PRUEBAS DE INTEGRACIN
Es la fase donde los mdulos de software individuales de las pruebas de unidad se combinan en un componente y se prueban como un grupo, centrndose en el control de la comunicacin de datos entre estos mdulos. Los grupos progresivamente ms grandes de componentes de software probados correspondientes a los elementos del diseo arquitectnico se integran y se prueban hasta que el software funcione como un sistema.

POR QU ES IMPORTANTE?

Un mdulo, ha sido diseado por un desarrollador de software individual que la comprensin y la lgica de programacin pueden ser diferentes de otros programadores. Las pruebas de integracin se hace necesaria para verificar los mdulos de software trabajen correctamente en la unidad. Corregir errores con la base de datos de las interfaces de los mdulos e interfaces de hardware externo.

ESTRATEGIAS
ENFOQUE BIG BANG ENFOQUE ELEMENTAL
BOTTOM UP TOP DOWN

ENFOQUE BIG BANG

Todos o la mayora de los mdulos desarrollados estn integrados juntos para formar un sistema de software completo o la mayor parte del sistema y luego se usa para las pruebas de integracin. Ventajas: Conveniente para los sistemas pequeos. Es muy eficaz para ahorrar tiempo en el proceso de pruebas de integracin. Desventajas: Difcil localizacin de fallos.

ENFOQUE ELEMENTAL
BOTTOM UP
Los componentes de ms bajo nivel se prueban primero, despus se utiliza para facilitar la prueba de los componentes de ms alto nivel. El proceso se repite hasta que se prueba el componente de la parte superior de la jerarqua.

ENFOQUE ELEMENTAL
TOP DOWN
Los mdulos integrados principales son probados y la rama del mdulo se prueba paso a paso hasta el final del mdulo correspondiente.

3. PRUEBAS DE SISTEMA
Es la prueba de un producto completo y totalmente integrado de software. Las pruebas del sistema es en realidad una serie de pruebas diferentes cuyo nico propsito es hacer ejercicio todo el sistema informtico . Necesita, por regla, todos los componentes de software "integrados" que han pasado con xito las pruebas de integracin , as como el sistema de software propio integrado con cualquier sistema de hardware aplicable. Entra en el mbito de Black Box, debido implica el funcionamiento del software externo desde la perspectiva del usuario, es decir, lo opuesto a White Box.

PRUEBAS DE CAJA BLANCA

La caja transparente o caja blanca simboliza la capacidad de ver a travs de la cubierta exterior del software en su funcionamiento interno. Codificacin interna Fortalecimiento de la seguridad Mejora el diseo Puede ser bastante complejo. Una pequea aplicacin que realiza una sola operacin sencilla puede ser probado en pocos minutos, mientras que las aplicaciones de programacin ms grandes toman das o semanas.

PRUEBAS DE CAJA NEGRA

Se prueban las funcionalidades del SW desde una perspectiva de tipo externo o usuario final. Por ejemplo: un sistema operativo como Windows, un sitio web como Google o una base de datos como Oracle. Black Box slo se centrar en las entradas y salidas sin conocer su cdigo interno. Facilita la comunicacin entre los mdulos de pruebas (Pruebas de Integracin). Requiere menos habilidad tcnica, menos tiempo y menos herramientas pero solo te permite detectar errores y fallos pero no te acerca a la solucin de stos.

TIPOS DE PRUEBAS DE SISTEMA

EXISTEN MAS DE 100 TIPOS DE PRUEBAS DE SISTEMA!

PRUEBAS DE REGRESIN
El propsito de las pruebas de regresin es la confirmacin de que un programa reciente o cambio de cdigo no ha afectado negativamente a las caractersticas existentes. Las pruebas de regresin es ms que la seleccin total o parcial de los casos de prueba ya ejecutadas, que se vuelven a ejecutar para garantizar las funcionalidades existentes funcionan bien.

PRUEBAS DE RECUPERACIN
Es la actividad donde se prueba lo bien que una aplicacin es capaz de recuperarse de los fallos de software (crash) fallos de hardware y otros problemas similares. El objetivo, bsicamente es comprobar qu tan rpido y mejor la aplicacin puede recuperar en contra de cualquier tipo de error o fallo de hardware, etc. Un ejemplo sera reiniciar el sistema mientras que un navegador tiene un nmero definido de sesiones. Luego se comprueba que el navegador es capaz de recuperar todos ellos.

PRUEBAS DE SEGURIDAD
El objetivo de las pruebas de seguridad es identificar las amenazas en el sistema y medir sus posibles vulnerabilidades. Tambin ayuda en la deteccin de los posibles riesgos de seguridad en el sistema y ayudar a los desarrolladores en la fijacin de estos problemas a travs de la codificacin. En este tipo de prueba, probador juega un papel del atacante y jugar todo el sistema para encontrar los errores relacionados con la seguridad. Esta prueba de la seguridad es muy importante en la industria de TI para proteger los datos por todos los medios.

PRUEBAS ALPHA
Realizadas por un desarrollador. La fiabilidad y las pruebas de seguridad no se realizan en profundidad. Pruebas alfa requiere entorno de laboratorio o entorno de prueba.

PRUEBAS BETA
Realizadas por el usuario final. Fiabilidad, seguridad, robustez se comprueban. No requiere ningn entorno de laboratorio o ambiente de prueba. Software se pone a disposicin del pblico. Las sugerencias que se obtiene se llevar a cabo en las versiones futuras del producto.

correcciones pueden ser abordados por los desarrolladores de forma inmediata.

FASES DE PRUEBAS

PRE-ALPHA: El SW es un prototipo pero incompleto, no se publica. ALPHA: El SW est cerca de su desarrollo y se comprueban errores. BETA: El SW es estable y se libera a usuarios limitados. RC: El SW no sufre cambios radicales solo correccin de errores. RELEASE: Todo OK, el software se libera al pblico.

PRUEBAS DE SOFTWARE POR: EDUARDO ROJAS HUAMN GABRIEL OBREGN LUCIANI THX!