Tcnicas de prueba del software

3/23/13

Tcnicas de prueba
3/23/13
El desarrollo de Sistemas de software implica la realizacin de una serie de actividades predispuestas a incorporar errores. Debido a que estos errores se deben a nuestra habilidad innata de provocar errores, tenemos que incorporar una actividad que garantice la calidad del software. Haga clic para modificar el estilo de subttulo del patrn

Fundamentos de la prueba del software

3/23/13
La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error

En la etapa de prueba del software se crean una serie de casos de prueba que intentan "destruir" el software desarrollado.

La prueba requiere que se descarten ideas preconcebidas sobre la "calidad o correccin" del software desarrollado.

Objetivos de la prueba
3/23/13
El objetivo es disear casos de prueba que, sistemticamente, saquen a la luz diferentes clases de errores, hacindolo con la menor cantidad de tiempo y de esfuerzo.

La prueba no puede asegurar la ausencia de errores; slo puede demostrar que existen defectos en el software.

Proceso de prueba
El proceso de prueba tiene dos entradas:

3/23/13

Configuracin del software

Incluye la especificacin de requisitos del software, la especificacin del diseo y el cdigo fuente. Incluye un plan y un procedimiento de Prueba. Si el funcionamiento del software parece ser correcto y los errores encontrados son fciles de corregir, podemos concluir con que: Configuracin de prueba La calidad y la fiabilidad del software son aceptables, o que Las pruebas son inadecuadas para descubrir errores serios

Prueba Funcional
3/23/13
Es una prueba basada en la ejecucin, revisin y retroalimentacin de las funcionalidades previamente diseadas para el software. Las pruebas funcionales se hacen mediante el diseo de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informtico.

prueba de Humo Las pruebas de aceptacin Pruebas de regresin Beta de prueba Prueba Alfa

Proceso de prueba
3/23/13

A todas las pruebas se les debera poder hacer un seguimiento hasta cumplir con los requisitos del cliente Principios de las pruebas

Las pruebas deberan planificarse mucho antes de que empiecen. El principio de Pareto es aplicable a la prueba del software.

Para ser ms eficaces, las pruebas deberan ser realizadas por un equipo independiente.

Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande No son posibles las pruebas exhaustivas.

3/23/13

Las pruebas
DE LA CAJA NEGRA Se basan sobre la interfaz del software De sistema. El mtodo de la caja negra se centra en los requisitos fundamentales del software y permite obtener entradas que prueben todos los requisitos funcionales del programa.

3/23/13

DE LA CAJA BLANCA

Comprueban los caminos lgicos del software proponiendo Se puede examinar el estado del programa en varios puntos para determinar si el estado real coincide con el esperado o mencionado.

Consiste en realizar pruebas para verificar que lneas especficas de cdigo funcionan tal como esta definido. Tambin se le conoce como prueba de caja-transparente

Con este equipo de pruebas se intenta encontrar:

Funciones incorrectas o ausentes. Errores de interfaz. a Errores en estructuras de datos o en accesos a las bases de datos externas. Errores de rendimiento. Errores de inicializacin y terminacin.
3/23/13

Las pruebas de caja blanca intentan garantizar que:

Se ejecutan al menos una vez todos los caminos independientes de cada mdulo Se utilizan las decisiones en su parte verdadera y en su parte falsa Se ejecuten todos los bucles en sus lmites Se utilizan todas las estructuras de datos internas.

Prueba del camino bsico

El mtodo del camino bsico permite obtener una medida de la complejidad de un diseo procedimental, y utilizar esta medida como gua para la definicin de una serie de caminos bsicos de ejecucin, diseando casos de prueba que garanticen que cada camino se ejecuta almenos una vez.

3/23/13

Actividades de prueba de software

Actividades de desarrollo

3/23/13

Anlisis Diseo Doc. Diseo Cod. Mdulos Cd. Completo Codificacin

Doc. Requisitos

P. validacin P. integracin P. unidades

Integracin Mantenimiento

Prueba de bucles

3/23/13

Los bucles son la piedra angular de la inmensa mayora de los algoritmos implementados en software, por lo que tenemos que prestarles una atencin especial a la hora de realizar la prueba del software. La prueba de bucles es una tcnica de prueba de caja blanca que se centra en la validez de las construcciones de los bucles.

Bucles Anidados
3/23/13

Si extendiramos el enfoque de prueba de los bucles simples a los bucles anidados, el nmero de posibles pruebas aumenta geomtricamente a medida que aumenta el nivel de anidamiento

Bucles No Estructurados
Siempre que sea posible,esta clase de bucles se deben redisear para que se ajusten a las construcciones de programacin estructurada

Bucles concatenados
3/23/13

Los bucles concatenados se probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto

Mtodos de prueba basados en grafos

particin equivalente: La particin equivalente es un mtodo de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. anlisis de valores lmite: Por razones que no estn del todo claras, los errores tienden a darse ms en los lmites del campo de entrada que en el centro. prueba de comparacin: En la mayora de los casos, la comparacin de las salidas se puede llevar a cabo mediante una herramienta automtica. prueba de la tabla ortogonal: el nmero de parmetros de entrada es pequeo y los valores de cada uno de los parmetros est claramente delimitado. En cualquier caso, cuando el nmero de valores de entrada crece y el nmero de valores diferentes para cada elemento de dato se incrementa, la prueba
3/23/13

Complejidad ciclomtica
refleja directamente el nmero de caminos independientes que un programa puede tomar durante su ejecucin. Cualquier desarrollador que haya probado cdigo en su vida, sabe que la cantidad de pruebas necesarias para ejercitar un determinado lugar del cdigo es directamente proporcional a su rbol de decisiones. En otras palabras, cuantos ms caminos el cdigo puede tomar (ya sea por medio de condiciones o bucles), mayor es la cantidad de pruebas necesarias.
3/23/13

Tabla ortogonal se utiliza de la siguiente manera

Detecta y asla todos los fallos de modalidad simple Un fallo de modalidad simple es un problema que afecta a un solo parmetro. Detecta todos los fallos de modalidad doble Un problema donde estn afectados dos parmetros que intervienen conjuntamente, se llama fallo de modalidad doble Fallos multimodales Las tablas ortogonales [del tipo indicado] pueden asegurar la deteccin nicamente de fallos de modalidad simple o doble.

3/23/13

Recomendaciones Generales

Debe contarse con criterios de aceptacin previamente aprobados por el usuario No hay que olvidar validar tambin la documentacin y los procedimientos de uso (por ejemplo, mediante una auditora) Las pruebas se deben realizar en el entorno en el que se utilizar el sistema (lo que incluye al personal que lo maneja)

3/23/13