INTRODUCCION El presente trabajo est basado en los principales mtodos de prueba de software.

Describe los objetivos que se persiguen al realizar la prueba y los principios de la prueba. Un producto puede probarse de acuerdo al conocimiento de la funcin especfica para la que fue diseado el producto (caja negra). Con la aplicacin de esta tcnica se adquieren pruebas que disminuyen el numero de casos de prueba. La prueba del mtodo de la caja de cristal frecuentemente es ms eficaz para descubrir errores debido a que los programas sutiles ocurren en la interfaz de subprogramas. Estrategias de prueba del software Una estrategia de prueba del software integra los mtodos de diseo de caso de pruebas del software en una serie bien planeada de pasos que desembocara en la eficaz construccin de software. La estrategia proporciona un mapa que describe los pasos que se darn como parte de la prueba indica cuando se planean y cuando se dan estos pasos, adems de cuanto esfuerzo, tiempo y recursos consumiran. Por tanto, cualquier estrategia de prueba debe incorporar la planeacin de pruebas, el diseo de caso de pruebas, la ejecucin de pruebas y la recoleccin y evolucin de los datos resultantes. Una estrategia de prueba del software debe ser lo suficionetemente flexible como para promover un enfoque perzonalizado al mismo tiempo debe ser lo adecuadamente rigido como para promover una planeacin razonable y un seguimiento administrativo del avanze del proyecto. Qu es? El software se prueba para descrubrir errores cometidos sin darse cuenta al realizar su diseo y construccin. pero como se realizan las pruebas? Debe desarrollarse un plan formal para las pruebas? debe probase el programa como un lodo o solo deben aplicarse pruebas a una parte pequena? deben volver a realizarse las pruebas ejecutadas a medida que se agregan nuevos componentes a un sitemas de gran tamano?
1

Cundo debe pedirse la participacin del cliente? Estas y muchas otras preguntas se respondern cuando desarrolle una estrategia de prueba del software. Quin lo hace? El jefe de proyecto, los ingenieros del software o los especialistas en pruebas son quienes desarrollan la estrategia para la prueba del software Por qu es importante? Con frecuencia, la prueba requiere una mayor cantidad del esfuerzo dedicado al proyecto que cualquier otra actividad de ingeniera del software. Si se realiza sin un plan, se desperdicia tiempo se dedica un esfuerzo innecesario y, aun peor, es posible que aun no se detecten errores. Por tanto la razonable seria establecer una estrategia sistemtica para probar el software Cules son los pasos? La prueba empieza por lo pequeo y avanza hacia lo grande esto significa que en las primeras etapas la prueba se concentra en un solo componente o un grupo pequeo de componentes relacionados y se aplica para descubrir errores en la lgica de datos y de procesamiento que se a encapsulado en el componente una ves probados los componentes deben integrarse hasta que todo el sistema se haya construido. En este punto se ejecuta una serie de pruebas de alto nivel para descubrir errores en la satisfaccin de los requisitos dl cliente a medida que se descubren, lo errores deben diagnosticarse y corregirse empleando un proceso llamado depuracin. Cul es producto obtenido? Una especificacin de la prueba documenta el enfoque que aplico el equipo de software a la prueba al definir un plan que detalla una estrategia general y un procedimiento que describe los pasos especficos y se darn en las pruebas que abran de realizarse. Cmo puedo estar seguro de que lo he hecho correctamente? Al revisar la especificacin de la prueba antes de realizarla se evalua si estn completos los casos y las tareas de prueba. Un plan y un procedimiento de
2

prueba efectivos llevaran a la construccin ordenada del software y al descubrimiento de errores en cada etapa de proceso de costruccion. Una estrategia global

Prueba de Unidad El proceso de verificacin se centra en la menor unidad de diseo del software. Se aplica sobre la descripcin del diseo procedimental. Usa tcnica de prueba de caja blanca. Se puede realizar en paralelo para diferentes mdulos.

mbito de Prueba La interfaz del mdulo. El impacto de los datos globales sobre el mdulo. Las estructuras de datos locales. Las condiciones lmite. Los caminos de ejecucin de la estructura de control. Los caminos de manejo de errores. Procedimiento de Prueba Para cada prueba, se debe desarrollar un software que controle y/o resguarde. Un controlador es un programa principal que acepta los datos del caso de prueba, pasa los datos al mdulo e imprime los resultados. Un resguardo es un subprograma que reemplaza a los mdulos subordinados, realiza alguna manipulacin de datos, imprime una verificacin de entrada y devuelve el control.

La prueba de Integracin Es una tcnica sistemtica para construir la estructura del programa y detectar errores asociados con la interaccin. La integracin no incremental no es recomendable. La integracin incremental puede ser descendente o ascendente. Se necesitan pruebas de regresin.

Integracin descendente

Los mdulos subordinados al mdulo de control principal se van incorporando a la estructura primero-en-profundidad, o primero en anchura. Se usa el mdulo de control principal como controlador de la prueba, disponiendo de resguardos para todos los mdulos directamente subordinados. Se sustituyen los resguardos subordinados uno a uno por los mdulos. Se llevan a cabo pruebas cada vez que se integra un mdulo. Tras terminar las pruebas se reemplaza otro resguardo con el mdulo real

Integracin Ascendente Empieza la construccin y la prueba con los mdulos atmicos eliminando la necesidad de resguardos. Se combinan los mdulos de bajo nivel en grupos que realicen una sub funcin especfica. Se escribe un controlador para coordinar la entrada y la salida de los casos de prueba. Se prueba el grupo. Se eliminan los controladores y combinan los grupos movindose hacia arriba por la estructura del programa.

Enfoque combinado

La Prueba de validacin
7

Comprueba que el software, una vez ensamblado, funciona de acuerdo con las expectativas razonables del cliente. Se satisfacen los requerimientos funcionales. Se alcanzan los requisitos de rendimiento. La documentacin es correcta e inteligible. Se alcanzan otros requerimientos (compatibilidad, recuperacin de errores...) Usa tcnicas de caja negra Revisin de la configuracin Comprobar, para todos los elementos de la configuracin del software que: se han desarrollado apropiadamente, se han catalogado, y estn suficientemente detallados para soportar la fase de mantenimiento. Pruebas alfa y Beta Son pruebas de aceptacin que permiten que el cliente valide los requisitos. Las pruebas alfa se llevan a cabo en un entorno controlado. Las pruebas beta se llevan a cabo en el lugar de trabajo del cliente. Pueden durar semanas o meses La Prueba del Sistema El objetivo es verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas. La responsabilidad es de todos los creadores de cada uno de los elementos del sistema.

Medidas Preventivas Disear caminos de manejo de errores que prueben toda la informacin procedente de otros elementos del sistema. Realizar pruebas que simulen datos en mal estado u otros problemas de la interfaz del software.
8

 Registrar los resultados de las pruebas. Participar en la planificacin y el diseo de casos de prueba Tipos de Prueba

Prueba de Recuperacin Fuerza el fallo del software de varias formas y verifica que la recuperacin se produce adecuadamente. Si la recuperacin es automtica hay que evaluar la correccin de la inicializacin, de los mecanismos de recuperacin del estado del sistema, de la recuperacin de los datos y del proceso de rearranque.
9

 Si la recuperacin no es automtica, hay que evaluar los tiempos medios de reparacin para determinar si estn dentro de unos lmites aceptables Un sistema tolerante a fallos evita que cese el funcionamiento de todo el sistema cuando se produce un fallo del proceso. Prueba de Seguridad Verifica que los mecanismos de proteccin incorporados protegern al sistema. Intenta conseguir las claves de acceso de cualquier forma. Ataca con software a medida. Bloquea el sistema. Provoca errores del sistema entrando durante su recuperacin. Un sistema que maneje informacin que pueda afectar de forma inapropiada a las personas es un posible objetivo para entradas ilegales. Prueba de resistencia Enfrenta al programa con situaciones atpicas, esto es, ejecuta el sistema de forma que demande recursos en cantidad, frecuencia o volmenes anormales. Incrementa las frecuencias de datos de entrada. Ejecuta casos que requieran el mximo de memoria. Buscar demasiados datos que residan en disco. Realiza pruebas de sensibilidad intentando descubrir combinaciones de datos dentro de una clase de entrada vlida que pueda producir inestabilidad o un proceso incorrecto Prueba de Rendimiento Prueban el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. Requiere de instrumentacin tanto software como hardware para los procesos de monitorizacin y medicin. Se lleva a cabo durante todos los pasos de prueba. Los sistemas de tiempo real y los sistemas empotrados se tienen que ajustar a los requisitos de rendimiento.

10

Tcnicas de prueba

El desarrollo de Sistemas de software implica la realizacin de una serie de actividades predispuestas a incorporar errores (en la etapa de definicin de requerimientos, de diseo, de desarrollo, ...).

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.

En este captulo estudiaremos: Fundamentos de la prueba del software, que definen los objetivos fundamentales de la fase de prueba. Diseo de casos de prueba, que se centra en un conjunto de tcnicas para que satisfagan los objetivos globales de la prueba.

1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

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.

1.1. Objetivos de la prueba

La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces Una prueba tiene xito si descubre un error no detectado hasta entonces

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
11

esfuerzo.

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

1.2. Proceso de prueba

12

El proceso de prueba tiene dos entradas: Configuracin del software: Incluye la especificacin de requisitos del software, la especificacin del diseo y el cdigo fuente Configuracin de prueba: 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: La calidad y la fiabilidad del software son aceptables, o que Las pruebas son inadecuadas para descubrir errores serios

1.3. Diseo de casos de prueba

Se trata de disear pruebas que tengan la mayor probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo y de tiempo.

Cualquier producto de ingeniera se puede probar de dos formas:

Pruebas de caja negra: Realizar pruebas de forma que se compruebe que cada funcin es operativa. Pruebas de caja blanca: Desarrollar pruebas de forma que se asegure que la operacin interna se ajusta a las especificaciones, y que todos los componentes internos se han probado de forma adecuada.

En la prueba de la caja negra, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta.

En la prueba de caja blanca se realiza un examen minucioso de los detalles procedimentales, comprobando los caminos lgicos del programa,

comprobando los bucles y condiciones, y examinado el estado del programa en varios puntos.
13

A primera vista, la prueba de caja blanca profunda nos llevara a tener "programas 100 por cien correctos", es decir: Definir todos los caminos lgicos Desarrollar casos de prueba para todos los caminos lgicos Evaluar los resultados

Pero esto supone un estudio demasiado exhaustivo, que prolongara excesivamente los planes de desarrollo del software, por lo que se har un estudio de los caminos lgicos importantes.

2. PRUEBA DE LA CAJA BLANCA

La prueba de la caja blanca es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para derivar los casos de prueba.

14

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

2.1. Prueba del camino bsico

El mtodo del camino bsico (propuesto por McCabe) 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 al menos una vez.

2.1.1. Notacin del grafo de flujo o grafo del programa

Representa el flujo de control lgico con la siguiente notacin:

15

A continuacin se muestra un ejemplo basado en un diagrama de flujo que representa la estructura de control del programa.

16

En el grafo de flujo Cada nodo representa una o ms sentencias procedimentales Un solo nodo puede corresponder a una secuencia de pasos del proceso y a una decisin Las flechas (aristas) representan el flujo de control

Cualquier representacin del diseo procedimental se puede traducir a un grafo de flujo.

Si en el diseo procedimental se utilizan condiciones compuestas, la generacin del grafo de flujo tiene que descomponer las condiciones compuestas en condiciones sencillas, tal y como muestra la figura siguiente.

17

2.1.2. Complejidad ciclomtica

Es una medida que proporciona una idea de la complejidad lgica de un programa. La complejidad ciclomtica coincide con el nmero de regiones del grafo de flujo La complejidad ciclomtica, V(G), de un grafo de flujo G, se define como V(G) = Aristas - Nodos + 2 La complejidad ciclomtica, V(G), de un grafo de flujo G, tambin se define como V(G) = Nodos de predicado + 1

A partir del grafo de flujo de la figura 4, la complejidad ciclomtica sera: Como el grafo tiene cuatro regiones, V(G) = 4 Como el grafo tiene 11 aristas y 9 nodos, V(G) = 11 - 9 - 2 = 4 Como el grafo tiene 3 nodos predicado, V(G) = 3 + 1 = 4

A partir del valor de la complejidad ciclomtica obtenemos el nmero de caminos independientes, que nos dan un valor lmite para el nmero de pruebas que tenemos que disear.

En el ejemplo, el nmero de caminos independientes es 4, y los caminos independientes son: 1-11 1-2-3-4-5-10-1-11 1-2-3-6-7-9-10-1-11 1-2-3-6-8-9-10-1-11

2.1.3. Pasos del diseo de pruebas mediante el camino bsico

Obtener el grafo de flujo, a partir del diseo o del cdigo del mdulo Obtener la complejidad ciclomtica del grafo de flujo Definir el conjunto bsico de caminos independientes Determinar los casos de prueba que permitan la ejecucin de cada uno de los caminos anteriores Ejecutar cada caso de prueba y comprobar que los resultados son los
18

esperados

2.2. Prueba de bucles

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.

Se pueden definir cuatro tipos de bucles diferentes: Bucles simples Bucles concatenados Bucles anidados Bucles no estructurados

19

2.2.1. Bucles simples

A los bucles simples (de n iteraciones) se les tiene que aplicar el conjunto de pruebas siguientes:

Saltar el bucle Pasar slo una vez por el bucle Pasar dos veces por el bucle Hacer m pasos del bucle con m < n Hacer n-1, n y n+1 pasos por el bucle

2.2.2. Bucles anidados

Si extendisemos el conjunto de pruebas de los bucles simples a los bucles anidados, el nmero de pruebas crecera geomtricamente, por lo que Beizer sugiere el siguiente conjunto de pruebas para bucles anidados:

Comenzar con el bucle ms interno, estableciendo los dems bucles a los valores mnimos Llevar a cabo las pruebas de bucles simples para el bucle ms interno, conservando los valores de iteracin de los bucles ms externos a los valores mnimos

Progresar hacia fuera en el siguiente bucle ms externo, y manteniendo los bucles ms externos a sus valores mnimos
20

Continuar hasta que se hayan probado todos los bucles

2.2.3. Bucles concatenados

Probar los bucles concatenados mediante las tcnicas de prueba para bucles simples, considerndolos como bucles independientes.

2.2.4. Bucles no estructurados

Redisear estos bucles para que se ajusten a las construcciones de la programacin estructurada.

Ejemplo

Construir el Grafo de Flujo correspondiente a la siguiente especificacin del software en LDP.

21

Solucin

22

Ejemplo

Construir el Grafo de Flujo correspondiente al siguiente cdigo de un programa

Solucin

23

3. 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 rendimento 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

3.1.

Prueba de particin equivalente

Este mtodo de prueba de caja negra divide el dominio de entrada de un programa en clases de datos, a partir de las cuales deriva los casos de prueba.

Cada una de estas clases de equivalencia representa a un conjunto de estados vlidos o invlidos para las condiciones de entrada.

24

3.1.1. Identificacin de las clases de equivalencia

Se identifican clases de equivalencia vlidas e invlidas con la siguiente tabla

Clases de equivalencia Condiciones externas Clases de equivalencia vlidas invlidas

25

A continuacin se siguen estas directrices:

Si una condicin de entrada especifica un rango de valores (p.e, entre 1 y 999), se define una CEV (1 <= valor dos CEI (valor < 1 y valor > 999) <= 999) y

Si una CE requiere un valor especfico (p.e., el primer carcter tiene que ser una letra), se define una CEV (una letra) y una CEI (no es una letra)

Si una CE especifica un conjunto de valores de entrada, se define una CEV para cada uno de los valores vlidos, y una CEI (p.e., CEV para "Moto", "Coche" y "Camin", y CEI para "Bicicleta")

Si una condicin de entrada especifica el nmero de valores (p.e., una casa puede tener uno o dos propietarios), identificar una CEV y dos CEI (0 propietarios y 3 propietarios)

3.1.2. Identificacin de casos de prueba

Seguir estos pasos Asignar un nmero nico a cada clase de equivalencia Escribir casos de prueba hasta que sean cubiertas todas las CEV, intentando cubrir en cada casos tantas CEV como sea posible Para cada CEI, escribir un caso de prueba, cubriendo en cada caso una CEI

Ejemplo Disear casos de prueba de particin equivalente para un software que capte estos datos de entrada:

Cdigo de rea: En blanco o un nmero de tres dgitos Prefijo: Nmero de tres dgitos que no comiencen por 0 1 Sufijo: Nmero de cuatro dgitos Ordenes: "Cheque", "Depsito", "Pago factura" Palabra clave: Valor alfanumrico de 6 dgitos
26